Decentralized Regulation of Distributed Systems:

Beyond Access Control

Naftaly Minsky

Rutgers University

December 30, 2007

Abstract

This paper introduces a model of interaction control for the regulation of distributed

systems, which can cope with their increasing openness and heterogeneity. This model

goes well beyond conventional access control. It is, in particular, inherently decentral-

ized, and thus scalable even for wide range of stateful policies. And it is very general,

and not biased toward any particular type of policies; thus providing a significant

realization of the age old principle of separation of policy from mechanism.

This, so called, LGI model is an abstraction of an implemented mechanism called

Moses (that has sometimes been called “LGI” as well), which regulates Internet com-

munication, providing several important capabilities not present in the LGI model,

but consistent with it. Moreover, the LGI model can be reified into a whole family of

additional mechanisms—called LGI-based mechanisms—which would share the basic

properties of this model, but may be applied to different types of communications, such

as wireless communication of various kinds, and can add a host of features to those

inherent in the model itself.

1

1 Introduction

Software technology is undergoing a relentless transition from monolithic systems, con-

structed according to a single overall design, into open systems, consisting of a distributed and

heterogeneous collection of autonomous components written in different languages, running

on different platforms, and designed, constructed, and even maintained by different organiza-

tions. (The concept of service oriented architecture (SOA), popular particularly for business

applications [15], is one approach, among many, for building such systems.) Unfortunately,

although there are powerful reasons for this transition to open systems, the anarchical nature

of such systems presents serious obstacles to their manageability, dependability and security

[26].

The thesis of this paper is that the inherent anarchy of open systems can be usefully

tamed by regulating the interaction between their disparate components, thus inducing a

degree of order into them. This, in analogy, is how orderly societal systems are formed. The

transportation system, for example, is governed by traffic laws that regulate such things as:

on which side of the road one is allowed to drive, to whom should one give the right of way, and

how should one react to the changing traffic lights. Such laws enable drivers to coordinate

harmoniously with each other, and to negotiate their passage through intersections with

relative safety. This, despite the fact that the drivers themselves are an heterogeneous

bunch, with little if any knowledge of each other, except for the confidence they have in the,

more or less, universal compliance with the common traffic laws.

The regulation of distributed software systems can have analogous salutary effects. In

particular, such regulation can help address the following needs of open systems: (1) The

need to protect a system from unruly, buggy, or malicious components, from within or from

without. (2) The need to provide for modularization, in particular by bundling a given group

of components—which may be dispersed over the Internet—into a kind of virtual module,

with some private aspects, and with a specified interfaces to the rest of the system. (3)

The need to facilitate safe and harmonious coordination between disparate agents, even if

they have little or no prior knowledge of each other’s internal behavior. And (4) the need to

support effective system management, by providing the designated managers with the power

to monitor and control the activities of the system components within their purview.

To be able to address these needs, and others, in a reasonably efficient and scalable

2

manner, we maintain that a regulatory mechanism must satisfy the following three principles:

Principle 1 (statefulness) The regulatory mechanism needs to be sensitive to the history

of interaction between the regulated components.

Such sensitivity is obviously necessary for regulating coordinations, and for supporting man-

agement, both of which are highly dynamic processes; and it is also necessary for the security

of systems, which can be endangered by improper dynamic behavior of components, such as

sending message in an improper order, or sending too many messages.

Principle 2 (decentralization) The regulatory mechanism need to be decentralized.

This principle is required because centralized regulation tends to be unscalable, particularly

under stateful regulation (as argued in [24]), and because central control (by means of a refer-

ence monitor, say) tends to distort the inherently concurrent, and independent, interactions

between the distributed components.

Principle 3 (generality) The regulatory mechanism should not be biased towards any par-

ticular kind of policies, and should be able to support a wide range of them.

This is, essentially, the age-old principle of separation of policy from mechanism [31]. This

principle is increasingly critical because complex systems tend to involve a multitude of

diverse policies, regarding various types of system activities; and such policies often need to

interoperate. Using dozens of incompatible mechanisms to implement these policies would

be very hard, and would make the resulting system incomprehensible and unmanageable.

Unfortunately, these principles are largely not satisfied by conventional access control

(AC)—the currently dominant approach to regulation of distributed systems—which limits

the ability of AC to address the above mentioned needs of open systems. This is true for

contemporary industrial AC mechanisms such as Tivoli [17] and XACML [12]; for middle-

wares such as CORBA and J2EE; as well as for modern academic policy mechanisms such

as Ponder [10], Oasis [13], and SPL [27].

The limitations of the conventional AC mechanisms are due, in part, to their origin,

which is a model formulated more than thirty years ago, to regulate processes residing in

a single host. Despite the many extensions of the original model, including the use of

digital certificates and roles (as under RBAC [28]), and some attempts at stateful policies

3

[27], most current AC mechanisms still retain much of their original structure, including a

mostly centralized reference monitor, and an unwarranted dichotomy between mandatory

and discretionary policies—which, as we shall see, tends to limit the generality of these

mechanisms. Moreover, current AC mechanisms generally share the rather limited objective

of the original AC model, which is, broadly speaking, to permit access only to those that

have the right for it, but without any concern about the the dynamic behavior of those that

get such access. This is analogous to having traffic laws that require only that every driver

has a driving license, without any concern about the dynamic process of driving.

We submit that conventional access control is not sufficient for effective regulation of

open distributed systems. What is needed is a more general, and structurally different,

kind of regulation, which satisfies the three principles stated above; and which controls not

only access to objects and services, but the entire dynamic process of interaction between

distributed agents. We use the term interaction control (IC) for such a regulation.

The purpose of this paper is to introduce an abstract model of such interaction control,

which we call the LGI model (LGI stands for “law governed interaction”). This model,

which is an abstraction of an existing interaction control mechanism called Moses1 [22], can

be reified into a whole family of mechanisms—called LGI-based mechanisms—of which Moses

is a member.

The rest of this paper is organized as follows: The LGI model is introduced in Section 2.

An analysis of this model is carried out in Section 3, along with a fairly detailed comparison

with conventional access control. Section 4 elaborates on a critical aspect of the LGI model,

namely the type of trust it provides between distinct actors interacting under an LGI-based

mechanism. We conclude in Section 5 with a very brief summary of this paper; and with a

glimpse at the realization of the LGI model via the Moses mechanism; and at some additional

LGI-based mechanisms currently under consideration.

1The Moses mechanism has also been called LGI, resulting in some confusion. Henceforth, we will reserve

the name LGI for the model introduced here, and will use the name Moses exclusively for the concrete

mechanism that inspired this model, but which is only one of its possible realizations.

4

2 The LGI Model of Interaction Control

The model to be introduced here aims to provides the means for regulating the interactions

among the members of distributed groups of autonomous computing processes, which we

call actors. The regulation is expressed via a constraint, called a law, over the interaction

between actors. And an actor operating in compliance with a specific law L is called an

L-agent.

In formulating this model we make no assumptions about the internal structure or behav-

ior of the actors whose interactions are to be regulated, about the languages in which they

are programmed, or about the type of host on which they run. Actors are viewed essentially

as black boxes that interact by means of message passing. The messages exchanged between

the actors can be asynchronous or synchronous (via RPC of some kind). And the model

makes no assumptions about the reliability of the message passing, or about their latency;

or even about the fabric of the communication network, which can, in particular, be via the

Internet, or via some form of ad hoc wireless communication. But the specific mechanisms

based on this model may make various choices about these matters.

We start, in Section 2.1 by introducing the concepts of an L-agent, and of the law under

which it operates. Then, in Section 2.2, we introduce the concept of law-based trust between

agents, and a grouping of agents called communities, whose significance is based on the

existence of such trust. We conclude, in Section 2.3, with a discussion of the manner in which

this abstract model can to be reified into any number of concrete LGI-based mechanisms.

2.1 Agents and Laws

We define an L-agent to be an actor that complies with a given law L. (We often use the

term LGI agent, or simply an agent, when the law under which it operates is assumed to be

known, or if it is of no immediate concern.) Structurally, an L-agent x is viewed as a pair

x = 〈a, TLx 〉 (1)

where a is an actor, and TLx is a device trusted to mediate the interactions of a with other

