Flexibly Constructing Secure Groups in Antigone 2.0(cid:0) Patrick McDaniel,AtulPrakash,Jim Irrer, Sharad Mittal,Thai-ChuinThuang ElectricalEngineering and ComputerScience Department UniversityofMichigan, AnnArbor pdmcdan(cid:1) aprakash,irrer,mittals,thuang @eecs.umich.edu (cid:2) Abstract throughapolicyspecificationorimplicitlybyanimplemen- tation. Contemporarygroup communication platformsop- Groupcommunicationisincreasinglyusedasalowcost eratefromanlargelyfixedsetofpolicies. Theseimplicitly buildingblockforthedevelopmentofhighlyavailableand defined policies represent the threat and trust models ap- survivable services in dynamic environments. However, propriateforasetoftargetenvironments. However,anap- contemporary frameworks often provide limited facilities plication and session whose security requirements are not for the definition and enforcementof precise security poli- directlyaddressedbytheframeworkmustimplementaddi- cies. This paperpresents the Antigone 2.0 frameworkthat tional infrastructureor modify their security model. Thus, allows the flexible specification and enforcement of group theseapplicationswouldbenefitfromframeworksallowing securitypolicies. Enforcementisachievedthroughthepol- theexplicitdefinition,distribution,andsubsequentenforce- icy directed composition and configuration of sets of ba- mentofsecuritypoliciesappropritatefortheruntimeenvi- sic security services implementing the group. We summa- ronment. rize the design of the Antigone 2.0 architecture, its use, In this paper we describe the design and use of the andtheApplicationProgrammingInterface(API).Theuse Antigone 2.0 system. Antigone provides flexible inter- of the API is illustrated through two applications built on facesforthedefinitionandimplementationofsecuritypoli- Antigone; a reliable multicast system and host level mul- ciesthroughthecomposition and configurationofsecurity ticast security service. We conclude with a description of mechanisms. Thesetofservicesandprotocolsusedtoim- currentstatusandplansforfuturework. plementthegroupisdevelopedfroma systematicanalysis ofthepropertiesappropriateforagivensessioninconjunc- tion with operational conditions and participant require- 1 Introduction ments.Theresultingsessiondefiningpolicyisdistributedto allgroupparticipantsandenforceduniformlyateachhost. Group communication is increasingly used as an efficient In Antigone, we define a group policy as the specifica- building block for distributed systems. However, the cost tionofallsecurityrelevantpropertiesofthesession. Thus, and complexity of providing properties such as reliability, agrouppolicystateshowsecuritydirectsbehavior,theen- survivability, and security within a group is significantly tities allowed to participate, and the mechanisms used to higher than in peer communication. These costs are due achieve security objectives. This view of policy affords a totheadditionalnumberoffailuremodes,heterogeneityof greaterdegreeofcoordinationthanfoundinextantsystems; thegroupmembers,andtheincreasedvulnerabilitytocom- statementsofauthorizationandaccesscontrol,keymanage- promise.Becauseofthesefactors,itisimportanttoidentify ment, data security, and other aspects of the group are de- preciselythepropertiesappropriateforaparticularsession. finedwithinasingleunifyingpolicy. Thepropertiesrequiredbyasessionaredefinedthrough Policyhasbeenusedindifferentcontextsasavehiclefor a group policy. Policy may be stated either explicitly representingauthorizationandaccesscontrol[4,7,33,28], (cid:3) Thiswork is supported in part by the Defense Advanced Research peersessionsecurity[35],qualityofserviceguarantees[6], ProjectsAgency(DARPA)andAirForceResearchLaboratory,AirForce and network configuration [31]. These approaches define MaterielCommand,USAF,underagreementnumberF30602-00-2-0508. a policy language or schema appropriate for their target TheU.S.Governmentisauthorizedtoreproduceanddistributereprintsfor Governmentalpurposesnotwithstandinganycopyrightannotationthereon. problemdomain. Antigoneexpandsonthisworkbydefin- Theviewsandconclusionscontainedhereinarethoseoftheauthorsand ing an approach in which policy is used to provision and shouldnotbeinterpretedasnecessarilyrepresentingtheofficialpolicies regulate the services supporting communication. Further- orendorsements, eitherexpressedorimplied, oftheDefenseAdvanced more, group participants can determine the compliance of ResearchProjectsAgency(DARPA),theAirForceResearchLaboratory, ortheU.S.Government. thegroupdefinitionwithlocalrequirements. 2 Architecture Recent systems have adopted a more flexible definition of security policy. For example, the Security Policy Sys- tem [35] provides interfaces for the flexible definition of This section presents a brief overviewof the Antigone 2.0 security policies for IPSec [18] connections. These poli- system. The following subsection describes the Antigone cies specify precisely the kinds of security mechanisms to system model. The remaining subsections describe the appliedtopeersession. Similarly,theGSAKMP[14]pro- Antigone architecture and policy specification language. tocoldefinesapolicytokendefiningthespecificsofagroup This section is not intended to providean exhaustivetuto- session. The policy token is an exhaustive data structure rialonAntigone,butonlytointroduceitsmodelanddesign. (containingover150fields)statingpreciselythekindsofse- SignificantdetailabouttheAntigone2.0systemanditspre- curityforagivengroupsession. Grouppropertiesofautho- decessorscanbefoundin[21,20,19]. rization,accesscontrol,datasecurity,andkeymanagement are defined precisely through the token. However, while 2.1 Systemmodel thesesystemsprovideagreatdealofflexibilityindefining policy, the range of supported mechanisms and policies is Depicted in Figure 1, an Antigone group is modeled as largely fixed. Thus, addressing unforeseen or exceptional the collection of participants collaborating towards a set securitydemandsrequiresadditionalapplicationinfrastruc- of shared goals. We assume the existence of a policy is- ture. suer with the authority to state session requirements. The issuerstatestheconditionalrequirementsoffuturesessions TheDCCM[9]systemdevelopedbyBranstadet.al. al- throughthegrouppolicy. Adherenceofagrouppolicytoa lows the definition of flexible policies through Crypto- setofcorrectnessprinciples(describinglegalsecuritypoli- graphicContextNegotiationTemplates(CCNT).Eachtem- cies) is assessed through the analysis algorithm. A group platedefinesthetypesandsemanticsoftheavailablemech- policy is issued only if the analysis algorithm determines anisms and parameters of a system. A principal aspect of thatthepolicyconformstotheseprinciples. the DCCM project is its use of policy as entirely defining Eachparticipantstatesitssetoflocalrequirementsonfu- thecontextinwhichagroupoperates. Policymaybenego- turesession througha localpolicy. Each participanttrusts tiatedorstatedbyaninitiatingmember,andflexiblemech- the issuer to create a group policy consistent with session anisms for policy representation and interpretation are de- objectives. However, a participant can verify a policy in- fined. A DCCMpolicyfocusesonthemechanismsimple- stance meets the requirements stated in their local policy menting group security services; authorization and access throughthecompliancealgorithm.Failureofthegrouppol- control is defined independently of the derived group pol- icytocomplytothelocalpolicycanresultinthemodifica- icy. tion of the local policy or the abstention of the participant fromthesession. Mechanism composition has long been used as a build- An initiator is an entity that generates a policyinstance ing block for distributed systems [25, 26, 2, 3, 11, 24]. fromgroupandlocalpolicies. Theserviceusedtoacquire Composition-basedframeworksspecifythecompileorrun- localpoliciespriortoreconciliationisoutsidethescopeof time organizationof sets of protocols and services usedto thecurrentwork. Weviewthisserviceaspartofthesession implement a communication service. The resulting soft- announcement protocol [12], but may revisit this decision ware addresses the requirements of each session. How- inthefuture. Aninstanceistheresultofthereconciliation ever, the definition and synchronization of specifications of the group and local policies within the run-time envi- is largely relegated to system administrators and develop- ronment. Throughreconciliation,aninstanceidentifiesrel- ers. Our approach seeks to extend compositional systems evant session requirements, and defines how requirements bydefininganarchitectureandlanguageinwhichsecurity aremapped intoaconfiguration. Theinitiatoris trustedto requirementsareconsistentlymappedintoasystemconfig- evaluatethegroupandlocalpoliciescorrectly. uration. Currently,Antigonedoesnotprovideaninteractivepol- icynegotiationprotocol. However,eachparticipantdefines The remainder of this paper is as follows. The follow- therangeofacceptablepoliciesthroughthierlocalpolicies. ing section gives a brief overview of the Antigone group Reconciliationattemptstofindainstancethatiscompliant model,policyspecificationlanguage,andarchitecture.Sec- with each local policy(see Section 2.4). Hence, Antigone tion 3 describes the Antigone Applications Programming providesimplicitnegotiationthroughtheevaluationoflocal Interface(API).Section4 demonstratestheuseoftheAPI policies. We intend to investigatethe extentionof the rec- in two demonstrative applications. Section 5 considers a onciliationprocesstoaninteractiveprotocolinthefuture. numberofworksrelatingtothemanagementofgrouppoli- Apolicyinstancedefinesthesessionconfiguration(pro- cies. WeconcludeinSection6. visioning) and the rules used for authorization and access Initiator(cid:13) Participant(cid:13) evaluation. In this case, the group is disbanded and re- initializedunderanewlyestablishedinstance. Reconciliation(cid:13) Participant(cid:13) Antigoneprovidesend-to-endgroupsecurityservice. In (cid:6)+(cid:13) this, each participant acts as a policy enforcement point . . .(cid:13) (PEP). Note that while many environments may benefit from the introduction of other non-participant PEPs (e.g., Participant(cid:13) Policy Issuer(cid:13) policy gateways, IPSec tunnels, etc.), we view these fea- (cid:5)Compliance(cid:13) turesasorthogonaltothecurrentwork. However,weplan (cid:7)Analysis(cid:13) (cid:6)+(cid:13) torevisitthisdecisionasAntigonematuresandmoreenvi- ronmentalrequirementsbecomeapparent. (cid:4)Group Policy(cid:13) Local Policy(cid:13) Policy Instance(cid:13) Figure1: SystemModel-Asessionisacollectionofpar- ticipantscollaboratingtowardssomesetofsharedgoals. A 2.2 AntigoneArchitecture policyissuerstatesagrouppolicyasasetofrequirements appropriate for future sessions. The group and expected Described in Fig. 2, the Antigone architecture consists of participantlocalpoliciesarereconciledtoarriveatapolicy four components; the group interface layer, the mecha- instancestatingaconcretesetofrequirementsandconfigu- nism layer, the policy engine, and the broadcast transport rations. Priortojoiningthegroup, eachparticipantchecks layer. The group interface layer arbitrates communica- complianceoftheinstancewithitslocalpolicy. tion between the application and lower layers of Antigone through a simple message oriented API (a brief overview ofthisAPIisgiveninSection3.1). Grouprelevantactions suchasjoin, send, receive,andleaveareprovidedthrough control. Provisioningofagroupidentifiesthebasicsecurity simple C++ object methods. These actions are translated requirementsandthemappingofthoserequirementsintoa intoeventsdeliveredtotheotherlayersofAntigone. Group configurationofsecurity-relatedservicesormechanismsat events(e.g.,messagereceived)arepolledbytheapplication membersites. Authorizationandaccesscontrolstatements throughtheAPI. definehowsessionsregulateactionwithinthegroup. Participant software is modeled as collections of secu- Themechanismlayerprovidesasetofmechanismsused ritymechanisms.Eachmechanismprovidesadistinctcom- to implement security policies. The mechanisms and con- municationservicethatisconfiguredtoaddresssessionre- figuration to be used in a session are defined by the pol- quirements.Associatedwithamechanismisasetofconfig- icyinstance. WhiletheAntigoneimplementationcurrently urationparametersusedtodirectitsoperation. Aninstance provides a suite of mechanisms appropriate for many en- defines precisely the set of mechanisms and configuration vironments, new mechanisms can be developed and inte- used to implement the session. For example, a data secu- grated with Antigone easily. Note that mechanisms need ritymechanismimplementstransformsthatenforcecontent notonlyprovidesecurityservices;otherrelevantfunctions security policies (e.g., message confidentiality, integrity, (e.g., auditing, failure detection and recovery, replication) source authentication). The data security mechanism con- can be implemented through Antigone mechanisms. For figurationidentifieswhichtransformsareusedtosecureap- example, the current implementation implements a novel plicationmessages(seeSection3.2). securecrashfailuredetectionmechanism[20]. Similar to other secure group communication frame- The policy engine directs the configuration and opera- works [13], the distribution of the policyinstanceis a two tionofmechanismsthroughtheevaluationofpolicies(i.e., phase process. Potential group participants mutually au- reconciliation and compliance checking). Initially, as di- thenticatethemselveswiththeinitiator(howauthentication rected bythe policyinstance, the policyengine provisions is performed is determined by the instance). The instance themechanismlayerbyinitializingandconfiguringtheap- is distributed following authentication only if the initiator propriate software mechanisms. Subsequently, the policy determinesthatthe participanthastheright to viewpolicy engine governs protected action through the evaluation of (asdetermined bytheinstanceaccesscontrolpolicy). The authorizationandaccesscontrolpolicy. memberjoinsthegroupifthereceivedinstanceiscompliant The broadcast transport layer defines a single abstrac- withitslocalpolicy. tionforunreliablegroupcommunication. Duetoanumber Note that because the instance defines the policy used of economic and technological issues, multicast is not yet throughoutthelifetimeofthegroup,nofurtherpolicysyn- globallyavailable.Thus,whereneeded,Antigoneemulates chronization is necessary. However, as described in [19], amulticastchannelusingtheavailablenetworkresourcesin specialized reconfig events can trigger the policy re- thetransportlayer. Application(cid:13) ;(cid:13) (cid:8)Antigone Group Interface(cid:13) Mechanisms Layer(cid:13) ...(cid:13) M(cid:13) M(cid:13) M(cid:13) M(cid:13) Policy(cid:13) 1(cid:13) 2(cid:13) 3(cid:13) n(cid:13) Engine(cid:13) Antigone Broadcast Transport Layer(cid:13) UDP/Multicast/IP(cid:13) Figure2: Antigoneconsistsoffourcomponents;thegroupinterfacelayer,themechanismlayer,thepolicyengine,andthe broadcast transport layer. The group interface layer arbitrates communication between the application and lower layers of AntigonethroughasimplemessageorientedAPI.Themechanismlayerprovidesasetsoftwareservicesusedtoimplement securegroups. Thepolicyenginedirectstheconfigurationandoperationofmechanismsthroughtheevaluationofgroupand localpolicies. Thebroadcasttransportlayerprovidesasinglegroupcommunicationabstractionsupportingvaryingnetwork environments. 2.3 PolicyLanguage less than 100 members. Conditionals form a logical con- junction, where all conditionals must evaluate to true for Each group and local policy is explicitly stated through the clause to satisfied. If a clause is satisfied, then the a policy specification. The prototype Ismene Policy De- consequences are applied to the policy. In this example, scription Language (IPDL) defines the format and seman- if a manager is present and the group will contain less ticofthesespecifications. Ismeneisasubsystemsdefining than 100 members, the LKHKeyMnger mechanism will a grammar and algorithms for the process of policy deter- be used with the identified configuration (i.e., rekeyOn- miniationandanalysis[19]. Join=trueandrekeyOnLeave=true). An IPDL policy is defined through a totally ordered set In the event the first clause is not satisfied, the second ofclauses,wheretheorderingisimplicitlydefinedbytheir clauseisconsulted. Thissecondclauserepresentsadefault occurrence in the specification. Each clause is defined by policy; because itdoesnot containanyconditions, it isal- a tuple of tags, conditions, and consequences. Conditions wayssatisfied. Thus,wherethefirstclauseisnotsatisfied, testsomemeasurableaspectoftheoperatingenvironment, the group falls back to a default Key-Encrypting-Key[15] group membership, or presence of credentials. Conse- keymanagementpolicy. However,ifthefirstclauseissat- quencesdefinewhatpoliciesaretobeappliedtothegroup. isfied,thesecondclauseisignored. Tagsprovidestructuretothespecificationbydirectlydefin- The data handling clause illustrates the use of the ingtherelationsbetweensub-policies. pick consequence. Pick consequences afford the initia- Figure 3 presents a subset of clauses from a typical tor flexibility in developing the session. Semantically, the group policy. The following example describes how a pickstatementindicatesthatexactlyoneconfigurationmust provisioning policy is derived from these clauses. The be selected. In the example, pick is used to state flexi- key management clauses identify several key manage- ble policy; either DES or AES can be used to implement ment policies appropriate for different operating environ- confidentiality, but not both or neither. The reconciliation ments. Initially, the initiator evaluatesthe conditionals as- process assesses the group and local policies to determine sociated with the first key management clause. The the mostdesirable configuration in the pick statement(see GroupIncludes conditional tests whether a manager is Section2.4below). expectedtoparticipateinthegroup. TheGroupSmaller Authorizationandaccesscontrolareperformedafterthe conditional tests whether the expected group will contain group has been provisioned. Typically, the evaluation of % Key Management Provisioning key management: GroupIncludes(Manager), GroupSmaller(100) :: Config( LKHKeyMnger(rekeyOnJoin=true,rekeyOnLeave=true) ); key management: :: Config( KEKKeyMnger(rekeytimer=300) ); % Data Handling Provisioning data handling: :: Pick( Config(adhdlr(conf=des)), Config(adhdlr(conf=aes)) ); % Join Authorization and Access Control join: Credential(Role=Manager,IssuedBy=$Trusted CA) :: accept; join: Credential(Role=SoftwareDesigner,IssuedBy=$TrustedCA) :: accept; Figure3: AsubsetofclausesdefineforanexampleIPDLgrouppolicy. authorizationrequeststestthepresenceofcredentialsprov- 2.5 Implementing Policy ing a members right to perform some action (e.g., join Inter-component communication in Antigone is event the group). The simple join rules defined in Figure 3 based. Theobservationofa securityrelevanteventbyany state that any member who presents credentials issued by componentistranslatedintoaneventobject. Wherepolicy a trusted CA delegating the right to act as a Manager or decisionisrequired,thiseventispostedtothepolicyengine SoftwareDesigner will be permitted into the group. eventqueue.If,basedonthepolicyinstance,theenginede- Note that through the use of conditionals, a large number termines that further processing is warranted, the event is ofcomplexauthorizationandaccesscontrolmodelsmaybe postedtotheappropriatelayerorapplication. defined. For example, consider an application wishing to broad- castamessagetothegroup.Theapplicationinitiallymakes the SendMessage() API call (see Section3.1) with the datatobesent.Themechanismlayertranslatesthiscallinto 2.4 Reconciliation a SEND event, which is posted to the policy engine event queue. Thepolicyenginechecksthepolicyinstance, local Thegrouppolicyisreconciledwiththelocalpoliciesofthe credentials, and operational conditions to determine if the expected participants to arrive at a concrete configuration. applicationhastherighttosendcontenttothegroup1. Thus,reconciliationdetermineswhichrequirementsarerel- Ifpermitted,theSENDeventispostedtothemechanisms evanttoasession,andultimatelyhowthesessionisimple- layer. The mechanisms layer allows each mechanism to mented. Ismene group policies are authoritative; all con- processtheevent.Inprocessingtheevent,theDataSecurity figurations and pick statements used to define the instance mechanism will perform a transform designed to provide mustbeexplicitlystatedinthegrouppolicy.Localpolicies theprovisioneddatasecurityguarantees(e.g.,confidential- areconsultedonlywhereflexibilityisexpresslygrantedby ity). The result is broadcast to the group via the transport theissuerthroughpickstatements. layer. Reconciliation is the process by which configurations Uponreceptionofthemessage,otherparticipantstrans- frompick statementsinthegrouppolicyareselected. The late the receivedmessageintoa RECV eventand postitto selection process is guided by the configuration and pick their local policy engine. The right of the sender to trans- statements inthe local policies. Reconciliationappears on mitdatawillbeassessedwithrespecttotheaccesscontrol first viewingto be intractable. However,by restricting the policydefinedintheinstance.Ifadmitted,thereversetrans- structureandcontentsofIPDLpolicies,onecandevelopan formis performed bytheData Securitymechanism onthe efficientreconciliationstrategy. [22]formulatestherecon- receiveddata. Once the original content is recovered, it is ciliationproblemandconsidersthecomplexityofthemost deliveredtotheapplication. generalcase. Severalstrategiesareproposedandanalyzed. Notethattheprocessingofasingleeventmaytriggerthe ThisanalysisleadtotheefficientPrioritizedPolicyRecon- 1Consultingauthorizationandaccesscontrolpolicy oneachrelevant ciliation(PPR)algorithmusedbytheAntigoneimplemen- actionmayseriouslyaffectperformance. Antigonemitigatesthesecosts tation. byevaluatingnotonlyactionacceptanceordenial,butalsotheconditions For brevity, we have omitted many details of the IPDL underwhichtheresultshouldcontinuetobeconsideredvalid(i.e.,invari- antresult,timedvalidityresult,transientresult). Therefore,authorization construction,algorithms,anduse. Interestedreadersarere- andaccesscontrolpoliciesneedonlybeconsultedwhenavalidprevious ferredto [19,22]. resultisunavailable. enforcementofmanypolicies. Forexample,aNEW PAR- apcc determines if any possible instance resulting from TICIPANTevent(representinganewlyadmittedmember) reconciliation violates this assertion (i.e., the instance de- may requirethe initiation ofsession rekeying,the creation finesanLKHmechanism,butnotenforceanexplicitleave ofnewprocessmonitoringtimers(forfailuredetectionand policy). Theuseriswarnedofanysuchpossibleviolation. recovery[20]),etc. Theenforcementofeachofthesepoli- Inaddition, policieswhich are irreconcilable (i.e., policies ciesmayleadtothegenerationofotherevents(e.g.,INIT which,duetotheirconstruction,willalwayscausetherec- REKEY),authorizationandaccesscontroldecisions,and/or onciliationalgorithmtofail)areidentified. sessiontraffic. Once policies have been created, they can be stored in AcentralgoalofIsmene(andAntigone)istheeasyinte- any available repository. For example, an LDAP [34] ser- grationofadditionalservicesandconditionals. Tothisend, vicecanbeusedtostoreandretrievegroupandlocalpoli- Antigone provides simple APIs for the creation of condi- cies. Thisapproachisusefulwherethelocaldomainwishes tionals, mechanisms, and configurations. Developers cre- to enforce a set of security policies for all applications, or ate new mechanisms by constructing objects conforming whereusersdonothavethedesireorsophisticationtostate to the AMechanism API. Developer stated unique iden- policy. Notethatwhilethestorageandretrievalofpolicies tifiers (defining the mechanism and its configurations) can is outside the scope of Antigone, each policy is evaluated beaddedtoIDPLpolicies,andaresubsequentlyusedasany byAntigone for freshness, integrity,and authenticity prior othermechanism. toitsuse. Application or mechanism specific conditionals can be implemented throughtheAPolicyImplementor inter- 3 Applications Programming face.APolicyImplementorobjectsdefineoneormore conditionals to be used by Ismene. The unique identi- Interface fiersassociatedwiththeseconditionalscanbeimmediately added to IDPL policies. Ismene performs an upcall to The Antigone API abstracts group operations into a small the implementor object upon encountering a defined con- set of message oriented interfaces. Conceptually, an ap- ditional. The object is required to evaluatetheconditional plication need only provide group addressing information andreturnitsresult. andsecuritypoliciesappropriatefortheapplication(seebelow). Once the group interface is created, the application cantransmitandreceivemessagesasneeded. 2.6 PolicyCreation The current implementation of Antigone consists of ap- Central to the security of any application is the definition proximately30,000linesofC++sourceandhasbeenused ofapplicationpolicies. Eachapplication,environment,and as the basis for several non-trivial group applications (see hostcanhaveuniquerequirementsandabilitieswhichmust next section). All source code and documentation for the bereflectedinthelocalandgrouppolicies. Theapcctool AntigonePolicyDescriptionlanguage,theAntigoneframe- isusedtoassessAntigonepolicieswithrespecttothesere- work,andapplicationsarefreelyavailable.Thesixlibraries quirements. comprisingAntigonearedescribedinFigure4. apcc is a policycompiler; group and local policies are The Antigone API separates group operation from the assessedtoensurea)thepolicyhasthecorrectsyntax(i.e., broadcast medium. This separation is reflected in the conforms the to the policy language grammar), and b) is AGroup(AntigoneGroup)andATransport(AntigoneTrans- consistentwithasetofusersuppliedassertions(whichde- port)APIs. Thefollowingsubsectionsgiveanoverviewof fine the correct usage principles discussed in Section 2). thedesign,implementation,andinterfacesoftheselibraries. Anypolicyspecificationnotconformingtothepolicygram- Interestedreadersarereferredto[19]forfurtherdetail. marisrejectedbyapcc. Figure5presentsasimpleexampleapplicationusingthe Policyassertionsdefinethecorrectusageoftheunderly- AntigoneAPIs. Theapplicationcreatesagroupobjectfora ingsecurity mechanisms; dependencies and incompatibili- serverifinvokedwithnoparameters,oraclientifinvoked tiesbetweendifferentmechanismsareidentified.Forexam- with the name of the server host. Each process sends one ple,thefollowingassertionidentifiesadependencybetween messageandreceivesallapplicationdataarrivingwithin60 securitymechanisms; seconds.Alllinenumberscitedinthefollowingsubsections refertothisexample. assert: config(lkhkeymgt()) :: config(membership(leave=explicit)); 3.1 AntigoneGroup API This assertion states that all systems implementing a Log- ical Key Hierarchy [30, 32] must also implement explicit TheAGroupobjectservesasaconduitforallcommunica- (member) leaves. The analysis algorithm implemented by tion between an application and the group. After this ob- Directory Name Description atk Toolkit basicsetofobjectsimplementingbasicdataandstructures(e.g.,queues,timers, strings, )andcryptographicfunctions(e.g.,keys,hashfunctions,digitalcer- (cid:9)(cid:10)(cid:9)(cid:11)(cid:9) tificates, )usedbytheotherlibraries. (cid:9)(cid:11)(cid:9)(cid:11)(cid:9) atrans TransportLayer interfaces for an abstract broadcast channel in varying network environments. ThisembodiestheentiretyofthetransportlibrarydescribedinSubsection3.2. amech MechanismLayer abstractinterfacesandclassesuponwhichspecificsecuregroupmechanismsare built,coordinatestheoperationofmechanismsasdirectedbythepolicyinstance. mechs Mechanisms collectionofmechanismsdefiningtheservicesunderwhichagroupcanbecon- structed.Policiesareenforcedusingthesebasicservices. apdl PolicyDescription providesinterfacesforthedefinitionandevaluationofpolicies.Thelexicalana- Language lyzerandallpolicyalgorithmsareimplementedinthislibrary. agrp Group-MainAPI AntigoneApplicationsProgrammingInterfaceforsecuregroups. Applications communicatewithAntigonethroughthisAPIdirectly. Figure4: AntigoneComponentLibraries #include 1 #include 2 int main (int argc, char **argv) { // usage: simple [ host_name_of_server ] 3 if (getenv ("NAME") == NULL) setenv ("NAME", "unknown", 1); // set up id 4 5 AGroup *group; // group object, policy files 6 String locPol = "local.apd", grpPol = "example.apd", polList = ""; 7 8 // Setup the transport layer address - multicast address and port 9 IPAddress *groupIp = IPAddress::IPAddressFactory("224.1.1.27", 9000); 10 // specify server and port (argv[1] is the host name of the server) 11 IPAddress *serverIp = 12 IPAddress::IPAddressFactory(argc==1?"224.1.1.27":argv[1], 9001); 13 // Construct transport layer 14 ATransport *transport = 15 new ATransport(groupIp, serverIp->Port(), ATransport::AT_SYMMETRIC); 16 17 if (argc == 1) // server constructor for group - 5 parameters 18 group = new AGroup(transport, grpPol, locPol, polList, NULL); 19 else // client constructor for group - only 3 parameters 20 group = new AGroup(transport, locPol, NULL); 21 (void)group->Connect(); 22 23 // Set up a buffer and send it 24 String msg; 25 msg.sprintf ("Hello World from %s\n", getenv("NAME")); 26 Buffer *buf = new Buffer(); 27 (*buf) << msg; 28 group->sendMessage(buf); 29 30 AtkTimer timer(60 * 1000); timer.reset(); // wait for up to 60 seconds 31 while (group->readMessage(&buf, &timer)) { // read messages from group 32 (*buf) >> msg; // extract message from buffer 33 cout << " Received: " << (char*)msg; // print message 34 delete buf; 35 } 36 group->Quit(); // Leave, shutdown interface to the group 37 exit (0); 38 } 39 Figure5: ExampleApplication % File : example.apd % File : local.apd % Description : Example Antigone Group Policy % Description : Example Antigone Local Policy % Attributes Section issr:= < iQBVAw ... >; issr:= < iQBVAw ... >; % Requirements % Provisioning Section provision: :: authentication, data_security; provision: :: authentication, membership, authentication: :: config(OpenSSL()); keymgmt, datmgmt; data_security: :: config(adhdlr(guar=conf)); authentication: :: config(OpenSSL()); membership: :: config(amember(retry=3)); % No local policy regarding access control keymgmt: :: config(lkhkey(sens=memsens)); join: :: accept; rekey: :: accept; datmgmt: :: config(adhdlr(guar=conf,conf=desx)), send: :: accept; leave: :: accept; config(adhdlr(guar=intg,intg=md5)); % Authorization/Access Control Policies Figure7: ExampleLocalPolicy init: Credential(&cert,iss=$issr, subj.CN=$joiner) :: accept; join: Credential(&cert,iss=$issr,fs=$fsys, subj.CN=$joiner) :: accept; jects allow Antigone to reduce the cost and simplify mes- rekey: Credential(&key,key=$lkhKey) :: accept; sagememorymanagement,translatebetweenhardwareand send: Credential(&key,key=$sessKey) :: accept; operatingsystemplatforms,andoptimizemessageprocess- eject: Credential(&key,key=$sessKey) :: accept; leave: :: accept; ing(e.g.,reducebuffercopying). TheinterfacetothegroupisshutdownthroughtheQuit % Policy Verification APIcall.Thiscallexitsfromthegroup(explicitlysendinga signature := < sdD5aR ... >; leavemessageasdictatedbypolicy),destroyssensitivein- formation(e.g.,keys,messages), andcleansupallinternal Figure6: ExampleGroupPolicy data. An example policy appropriate for the above application is presented in Figure 6. This policy states a ba- jectiscreated(seebelow),alltransmissionsandreceptions, sic set of mechanisms are to be configured for the group; state changes, and status probing are performed through an OpenSSL mechanism for authentication, the Antigone AGroupmembermethods. Thethreephasesofagroupob- imember membership management mechanism, a Log- jectinclude: initialization,operation,andshutdown. ical Key Hierarchy key distribution mechanism, and the adhdlr data handler mechanism. The key management TheinitializationofanAGroupobjectrequiresthemem- mechanism is configured to rekey after each membership ber specify the appropriate policies and supply a transport change (e.g., member join or leave). The data handler object(lines21and23inFigure5). Theserverconstructor mechanism is configured to provide confidentiality by en- (line21)suppliesgroupandlocalpolicieswhicharerecon- cryptingallapplicationtrafficusingDESX,andtoprovide ciled to arrive at the session defining policy instance. Al- integritythrough keyedHMACsgenerated using the MD5 though not used in the example, the polList parameter hashalgorithm.Theauthorizationandaccesscontrolmodel identifies the list of local policies to be considered by the for the group states that an appropriate certificate must be reconciliation algorithm. The client constructor (line 23) presented to gain access to the group, and that subsequent suppliesitslocalpolicyanddefers totheserverforthein- actionispredicatedonproofofknowledgeoftheappropri- stance. The Connect call (line 24) initializes the proper atesessionorkeymanagementkeys. interfaces,joinsthegroup,andretrievesorderives(through AnexamplelocalpolicyispresentedinFigure7.Thislo- the reconciliation algorithm) the policy instance. Failures calpolicystatesthatthelocalentitywillonlyparticipatein (either at the transportorgroup layers) generatean excep- groupsthatenforceapolicyrequiringOpenSSLauthentica- tion. tionandwhichprovideconfidentialityofapplicationtraffic. Subsequent sending, receiving, and processing of the Thelocalpolicystatesnorequirementsforgroupauthoriza- messagesduringoperationisachievedthroughanAPIsim- tion (i.e., the local member accepts any authorization and ilar to Berkeley Sockets [29] (e.g., sendMessage - line accesscontrolmodeldefinedbythegrouppolicy). 31, readMessage-line34). sendMessagesendsand eventuallydeletesbuffers.readMessagecreatesabuffer object for each incoming message. The Buffer object 3.2 AntigoneBroadcast Transport Layer simplifies the tasks of memory management and message marshaling. Buffer objects handle translations between Multicast services have yet to become globally available. machine bit formats, automatically resize as needed, and As such, dependence on multicast would likely limit the maintainaninternalheapofmessagestructures. Theseob- usefulness of Antigone. Through the broadcast transport layer,Antigoneimplementsasinglegroupcommunication Application(cid:13) abstraction supporting environments with varying network resources. Applications identify at run time the level of multicast supported by the network infrastructure. This (cid:12)SRM(cid:13) Reliable Transport Layer(cid:13) specification, called a broadcast transport mode, is subse- FEC(cid:13) quentlyusedtodirectthedeliveryofgroupmessages. The broadcasttransportlayerimplementsthreetransportmodes: Antigone(cid:13) symmetricmulticast,point-to-point,andasymmetricmulti- cast. Thesymmetric multicast mode uses multicast to deliver Figure8: ReliableTransportLayer all messages. Applications using this mode assume com- plete, bi-directional multicast connectivity between group members. In effect, there is no logical differencebetween thisalikelycandidateforfutureuse. thismodeanddirectmulticast. The transport API requires the application supply the The point-to-point transport mode emulates a multicast multicastorunicastaddressinginformationappropriatefor group using point-to-point communication. All messages theenvironmentandtransportmode.IPaddressesarespec- intendedforthegroupareunicasttothesessionleader,and ified through the creation of encapsulating IPAddress relayedtogroupmembersviaUDP/IP.Aseachmessageis objects (lines 11, 15). These objects and the enumerated transmittedbythesessionleadertomembersindependently, transport mode are passed to the constructor (line 18) of bandwidth costs increase linearly with group size. This thetransportobjectconstructor,whichisultimatelypassed approach represents a simplified Overlay Network, where to the AGroup object upon its construction (lines 21 and broadcast channels are emulated over point to point com- 23). The transportobject is not directly accessed after be- munication. We note that a number of techniques can be ing passed to the AGroup object; all communication with usedtovastlyreducethecostsourimplementation[17].We thegroupisperformedthroughtheAGroupobject. plan to investigate these and other approaches in the near future. In[1],wedescribeourexperienceswiththedeployment 4 Applications oftheSecureDistributedVirtualConferencing(SDVC)application. This video-conferencing application isbased on This section briefly describes the use of Antigone in two anearlyversionofAntigone. Thedeployedsystemwasto applications: a reliablebroadcastlayer andansecuremul- securely transmit video and audio of the September 1998 ticastlayerusedtoaugmentexistinggroupapplications. A Internet 2 Member Meeting using a symmetric multicast number of other applications (such as a streaming media service. The receivers (group members) were distributed and filesystem mirroring service) havebeen developedus- atseveralinstitutionsacrosstheUnitedStates. Whilesome ingAntigone. Forbrevity,weomittheirdiscussion. ofthereceiverswereabletogainaccesstothevideostream, others were not. It wasdetermined that the network could 4.1 Reliable Transport Layer delivermulticastpacketstowardsthereceivers(groupmem- bers), but multicast traffic in the reverse direction was not The Reliable Transport Layer (RTL) providesFIFO deliv- consistentlyavailable(towardsthesessionleader).Thelack ery of application traffic delivered by an Antigone group. of bi-directional connectivity was attributed to limitations Depicted in Figure 8, RTL uses a combinationof Forward ofthereverseroutingofmulticastpackets. Wepresentsig- ErrorCorrection(FEC)andtheapproachusedintheScal- nificanttechnicaldetailofthisissuein[1]. ableReliableMulticast(SRM)protocol [10]todetectand The limited availability of bi-directional multicast on recoverfromlostpackets.Amechanismimplementingeach the Internet coupled with the costs of point-to-point mul- approachislayeredbetweentheapplicationandAntigone. ticastemulationleadustointroduceasymmetricmulticast. The FEC mechanismuses a modified version of the ap- Thismodeallowsformessagesemanatingfromthesession proachdescribedin [27]. Inourimplementation,FECpro- leader to be multicast, and allother message to be relayed ducesanadditional redundantpacketsforeach original (cid:13) (cid:14) through the session leader via unicast. Members unicast packets.All packetsaretransmittedtothegroup. Be- (cid:14)(cid:16)(cid:15)(cid:17)(cid:13) each group message directly to the session leader, and the cause of the properties of packet construction, all original sessionleaderretransmitsthemessagetothegroupviamul- packets can be recovered from any packets. However, (cid:14) ticast. Thus, we reduce the costsassociated with point-to- a receiver encountering or more losses cannot recover. (cid:13) pointgroupemulationtoaunicastfollowedbyamulticast. Where enabled, these failures are repaired using the SRM The increasing popularity of single source multicast make mechanism. The SRM mechanism implements the general approach implementedbyScalableReliable Multicast protocol. Re- (cid:18)Application(cid:13) ceivers detecting a lost packet broadcast a retransmission request to the group. Sender implosion is avoided by ran- domly delaying the retranmission request. To simplify, all (cid:19)socket_s(cid:13) receiverssuppressrequestscorrespondingtopreviouslyre- Library(cid:13) questedpackets. Ifnosuchrequestisobservedpriortothe expiration of a random interval, the request is broadcast. Thisapproachcaneffectivelyprovidefullreliabledatade- Antigone(cid:13) livery.However,theFECmechanismcanbeusedtoreduce 2.0(cid:13) thenumberofretransmissionrequests. (cid:21)User Space(cid:13) Based on policy, an application can select either FEC, SRM, or both. Furthermore, policy can be used to pa- (cid:20)Kernel(cid:13) rameterize their operation based on administrative consid- erations and operating conditions. For example, the FEC IP Stack(cid:13) mechanism may wish to increase redundancy (e.g., larger values for ) where observed loss rates are high, and de- (cid:13) creaseredundancywhereratesarelow. NotetheRTMpol- icy can be specified directly in the Antigone group pol- Figure9:TheSocket sLibraryactsasa“bumpinthestack” icy. RTM probes Antigone for the appropriate configura- byredirectingallmulticasttraffictowardstheAntigonein- tionduring itsinitialization, and appealsto theapplication terfaces. fordirectionwhereaconfigurationisnotspecified. socket s call receives and sends all Antigone specific 4.2 End-Host Security communication (Authorization requests, Rekey messages, etc..). The thread establishes a local connection with the The proliferation of group multicast applications (e.g., parent application. Data received from the (Antigone) VIC[23])hasraisedawarenessoftheneedforsecuremulti- group is directed to the application through the local con- castservices. However,re-architectingapplicationstotake nection.Theparentprocessreceivesthisdatafromthelocal advantage of security services is often difficult. Thus, it connectionaswithanynormalsocket. ishighlydesirabletousetheend-host(transport)levelser- ThekeyinterfacestoSocket sinclude: vicesforsecurity.Towardsthisend,wehavedevelopedthe Socket s library. Socket s redirects multicast traffic socket s : creates a “socket” endpoint for com- (cid:22) toauser-spaceinstantiationofAntigone. Existingapplica- munication. If the desired socket is of the type tions can integrate with Antigone with only minor source SOCK DGRAM (UDP), it initializes an Antigone codemodificationthroughthislibrary. group object and returns a “socket” filehandle. Note Illustrated in Figure 9, the Socket s library acts as a that(un-secured)unicastsocketscanbecreatedbyac- “bump in stack” by inserting Antigone between the appli- cessingthelibcsocketcall. cationandthestandardnetworkinterfaces. Eachsocketre- latedcallintheapplicationisreplacedwiththeappropriate (cid:22) bind s: creates and initializes an AntigoneTransport Socket s call. For example, each bind call is replaced object(seeSection3.2)usingthesuppliedaddressand withbind s. The“ s”callsdirectmulticastrelatedtraffic portnumber. towardsAntigone,andnon-multicasttraffictothestandard setsockopt s : set socket parameters. The following library. (cid:22) twosocketoptionsarecurrentlysupported: Local policies are managed at the host level; configuration and policy files are placed in a well-known directory, – IP MULTICAST LOOP - enables/disables local and are accessed by Socket s as needed. Each domain hostmulticastloopback has a known session leader who initiates and maintains – IP ADD MEMBERSHIP - joins the Antigone groupsforeachactivesessionoccurringwithinitsadminis- groupasdescribedabove trativescope. Theidentityandlocationthesessionleaderis configuredateachhost. sendto s: sendamessagetothemulticastgroup. The (cid:22) Users initiate communication with an Antigone group hostnetwork address andmessage dataistransmitted through the socket s and setsockopt s (IGMP using Antigone sendMessage interface (see Sec- join [8]) calls. A background thread created during the tion3.1).

Flexibly Constructing Secure Groups in Antigone 2.0

Similar Flexibly Constructing Secure Groups in Antigone 2.0