Naftaly Minsky Rutgers University

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.


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.


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.


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…


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.


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


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


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.


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


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


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.


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


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, ...


… 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.


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.


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.


Interoperability

Let us focus on the interoperability

between E2 and E1

E3

E2 E1

P2P1

P3

PC


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)


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.

http://www.cs.rutgers.edu/moses/

Questions?

Naftaly Minsky Rutgers University

Documents

Transcript of Naftaly Minsky Rutgers University