agents, in compliance with law L. The mediator TLx is called the private controller (or simply

the controller) of agent x, and the actor a is said to animate agent x.

Mostly, however, this model views an agent as a unit, and is not concerned with its

5

internal structure. In particular, this model does not specify the structure of the controller,

and its precise relationship with the actor whose messaging activity it mediates. Indeed, as

we shall see in Section 4, different realizations of this model may have the controller either

hosted by a different process than the actor, or by the actor itself. Also, we point out that

the controller TLx should not be viewed as a wrapper of a. In particular, because we do not

rule out the possibility that the same computing process a operates, concurrently, as the

actor of several different agents, possibly under different laws; moreover, the actor might

communicate via regular, non-LGI, messages.

Note also that an agent may be permitted, by its law, to cross-interact (or “interoperate”)

with agents operating under different laws; and even with actors not operating under LGI

at all2. But the messages sent by an L-agent must comply with its law L, and are, thus,

called L-messages.

Now, an LGI law (or, simply, a law) is defined in terms of three elements: (a) a set E of

regulated events; (b) the control-state (CSx) associated with each agent x; and (c) a set O of

control operations. We define these elements below, and then, in Section 2.1.1, we define the

concept of law, and what it means to comply with it. We conclude this section by modeling

the interactive behavior of an agent as a state machine on Section 2.1.2.

The Set E of Regulated Events: This is the set of events that may occur at any agent

and whose disposition is subject to the law under which this agent operates. The specific

agent where an event occurs is called the home of this event. And every event is associated

with the local time of its occurrence.

This set consists of the following three types of events, described here without any details

of their structures: (a) the arrived event, which represents the arrival at the home agent

of a message sent from elsewhere, identifying the law under which this message has been

sent; (b) the sent event, which represents the act of message sending by the actor of the

home agent; and (c) the adopted event, which occurs when some actor adopts a law L,

thus creating an L-agent (this is, thus, the very first regulated event in the lifetime of every

agent, representing its birth, as it were.) Note that a mechanism based on this model can

add events to this set, more about which later.

2For simplicity, we mostly ignore in this paper the possibility of an interaction between LGI agents and

actors not operating under LGI (a possibility that is supported by the Moses mechanism).

6

The Control-State (CS) of an Agent: The control-state CSx is the state maintained by

agent x in compliance with the law under which it operates—it is distinct from the internal

state of the actor of agent x. This state, which is initially empty, can change dynamically

in response to the various events that occur at it, subject to the law under which this agent

operates.

The Set O of Control Operations: These are the operations that can be mandated by

a law, to be carried out at a given agent, upon the occurrence of regulated events at it. In

a sense, these operations constitute the repertoire of the law—i.e., it is the set of operations

that the law is able to mandate. The set O is partitioned into two subsets: the set Os of

state-operations, and the set and Oc of communication-operations. Operations in Os, which

are not spelled out here, can change the control state CS of an agent. Operations in Oc

affect the exchange of messages between a given agents and its peers. This set consists of

the following two operations: (a) the forward operation, which forwards a message from x

to some other agent; and (b) the deliver operation, which delivers a message to the actor

of the home agent—in effect, accepting the message on behalf of this actor. As in the case

of regulated events, the set O can be extended by a mechanism based on this model.

2.1.1 The Concept of LGI Law

The role of a law under LGI is to decide what should be done in response to the occurrence

of a regulated event at an agent operating under this law. This decision, which is called the

ruling of the law, consists of a sequence of zero or more control operations from the set O.

More formally, a law is defined as follows:

Definition 1 (law) Given a set E of all regulated events, a set O of all control operations,

and a set S of all possible control-states, a law L is a function:

L : E × S → O∗ (2)

In other words, a law maps every possible (event, state) pair into a sequence of zero or more

control operations, which constitute the ruling of the law. Note that this mapping may be

nondeterministic.

7

It should be pointed out that this definition does not specify a language for writing

laws (which we call a law-language). This for several reasons: First, because despite the

pragmatic importance of choosing an appropriate law-language, this choice has no impact

on the semantics of the model itself, as long as the chosen language is sufficiently powerful

to specify all possible functions of the form of Formula 2. Second, by not specifying a law-

language we provide the freedom to employ different law-languages for different applications

domains, possibly under the same mechanism. Indeed, the implemented Moses mechanism

employs two different law-languages, one based on the logic-programming language Prolog,

and the other based on Java. Finally, leaving the language out of this model simplifies it,

and would facilitate the analysis of its underlying nature.

Several additional observations are worth making about this concept of law. First, a

law is local. That is, it is defined locally, at each agent, in the following sense: (a) the law

regulates explicitly only local events at each individual agent; (b) the ruling of the law for an

event e at agent x depends only on e itself and on the local control-state CSx of x; and (c) the

ruling of the law at a given agent x can mandate only operations to be carried out locally at

x, such as an update of the local control-state CSx, or the forwarding of a message from x to

some other agent. As we shall see later, this locality has profound implications. In particular,

it enhances the scalability of LGI-based mechanisms, and with no loss of generality.

Second, a law cannot be inconsistent. That is, a law specifies a single ruling for any given

(event, state) pair. This is worth mentioning, in particular, because many conventional AC

mechanisms admit policies with conflicts, and then have to provide means for the resolution

of these conflicts.

Third, it may be instructive to compare the concept of law under LGI with the concept

of policy under conventional AC. Broadly speaking an LGI law represents a class of AC

policies. For example, we may have a law that represents a whole class of capability based

policies, and another law that represents RBAC policies. More specifically, the counterpart

under LGI of a single AC policy, is a law together with the states of all agents operating

under it, at a given moment in time. These states may represents such things as the the

capabilities possessed by these agents. We shall illustrate this correspondence via an example

in Section 3.1. In this paper we use the term “policy” when discussing access control; and,

sometimes, when talking informally about a constraints over interactions.

8

Compliance with a Law: We say that an agent x complies with a given law L—and thus

constitutes an L-agent—if the following three conditions are satisfied: (1) the ruling of law

is carried out3 in response to the occurrence of every regulated event at x; (2) the ruling,

which consists of a sequence of operations, is carried out atomically for each event at x, in

the order of the occurrence of these events (events that occur simultaneously are handled

sequentially, in arbitrary order); and (3) control operations are not carried out at x, unless

mandated by its law—thus, in particular, no messages are forwarded from x to anybody,

without it being mandated by the law.

2.1.2 An L-Agent as a State-Machine

It is instructive to take the state machine view of the interactive behavior of an L-Agent.

This view is defined by the following variant of Formula 1:

L : E × S → (S × O∗c ) (3)

where E—the set of regulated events—represents the input alphabet of the machine; S rep-

resents (as above) all possible control-states of an agent; and Oc—the set of communication

operations—represents the output alphabet of the machine. In other words, a law in this

formula maps every (event, state) pair into a new state, via state operations from Os in

its ruling, along with the set of outputs (using the state machine terminology) defined by

operation from Oc in its ruling.

This formula represents explicitly the interplay between the law and the state of an agent.

On one hand, the ruling of the law depends, in part, on the state of the home agent. On

the other hand, the law maps the state to another state. That is, the dynamic behavior

of the state of an agent is regulated by its law. This interplay between the fixed law and

the dynamically changing state is an important characteristic of the LGI model, which is

responsible for much of its power, as we shall see in due course.

It should be pointed out that this view of an agent is similar to the model of I/O automata

introduced by Nancy Lynch [19]. But there is a fundamental difference between LGI and

the I/O automata model, in their treatment of collections of distributed actors, which is the

subject of the following section.

3If the ruling of the law for a given event is empty, then nothing extra will be done in response to this

event; in other words, this event is effectively ignored by the law.

9

2.2 Communities, and the Concept of Law-Based Trust

As has been pointed out above, the purpose of this model is to provide means for regulating

the interactions among the members of distributed groups of agents. The main type of group

to be considered here is a set of agents operating under a common law L. Such a group is

called an L-community (or, simply, a community, when the identity of L is assumed known,

or is of no concern). While our discussion below focuses on communities, the ability of agents

operating under different laws to cross-interact, subject to their respective laws (as stated

in Section 2.1), means that one can deal with systems consisting of multiple interoperating

communities.

One of the main advantages of effective regulation is that it provides the members of

