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

2. 2 N. Minsky, Ottawa April/05 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. 3 N. Minsky, Ottawa April/05 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. 4 N. Minsky, Ottawa April/05 Server-Centric Access-Control (AC) Reference Monitor (RM) server It generally supports only stateless, purely reactive, ACL-based policies, enhanced with RBAC—and this is far from sufficient.

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

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

8. 8 N. Minsky, Ottawa April/05 Distributed Law-Enforcement under LGI L I S x u v y L I SxSx L I SvSv L I SySy L I SuSu m ==> y m’ m’’ m m ==> y m

9. 9 N. Minsky, Ottawa April/05 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 CS X 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. 10 N. Minsky, Ottawa April/05 Deployment of LGI (Using Distributed TCB) I I I I IIx y controller service adopt(L, name) adopt(…) m’ m’’ L m ==> y L

11. 11 N. Minsky, Ottawa April/05 Motivating the Need for Interoperability, and for Policy-Hierarchy  Consider a coalition C of enterprises {E 1,..., E n }, governed by a coalition-policy P C ---where each E i is governed by its own internal-policy P i. E3E3 E2E2 E1E1 P2P2 P1P1 P3P3 PCPC

12. 12 N. Minsky, Ottawa April/05 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. 13 N. Minsky, Ottawa April/05 Example (cont.) E2E2 E3E3 E1E1 Roles: each Ei has its director Di; and the coalition C has a director D C. A director Di can mint Ei-currency $ i needed to pay for services provided by Ei and it can give D C some of this currency A director D C can distribute some of its B($ 1 ) budget among other directors A director D 2 can distribute its B($ 1 ) budget among agents at its enterprise B($ 1 ) B1B1 All service requests should be monitored PCPC P2P2 P1P1

14. 14 N. Minsky, Ottawa April/05 Enforcement by Composition …  Given the set {P C, P 1,..., P n } of policies.  Construct a set {P i,j } of compositions: where P i,j = composition (P i, P C, P j ).  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. 15 N. Minsky, Ottawa April/05 … 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 P i...  Overly centralized, thus unscalable.  The RM need to be trusted by all coalition members.  Alternatively we can have N^2 different RMs, R i,j each trusted by {E i, C, E j }—still problematic.

16. 16 N. Minsky, Ottawa April/05 The Proposed Approach  Instead of creating N^2 compositions (P i, P C, P j ), we will enable each enterprise E i to create its own policy P i, subject only to the constraint that P i would conform to P C.  We will then allow E i and E j to interoperate, once each of them enforces its own policy.

17. 17 N. Minsky, Ottawa April/05 Hierarchy Organization of Coalition Policies PCPC P1P1 P2P2 PnPn superiorsubordinate P i is defined as subordinate to P c, as thus constrained to conform to it.

18. 18 N. Minsky, Ottawa April/05 Interoperability  Let us focus on the interoperability between E 2 and E 1 E3E3 E2E2 E1E1 P2P2 P1P1 P3P3 PCPC

19. 19 N. Minsky, Ottawa April/05 Interoperability (cont.) imported(x,P 2,m) E2E2 E1E1 x y Authenticated by CA 2 and CA C Authenticated by CA 1 and CA C controller P1P1 P2P2 C x C y CS x II m export(m,y,P 1 )

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

21. Questions?