Naftaly Minsky
Rutgers University
Law-Governed Interaction:a Decentralized
Access-Control Mechanism
N. Minsky, Ottawa April/05 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.
N. Minsky, Ottawa April/05 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.
N. Minsky, Ottawa April/05 4
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.
N. Minsky, Ottawa April/05 5
Enforcing a Communal AC Policy
Enterprise-wide (communal) policyP
Enterprise
delegate
The communal policy may be that certain type of transactions need to be monitores…
N. Minsky, Ottawa April/05 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.
N. Minsky, Ottawa April/05 7
Centralized Enforcement of Communal Policies
* The problems: potential congestion, and single point of failure
m’x
u v
ym ==> 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
N. Minsky, Ottawa April/05 8
Distributed Law-Enforcement under LGI
L
I
S
x
u v
y
L
I
Sx
L
I
Sv
L
I
Sy
L
I
Su
m ==> y m’ m’’
m m ==> ym
N. Minsky, Ottawa April/05 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.
N. Minsky, Ottawa April/05 10
Deployment of LGI(Using Distributed TCB)
II
I
I
IIx y
controller servicecontroller service
adopt(L, name) adopt(L, name)
adopt(…)
adopt(…)
m’ m’’L
m ==> yL
N. Minsky, Ottawa April/05 11
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 .
E3
E2 E1
P2P1
P3
PC
N. Minsky, Ottawa April/05 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.
N. Minsky, Ottawa April/05 13
Example (cont.)
E2
E3
E1
Roles: each Ei has its director Di; and the coalition C has a director DC.
A director Di can mint Ei-currency $i
needed to pay for services provided by Ei and it can give DC some of this currency
A director DC can distribute some of its B($1) budget among other directors
A director D2 can distribute its B($1) budget among agents at its enterprise
B($1)B1
All service requests should be monitored
PC
P2P1
N. Minsky, Ottawa April/05 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, ...
N. Minsky, Ottawa April/05 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, R i,j each trusted by {Ei , C , Ej}—still problematic.
N. Minsky, Ottawa April/05 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.
N. Minsky, Ottawa April/05 17
Hierarchy Organization of Coalition Policies
PC
P1 P2 Pn
superior subordinate
Pi is defined as subordinate to Pc, as thus constrained to conform to it.
N. Minsky, Ottawa April/05 18
Interoperability
Let us focus on the interoperability
between E2 and E1
E3
E2 E1
P2P1
P3
PC
N. Minsky, Ottawa April/05 19
Interoperability (cont.)
imported(x,P2,m)
E2 E1
x y
Authenticated by CA2 and CAC
Authenticated by CA1 and CAC
controller controller
P1P2
Cx Cy
CSx
I I
CSx
m
export(m,y,P1)
N. Minsky, Ottawa April/05 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.
Questions?
Top Related