an L-community a degree of predictability about each other’s interactive behavior, even if

the community is heterogeneous, and even if its members are unfamiliar with each other’s

structure and internal behavior. Such predictability could allow software agents to coordinate

harmoniously with each other, in some analogy to the manner in which car drivers coordinate

their passage through intersection, based on their (often reliable) trust that other drivers

comply with the traffic laws.

But this ability to predict the behavior of the members of an L-community is meaningful

only if we know who they are. This is not as simple as it may seem to be. In particular,

when getting a message m from some IP address, how does one know that it has been sent

by a bona fide L-agent? In other words, how does one know that m is an L-message?

One way for knowing who is an L-agent, is by directly enforcing a law L on a given set S

of actors. This can be done by isolating all members of S from all means of communications,

except communication via mediators designed to enforce law L. But while such direct

law-enforcement may be possible in some close environments, such as a LAN, it is not

possible for more open systems, where one cannot isolate actors from the standard means of

communication.

To provide a meaningful ability for an LGI agent to reason about the interactive behavior

of its peers, in the absence of direct law-enforcement, one needs to be able to recognize other

LGI agents upon actual interaction with them, and to identify the law under which they

operate. We call such a recognition law-based trust (or L-trust, for short), as defined below:

Definition 2 (law-based trust) Consider an L-agent x interacting with some computing

10

process y, (i.e, x sends a message to y, or receives a message from it). We say that x has a

law-based trust in y if the following two conditions are satisfied: (a) x can recognize whether

or not y is an LGI agent; and (b) if y is an LGI agent, operating under some law L’, then

x can determine if L’ is equal to its own law L, and it can get the text of law L’, if it is

different from L.

In particular, L-trust means that if both x and y are LGI agents, operating, respectively,

under laws L and L’, and if x sends a message to y, then: (a) x can be confident that the

message it is sending would be treated by y in compliance with its law L’; and (b) y can

be confident that the message it got from x has been sent in compliance with the law L of

x. So, this concept of trust provides interacting LGI agents with a degree of predictability

about each other’s behavior, whether they belong to a single community, or to different ones.

Note that this model does not specify how L-trust is to be supported. This is left up to

every LGI-based mechanism.

L-Trust Versus Law-Enforcement: L-trust is clearly weaker than the trust resulting

from actually forcing certain actors to become L-agents. Nevertheless, the very existence

of L-trust may often effectively compel certain actors to operate under a particular law L.

Broadly, this can be the case when one wishes to use services provided only under this law.

We illustrate this situation via the following example.

Consider an enterprise, whose management decided that all internal services—such as

printing, file-services, databases, etc.—be paid with internal currency, made available to

various agents as their budgets. The requests for such services, and the budgets that enables

them, are to be governed by the following (informally stated) three-point LGI law: (1) an

agent that plays the role of budget officer can assign any amount of currency to the budget

of any agent; (2) each service request must carry a payment, which cannot exceed the budget

available to the client—and which is deducted automatically from its budget, and then added

to the budget of the server; and (3) servers may send the balance of their earning to the

budget-officer, to get some credit (not specified here) from the management.

Now, if the budget officer operates under this law, than any server that wants to get

credit for its services would have to do likewise. And the clients who wish to get such

services would have to follow suit, both in their interaction with the compliant servers, and

with their interaction with the budget officer.

11

Due to this effective similarity between strict law-enforcement and L-trust, we will oc-

casionally talk about an LGI-based mechanism as if it enforces its laws, although this is

not strictly correct. This somewhat loose usage of the term “enforcement” is quite common

in access-control literature, when dealing with open set of clients and servers. Indeed, a

reference monitor, e.g. such as employed by the XACML mechanism, also cannot enforce its

policies, but can only provide an analogue for our law-based trust. Yet, it is usually referred

to as a policy enforcement mechanism.

2.3 From LGI model to LGI-based mechanisms

The LGI model is not itself an interaction control mechanism, because it is incomplete.

But it can be completed, and extended, in a variety of different ways, giving rise to a

potential family of what we call LGI-based mechanisms—one of which being the existing

Moses mechanism [22], which inspired this model. The elements of this model that need

to be completed, and those that can be extended, for the creation of a concrete LGI-based

mechanism, are mainly the following: (a) the specification of the communication medium

between system components; (b) the sets E and O; (c) the language for writing laws; and

(d) the support for L-trust. Moreover, an LGI-based mechanism can add new elements,

provided they are not inconsistent with the model itself. We now elaborate briefly on some

of these matters, pointing out the choices that have been made for the construction of the

Moses mechanism.

Concerning the nature of communication, Moses has been designed for Internet commu-

nication, using TCP/IP; but it is easy to apply the LGI model to variants of TCP, such

as HTTP, and it should be possible to do so for radically different types of communication,

such as wireless.

to other Internet communication protocols, such as HTTP, as well as to various modes

of wireless communication.

The set E of regulated events, and the set O of control operations specified in this model

are complete, in the sense that they are sufficient for an LGI-based mechanism. Indeed, as we

shall see in Section 3, an LGI-based mechanism that employs precisely these sets is possible,

and is more powerful, and better structured, than the traditional AC mechanisms. However,

one can add important capabilities to an LGI-based mechanism—such as obligations and

exception handling—simply by extending these two sets, as has been done in Moses.

12

A law-language is, of course, required for every LGI-based mechanism. In particular, the

Moses mechanism provides a choice between two such languages: one based on prolog, and

one on Java; and there is work underway for adopting a simpler language for Moses. In this

paper we use an informal law-language, described in in due course.

The support for law-based trust is critical to every LGI-based mechanism. In Section 4

we will discuss two techniques for providing such support, one of which is employed by the

Moses mechanism.

Finally, one can enhance the power and usability of an LGI-based mechanism by adding

completely new elements to it. We mention here two such elements, one of which has been

already added to the Moses mechanism, and the other is under construction. The first of these

is an hierarchical structure of laws, which adds significantly to our ability to regulate truly

complex systems, such as virtual enterprises [2]. The second new element is a mechanism for

changing the law of a community dynamically, while the community operates. This features

has been proposed in the original paper about LGI [20], but has not been implemented yet.

3 Analysis of the LGI Model

The purpose of this analysis is to identify the main characteristics of the LGI model, and thus

of every LGI-based mechanism—such as Moses. We will also compare this model with the

traditional access control, attempting to highlight the underlying differences between the two.

However, for simplicity we will confine our discussion to the case of a single L-community;

that is, we will not consider in this section any cross-interaction between different laws.

For the sake of this analysis, the reader is asked to assume that the LGI model has been

reified into a concrete mechanism by completing the parts left open by the model, along the

lines prescribed in Section 2.3, but without any extensions (in particular, without extending

the sets E and O of the model). We will, thus, be discussing an essentially minimalist LGI-

based mechanism, considerably weaker than the implemented Moses, in particular. Yet, we

will find that even this stripped down mechanism, would (if implemented) be more powerful

than conventional access control.

We start by exemplifying the manner in which AC policies can be handled under the

LGI model, via a law that implements a variant of the conventional capability-based class

of policies. In Section 3.2 we discuss the treatment of stateful policies—i.e., policies that

13

are sensitive to the history of interaction. We then reflect on the underlying structure of

the LGI model, and on its main consequences, as follows: first, we show in Section 3.3

that this model unifies the DAC and MAC dichotomy of traditional access control; second,

in Section 3.4, we show that this unification facilitates the realization of the principle of

separation of policy from mechanism, which largely eluded conventional AC mechanisms;

and third, in Section 3.5 we discuss the global sway that an LGI law can have over the

community governed by it—this despite the inherently local nature of laws. We conclude in

Section 3.6 by demonstrating the support provided by the LGI model to context sensitive

policies, for several types of context.

3.1 The Treatment of Conventional AC Policies

To show how conventional AC policies can be implemented under LGI, we discuss here a law

that implements a class of capability-based access control policies. Before we describe the

details of this law, called CB (for “capability based”), we outline below its main provisions.

First, under this law a capability is a term cap(y, d), which, when contained in the CS of

some agent x, signifies the right of x (its holder) to send messages of the form msg(m)

(with any content m) to agent y. Second, a capability cap(y, d) is delegateable only if d

is 1; and it can be delegated by its holder to any agent z by sending to z the message

