abstract

Law-Governed Interaction:
a Decentralized
Access-Control Mechanism
Naftaly Minsky & Constantine Serban
Rutgers University
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
2
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
3
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
4
Enforcing a Communal AC Policy
Enterprise-wide (communal) policy
P
Enterprise
N. Minsky, Ottawa, April/05
5
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
6
Centralized Enforcement of
Communal Policies
v
u
P
x
m ==> y
I
m’
y
S
Reference monitor
Legend:
P---Explicit statement of a policy.
I---Policy interpreter
S---the interaction state of the community
* The problems: potential congestion, and single point of failure
* Replication does not help, if S changes rapidly enough
N. Minsky, Ottawa, April/05
7
Distributed Law-Enforcement under LGI
L
m
u
L
m
I
Su
I
v
Sv
L
I
S
L
x
m ==> y
I
Sx
N. Minsky, Ottawa, April/05
m’
L
I
m’’
y
Sy
8
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
9
Deployment of LGI
(Using Distributed TCB)
controller server
controller server
I
I
I
I
x
adopt(L,
m ==> name)
y
L
I
N. Minsky, Ottawa, April/05
m’
L adopt(L, name)
m’’
I
10
y
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
P3
E2
E1
P2
N. Minsky, Ottawa, April/05
P1
PC
11
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
12
Example (cont.)
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 has
can its
distribute
some
itsthe
Roles:
each Ei
director
Di;of
and
B($1) budget
other Ddirectors
coalition
C hasamong
a director
C.
E3
A director D2 can distribute its B($1)
budget among agents at its enterprise
B1
All service requests should be monitored
B($1)
E2
E1
P1
P2
PC
N. Minsky, Ottawa, April/05
13
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
14
… 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,j
each trusted by {Ei , C , Ej}—still problematic.
N. Minsky, Ottawa, April/05
15
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
16
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.
N. Minsky, Ottawa, April/05
17
Interoperability
 Let us focus on the interoperability
between E2 and E1
E3
P3
E2
E1
P2
N. Minsky, Ottawa, April/05
P1
PC
18
Interoperability (cont.)
controller
controller
P2
P1
export(m,y,P1)
m
imported(x,P2,m)
I
I
CSx
CSx
x
Cx
E2
Authenticated by
CA2 and CAC
N. Minsky, Ottawa, April/05
y
Cy
E1
Authenticated by
CA1 and CAC
19
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.
N. Minsky, Ottawa, April/05
20
Questions?