Naftaly Minsky Rutgers University

1. Law-Governed Interaction: a Decentralized Access-Control Mechanism Naftaly Minsky Rutgers University

2. outline • The challenges. • The concept of law-governed interaction (LGI), and how it meets these challenges. • An example: flexible regulation of dynamic coalitions. • Conclusion: The release of LGI.

3. The Challenges Facing Access Control • The distributed and open nature of systems, and their large scale. • The need for more sophisticated policies, which may be statful (sensitive to the history of interaction), and proactive (not limited to permission/prohibition.) • The need for communal (rather than server-centric) policies, such as: • different servers subject to the same enterprise-wide policy • P2P communities • The need for interoperation between different policies, and for “conformance hierarchies” (e.g., in virtual enterprises) • The real challenge is to meet all the above needs, via a single mechanism, and to do it scalably.

4. Server-Centric Access-Control (AC) server Reference Monitor(RM) It generally supports only stateless, purely reactive, ACL-based policies, enhanced with RBAC—and this is far from sufficient.

5. delegate The communal policy may be that certain type of transactions need to be monitores… Enforcing a Communal AC Policy Enterprise-wide (communal) policy P Enterprise

6. The Concept of Law-Governed Interaction (LGI) • LGI is a message exchange mechanism that enables a community of distributed agents to interact under an explicit and strictly enforced policy, called the “law” of this community. • Some characteristics of LGI: • A communal, rather than server-centric, control. • High expressive power, including stateful and proactive laws—which is sensitive to roles (in much more general manner than RBAC) • Laws can be written either in prolog, or in Java • Incremental deployment, and efficient execution • A single system may have a multitude of interrelated laws, which may interoperate, and be hierarchically organized. • Enforcement is decentralized---for scalability.

7. v u m ==> x m P m’ m ==> y y x I S Reference monitor Legend: P---Explicit statement of a policy. I---Policy interpreter S---the interaction state of the community Centralized Enforcement of Communal Policies * The problems: potential congestion, and single point of failure * Replication does not help, if S changes rapidly enough

8. m ==> y m m v u L L I L I L m ==> y y Su Sy I x I Sx S L m’ I Sv m’’ Distributed Law-Enforcement under LGI

9. The local nature of LGI laws • Laws are defined locally, at each agent: • They deal explicitly only with local events—such as the sending or arrival of a message. • the ruling of a law for an event e at agent x is a function of e, and of the local control state CSX of x. • a ruling can mandate only local operations at x. • Local laws can have powerul global consequences—because of their global purview. • This localization does not reduce the expressive power of LGI laws, • and it provides scalability for many (althouh not all) laws.

10. controller service controller service I I I I I I m ==> y y x adopt(…) m’ L L adopt(L, name) adopt(L, name) adopt(…) m’’ Deployment of LGI(Using Distributed TCB)

11. E3 P3 E2 E1 P1 P2 PC Motivating the Need for Interoperability, and for Policy-Hierarchy • Consider a coalition C of enterprises {E1,..., En}, governed by a coalition-policy PC---where each Ei is governed by its own internal-policy Pi .

12. The Main Problems • The flexible formulation of these policies, so that (a) they will be consistent, and (b) their specification and evolution would be manageable. • Enforcement of these policies in a scalable manner.

13. B1 E3 B($1) E2 E1 P1 P2 PC Example (cont.) A director Di can mint Ei-currency $i needed to pay for services provided by Ei and it can giveDC some of this currency A director DC can distributesome of its B($1) budgetamong other directors Roles: each Ei has its director Di; and the coalition C has a director DC. A director D2 can distribute its B($1) budget among agents at its enterprise All service requests should be monitored

14. Enforcement by Composition… • Given the set {PC , P1,. . ., Pn} of policies. • Construct a set {Pi,j} of compositions: where Pi,j = composition (Pi , PC , Pj). • Provide these compositions to the reference monitor (RM) that mediates all coalition-relevant interactions. • Compositions were studied by: Gong & Qian 96, and by Bidan & Issarny 98, ...

15. … and its Problematics • It is unlikely for arbitrary, and independently formulated, policies to be consistent—such composition is likely to end with a big bang. • Policy composition is computationally hard (McDaniel & Prakash 2002) and we need N^2 such compositions! • Inflexibility: consider changing a single Pi . . . • Overly centralized, thus unscalable. • The RM need to be trusted by all coalition members. • Alternatively we can have N^2 different RMs, Ri,jeach trusted by {Ei , C , Ej}—still problematic.

16. The Proposed Approach • Instead of creating N^2 compositions (Pi , PC , Pj), we will enable each enterprise Ei to create its own policy Pi , subject only to the constraint that Pi would conform to PC . • We will then allow Ei and Ej to interoperate, once each of them enforces its own policy.

17. Hierarchy Organization of Coalition Policies PC superior subordinate P1 P2 Pn Pi is defined as subordinate to Pc, as thus constrained to conform to it.

18. E3 P3 E2 E1 P1 P2 PC Interoperability • Let us focus on the interoperability between E2 and E1

19. controller controller P1 P2 export(m,y,P1) imported(x,P2,m) m I I CSx CSx x y Cx Cy E2 E1 Authenticated by CA2and CAC Authenticated by CA1and CAC Interoperability (cont.)

20. Conclusion • LGI implementation via the Moses middleware is to be released in May 2005, via:http://www.cs.rutgers.edu/moses/ • This release does not support policy hierarchy.

21. Questions?