delegate(cap(y, d′)), where d′ can be either 1 or 0. The arrival of this message at z would

provide z with a delegateable or an undelegateable version of this capability, depending on

whether d′ is 1 or 0. (Note that this is just one of many possible ways for doing delegation;

we will return to the general topic of delegation later.) Finally, every new member x of

the CB-community is initialized with the delegateable capability cap(x, 1) for itself —which

according to the above, it would be able to delegate to any other member.

We specify this law here via an informal law-language modeled after the real Prolog-based

language of the Moses mechanism [22]. Under this language, a law (see Figure 1) consists of

a sequence of event-condition-action rules of the following form:

UPON e IF c DO [o]

where e is a regulated event (or a pattern that could match several such events); c is an

optional condition defined over the event e, and over the state CS of the home agent ; and [o]

14

is the sequence of control-operations that constitute the ruling of the law (i.e., the “action”

part of the rule).

Whenever an event e′ occurs at some some agent x, the ruling of its law is computed in

the following way: The sequences of rules that constitute the law are evaluated from top

to bottom, until a rule is found whose e part matches event e′, and whose condition c is

satisfied. The action [o] of this successful rule is then defined as the ruling of the law. If no

rule succeeds for a given event and state, then the ruling of the law for this event is defined

as empty, causing this event to be simply ignored.

Few additional details about this informal language are needed for the understanding of

our example laws in this paper. In particular, the control-state of the home agent can be

checked via a predicates of the form ∃T, which means “there exists a term T in the control

state of the home agent.” More details are provided in Appendix A.

R1. UPON adopted DO [+cap(self,1)]

R2. UPON sent(msg( ),Y)

IF ∃cap(Y, ) DO [forward]

ELSE DO [deliver(‘‘illegal message’’)]

R3. UPON arrived( ,msg( )) DO [deliver]

R4. UPON sent(delegate(cap(Y,D)), )

IF (∃cap(Y,1)) DO [deliver]

R5. UPON arrived( ,delegate(cap(Y,D)))

DO [+cap(Y,D), deliver]

Figure 1: Law CB of Capability Based Control

Now, law CB itself, written in this informal language, is displayed in Figure 1. This law

consists of five rules, which we now discuss in some detail. Rule R1 is triggered by the

adopted event—the first event in the lifetime of every agent—and its ruling is to add to the

state (CS) of the home agent a term cap(self,1) representing a delegateable capability

for itself (note that the symbol self denotes the home agent). This means that every agent

operating under this law would be initialized in this way.

Rule R2 is triggered by the sending of any message of the form msg( ) (“ ” means an

arbitrary term—see Appendix A for this and other syntactic details of this law), to any agent

15

Y. This rule produces the ruling to forward the sent message only if the condition ∃cap(Y, )

is satisfied; that is if the sender has a cap term for Y in its state. Otherwise, this rule would

produce a ruling to deliver to the sender an “illegal message” warning. When a message

sent under this rule arrives at its destination it is delivered without further ado by Rule R3.

Note that these two rules provide the cap(...) terms with the semantics of a right to send

messages, i.e., the semantics of capabilities.

Rule R4 is triggered by an agent sending a message delegate(cap(Y,D)) to any agent

Z. The ruling for such sending would be to forward this message, but only if the sender

has the term cap(Y,1) in its CS, representing a delegateable capability. Finally, when this

delegate message arrives at its destination Z, it would trigger Rule R5 at Z, which would

cause the sent capability to be added to the CS of the receiver.

Finally, note that this law represents a class of AC policies, in that a policy under access

control includes the specification of a particular distribution of rights (e.g., capabilities),

while law CB allows for arbitrary such distributions. And it is only one of many possible

classes of capability-base policies, because law CB establishes a particular initialization of

states of agents, and a particular approach to delegation. And, obviously, many other

approaches to such matters can be supported by LGI—more about which, later.

3.2 Scalable Sensitivity to the History of Interaction

We now address the manner in which the LGI model meets the need for regulation to be

scalabely sensitive to the history of interaction between agents. Broadly speaking, this is

done not by maintaining the history itself, and not even selected parts of it—although both

are possible under this model, if really necessary—but by maintaining relevant functions of

this history, in the local states of individual agents.

We start this discussion with a very simple, and rather synthetic, example of so-called

budgetary control—a very important types of stateful control, which is nevertheless not sup-

ported by most, if not all, AC mechanisms. (For the treatment of a much more realistic

version of this example via LGI, see [22].) After this demonstration of the manner in which

sensitivity to history is accomplished under LGI, we will discuss the scalability of this ap-

proach, and point out to aspects of LGI that are instrumental in enabling it. We conclude

with a review of the treatment of stateful control under conventional access control, and will

point out the underlying reason for its limitations.

16

A Messaging-Budget (MB) Law—an Example: Consider a community required to

operate under the following constrain: no member of this community is allowed to send more

than 1000 messages. This constraint can be established by mean of law MB displayed in

Figure 2, under which the term budget(B) in the CS of an agent x means that x is allowed

to send B messages.

R1. UPON adopted DO [+(budget(1000))]

R2. UPON sent( , )

IF ∃budget(B) AND (B > 0) DO [decr(budget(B)), forward]

ELSE DO [deliver(‘‘message blocked’’)]

R3. UPON arrived( , ) DO [deliver]

Figure 2: Law MB of Messaging-Budget

This law consists of three rules. Rule R1 is triggered by the adopted event, and its ruling

is to add the term budget(1000) to the CS of the newly created agent—thus providing each

MB-agent with the initial messaging budget of 1000. Rule R2 is triggered by the sending

of any message, with the following result: If the message sender has in its CS the term

budget(B) with a positive B, its budget would be decremented by 1 (that is, budget(B) will

be replaced by budget(B-1)) and the message would be forwarded to its destination. But

if B is 0 then the sender would get a “message block” response, and its message would not

be forwarded. Finally, by Rule R3, the arrival of a message to any agent would cause this

message to be delivered with no further ado.

Scalability: The control provided by this law is scalable in two important senses. First,

it is scalable with respect to the length of interaction history. This is because there is no

need to maintain a complete, or even partial, record of the actual history of interaction.

All one needs here is to maintain the easily computable function of this history, namely the

balance of the budget for each agent. And the overhead of computing this balance would

stay essentially the same for any size of initial budget N. Second, this control is scalable with

respect to the size of the MB-community, because this law can be enforced in a completely

decentralized manner. This is due to the fact our constraint is defined over the local history

at each agent.

17

Of course, not every history-sensitive constraint can be implemented under LGI in such

a completely scalable manner. Because one can imagine constraints that require longer

historical records to be maintained, and which are non-local. LGI can handle all such

constraints, as discussed in Section 3.5, although not always scalably. But it is worth noting

that many kinds of important history-sensitive constraints are implementable very scalably

under LGI. This includes, in particular, the well known Chinese wall policy as has been

shown in [21]; and dynamic separation of duties policies, as has been shown in [4].

Enablers: It is worth identifying the aspects of the LGI model that enables this treatment

of history-sensitive constraints. Besides the very concept of law, and the fact that it is

sensitive to the local state at every agent, the main enabler of sensitivity to history is the

fact that the ruling of the law is not restricted to accepting a message or blocking it, but it

can contain several operations, including operations that can change the state. This allows

an agent to maintain in its state an arbitrary function of its local history of interaction.

The lack of this facility in most conventional AC mechanism, preclude them from providing

reasonably scalable sensitivity to history, as we shall see below.

Related Work: Traditional AC is stateful in a very limited sense: the distribution of

rights among the various subjects can be changed by delegation of rights. The need for

some additional forms sensitivity to history has been pointed out early on, including: the

so called “Chinese wall” policies and dynamic separation of duties policies [28]. But the

first comprehensive support for history-sensitivity has been proposed in the 1991 paper that

introduced LGI [20]. This has been followed by several attempts to provide general history-

sensitivity in the context of conventional access control. The best of these seem to be an AC

model introduced by Jojodia et al. [14], and the AC mechanism called SPL introduced and

implemented by Ribeiro et al. [27]. But both of these attempts are not sufficiently scalable,

due to inherent limitation of traditional access control.

Both of the above mentioned attempts are unscalable with respect to the size of the com-

