ࡱ> kmj _bjbj .xW+XX8,<3Oe{{{VtT,=3?3?3?3?3?3?3$T68bc3zVVzzc3{{x3z{{=3z=3}02{Tf51)3303M1\X9fpX902X92 "Xc3c33zzzzX9X a: G E N I Global Environment for Network Innovations GENI Security Architecture Spiral 3 Security Design Report Document ID: GENI-SEC-ARCH-Design-Report-Spiral3 March 29th, 2011 Prepared by: Stephen Schwab SPARTA, Inc. Security Policy Security Guidelines and Policies (Adam Slagell) Reviewed, commented and discussed the Legal, Law Enforcement and Regulatory Responsibilities of GENI Constituents document prepared by Adam Slagell. This document lays out a strategy for reducing unnecessary questions directed at GENI operators by ensuring that a range of questions that deal with the swamp of legal replies to DCMA takedowns or other law enforcement inquiries dont become a nuisance or negative for GENI deployments. Rather, GENI will pro-actively set up the personnel and relationships so that these sorts of issues can be forwarded to a GENI LLR representative who facilitates efficiently connecting the right organizations and POCs with access to the requested information with the inquiring party. Ultimately, GENI governance needs to address how much responsibility for these sorts of activities fall on the campus deployments vs. is taken on by an umbrella GENI body. But initially, the campus deployments are the visible elements of GENI, and so responses must be handled by these edge organizations, not by a central GENI entity. This is not unlike the Internet, where there is no Internet authority that in practice can respond to specific requests, but rather ISPs and DNS registrars, as well as hosting facilities and web and content hosting services that have grown up above the Internet infrastructure. GENI might also consider the role of ICANN in the Internet, as a policy body, but clearly that is a very long-term issue and would only become relevant if long-lived GENI experiments transitioned to become services that became more than prototypes supporting researchers. Security Mechanisms This section covers issues of Identification, Authentication/Authorization, Access Control and other low level mechanisms that should be relatively uniform and pervasive across the GENI architecture. All control frameworks and aggregate managers should have some degree of common notions for these security mechanisms, even if they are implemented in different (even initially incompatible) ways. Discussed and prepared plan for incorporation of ABAC distributed trust management into GENI control frameworks, focused on ProtoGENI and ORCA. We incorporate this plan here, for deliverables and contractual purposes. We acknowledge the contributions of all authors and participants to the ABAC in GENI authorization group listed on the separate paper, including Rob Ricci, Jeff Chase, Ted Faber and Tom Mitchell, in developing input and written material for this section. Introduction This is an initial sketch of the next steps towards getting an Authorization in GENI strategy worked out for the GENI AM API. The basic idea is to indicate what ProtoGENI and ORCA each need to use ABAC as the authorization approach within GENI, and then to roughly schedule the order of analysis, development, integration and test deployment activities to make this happen. High Level Strategy Write document laying out design & implementation plan (Steve Schwab, remainder of this document) Present Plan & Schedule at GEC 10 (Steve Schwab and Ted Faber) Seek community feedback and consensus at GEC10 (all authors) Test and field integration with ProtoGENI in the GPO lab (ProtoGENI, GPO, ISI, SPARTA) and independently with ORCA (ORCA/BEN, other cluster projects.) Basic Approach Two control frameworks will be integrating ABAC assertions into their implementations as an authorization scheme for GENI. ProtoGENI and ORCA will each execute a plan to use attributes for authorization. ProtoGENI will adopt ABAC credentials as a second format on the wire, using the current libabac implementation available from ISI (HYPERLINK "http://abac.deterlab.net"http://abac.deterlab.net). Under this approach, an implementation may pass ABAC credentials as an alternative to the current native ProtoGENI credentials. Authorization calls will be made on the server side to the libabac engine to verify that credential assertions satisfy the policy required to authorize (affirmatively permit) the requested operation to be invoked. During a transition period, both native and ABAC credentials will be supported, to assess usability and maturity of implementations. ORCA will adopt ABAC credentials in a manner consistent with the Slice-Based Facility Architecture abstractions. In particular, ORCA will leverage the owner, delegateOwner and speaksFor attributes in a stylized fashion to encode ownership over a resource and delegation of specific or collections of rights to manipulate or invoke operations that are mediated by ABAC authorization checks. Detailed Plans ProtoGENI with ABAC: Concept of Operations Use of a single round of ABAC negotiations as the default supported case for the immediate future. Defer use of multiple round negotiations until required by a GENI use case. Multiple round negotiations are primary useful to protect sensitive attributes from disclosure in settings where privacy is a requirement. Users acquire ABAC credentials to use ProtoGENI sketch out life cycle, end-to-end process. Which assertions are generated by client tool, user registry, or slice authority? AMs get a default/prototypical AM policy from ProtoGENI sketch out this policy, and how it will be maintained and distributed. All participants must come to an agreement on the set of assertions the standard vocabulary -- to be used for the local default AM policy. (ProtoGENI/ISI/SPARTA will craft a workable AM policy as a starting point..) Generate and agree on the ABAC assertions for users and slices to permit operations at the local AM. (A one-to-one policy mapping between attributes and API calls is the simplest candidate. More complex policies, such as one encoding the current GENI authorization semantics within ABAC are defined in a related GENI Rules in ABAC document by Ted Faber and John Wroclawski.) AMs may tailor the AM policy to reflect local policy issues. For example, certain pools of components within the aggregate may be reserved for local classes or research projects. Such a policy could be expressed by reference to explicit local attributes. ABAC supports multiple sources of user assertions (credentials) as well as multiple sources of AM (provider side) policies. It is the union of all credentials that determines the outcome of an authorization check as valid or not valid. Security Binding Property, as an abstraction to introduce, define and discuss further. For ProtoGENI, only the ID associated with the credentials (ABAC assertions) can use those assertions to invoke an operation. ORCA may take a less restrictive view on this, to be discussed further under an expanded ORCA Concept of Operations. Discuss long-term plans, including the possibility of adopting a dual-credential scheme, or transitioning to exclusive use of ABAC. [DEFERRED FOR FUTURE DISCUSSION] ABAC and InCommon/Shibboleth interoperation could be achieved using identity portals. The near-term approach articulated in this document defers discussion on this topic, but the design and implementation will be undertaken with awareness of this branch of work, to ensure the long-term ability to leverage these additional sources of attributes is not precluded. ProtoGENI development, integration and deployment Development task: tool for specifying AM policy (version 0.1 [GEC10]; version 1.0 [GEC11]) Development task: tool for examining AM policy (version 0.1 [GEC10]; version 1.0 [GEC11]) Development task: standalone tool for specifying User assertions (version 0.1 [GEC10]; version 0.5 [GEC10 + 2 months]) Integration task: integrate tool functionality for specifying User assertions into clients (omni, others) (version 1.0 [GEC11]) Test Use Case: Perl wrapped libabac sample code (ISI, [GEC10]) PG tests directory select test cases for create slice, create slivers on a slice, etc. to figure out what we need to adapt for PG + ABAC test cases Analysis task: Build, run, evaluate current libabac sample test cases in environment similar to ProtoGENI (PG, [GEC10]) Analysis task: How does a client determine that ABAC assertions are accepted at an AM? (Do we need a credential versions accepted call?) Analysis task: Inside the Slice Authority, ProtoGENIs older Emulab code makes calls to local_root() to verify authority to create a slice. How will this call/policy check be accommodated when using the libabac implementation? (PG, SPARTA [GEC10]) Analysis task: The current ProtoGENI credentials use a complex two level mapping scheme from privileges to types to operations. Replace with a one-to-one ABAC asserted privilege to API-level fine-grained policy basically, if a user has the privilege, they may invoke that API-level call. (ISI [GEC10]) Integration task: Modify ProtoGENI AM sources to invoke libabac for authorization checks. (PG, ISI, SPARTA) Development task: Need to work out how to scope to include the object identifier, e.g. slice ID or other specific ID within an ABAC assertion. (version 0.1 [GEC10] Implementation approach is to use attribute name-space overloading with RT0 initially; version 1.0 [GEC10 + 2 months] libabac implementation extended to support single explicit parameter. Note: we believe we only need support for a single RT1 parameter, which should accelerate implementation.) (ISI, SPARTA) Development task: Assertions have lifetimes (credential timeouts). ProtoGENI needs to be concerned with assertion lifetime and how to support certification revocation lists (CRLs) at the rate of about 1 CRL update / 24 hour period. (PG, [GEC11]) Development task: Additional Tool: ProtoGENI flash clients parse the current native credentials in XML format. We need to create a webservice (to be run over the network, or better yet, locally) that will convert ABAC-encoded-credentials into renderable XML so the flash clients (and any other similar client) can parse-and-display via a call on the webservice. (ISI, SPARTA, [GEC10 + 3 months] Lab Test Case: GPO lab to build, configure, exercise end-to-end user-slice creation lifecycle using ABAC authorization scheme as-integrated in PG. Field Test Case: GPO lab as a source of third party user assertions and third party AM policy assertions. ORCA with ABAC: Concept of Operations Basic ABAC definitions: Subjects have attributes. Possession of an attribute says the subject is a member of a set associated with some role. Subjects may empower servers to act in their behalf, by delegating attributes to those servers. Attributes are asserted by attribute roots. Any entity can be a root for its own name space. Objects have attributes. An authorization policy for an object may consider these attributes. One attribute that an object may have is an object name. Subject attributes may have a single parameter: an object name. An authorization policy for an object may filter on the subject parameter. When a subject attempts to operate on an object, an authorization policy determines if the operation is permitted. The authorization policy may consider attributes of the subject, the object and any relevant ABAC inference rules. The policy knows the sources of those attributes and inference rules (i.e., the roots), and it considers those as well. GENI Semantics: The subjects are users (experimenters) and operators, and software operating on their behalf. Objects are slices. There are one or more IdPs that authenticate users and operators and endorse their public keys. IdPs issue GENI credentials to subjects. IdPs act as ABAC roots: GENI credentials are ABAC credentials. Users create slices, or request them to be created. The entity that approves slices is called an SA. Users become owners of their slices. Owners may delegate ownership privileges on their slices to other users or groups. Users request resources for their slices from AMs. AMs assign resources to slices. An assignment of resources to a slice is called a sliver. AMs advertise themselves and their resources to one or more clearinghouses. Users may request a clearinghouse to identify suitable AMs, and resources available through those AMs. Instantiation of a slice: User obtains GENI credentials from one or more IdPs. User requests SA to create a slice. The SA assigns a name S to the created slice, and endorses it, (e.g., issues SliceID.) The SliceID may include attributes of the slice, (e.g., "SA says this is a GENI slice".) The SA issues an ownership attribute for the slice, "SA.owner(S)<--user". User requests AM to create a sliver for slice S, and assign resources to it. User requests a ticket for resources at AM. User requests the AM to create the sliver, passing the ticket, if any. ORCA specific abstractions: Users act through slice managers (SMs). A user may use ABAC to delegate some or all of its attributes to an SM that is speaking for that user. AMs may delegate to CHs some of their power to assign resources to slices. The tickets may be requested from a broker/CH. This is a policy decision point: the broker/CH may consider user credentials, generally the same credentials that an AM might require. The CH must be pre-empowered by the AM to issue the ticket. This occurs outside of ABAC, using SHARP ticket delegation. Additional Notes ORCA (GENI) credentials may (will) be retrieved from a number of different services, including an identity Portal, or idP, that the user authenticates to at their institution. They may use any identity or authentication scheme, including ones administered by their local campus, to retrieve these credentials. Attributes associated with an ABAC identity may be made in credentials (assertions) provided by any source of such attributes whether internal to the GENI eco-system or an external source. Users may collect and forward sets of these credentials as required to gain access to specific AMs or slices. User credentials (attributes), and not slice credentials or attributes, are the sole means for the requestor (subject) of an operation to provide input the authorization check. (This authorization check may be referred to as the policy decision point, or PDP, in the ORCA design documentation.) AMs and Slices will be the primary objects on which operations are invoked, and hence against which authorization checks will be performed. In practice, this means that ABAC authorization policies will seek to establish whether a set of credentials entails the possession of a specific attribute (right or privilege) relative to an AM or slice, but the root of this authorization policy namespace will typically be neither the AM or slice, but the SA. (Delegation will be used by the AMs policy to grant the SA the ability to assert these types of policies.) Hierarchical attribute delegation is subsumed by the more general ORCA (SHARP)ticket delegation abstraction. (ORCAs ticket mechanisms are strictly more powerful than ABAC assertions, in that the mechanism may be used to delegate claims on resources that go beyond authorization policy to include resource management decisions.) The owner of an ORCA slice may delegate (via ABAC assertions) the rights to perform a subset of operations on that slice to another ORCA principal. Authorization points (PDP points) in ORCA must be configured with the list of anchors roots in ABAC that are trusted and permitted to issue credentials with attributes about ORCA requestors (subjects). ORCA development, integration and deployment Analysis: Build and install libabac for use in the ORCA development environment. Analysis: Determine how to call libabac from Java. Development: Modify SM to act as an SA: generate a self-signed SliceID credential for each new slice. Development: Modify SM to act as an SA: generate a slice ownership cert for the user. Development: Modify SM to tack credentials onto requests as a property. Integration: Modify AM to call libabac to validate credentials passed with request. Trial Deployment: Configure libabac on AM with suitable anchors and inference rules for authorization policies. Development: Modify AM to call libabac to check request and credentials against authorization policy. Development: Enhance error logs to handle authorization failures, and possible retry. A brief discussion of the Identity Portals concept for exporting Shibboleth attributes, based on ideas from Jeff Chase, the Shibboleth/In Commons projects and software coordinated through Ken Klingenstein is included here. Basically, ABAC does not specifically base its decisions on the source of an attribute a priori, such as a few selected roots-of-trust, but rather on the policy statements of the authorizing party (the AM or control framework in GENI), sometimes referred to as the policy decision point (PDP) or relying party. This flexibility does not mean that any attribute can be attested to by any entity with a key in the system, and have equal weight. Policies dictate which attributes will be acted upon as true/valid/legitimate when signed (spoken, attested to) by different entities or actors in the GENI system. One particularly useful source of attributes is Shibboleth and the In Commons federation used by a large consortium of higher education institutions. For their users, which may include all students, faculty and staff at the institution, Shibboleth is relied upon to provide attributes for web services while limiting and controlling propagation of those attributes, or permanent storage of those attributes. This prevents reuse in other contexts, or for arbitrary, potentially unauthorized, uses. Such restrictions are especially important where student personally identifying information might be conjoined with specific attributes that might allow inferences. For GENI, the Shibboleth Identity Providers may be bridged into the rest of the control frameworks by introducing the notion of Identify Portals. These portals would explicitly be authorized to convert ephemeral attributes available only for the scope or lifetime of a web services session into ABAC-style attributes that could have longer lifetimes and be passed around or for consumption by GENI control frameworks and AMs. ORCA in particular may prototype this strategy, although if successful, such attributes could be used by any part of GENI that incorporates them into its policy. A key issue is deciding exactly which entitys signature or signatures will be used to sign these Identity Portal attributes. Miscellaneous Security Several other projects with security requirements in Spiral 3 will be contacted and their GENI projects included in subsequent reports. We note that we have already been in communication with these projects. Million Node GENI /SecureUpdates (Justin Cappos) securing updates of software in GENI components is essential to maintaining security properties of the system once it is deployed. We will review these mechanisms and their use within the architecture in the full-year report. Enterprise GENI (Rob Sherwood, Nick McKeown, Guru Parulkar, Guido Appenzeller) In email exchanges with Rob Sherwood, we determined that new versions of Enterprise GENI flowvisor software was being released, and that there were appropriate hooks in that software for making calls to an external authorization engine. Potentially, this could be ABAC or another distributed authorization framework. However, we have not had a chance to review the overall flowvisor software to ensure that ABAC attribute credentials can readily be integrated into the system in a manner that will allow requests to pass a set of appropriate ABAC credentials to be used in a subsequent enforcement checks. Subsequent to the integration, deployment and demonstration of usability of ProtoGENI with ABAC, we should prove-out the end-to-end mechanisms to carry ABAC attributes from experimenter tools where they are selected, through the control framework for slice provisioning and deployment, to flowvisor enforcement at the aggregate manager (AM) level. Hive Mind (Sean Peisert, Stephen Templeton, Justin Cummins/Matt Bishop) In email and teleconferences with the Hive Mind project, as well as in their project overview report, we gained an understanding of their Swarm Intelligence (ant-like) approach to security monitoring that may be particularly attractive within the GENI project. While the Hive Mind approach is still being prototyped, the basic idea of using a dynamic approach to managing the deployment of sensors at differing rates and differing data-collection/sharing strategies across GENI would seem to be sound. The prototype supports rapid deployment of different sensors, which may be useful for quickly adapting the framework to monitoring different deployments of aggregates with novel resources as they are added to GENI. One potentially attractive idea to explore in future years of this effort is whether the ants/primitive sensors can seamlessly cross from the control plane (control framework/aggregate manager/component) level to the experiment plane where experiments that provide long-lived services to Internet/GENI end-users (not necessarily researchers) will be deployed. Monitoring the control plane is relatively easier in GENI because of the limited rate at which new components will be introduced. However, these sensors, and other traditional IDS approaches, would potentially be blind to activities going on within an experiment. Initially this is not a security issue, but as experiments transition from private, short-lived runs on the GENI infrastructure to longer-lived service oriented deployment experiments, the need to provide an easy way to monitor them will become more important. It is unreasonable to ask each GENI experimenter to develop their own security monitoring framework, but it might be relatively easy to adapt existing sensors in Hive Mind to provide some information about activities, such as API calls or new clients invoking services, within each experiment. Such information would then be propagated to other parts of the Hive Mind system, and potentially used to trigger security alerts at higher levels, providing visibility inside experiments in a lightweight, non-interfering manner.      PAGE \* MERGEFORMAT 2 359:WoqŸq`R`DR6h>CJOJQJ^JaJhUwCJOJQJ^JaJhotCJOJQJ^JaJ h>h>CJOJQJ^JaJ ho3h>CJ OJQJ^JaJ hot5CJ$OJQJ\^JaJ$&ho3h>5CJ$OJQJ\^JaJ$ h>5CJ$OJQJ\^JaJ$ho3h>OJQJ^J ho3h>CJOJQJ^JaJ&ho3h>5CJ0OJPJQJ\aJ0*ho3h>5CJ0OJPJQJ\^JaJ0345Ppq$a$gd> 7 8 ()gd^ & F gd^gdUw$a$gd>  ) 5 7 8  '(.N!"qr%*пؿؿÿذппЌЌ{h*Gh^6h5h^0Jjh^Uh Ph^CJOJQJaJ h^5hSh^5h =h^5 h Ph&h PhUwh< hQ5h^h!h&h#h>OJQJ^Jho3h>OJQJ^Jh>OJQJ^J.=|"$O8 !!E##V%X%Y%%%B&& & Fgd^ & Fgd^gd^ & Fgd^*9>GH"O.$>$Y%%%1-1D1E1y2z233O4\444 5 5d8~8::::<<<3E4EaEoHqH¶¶˜¶ڑrh{eh^CJOJQJaJhSh^5hkAh^5 hkAh^hkAh^CJOJQJaJh7Zh^CJOJQJaJh^CJOJQJaJhkAh^5CJOJQJaJhgh^6 h^5hagh^5 h*Gh Ph*Gh^6h^ h^6+&9'x'(() *=++-}.0011-1z234F66$77d89:< & Fgd^gd^gd^ & Fgd^<<<>1?X@BCeD3E4EaEEEMFFFAGGHoHpHqHKKFN & Fgd^gd^ & Fgd^gd^gd^qHzHHHHHHHHHIKKMENFNQQ(Q)Q8QOQfQQQ RRR(R)RSS S,S.S:ShUwh^h P4FNGNQQ)QQSS^SWW___________$a$gd~& & FgdK,7^gd&Uj & Fgd&^gdia & FgdiagdUw & F gd^______________hK,7h~&mHnHuh~&jh~&UjhS;GUhS;G ____ & FgdK,7,1h/ =!"#$% b 0002 0@P`p2( 0@P`p 0@P`p 0@P`p 0@P`p 0@P`p 0@P`p8XV~PJ_HmH nH sH tH D`D >NormalCJPJ_HaJmH sH tH ^@^ ^ Heading 1$<@&"5CJ KH OJPJQJ\^JaJ DA`D Default Paragraph FontRiR  Table Normal4 l4a (k (No List f@f ^ List Paragraphd^m$CJOJPJQJ^JaJ6U@6 ^0 Hyperlink >*B*phHZ@H ^0 Plain TextCJOJPJQJ^JaJN!N ^0Plain Text CharCJOJPJQJ^JaJV1V ^Heading 1 Char"5CJ KH OJPJQJ\^JaJ 4B4 ~&Header  H$:/Q: ~& Header Char CJPJaJ4 @b4 ~&0Footer  H$:/q: ~&0 Footer Char CJPJaJPK![Content_Types].xmlj0Eжr(΢Iw},-j4 wP-t#bΙ{UTU^hd}㨫)*1P' ^W0)T9<l#$yi};~@(Hu* Dנz/0ǰ $ X3aZ,D0j~3߶b~i>3\`?/[G\!-Rk.sԻ..a濭?PK!֧6 _rels/.relsj0 }Q%v/C/}(h"O = C?hv=Ʌ%[xp{۵_Pѣ<1H0ORBdJE4b$q_6LR7`0̞O,En7Lib/SeеPK!kytheme/theme/themeManager.xml M @}w7c(EbˮCAǠҟ7՛K Y, e.|,H,lxɴIsQ}#Ր ֵ+!,^$j=GW)E+& 8PK!Ptheme/theme/theme1.xmlYOo6w toc'vuر-MniP@I}úama[إ4:lЯGRX^6؊>$ !)O^rC$y@/yH*񄴽)޵߻UDb`}"qۋJחX^)I`nEp)liV[]1M<OP6r=zgbIguSebORD۫qu gZo~ٺlAplxpT0+[}`jzAV2Fi@qv֬5\|ʜ̭NleXdsjcs7f W+Ն7`g ȘJj|h(KD- dXiJ؇(x$( :;˹! I_TS 1?E??ZBΪmU/?~xY'y5g&΋/ɋ>GMGeD3Vq%'#q$8K)fw9:ĵ x}rxwr:\TZaG*y8IjbRc|XŻǿI u3KGnD1NIBs RuK>V.EL+M2#'fi ~V vl{u8zH *:(W☕ ~JTe\O*tHGHY}KNP*ݾ˦TѼ9/#A7qZ$*c?qUnwN%Oi4 =3ڗP 1Pm \\9Mؓ2aD];Yt\[x]}Wr|]g- eW )6-rCSj id DЇAΜIqbJ#x꺃 6k#ASh&ʌt(Q%p%m&]caSl=X\P1Mh9MVdDAaVB[݈fJíP|8 քAV^f Hn- "d>znNJ ة>b&2vKyϼD:,AGm\nziÙ.uχYC6OMf3or$5NHT[XF64T,ќM0E)`#5XY`פ;%1U٥m;R>QD DcpU'&LE/pm%]8firS4d 7y\`JnίI R3U~7+׸#m qBiDi*L69mY&iHE=(K&N!V.KeLDĕ{D vEꦚdeNƟe(MN9ߜR6&3(a/DUz<{ˊYȳV)9Z[4^n5!J?Q3eBoCM m<.vpIYfZY_p[=al-Y}Nc͙ŋ4vfavl'SA8|*u{-ߟ0%M07%<ҍPK! ѐ'theme/theme/_rels/themeManager.xml.relsM 0wooӺ&݈Э5 6?$Q ,.aic21h:qm@RN;d`o7gK(M&$R(.1r'JЊT8V"AȻHu}|$b{P8g/]QAsم(#L[PK-![Content_Types].xmlPK-!֧6 +_rels/.relsPK-!kytheme/theme/themeManager.xmlPK-!Ptheme/theme/theme1.xmlPK-! ѐ' theme/theme/_rels/themeManager.xml.relsPK] Wx ***-*qH__0358:&<FN__124679;qWX $&-!8@0(  B S  ? _Toc178827001 _Toc176220177 _Toc176220262 _Toc178827002 _Toc176220178 _Toc176220263 _Toc176220179 _Toc176220264 _Toc178827004 _Toc17882700733::qW 22255Wf0t,!WW>*urn:schemas-microsoft-com:office:smarttags PersonName @t% FM%nu,9>G$-hqIRU^YbU\< C p y ?!J!Q!W!l!v!!!'"0"V#_#u#|#$$%%&&' 'p'z'''----. .00$1+1219111D5G5}====&>-> ??]?d??? JJAKIKKKLLNNNNWWWWWWWWWWWWWW`OWWWWWWWWWWWWWWWWW`OWW pR9*M%;,,&v@"o5*7wd 4(4ALf tl&WtNuxh8%^`o(.^`.pL^p`L.@ ^@ `.^`.L^`L.^`.^`.PL^P`L.^`OJPJQJ^Jo(n^`OJ QJ ^J o(hHopp^p`OJQJo(hH@ @ ^@ `OJQJo(hH^`OJ QJ ^J o(hHo^`OJQJo(hH^`OJQJo(hH^`OJ QJ ^J o(hHoPP^P`OJQJo(hH^`o(.^`.pL^p`L.@ ^@ `.^`.L^`L.^`.^`.PL^P`L.^`o(. ^`hH. pL^p`LhH. @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PL^P`LhH.^`o(.^`.pL^p`L.@ ^@ `.^`.L^`L.^`.^`.PL^P`L.^`OJPJQJ^Jo(^`OJ QJ ^J o(o p^p`OJQJo( @ ^@ `OJQJo(^`OJ QJ ^J o(o ^`OJQJo( ^`OJQJo(^`OJ QJ ^J o(o P^P`OJQJo(^`OJPJQJ^Jo(^`OJ QJ ^J o(hHopp^p`OJQJo(hH@ @ ^@ `OJQJo(hH^`OJ QJ ^J o(hHo^`OJQJo(hH^`OJQJo(hH^`OJ QJ ^J o(hHoPP^P`OJQJo(hH^`o(.^`.pL^p`L.@ ^@ `.^`.L^`L.^`.^`.PL^P`L.^`o(.^`.pL^p`L.@ ^@ `.^`.L^`L.^`.^`.PL^P`L. *M%tlWtNuAL;,,&xwd 4p"o5* v~        |        v~                 v~        r^                          v~        |!,,K,78e76>S;G P4U&UjuUwia<&+Q(9F^F I>ot~&WW@WW!WWWx@Unknown G* Times New Roman5Symbol3. * Arial;SimSun[SO7.{ @Calibri; Batang7K@Cambria9=  K @Consolas;Wingdings?= * Courier NewA BCambria Math"1hs&i J , J ,!4WW2qHX?>2! xxStephen SchwabStephen Schwab0         Oh+'0d   , 8DLT\Stephen SchwabNormalStephen Schwab14Microsoft Office Word@2!@zkI'@7E  J՜.+,D՜.+,8 hp  SPARTA, Inc.,W  Title 8@ _PID_HLINKSAl@http://abac.deterlab.net/  !"#$%&'()*+,-./0123456789:;<>?@ABCDEFGHIJKLMNOPQRSTUVWXY[\]^_`acdefghilRoot Entry F^Tn1Table=9WordDocument.xSummaryInformation(ZDocumentSummaryInformation8bCompObjy  F'Microsoft Office Word 97-2003 Document MSWordDocWord.Document.89q