Flexibly Constructing Secure Groups in Antigone 2.0

13 Pages·2001·0.08 MB·English

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(seebe-
low). 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 <stdlib.h>
1
#include <AGroup.h>
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 applica-
tion 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)ap-
plication. 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; configura-
tion 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).