munity in question, because both employ a central reference monitor for policy enforcement.

And although in the absence of state, a centralized policy enforcement can be made scal-

able by replicating the reference monitor, such replication becomes very problematic under

stateful policies because of the need to synchronize the replicas, as has been argued in [24].

18

Regarding scalability with respect to the length of interaction history: The model of

Jojodia et al. [14] is not scalable because it implements history-sensitivity by storing globally

every event (or action) that happen in a system. The SPL mechanism of Ribeiro et al. [27],

is more sophisticated in this respect. This mechanism provides an automatic “compilation

algorithm” that reduces the amount of information to be saved and the way that information

should be queried, for a given constraint to be evaluated over the history. The technique is

clearly more scalable than the previously mentioned one, but it is not scalable enough. In

particular, to implement our simple example of messaging budget, SPL will have to keep at

least part of the history of up to N messages—where N is the initial messaging budget—and

this history will have to be kept in a central place, which makes it quite unscalable for large

values of N. The underlying reason for this lack of scalability of SPL, and of the Jajodia’s

model, is that both of them retain the traditional AC model, under which a policy can only

rule to permit or deny the transfer of a message, but cannot also change any state, as is done

under law MB above.

3.3 The Unification of Mandatory and Discretionary Controls

The 1999 report “Trust in Cyberspace,” by the National Academy of Science, characterizes

the conventional access control technology as follows ([29] page 114): the two basic types

of access control policies that have dominated the computer security work for over two and

a half decades [are the] discretionary access control [DAC] and mandatory access control

[MAC] . This report continues to explain that DAC policies are discretionary in the sense

that a subject can pass (via delegation) it’s access permissions on to another subject; and

that MAC policies enforce access control on the basis of fixed regulations mandated by a

central authority, as typified by the Bell-LaPadula model.

But despite the prevalence of this MAC-DAC dichotomy, it is highly problematic. First,

because it is not quite coherent, and second because it tends to limit the generality of

AC mechanisms. This dichotomy is not coherent in that every DAC policy has an implicit

mandatory aspect. For example, the distribution of capabilities in an access control matrix is

a common example of a discretionary (DAC) policy, but the very meaning of the capabilities,

and the ability to delegate them, are based on an essentially mandatory (MAC) policy built

into the very fabric of the AC mechanism at hand. It is this implicit nature of the mandatory

part of this policy that makes it seem to be a pure DAC, which it is not. Moreover, making

19

the mandatory counterpart of what is called a DAC policy implicit, reduces the flexibility

and generality of AC mechanisms. Because any change in this mandatory policy—like a

change of the delegation process—would involve changing the mechanism itself, or replacing

it with another. We will return to this matter in the following section.

Under the LGI model, on the other hand, a regulatory regime4 has two parts: the explic-

itly stated and fixed law, which is mandatory for all members of the community in question;

and the semi discretionary, dynamically changing, state. While the law and the state cor-

respond roughly to the concepts of MAC and DAC, they cannot be viewed as a dichotomy,

but are, rather, inextricable intertwined parts of a unified concept of regulation. Indeed,

the ruling of the law depends on the state; and the state changes in response to events that

occur mostly at the discretion of some actors, but only according to the mandatory rules

laid out by the law.

This interdependence between the law and the state under the LGI model is clearly

demonstrated by law CB introduced in Section 3.1. It is this law that defines the semantics

of capabilities, and the manner in which they can be delegated. But the actual distribution

of such capabilities—i.e., the state of the various agents—is determined by the delegate

messages, sent at the discretion of the various actors. An important consequence of this

unification of the traditional MAC and DAC is discussed next.

3.4 Separation of Policy from Mechanism

One of the holy grails of secure computing has been the age-old principle of separation

of policy from mechanism, formulated in the early 1970s, by Wulf et al. [31] and others.

What this principle means, essentially, is that an AC mechanism should be as general as

possible, without a bias to any particular kind of policies, thus accommodating a wide range

of them. But despite the obvious importance of this principle—particularly for complex

systems that need to use multiple policies—it has not been satisfied to a significant degree

by conventional AC mechanism. This is arguably because the failure of these mechanisms

to have the mandatory aspects of a policy explicit.

The situation is very different under the LGI model due to its concept of law. The lack

of bias of this model toward any particular type of policy is evident from our example CB4We are avoiding here the term “policy,” to avoid confusion with the concept of policy under the traditional

AC model.

20

law. Although the LGI model has no built-in concepts of capability, or of delegation, this

law creates a certain interpretation of these concepts, as it can as easily creates others, as

we shall see below. We now demonstrate the degree to which LGI satisfies the principle of

separation of policy from mechanism, via brief case studies of the treatment of two well known

aspects of control—delegation, and role-based access control (RBAC)—under conventional

AC mechanisms, and under LGI.

3.4.1 Delegation—a Case Study

The basic concept of delegation is very simple: it is the giving to somebody else a right that

one has for itself. But there are various possible ways for delegation to be carried out, and

various kinds of constraints that one may want to impose on the process of delegation. We call

a specific choice among these possibilities delegation-regime, which may specify such things as

who is permitted to delegate which privileges to whom, and under which circumstances; and

how such delegation should affect the privileges of the delegator itself. Here is a sample of

possible aspects of such a regime: (1) The requirement that certain rights would be delegated

only by transfer ; that is, the delegator would give up its own right, when delegating it to

somebody else. (2) Some restriction on the number of times a given right may be delegated, if

at all. (3) Making delegation operate as loans, to be returned within a specified time period.

And, of course, one may want to have a sophisticated delegation regime that employs some

combinations of the above mention types of constraints, and others.

Despite the need of different applications to employ different delegation regimes of such

kinds, most conventional AC mechanism employ a fairly simple built-in regime that does

not provide much choice. According to [6], “The standard approach to delegation is binary:

either delegation is possible, and then no substantial further control over the way it is used

is possible, or else no delegation is permitted.” Recently, several more sophisticated delega-

tion regimes have been proposed. In particular, Bandmann et al. [6] proposed a model of

constraint delegation which allows one to control the possible shapes of delegation chains.

Also, Li et al. [18] permitting a fixed upper bound to be imposed on the depth of dele-

gation chains. But each of these delegation regimes requires a new AC mechanism to be

constructed—contrary to the principle of separation of policy from mechanism.

Under the LGI model, on the other hand, the delegation regime is specified by the law of

a community, as it is the case with law CB introduced in Section 3.1. And it is easy to see

21

how other types of delegation regimes can be similarly defined. For a demonstration of how

sophisticated delegation and revocation (the inverse of delegation) regimes can be defined

by a law, under the Moses LGI-based mechanism, see [5, 1].

3.4.2 Role Base Access Control (RBAC)—a Case Study

An important extension of the traditional matrix-based AC model has been the introduction

of the “role-based access control” (RBAC) model, by Sandhu and his colleagues [28]. This

model views roles—which represent such things as the position that a given individual holds

in a given organization—as a set of permissions, and defines an AC-policy essentially as a

pair of mappings: a mapping of users to sets of roles, and a mapping of roles to sets of

permissions. The RBAC model also provides for a hierarchical organization of roles, and

includes certain constraints on the combinations of roles that a given individual can possess

at one time.

The RBAC model has been widely adopted by the industry and been broadly accepted

by the research community. But despite its considerable structural complexity (the official

RBAC has four “reference models” of increasing sophistication) RBAC proved to be overly

restrictive, which gave rise to a host of RBAC-based models that generalized RBAC in

various ways. These generalizations include, but are not limited to: (1) parameterization of

the roles of a subject by its other attributes [11]; (2) making authorization dependent on

some dynamic relationship between the subject, and the object on which it operates [7]; (3)

making the rights associated with a role dependent on the context, such as time and location

[25]; and (4) providing for dynamic, and temporal, control over role-permission activation

and deactivation, and over user-role assignment and activation (TRBAC [8] and GTRBAC

[16]).

Now, the original RBAC model, and each of its extensions, requires a different AC mech-

anism for its support—again, in a sharp breach of the principle of separation of policy from

mechanism.

Under LGI, on the other hand, we have shown in [4] that the original RBAC model itself,

and every one of the above mentioned extensions of it, can be defined simply by writing a

suitable law. And, thus, they can all be realized via a single fully implemented LGI-based

mechanism. And this, despite the fact that LGI has no built-in concept of roles.

22

3.5 On the Global Sway of the Local Laws of LGI

By its very definition, a law L eestablishes a regularity over the entire L-community governed

by it, in that every member of this community responds to events occurring at it according

to the same law L. This does not mean that the members of this community behave in

the same way, because different members may have different states, resulting in different

rulings for the same events occurring in them. But the existence of a common law induces

an order over a community, providing its members with a degree of predictability concerning

the possible behavior of their peers. For instance, and under law CB (of Section 3.1) a term

cap(z,0) has the same meaning for every agent that has it in its CS; and no agent operating

under law MB (see Section 3.2) can send more than N messages.

Structurally, the regularities that can be established via LGI laws are local, in that the

constraint imposed by a given law L on the behavior of every member of the L-community

can be sensitive only to its own local state—due to the local nature of laws. This seems

to imply that non-local constraints, i.e., a constraint defined over the coincidental state

of several (perhaps all) community members, cannot be imposed via LGI laws. A general

definition of the concept of non-local constraints is somewhat problematic because of the

inherent ambiguity of the term “coincidental” in a distributed context. One way to define

this concept involves assuming a central reference monitor that mediates all interactions

between the members of a given community, thus maintaining its global state. Due to space

limitation we will not provide here a formal definition of this concept, but will, instead,

bring the following simple, if synthetic, example of a non-local constraint: the aggregate of

all messages sent by all members of a given community should not exceed a given N .

Fortunately, as has been shown in [24], the locality of LGI laws does not reduce their

expressive power, in the following sense:

Any non-local constraint on interaction that can be implemented via a central

reference monitor, which maintains the global interaction state of the entire com-

munity, can be formulated via a local LGI law.

This important result is due to the ability of LGI laws to mandate the movement of relevant

information from one agent to another, getting such information to the appropriate decision

points. This ability can be used to effectively localize non-local constraints. Of course,

the implementation of a non-local constraint via a local law may involve certain amount

23

of aggregation of information, which may reduce its scalability. But we have found that in

practice, many useful non-local constraints involve modest amounts of aggregation, which

has only a marginal effect of scalability. For more about this matter, see [32].

3.6 Sensitivity to Context

The LGI model seems to be inherently insensitive to anything but the history of the regulated

events that occurred at each agent (which includes the history of interaction of a given agent

with others). This is because the ruling of a law is a function of the pair (event, state), and

the state is itself some function of the history of local events. Nevertheless, we show here

that LGI laws can be written to be effectively sensitive to other things besides the interaction

history. Specifically, we will discuss sensitivity to what we call: (a) credentials, (b) physical

context, and (c) inside information.

Sensitivity to Credential: Much of the trust one is willing to place in actors over the

Internet is based on credentials represented, most notably, by digital certificates. And both

authentication and authorization decisions needs to be sensitive to such credentials. This

gave rise to what is broadly called trust management, and to tools such as KeyNote [9].

LGI can exhibit such sensitivity to credential simply as follows. The law of a community

can be written to accept valid certificates signed by specified CAs, which are contained

in certain messages. For example, a given law L can be written to accept certain types

of messages sent by an actor as a submission of a certificate attesting to the role played

by this actor in a given societal context (say, an enterprise). This law would then verify

the cryptographic validity of this certificate, and that it has been signed by a CA that is

acceptable to this law. If the certificate is found valid and acceptable, then the law can

mandate to record the role attested to by the certificate in the state of agent at hand (say,

by adding to it a term such as role(manager)). Moreover, this law can be written to take

this term into account in its rulings concerning various event.

Although this sensitivity to credential is implicit in the basic LGI model, and requires

no additional elements, the existing Moses mechanism provides some tools for making the

treatment of credentials more convenient. These tools have been described in [22], and their

use has been explored in several papers, such as [1, 5].

24

Sensitivity to Physical Context: By “physical context” we mean here attributes of the

environment in which a given actors operates. These may, for example, be the temperature

and pressure measured by the sensors associated with an actor; or the geographical location

reported by its GPS. Of course, an LGI-based mechanism per se is not aware of such at-

tributes. But it can be made aware of them via the following simple means: (a) the actor in

question sends a message, ostensibly to itself, but really meant to be picked up by the law,

reporting its location, say, as measured by its GPS; (b) the law at hand is written to pick up

this message and to store the reported location in the control-state of this agent. Now, when

the location is stored in the state of an agent it can be taken into account for computing the

ruling of the law for various events occurring at that agent.

Of course, the resulting sensitivity to location, or to other physical attributes, is mean-

ingful only if the self reporting of actors is trustworthy. But this is often the case in practice,

either for specific actors, or even for entire community of them. As an example, consider a

community of cars communicating electronically with each other, subject to some LGI law.

The GPS built into such cars, and the software that manages it, may have been produced

by a single manufacturer, and their behavior may be known and trusted. Various sensor

networks can be handled in a similar fashion.

Sensitivity to Inside Information: By “inside information” we mean information about

some attributes of the internal state of an actor, such as the CPU utilization of its host,

or its stage in whatever computing task it is involved in. Here, like in the case of physical

context, we would rely on self reporting by the actor itself. And, again, such self reporting

needs to be trustworthy to be relayed on by the law. Thus, a law of a certain community

can incorporate information about the dynamically changing internal state of trusted actors,

despite the fact that the LGI model itself views actors as black boxes.

4 Establishing Law-Based Trust

This Section introduces two approaches for establishing law-based trust (L-trust), as required

by the LGI model: (a) mediation of interaction between the actors, by means of decentralized

trusted computing base (TCB); and (b) voluntary compliance by the actors themselves.

25

4.1 Using Trusted Mediators

The technique discussed here for establishing L-trust is the one employed by the Moses LGI-

based mechanism. Under this technique, the private controller TLx of an L-agent x, defined

by Equation 1, is hosted by a process that is independent of the actor a of agent x, and is

running on a different host than that of this actor, anywhere on the Internet. We assume for

now that TLx is trusted—thus the letter “T” in the symbol for controllers—by all members

of the L-community. For the support of this assumption, see Section 4.1.2. A distributed

collection of such controllers are assumed to be available, as is illustrated in Figure 3. We

first discuss the nature of this mediation mechanism, and then explain how it can serve as

the basis for L-trust.

4.1.1 The Mediation Mechanism

The Structure and Operations of Controllers: It is the controller TLx that is viewed

as the locus of the regulated events at agent x. In particular, an arrived event occurs at

controller TLx when a message addressed to x arrives at TL

x . Similarly, a sent event occurs

at TLx when a message sent by its actor a arrives at it, on its way to its target. It is also

the controller TLx that maintain the control-state of agent x, and which can execute control

operations mandated by its law. Structurally, a controller can be described as a triple

(depicted by boxes in Figure 3):

TLx = 〈L, Sx, I〉, (4)

where L is the law under which this particular controller operates; Sx is the control-state

of agent x, which is not directly accessible to the actor of this agent; and I is a generic

mechanism that complies with law L by interpreting this law, and carrying out its rulings,

in the manner defined in Section 2.1.1.

The Dual Mediation Implied by the LGI Model One of the important consequences

of the local nature of LGI laws is that under LGI every message exchange involves dual

control: on the sides of both the sender of a message, and of its receiver. Indeed, the

passage of a message from an actor ax of agent x to an actor ay of y must be mediated

first by the controller Tx associated with of ax, and then by the controller Ty associated

with ay, as is illustrated in Figure 3. This is because both the sender and receiver must

26

I

S

IL

IL

IL

IL

IL

IL

II

Sx SyTyTx

AyAx

S

S

S

S

agent x

agent y

Figure 3: LGI Interaction: Actors are depicted by circles, interacting across the internet

(lightly shaded cloud) via their controllers (boxes) operating under law L. Agents are depicted

by dashed ovals that enclose (actor, controller) pairs. Thin arrows represent messages, and

thick arrows represent modification of state.

individually comply with the law under which each of them operates. This is in contrast

with the conventional AC mechanisms, which use a single reference monitor to mediate the

exchange of messages. Such a reference monitor is usually placed at the server side, or is

used as a central policy decision point (PDP) for an entire system, as under XACML [12].

The dual mediation under LGI has several important implications, not the least of them is

that it facilitates interoperability by providing flexible control over cross-interaction between

agents operating under different laws, as has been shown in [2].

Selective Decentralization of Mediation: Although the mediation of inter-agent in-

teraction under Moses is inherently decentralized—each actor operating via its own con-

troller—this mechanism lends itself to a wide range of choices of partial centralizations, or

even complete centralization, of mediation.

This is due to the fact that private controllers are hosted, under Moses, by the so called

controller pool, each of which capable of hosting a large number5 of private controllers, thus

5Under the current implementation of Moses each controller pool can host several thousand of controllers,

depending on the application.

27

serving several different agents, possibly subject to different laws. A distributed collection

of such controller pools are assumed to be available, as is illustrated in Figure 3.

This allows one to run any given sub-group of controllers on a single controller-pool,

thus creating a whole spectrum of possible implementations of mediation—anything be-

tween complete decentralization, where each controller of a given community operates on a

separate controller-pool, to a complete centralization, where all controllers are hosted by a

single controller pool. The potential for performance optimization inherent in such selective

centralization of mediation is yet to be explored; for some initial ideas about this matter see

[22].

4.1.2 The Basis for L-Trust

The support for L-trust provided by this technique of mediation of inter-agent communica-

tion, as realized by the Moses mechanism, rests on three elements: (a) the assurance that

the message exchange between x and y is mediated by correctly implemented controllers; (b)

the ability of each of these agents to identify the law under which its interlocutor operates;

and (c) the assurance that the messages exchanged between x and y are transmitted securely

over the internet.

The first of these elements means, essentially, that the collection of controller pools

used by the given system must all be trusted to be correctly implemented, and that they

have not been corrupted by some malicious attacks. Such a collection can then serve the

role of a trusted computing base (TCB). But unlike the traditional TCB, which is usually

centralized, our collection of controller is designed to be decentralized, and is thus referred

to as “decentralized TCB”, or DTCB.

Moses implements such a DTCB via what is called a controller service (CoS), which

creates, maintains, and continuously tests, a distributed collection of controller-pools. The

CoS also vouches for the correctness of its controller-pools via digital certificates, which are

used by controllers to authenticate each other as part of their handshake. And there is an

ongoing research on techniques for protecting such a DTCB from various kinds of attacks;

in particular, by intrusion detection, by making it harder to target specific actors, or specific

law; and by other means.

The controller-service provided by Moses can be operated by an enterprise for its own

internal use, or by a federation of enterprises for the use of its members. But if Moses is to

28

be used by arbitrary actors all over the Internet, then the CoS needs to be managed by a

reputable commercial company or governmental institution, whose business it is to provide

its customers with trustworthy controllers. This organization must be willing to vouch for

the trustworthiness of its controllers, and to assume liability for their failures. Such an

Internet wide CoS is yet to be established.

To provide for element (b) above, namely the ability of each agents to identify the law

under which the controller of its interlocutor operates, the handshake between controllers

include exchange of the one way hash [30] of their respective laws. Finally, to provide

for element (c), namely the assurance that L-messages exchanged between x and y are

transmitted securely over the internet, all messages between actors and their controllers, and

between pairs of controllers, need to be digitally signed and encrypted. These conventional,

but rather expensive, measures can be dispensed with if one is not concerned about malicious

attacks on the transfer of messages. (The current release of Moses does not take these

measures, but it can be easily modified to incorporate them.)

4.2 Voluntary Compliance

Consider a set S of actors that agree to interact with each other, subject to a given law L,

thus forming an L-community. An individual member in this set can comply with law L,

without any extra knowledge about its peers, due to the local nature of laws under LGI. In

particular, this can be done by having each member x of S implement its own controller TLx

(see Equation 4) as a stub—in some analogy to the manner in which one conforms to the

TCP/IP communication. But can such purely voluntary compliance be a basis for L-trust?

We maintain that voluntary compliance can be a reasonable basis for L-trust in the

following three cases: (a) when the set S of actors is small and close-knit; (b) when the set

S is homogeneous, even if large; and (c) under some stringent conditions, even when S is

large and heterogeneous.

When a set S of actors is small, and when all its members have been written by one

programmer, or by a small team of programmers working in concert, they can confidently

trust each other to write code that complies with an agreed upon law—in some analogy to

the manner in which the members of a string quartet can trust each other to play the same

music.

When a set S is homogeneous, for example, when its members are copies of a single

29

program, then they can obviously trust each other to conform to the law that is built into

their common code—regardless of the size of the set. This is how birds of a feather flock

together, having their rules of engagement inborn. Note, however, that in these two cases,

the L-trust between the members of set S would be compromised if there is a danger of

malicious attacks on the code of some of these actors, or on the messages exchanged between

them.

Finally, even when the set S is heterogeneous, open, and large, one can still base L-trust

on voluntary compliance with a given law L if the following two conditions are satisfied:

(1) if it is the vested interest of every actor in the system to comply with law L; and (2) if

failure of any given agent x to comply with L ccannot cause any serious harm to anybody

else. Both of these conditions need to be satisfied for L-trust to be effective, because if

condition (1) is not satisfied then there is little chance for L to be universally adopted and

complied with, without some form of enforcement; and if condition (2) is not satisfied, than

one has to worry about someone not observing L—perhaps inadvertently and even contrary

to its own self interest—and thus causing harm to others.

There are some well known applications where both of these conditions are satisfied, at

least approximately. This is what enables the use of HTML for writing web pages, and the use

of IP for communication, to be voluntarily established as de facto “laws” of the Internet. But

for many, perhaps most, applications—including e-commerce, medical applications, various

societal infrastructures, and defense applications—one or both of these conditions are far

from being satisfied. For these critical applications, and others, one has to resort to an

“enforcement” technique, such as described in Section 4.1.

5 Conclusion

This paper introduces a model of interaction control for the regulation of distributed systems,

which can cope with their increasing openness and heterogeneity. The model, called LGI,

differs from conventional access control (AC) in several respects: in its objectives, in its

technical approach, and in its results. The main objective of conventional AC is to permit

access only to those that have the right for it, but without any concern about the dynamic

behavior of those that do get access. LGI, on the other hand, aims to regulate the dynamic

behavior of interacting parties as well.

30

The technical approach adopted by LGI differs from that of AC, in two ways: First,

LGI is inherently decentralized. Second, LGI replaces the conventional concept of policy,

traditionally defined as an access control matrix, with the pair 〈law, state〉. Here the law

holds sway over an entire distributed community, and is fixed; while the state is a distributed

collection of local states, each of which can change dynamically independently of the others,

but subject to the global law.

The consequence of this approach to regulation includes the following results, not matched

by any conventional AC mechanism: (1) Scalability of the support provided for a wide range

of constraints over interaction, mostly due to decentralization. And (2) generality of the

model, due, in part, to its unification of the traditional dichotomy between mandatory

and discretionary policies. Consequently, LGI constitutes a significant realization of the

important principle of separation of policy from mechanism.

Moreover, the LGI model can be reified into a whole family of mechanisms—called LGI-

based mechanisms, which may be designed for different types of communication, and can

add a host of capabilities to those inherent in the model itself. In particular the Moses

mechanism—of which the LGI model is an abstraction—which has been designed for Internet

messaging, has several capabilities not present in the LGI model itself. These include:

(a) proactive control, provided via the concept of enforced obligation, which ensures that

a specified action would be carried out in the future, under specified circumstances [24];

(b) the treatment of certain types of communication failures as regulated events, called

exceptions, which can then be acted upon by the control mechanism, providing a significance

fault-tolerance capability [23]; and (c) the organization of the laws of a given system into

a conformance hierarchy [3], which facilitates the regulation of very complex systems, like

virtual organizations, grids, and dynamic coalitions [2].

We are now considering another LGI-based mechanisms, one defined over wireless com-

munication, to be designed for the needs of pervasive computing.

Acknowledgment: I am indebted to Yaron Minsky for many rewarding discussions on

this topic.

31

A Appendix: Some Details of the Informal Law-

Language Used in this Paper:

Here are some details about the informal law-languages used in this paper: (1) Capitalized

symbols represent variables that can match any string; and “ ” represents a don’t-care sym-

bol. (2) The regulated events in the set E of this mechanism consists of: (a) adopted, which

represents the first event in the lifetime of the agent; (b) sent(Msg,Target), which repre-

sents the sending of message Msg to the specified target; and (c) arrived(Sender, Msg),

which represents the arrival at the home agent of the specified message, sent by the specified

sender. (3) The control state of an agent is represented as a bag of terms, whose structure

is left unspecified here. And (4) The control operations available under this mechanism

include: (a) forward(Msg,Target), which forwards the specified message to its target (a

shorter variant, forward, usable only in a rule that deals with a sent event, forwards the

message sent to its intended target); (b) deliver(Text) delivers the specified text to the

actor of the home agent (a shorter variant, simply deliver, delivers the arriving message to

the home actor); and (c) several operations on the state, including +T, which adds the term

T to the state, (additional such operations are, as needed, in our examples).

References

[1] X. Ao, N. Minsky, and V. Ungureanu. Formal treatment of certificate revoca-

tion under communal access control. In Proc. of the 2001 IEEE Symposium on

Security and Privacy, May 2001, Oakland California, May 2001. (available from

http://www.cs.rutgers.edu/~minsky/pubs.html).

[2] X. Ao and N. H. Minsky. Flexible regulation of distributed coalitions. In LNCS 2808: the

Proc. of the European Symposium on Research in Computer Security (ESORICS) 2003,

October 2003. (available from http://www.cs.rutgers.edu/~minsky/pubs.html).

[3] X. Ao, N. H. Minsky, and T. Nguyen. A hierarchical policy specification language, and

enforcement mechanism, for governing digital enterprises. In Proc. of the IEEE 3rd In-

ternational Workshop on Policies for Distributed Systems and Networks Monterey Cali-

fornia, June 2002. (available from http://www.cs.rutgers.edu/~minsky/pubs.html).

32

[4] X. Ao and Naftaly H. Minsky. On the role of roles: from role-based to role-

sensitive access control. In Proc. of the 9th ACM Symposium on Access Control

Models and Technologies, Yorktown Hights, NY, USA, June 2004. (available from

http://www.cs.rutgers.edu/~minsky/pubs.html).

[5] Xuhui Ao and Naftaly H. Minsky. Regulated delegation in distributed sys-

tems. In Proc. of the IEEE 7th International Workshop on Policies for Distributed

Systems and Networks, London, Ontario, Canada, June 2006. (available from

http://www.cs.rutgers.edu/~minsky/pubs.html).

[6] Olav Bandmann, Mads Dam, and Babak Sadighi Firozabadi. Constrained delegations.

In proceedings of 2002 IEEE Symposium on Security and Privacy, May 2002.

[7] J. Barkley, K. Beznosov, and J. Uppal. Supporting relationships in access control using

role based access control. In Proceedings of the Fourth ACM Workshop on Role-Based

Access Control, pages 55–65, October 1999.

[8] Elisa Bertino, Piero A. Bonatti, and Elena Ferrari. Trbac: A temporal role-based access

control model. ACM Transactions on Information and System Security, 4(3):191–233,

2001.

[9] M. Blaze, J. Feigenbaum, J. Ioannidis, and A. Keromytis. The keynote trust-

management systems, version 2. ietf rfc 2704. Sep 1999.

[10] N. Damianou, N. Dulay, E. Lupu, and M. Sloman. The ponder policy specification

language. In Morris Sloman, editor, Proc. of Policy Worshop, 2001, Bristol UK, January

2001.

[11] Luigi Giuri and Pietro Iglio. Role templates for content-based access control. In Pro-

ceedings of the Second ACM Workshop on Role-Based Access Control (RBAC’97), pages

153–159, 1997.

[12] S. Godic and T. Moses. Oasis extensible access control. markup language

(xacml), version 2. Technical report, Oasis, March 2005. (available at

http://xml.coverpages.org/ni2004-10-05-a.html ).

33

[13] R.J. Hayton, J.M. Bacon, and K. Moody. Access control in an open distributed enviro-

ment. In Proceedings of the 1998 IEEE Symposium on Security and Privacy, 1998.

[14] S. jajodia, P. Samarati, M. L. Sapino, and V. S. Subramanian. Flexible support for

multiple access control policies. ACM Trans. on Database Systems, 26(2):214–260, June

2001.

[15] J. J. Jen, H. Chang, and J. Y. Chung. A policy framework for web-service based

business activity management (bam). Journal of Information Systems and e-Business

Management, 1(2), April 2004.

[16] James B. D. Joshi, Elisa Bertino, Basit Sahfiq, and Arif Ghafoor. Dependencies and

separation of duty constraints in gtrbac. In Proceedings of the 8th ACM Symposium on

Access Control Models and Technologies (SACMAT 2003), 2003.

[17] G. Karjoth. The authorization service of tivoli policy director. In Proc. of the 17th

Annual Computer Security Applications Conference (ACSAC 2001), December 2001.

[18] Ninghui Li, Benjamin N. Grosof, and Joan Feigenbaum. Delegation logic: A logic-based

approach to distributed authorization. ACM Transaction on Information and System

Security (TISSEC), pages 128–171, Feb 2003.

[19] N.A. Lynch and Tuttle M.R. An introduction to input/output automata. Technical

report, MIT, November 1988.

[20] Naftaly H. Minsky. The imposition of protocols over open distributed systems. IEEE

Transactions on Software Engineering, February 1991.

[21] Naftaly H. Minsky. A decentralized treatment of a highly distributed chinese-wall policy.

In Proc. of the IEEE 5th International Workshop on Policies for Distributed Systems

and Networks, Yorktown Hights, NY, USA, June 2004. (to be published; available from

http://www.cs.rutgers.edu/~minsky/pubs.html).

[22] Naftaly H. Minsky. Law Governed Interaction (LGI): A Distributed Coordination and

Control Mechanism (An Introduction, and a Reference Manual), June 2005. (available

at http://www.moses.rutgers.edu/documentation/manual.pdf).

34

[23] Naftaly H. Minsky and T. Murata. On manageability and robustness of open multi-agent

systems. In Carlos Lucena, Alessandro Garcia, Alexander Romanovsky, Jaelson Castro, ,

and Paulo Alencar, editors, Computer Security, Dependability, and Assurance. lncs 2940,

February 2004. (available from http://www.cs.rutgers.edu/~minsky/pubs.html).

[24] Naftaly H. Minsky and V. Ungureanu. Law-governed interaction: a coordination and

control mechanism for heterogeneous distributed systems. TOSEM, ACM Transactions

on Software Engineering and Methodology, 9(3):273–305, July 2000. (available from

http://www.cs.rutgers.edu/~minsky/pubs.html).

[25] M.J. Moyer and M. Abamad. Generalized role-based access control. In Proceedings of

the 21st International Conference on Distributed Computing Systems, pages 391–398,

2001.

[26] M. P. Papazoglou, P. Traverso, S. Dustdar, F. Leymann, and B. J. Kramer. Service-

oriented computing: A research roadmap. In Francisco Cubera, editor, Service Oriented

Computing (SOC), number 05462 in Dagstuhl Seminar Proceedings. Internationales

Begegnungs, 2006.

[27] Carlos Ribeiro and Paulo Ferreira. A policy-oriented language for expressing security

specifications. International Journal of Network Security, 5(3):299–316, November 2007.

[28] R.S. Sandhu, D. Ferraiolo, and R. Kuhn. The nist model for role-based access control:

Towards a unified standard. In Proceedings of ACM Workshop on Role-Based Access

Control. ACM, July 2000.

[29] F.B. Schneider, editor. Trust in Cyberspace. National Academy Press, 1999.

[30] B. Schneier. Applied Cryptography. John Wiley and Sons, 1996.

[31] W. Wulf, E. Cohen, W. Corwin, A. Jones, C. Levin, C. Pierson, and F. Pollack. Hydra:

The kernel of a multiprocessor operating system. Communications of the ACM, 17:337–

345, 1974.

[32] Wenxuan Zhang, Constantin Serban, and Naftaly H. Minsky. Establishing global prop-

erties of multi-agent systems via local laws. In Danny Weyns, editor, Environments for

Multiagent Systems III, LNAI 4389, pages 170–183. Springer-Verlag, 2007.

35