Multilevel Access Controlfor Environments with Object & Node Mobility

Jehan Wickramasuriya & Nalini VenkatasubramanianDept. of Information & Computer Science

University of California, IrvineIrvine, CA 92697-3425, USA

{jwickram,nalini}@ics.uci.edu

Carolyn L. TalcottComputer Science Laboratory

SRI InternationalMenlo Park, CA 94025, USA

clt@cs.stanford.edu

Abstract

The need for addressing security concerns in mobile, distributed environments is well known. However,

providing security mechanisms at the application layer is usually insufficient, especially when considering

object-oriented (OO) systems. This paper presents a domain-based approach to access control in a dis-

tributed environment with mobile objects and nodes. The dynamic nature and semantic diversity of OO

systems make it difficult to ensure information security and integrity via traditional access control meth-

ods. One of the challenges we tackle in this work is that of hiding sensitive information in insecure en-

vironments, by providing objects in the system a ’view’ of their state information, and subsequently man-

aging this view. We present a middleware-based architecture for providing access control in such an envi-

ronment and view-sensitive mechanisms for protection of resources while both objects and hosts are mobile.

We examine issues with delegation and revocation in the context of this architecture and discuss perfor-

mance issues in supporting these solutions, as well as an initial prototype implementation in the context of

a composable middleware framework, CompOSE|Q being developed at the University of California, Irvine.

Keywords: Access control, Mobility, Objects, Distributed systems, Meta-Architecture, Actors, Middleware,

Reflection, Security.

1 Introduction

Traditionally, distributed computing has always implied a vast, heterogenous environment usually connected by a

fixed network structure and nodes that communicate with each other via this network, generally through message-

passing. Introducing the concept of mobility complicates these traditional mechanisms and forces us to re-evaluate

how we view the system. Security is of paramount importance in highly mobile, distributed environments, both

from the perspective of a mobile host, as well as the object-level operations being performed on the host itself.

In addition to providing security at the application level, access control mechanisms are needed to prevent service

and content providers, as well as unauthorized personnel gaining access to client data and resources. Furthermore,

multilevel security can play a large part in secure information processing, by allowing entities to be associated with

different security classifications while sharing data in a safe manner, without the danger of ’leaking’ sensitive data

to unauthorized users. Security domains can be used to define access boundaries in large-scale networked systems.

For the purpose of this work, we assume the network space is partitioned into a set of federated domains, each

with varying security levels (levels of sensitivity). These levels effectively provide an administrative, domain-based

partition of the network and can be used as the basis to regulate access to various resources resident on nodes (both

fixed and mobile). The main goal of our work is to provide seamless application execution in object-based mobile

environments while preserving security constraints.

1

In highly dynamic, mobile environments we can identify two types of mobility; object mobility and node mobility.

Object mobility concerns the movement of individual objects between nodes in the network. These objects may be

dynamically created within a node and migrate from node to node within the network carrying possibly sensitive

state information. Node mobility refers to the physical movement of mobile hosts (e.g. laptop, PDA etc.) in a

distributed environment. The concept of object and node mobility is similar to the notion of logical and physical

mobility, introduced by Roman et. al [22] and Cardelli et. al (virtual and physical mobility) [7]. Combining the

two (which mimics what would happen in a typical setting) provides many challenges in coordinating movement,

maintaining concurrency and providing secure access to resources. Context [22] with respect to mobility repre-

sents a host’s location as well as its resources, services and other such components that represent a mobile unit’s

environment at any given time. This environment can vary dynamically depending on factors such as location,

residual power etc. Combining the notion of context awareness with access control facilitates seamless application

execution in the presence of object/node mobility and flexibility without sacrificing access control requirements.

Normally, when an application operating on secure content moves between security domains (i.e. the node moves

into a hostile environment), it may need to be restarted after the user has determined what content to hide (or

restore) and proceeds appropriately. This process can be achieved seamlessly using techniques proposed in this

paper.

We define a ’view’ of an object as the local representation of its state in the existing context. An object’s view

changes as it moves in and out of domains with varying security levels. Since not all state information may be

accessible to an object at any point in time, a trusted repository is required to store sensitive information that

needs to be hidden from an object. These operations should be transparent to the user, and the onus falls on the

middleware to implement policies and algorithms to provide this functionality. This approach supplements and

parallels current firewall-based approaches to corporate security by ’filtering’ out sensitive information at the object

level. Our goal is that of providing secure access in insecure environments, by not exposing sensitive data in these

insecure environments, and doing this in an efficient manner.

In this paper, we present an architecture for providing access control in a highly mobile environment for both

mobile objects and hosts (presented in Section 2). This type of architecture should typically be coupled with

an underlying access control architecture that provides traditional control of resources (or objects in this case).

Previous work looked at a capability-based access control model that focused on enforcement at the messaging layer

[31]. We define an object’s ’view’ as the local representation of its state, and attempt to dynamically assign and

manage these views under varying mobility conditions. In Section 3 we introduce the concept of view management

and maintenance as applicable to our notion of access control. We also present an algorithm for establishing views for

active objects in an environment where both nodes and objects are mobile, and provide some descriptions and rules

for domain-based access control. Section 4 discusses the challenge of providing delegation and revocation in a highly

mobile environment. We present a number of different simulation results in Section 5, analyzing performance of our

view management algorithm in order to identify classes of schemes that work well depending on various mobility

conditions. An initial prototype implementation of our underlying access control framework is also described, as

well as some initial accompanying results. This framework has been implemented within the CompOSE|Q system,

2

a QoS-enabled reflective middleware framework being developed at the University of California, Irvine. 1 Finally

in Section 6 we discuss related work in the area and some future research directions.

2 Supporting Object & Node Mobility

Existing security mechanisms which are applied in a fixed network infrastructure are further complicated by the

introduction of node mobility. Frequent disconnection, resource constraints and context-aware mobility provide

added complexity to access control mechanisms. We utilize the actor [1] model of computation to represent

objects, which provides us some useful properties that inherently make access control simpler, and provide a formal

model on which we build invariants for our framework. In this section, we elaborate on the challenges that will be

addressed in this paper, and present a system architecture on which we model the solutions to these challenges.

• View Establishment & Maintenance: The challenge here is to provide efficient algorithms for both establishing

local views for objects on mobile hosts and furthermore maintaining these views given changing mobility

conditions. One factor in deciding when to make changes to an objects’ local view is that of location. Due

to the nature of the environment, we need to consider both object tracking as well as node tracking. These

mechanisms need to be highly scalable, as objects (and nodes) may migrate frequently and in an unpredictable

manner. Message delivery is also an issue; handling messages in transit destined to objects in varying domains

may result in messages that are undeliverable (due to access control policy) possibly becoming deliverable

later. The problem of providing secure message delivery is beyond the scope of this paper but guaranteed

delivery of secure messages to mobile objects on mobile hosts is an area of future work. As part of tackling

this challenge of view management, we describe how we model views using our object-based framework and

provide algorithms and conditions for achieving view maintenance.

• Delegation & Revocation: Providing mechanisms for delegation and revocation with object and node mobility.

Complications may arise as a result of the mobility, as well as the varying security constraints an object or

node may have as a result of its location or application requirements. A particular example of this occurs

when an object with revocable access rights (resident on a node with the appropriate security level) moves to

a less secure domain (thereby losing sensitive state/data, which may be required for the delegated activity).

Another problem may be the fact that revocation cannot be carried out in a timely manner due to varying

degrees of mobility (e.g. the object could be moving from node to node in a rapid manner).

• Disconnection: Disconnection is a common occurrence in mobile environments, and although an object may

have its local view upon disconnection, the problem of re-evaluating access rights depending on where the

node ’appears’ next must be addressed (passive mobility). In addition, message delivery issues are again of

concern, as messages destined for an object (in transit) may not be deliverable upon reconnection due to

varying security constraints.

1CompOSE|Q is based on a meta-architectural model that facilitates specifying and reasoning about the composability of multipleresource management services in open distributed systems.

3

Fig. 1: Meta-level Security Architecture: Depicts layering of the systemarchitecture, and the security components utilized by the meta-securityactor.

Fig. 2: Representing an Object: An actor en-capsulating a thread and state as well as a setof methods and acquaintances. The greyed outregions indicate state that may be hidden aspart of it’s current view requirements.

Actors & The Two-Level MetaArchitecture (TLAM Model):

To simplify development of applications, we use Actors [1], a model of concurrent active objects that has a built-in

notion of encapsulation and interaction among the concurrent components of an ODS. In the actor paradigm,

the universe contains computational agents called actors, distributed over a network. Traditional passive objects

encapsulate state and a set of procedures that manipulate the state; actors extend this by encapsulating a thread

of control as well. It should be noted that actors have a conceptual location (or address) as well as a behavior

associated with them. Actor names (addresses) are uniquely tied to the identity of an actor and giving out the

actor’s name does not enable the recipient to receive messages directed to that actor [26]. In addition, as oppose

to traditional systems where there exists a user to object relationship (e.g. users having access types such as read

and write to objects) in an actor-based system, access control is better enforced from the point of view of incoming

and outgoing messages to a particular actor. Thus, primitive types used in traditional models (such as read and

write) are usually encapsulated using an execute method.

Each actor potentially executes in parallel with other actors and may communicate with other actors (its ac-

quaintances) via asynchronous message passing. Acquaintance laws dictate that acquaintances may be obtained

(a)when an actor is initialized, (b)when new actors are created and (c)when communicated in a message. Us-

ing Actors, we define a two level meta-architectural framework (TLAM) that permits customization of resource

management mechanisms such as placement, scheduling and synchronization. In the TLAM model [28], a system

contains two kinds of actors - base level actors and meta level actors. Base actors carry out application level

computation while meta level actors are a part of the runtime environment, and implement system-level resource

management activities. Meta-actors communicate with each other via meta-level messages, however, they may

examine and modify information corresponding to base-level actors residing on the same node.

Modelling Access Control Using the Actor Model: Given that we represent objects in our system as actors,

we can define an object model with regard to representing (passive) resources in the architecture.

• Any entity that needs to be protected must be represented as an object/actor. This includes passive entities

such as files, and operations on these entities (such as read and write for a file for example) are implemented

as methods of the actor and would be accessed like any other active object (message passing). An object may

4

Fig. 3: System Architecture

also have some state information (e.g. variables) in addition to a list of acquaintances as shown in Fig. 2.

• Given the statement above, the only way for an object to access any other entity (which are also objects)

is by message passing, and should hence have the address of that object as part of its set of acquaintances.

This way we can control access to all resources in the system (provided they are modelled as actors).

• The primary component in the access control model is the Meta-Level Security Actor (MSA), which is resident

on each node and responsible for handling messages destined to actors residing on that node. Variations of

this MSA (with subsets of the functionality) are also used in conjunction with the runtime utilized on the

mobile hosts. This MSA also holds domain information for both mobile and fixed hosts, based on the static

partition of the network space done apriori. This basic functionality can be partitioned in any way, depending

on the system environment.

2.1 System Architecture

The intended system environment is depicted in Fig. 3 and consists of; a directory service, which is assumed

to be a trusted entity and stores access control information as well as sensitive state and data associated with

objects and nodes; A trusted middleware service library, whereby various core service modules can be loaded

and unloaded dynamically (the security component being one of them). The network is partitioned into a set of

non-overlapping domains, which may be fine-grained (encompassing a single host) or course-grained. Mediating

access to the directory service is a set of Meta-security actors (MSA). Functionally, there are two types of MSAs;

a regional MSA (for mobile hosts) and local MSAs (running on either mobile hosts or fixed machines). These

regional MSAs can be running on multiple distributed server machines throughout the network (e.g. on a per

domain basis) or stand alone mobile hosts. Communication between the MSAs and the directory service is carried

out in a secure manner (e.g. using SSL). Nodes are modelled as thin clients, with a small runtime installed on the

mobile hosts that assists in providing and manipulating the local view at the host. This runtime is known as a

5

Mobile-MSA (MMSA) and is a stripped down version of the (local) Meta-security actor that resides on fixed nodes.

Optimizing communication between this entity and the MSA is of paramount importance, as well as implementing

algorithms that approximate a view for the node in order to minimize resource use. The functionality of the various

meta-security entities is outlined in Fig. 4.

delegation/revocation etc.). 1. Encapsulates and inteprets security policy as part of its behavior (view management,

2. Mutual authentication of meta-level communication.

4. Capability insertion/verification for outgoing/incoming messages. (a) Verification that incoming messages to a particular actor have the necessary rights. (b) Tagging outgoing messages with capabilities (for the sender) and maintaining system-wide capability information for all objects in the DS, as well as caching this information locally.

3. Authenticate and establish secure connections with directory services (e.g. SSL-based).

1. Mutual authentication of meta-level communication. 2. Authenticate and establish secure connections with directory services (e.g. SSL-based) 3. Maintain and update access control information pertaining to nodes in its domain (region). 4. Processing rights associated with messages from/to all mobile hosts in its domain, as well as routing these messages to the respective hosts (piggy-back access control information with messages).

1. Maintain local view of objects on the node.

LMSA (mobile nodes)

LMSA (non-mobile nodes)

RMSA (regional)

Fig. 4: Meta-security Functionality.

We make some initial assumptions about the execution environment: (a) Meta-Level Actors do not require

additional AC mechanisms (i.e. they are treated the same as regular actors, but with no restrictions); (b) Commu-

nication is secure. In other words, messages cannot be stolen, or tampered with in transit; (c) The acquaintance

lists of actors and actor annotations cannot be tampered with (other than by the meta-security actors); (d) All

methods within an actor are treated in a similar manner. 2

Location Management & Message Delivery: The key issue here is the interaction between location manage-

ment algorithms and secure object mobility mechanisms. It should be noted that while object mobility can be

constrained (by the system), in general the node mobility cannot. Delivery of messages to objects can be handled

as follows;

• to static objects on moving nodes: On a message send, the DS is queried for the current position of the

object. The position of the node is then returned, or an error message if the server doesn’t have a mapping

for it (in which case the message is discarded and has to be resent). After a given period of time the DS

2(i.e. at the moment we do not provide specialized access rights/policies for the execute behavior (protection of object references,specific method calls etc.), but this is certainly possible and is being looked at for future work.)

6

refreshes the position of the node (bulk refreshes for nodes on a per domain basis to reduce bandwidth and

the number of queries). These location entries also include a validity period to prevent stale entries from

overloading the DS. Any outgoing messages are captured by the host MSA, processed and tagged with the

necessary capabilities (which may be part of the application requirements, or simply specified via a policy

that the MSA simply interprets). Once the message is routed to the target domain, the RMSA extracts

the necessary information and processes it before forwarding (if access rights / view constraints allow it) the

message to the target object.

• to moving objects on moving nodes: Here an additional complication is that objects may have migrated

to new hosts, after the mapping has been retrieved from the DS. However as an extra step of indirection,

a forwarder will exist from the last known position of the object to the new one (this may happen several

times).

• to static objects on static nodes: The resident LMSA on the fixed node simply looks up the position of the

object at the DS (if it is not present in its own cache). Incoming and outgoing messages are in a similar

fashion to the previous two cases.

3 View Management & Maintenance

Here we present algorithms and discuss solutions for both establishing local views for objects on mobile hosts and

maintaining these views, given changing mobility conditions. The view management process changes the local

representation of state of an actor, thereby allowing dynamic protection of potentially sensitive information in

mobile environments. Managing the content of an object’s state (or local view) should take into account the

various possibilities that can occur as part of the behavior of an object (migration, disconnection etc.). In the

context of our architecture, we present techniques for managing this view information, both on the local nodes and

domains as well as at the directory service.

We specify the following definitions used in the development of the view management algorithms. We also define

invariants that the view management process must obey to accommodate varying mobility conditions.

Definition 3.1 (Actor-related):

• dom(α) returns the current domain of an actor α.

Additionally, ∀α ∈ dom → ∀node ∈ dom , ∀α ∈ node

• acq(α) is the (finite) set of acquaintances of an actor. acq(α) specifies the actors known to an actor, and thus

determines the possible actors to who that actor can send messages.

Definition 3.2 (Security level (SL)): A function, which when applied to an actor α returns the security level

of α. SL, when applied to a domain dom, also returns the security level of that domain and presently is modelled

with levels (a) Level 3 (L3) - high-level, (b) Level 2 (L2) - medium-level, (c) Level 1 (L1) - low-level and (d) Level

0 - no security. SLmax refers to the maximum security level of an actor, and is usually the security level assigned

at the time of creation.

SL(α) ⇒ x, where x is the SL of the actor α and x ∈ {L0,L1,L2,L3}.

7

Definition 3.2(a) (Security Level Reduction / Restoration): For a security level l, a function

SL Reduce(α, l) which when applied to an actor α returns the updated view for it by stripping out state and

acquaintances that violate DBAC 3.4. The inverse function, SL Restore(α, l) restores state information and

acquaintance information corresponding to security level l. The idea is that reduction and restoration should be

transparent, if the actor hasn’t otherwise changed state. Thus,

SL(α) = l’ ≥ l, SL Restore(SL Reduce(α, l), l′) = α

Additionally, incremental restoration has the same effect as carrying out SL Restore in one step.

For example, if l0 < l1 < l2 and SL(α) = l2;

α0 = SL Reduce(α, l0)α1 = SL Restore(α, l1)α2 = SL Restore(α0, l2)α2′ = SL Restore(α1, l2)

then α2 = α2′

Definition 3.2(b) (Security Domain): We define a security domain to be a collection of nodes, with an assigned

security level as defined previously.

Definition 3.3 (View): We define a view as a representation (encompassing both state and acquaintances) of all

actors on a given node at a point in time. That is, the collective state and data associated with each object on

a host. This view corresponds to a security level (SL) associated with a node. The total view of an object is the

view at the highest security level, which is represented in the directory service (containing possible acquaintances

and state). State information pertaining to an actor can be factored into security levels such that higher level

information can be restored even when lower level state has changed. There is a function SL Project such that;

SL Project(α, l) represents the information pertaining to security level l, which is empty if SL(α) < l:

state(α) = join(l ∈ L0,L1,L2,L3) SL Project(α, l)

state(SL Reduce(α, l)) = join(l’ ∈ L0,L1,L2,L3) SL Project(α, l′)

3.1 An Algorithm for View Management

Given the issues outlined in the previous section, we present a view management algorithm that takes into account

the various cases in which the view for an object can change. The algorithm is outlined in Fig. 5.

On startup, view refresh is an auxiliary process that is used on both a clean start (where no objects exist on

the system) as well as on restoring the system. The view refresh process bases the upper bound for restoration

on the SL for the object at the time of creation rather. The capabilities and security levels held by the objects

are determined by the principle that initiates the application. SL Reduce safely strips the necessary state and

acquaintance information from the actor, and stores it in the directory service (is also cached at the MSA);

SL Restore performs the inverse operation. This algorithm merely manages that state information, and it is

the responsibility of the meta-actors to maintain individual access rights for objects on their nodes (or domains).

Startup adheres to properties DBAC 3.4 and 3.5 defined below.

If an object migrates to a host in a domain of lower SL (in relation to the current domain of residence), the

SL of that object is decreased to match the target domain. Any state and acquaintance information of higher SL

8

is captured and held at the directory service. The object’s local view is updated to represent this change in state

(preserves DBAC 3.8). For node migration, if we assume the SL of a node is n, then the objects on that node have

a SL of less than or equal to n. When a node migrates to a new domain of SL less than its current SL, all objects

presently resident on the node must be treated in a manner similar to if it was merely the object moving into

the new domain. For disconnection, we identify the following three types of disconnection scenarios; (a) Sign-off

(shutdown); (b) Log-off (pseudo-state, where the host is disconnected, but remains registered with the directory

service); (c) Failure (unexpected disconnection). Reconnection or recovery of a disconnected node (which may be

failed unexpectedly) requires that it first authenticate itself with the regional MSA, which then refreshes the view

on the node in case of a domain change. On shutdown, objects are serialized and stored at the directory service,

along with the current view (acquaintances and state) at the time.

To ensure safe interaction between domain-based access control and object and node migration, the view

management process must satisfy the following key invariants:

DBAC 3.4 (Domain Security): For all domains, every actor, α must have a security level (SL), less than that

of the resident domain dom.

∀α ∈ dom, SL(α) ≤ SL(dom), for all domains dom (1)

DBAC 3.5 (Actor Creation): For all domains, we cannot create an actor α, with a security level higher than

that dictated by the resident domain. Furthermore, the security level of an actor cannot exceed that of the level

assigned at creation (represented as SLmax in Fig. 5). Furthermore, we can introduce two functions, SL cr(α) and

cr(α) where the former is the SL at the time of creation and cr(α) represents the actor’s creator. Then we require;

SL(α) ≤ SL cr(α) and SL cr(α)) ≤ SL cr(cr(α))

Using DBAC 3.4, this means that if dom is where α is created, then

SL cr(α) ≤ SL(dom) (2)

which is also an upperbound on SL(cr(α)).

DBAC 3.6 (Aquaintance & Message Relations): To constrain the security level of an actor α’s aquaintances

we can utilize the creation time SL (SL cr(α));

SL(α) ≥ SL cr(α′) for α′ ∈ acq(α) (3)

Given that actor is created obeying domain security the message policy might ensure that it’s continued, but if

the message is tracking the target from place to place it’s not obvious that this is the case. Hence, the following

additional constraint should be obeyed. An actor α can only send a message msg to actor α′ if;

∀α′′ ∈ acq(msg)), SL cr(α′′) ≤ SL(dom(α′))

DBAC 3.7 (Migration Preserves Domain Ordering): Given the migration of an actor α to domain dom2

and DBAC 3.4, we can firstly observe the fact that migration must preserve security levels (otherwise, a view

adjustment is required). For a request M, to move actor α to node ν

SL(α) ≤ SL(domv), where ν ∈ domv (4)

9

}

FOR all a in n IF SL(a) > SL(dom(n)) SL_Reduce(a,SL(dom(n))); ELSE IF SLmax(a) < SL(dom(n)) SL_Restore(a,SLmax(a));

view_refresh(n,dom) {

switch (event) {

case 1: \\ Startup

case 2: \\ Object Migration

case 3: \\ Node Migration

Initialize MSA; Authenticate & establish secure connection (e.g. SSL) to DS; FOR all registered nodes n (where n is in dom) view_refresh(n,dom); break;

FOR a migration_request(a,v) IF ( SL(a) > SL(dom(v)) SL_Reduce(a,SL(dom(v))) ) ELSE IF ( (SL(a) < SL(dom(v))) AND (SLmax(a) < SL(dom(n))) ) SL_Restore(a,SL(dom(v))); break;

FOR a boundary crossing by a node n, into a domain, dom MSA (regional) authenticates n; view_refresh(n,dom); break;

case 4: \\ Node Disconnection IF (node_state = LOG_OFF) MSA (regional) captures local view of node for view_TTL (view time−to−live); After view_TTL expires, view is committed to DS; MSA (regional) queues messages destined for node (no msg_timeout); ELSE \\ node_state = FAILURE MSA (regional) queues messages destined for node (with msg_timeout); break;

case 5: \\ Node Reconnection

View Management Algorithm

on reconnect (n) MSA (regional) authenticates n; view_refresh(n,dom); IF ( (n has queued messages) AND (msg_timeout has not expired) ) MSA (regional) routes messages to objects on n; break;

case 6: \\ Shutdown State, acquaintance and access rights information from the MSAs (local non−mobile, and regional) committed to DS; break;

Fig. 5: The View Management Algorithm.

10

DBAC 3.8 (Decrease in Security Level Maintains Acquaintance Relations): When an actor α, migrates

to a domain of lower security level (in relation to the current domain of residence) the SL of α is decreased to

match the target domain (Definition 3.2(a)). In addition, any of α’s acquaintances of higher SL must be extracted

and stored at the directory service3 before the migration process continues.

View Approximation: View approximation is an optimization to reduce the frequency of reconfiguration, given

rapidly changing mobility conditions. A view is associated with the current location (more specifically a domain)

of an object. Assuming the underlying location management system uses a history-based profiling mechanism

the algorithm looks to identify common movement patterns and then approximate the view to prevent excessive

computation of constantly switching state. We assume the profile information and location management algorithm

provides this (e.g. one simple metric is the number of boundary crossings between domains). In such a case, we

adjust the view to be the most conservative possible given the movement patterns of the node (SL(min{domains in

pattern})). An issue with view approximation is that critical information may not be accessible even when a node

has the required rights (SL) to access it because of the approximation. We propose the following solutions;

1. Trigger events on critical state information that will force a view refresh if necessary

2. Allow the user/application to control how far the view on a host should be allowed to diverge from its base

view.

It should be noted that the view approximation optimizations only hold when the node/object moves in and out

of the profile domains. Any abberations from these patterns will trigger the normal restoration and reduction

behavior.

4 Delegation & Revocation

Explicit transfer of access rights via a delegation process is a desirable component of an access control model.

Delegation is particularly useful in mobile environments where it may be necessary to have machines with more

resources perform certain computationally expensive tasks (i.e. cryptographic methods) on behalf of a mobile

client, both online and offline. Assuming authority is successfully delegated, at some point in time the delegator

may decide to revoke the delegated rights. However, providing delegation & revocation in a secure and relatively

efficient manner generally presents difficulties. For instance, cryptographic approaches (e.g. Kerberos [18] and

Delegation Certificates [2]) involve potentially large computational and communication overheads, which are unac-

ceptable in mobile environments where resources are at a premium. When considering highly dynamic and mobile

environments, there can be mobility during the delegation/revocation process which may lead to complications; (a)

consider the case where a delegate keeps hopping frequently (migrating) from node to node; (b) in a domain-based

environment with varying security levels, delegation and/or revocation may not be immediately possible due to the

varying security constraints of different domains.

Our access control architecture supports delegation and revocation in the following manner; the MSA on each

node encapsulates the behavior reflecting the desired policy for delegation and contains information about which

3The key notion here is that α not be allowed to leak acquaintances of higher SL to less secure domains, these acquaintances maybe discarded (no restore) or held securely if necessary.

11

validity_period, cascadable, restrict_info) {

IF request is local THEN MSA validates request IF max(SL(rights)) <= SL(SLmax(delegatee_aid)) THEN Add permissions to delegatee’s set of access rights Send acknowledgement to delegator (success) ELSE Send acknowledgement to delegator (failure) ENDELSE DS Lookup location of delegatee MSA Forward request to MSA Target MSA processes delegation_requestEND.

}

delegation_request (delegator_aid, delegatee_aid, rights,

}

revocation_request (tgt_aid, rights) {

IF request is local THEN MSA updates access rights information by removing rights corresponding to the given object (tgt_aid)ELSE // tgt_aid is on a remote node Forward request to global MSA Target MSA processes revocation_request

given object (tgt_aid)

Broadcast a (cache) refresh to all

IF cascadable THEN revoke rights for all sub-delegationsENDEND.

local / regional MSAs (policy dependent)

Update rights information directly in the DS by removing rights corresponding to the

Fig. 6: The Delegation & Revocation Processes.

objects are allowed to delegate authority etc. It should be noted that expiration of delegations is also supported

via the native ability provided by the capability objects themselves. Delegation in our framework is carried out as

shown in Fig. 6 where an actor α wishes to delegate a subset of its permissions to an actor β.

Note that we allow delegation to proceed even if the security level (SL) corresponding to the current view of the

delegatee actor is below the maximum SL of the rights being delegated. Here, all that needs to be enforced is the

fact that the delegatee’s security level at its default view is at least as high as the maximum SL of the rights. This

doesn’t cause any problems when the delegatee is at a view that falls below this maximum SL as these delegated

rights (acquaintances) will be not be accessible to it anyway. If and when it returns to a security level sufficiently

high enough to utilize these rights, they will appear naturally as part of the actor’s capability list (unless the

delegation has expired or been revoked).

For revocation, introduction of node mobility complicates the already difficult issue of revoking access rights

in a timely manner. If the system is constrained to object mobility, then it is possible to locate the object whose

rights need to be revoked and restrict its movement until this can be achieved. However with node mobility, we

cannot constrain the mobility of a mobile device. The original delegate has the authority to revoke access rights

(via the MSA), and currently, subsequent revocation of these rights would in turn also revoke all sub-delegations

(cascading). Additional entities may be allowed to revoke delegations, but this must be specified via the security

policy encapsulated within the MSA (which is assumed to a trusted party). At present the only restriction supported

is that of expiration which is disclosed via the delegation request at the time it is made.

12

4.1 Issues with Mobility

Here we examine the behavior of the domain-based access control service in the presence of migration. The

migration process [25] allows actors and their associated state to move from one node to another. It allows for

relocation of actors for easier access, availability and load balancing and is a vital property in mobile environments.

A migration request is given by a pair (α, ν), where α is the actor to be migrated, and ν is the destination node.

This is interpreted as a request to move the computation carried out by α to the node ν. In order to state

explicitly invariants maintained by the system during the migration process, we classify the migration process into

three phases wrt the actor being migrated and the node to which it is being migrated. These stages consist of an

Initiation Phase, a Remote Creation Phase and a Finalization Phase where a forwarder is established to forward

messages to α’s new location (ν). Given the framework & the aforementioned migration process, we consider the

following compositional issues:

Migration with Delegation: Consider the case where an actor, α attempting to delegate a set (subset) of its

rights to an actor, β.

[Case 1:] Delegator α Migrates: In this scenario, a DelegationReq has been issued, and the actor α wishes to

migrate. It should be noted however, that if migration occurs first, the object in question is frozen and these issues

do not arise.

• A restrictive approach would be to prevent α from migrating when there is an outstanding delegation request.

• Allowing migration to proceed, and then forwarding the acknowledgement (Step 4) to α’s new location.

Two issues arise from adopting the later approach: (a) Infinite forwarding - the actor could potentially keep

migrating for an infinite time, and the subsequent forwarding chain would grow along with it potentially never

allowing the acknowledgement to be delivered to complete the delegation process. (b) Message delivery given the

security level (SL) of the new domain - here the acknowledgement may not be deliverable given α’s new domain.

In the case in which α migrates to a more secure domain (SL(α) ≤ SL(dom)) there is no problem, however if the

new domain is less secure (SL(α) ≥ SL(dom)) the message would not be deliverable (at this point in time).

A preliminary solution to this problem is to maintain a Delegation Authority (DA), that maintains information

about migrating objects that are concurrently processing delegations. In the later case, where α migrates to a less

secure domain, the DA maintains the acknowledgement on behalf of α.

[Case 2:] Delegate β Migrates: Here, β wants to migrate in the presence of a delegation. The issue here is

the delivery of the DelegationReq to the target β. The same issues as above apply here in regard to this - Infinite

forwarding & problematic message delivery to β in its new domain. Consider the following cases corresponding to

the migration process:

• Migration is initiated but not complete - a solution is for the delegation request to wait for the migration to

complete and then determine feasibility for delivery of the request.

• Migrated has been completed (i.e. β -> β’).

13

In the second case, we must again consider cases in which the new domain (in which β’ is resident) is of a higher

or lower SL compared to the original. In the case where the domain is more secure there is no problem as before,

however in the second case we encounter the same delivery problem as before, and further migration may cause

an intermediate forwarding problem if the SL reduction is non-monotonic. Here, scenarios in which the revocatee

migrates are being considered.

Migration with Revocation: As mentioned, in order to ensure that the object for which access rights are being

revoked is reached (located) a couple of solutions are available (broadcast or periodically monitoring access requests

by revocable actors).

[Solution 1:] Broadcast-based Revocation: In this case, the MSA which receives the revocation request

broadcasts an invalidation message to all nodes in the system, indicating that any MSA cached information relating

to the object in question be updated from the directory service. Since this will reach all nodes, the actor in question

will be located (once the migration in progress has completed). The issue with this approach is that it is obviously

costly in terms of communication overhead, particularly when in an environment where a lot of potential revocations

are possible. Additionally, if there are a lot of concurrent broadcasts going on in the system, a MSA may potentially

have to deal with multiple invalidation broadcasts. Prioritizing which requests to process and in which order may

also be a concert when real-time revocation is needed.

[Solution 2:] Monitor-based Revocation: In this case, we assume the existence of a trusted ”Revocation

Authority”, which monitors all revokable delegations in the system. Each time such an object attempts to access

anything, the RA is introduced as an auxiliary service on top of the basic access control framework. The RA

checks if the capability has been revoked (i.e. a Revocation request has been issued) before granting access to the

object. This indirectly allows the system to keep track of these objects even in the presence of migration. Since

this method does not depend directly on the reception of the revocation request, even if the target actor migrates

into domains of varying security level the RA will still allow the revocation to be made successfully.

5 Implementation & Performance

In this section we present some performance results pertaining to our architecture, carried out as a simulation which

takes into account the mobility issues as well as the effects of view maintenance and management. Additionally,

we provide some details of our prototype implementation of the system, along with some results.

• Simulation: Object and node mobility, effects of view management and maintenance as well as other opti-

mizations.

• Prototype implementation: basic underlying capability-based access control architecture. Design of meta-

security actors and directory service as well as changes to the middleware framework. Initial performance

results measuring meta-actor, communication and directory service overheads.

14

5.1 Simulation

Experimental Settings: The simulation consisted of modelling our DBAC framework in an environment where

both objects and nodes were mobile, and where parameters relating to the mobility conditions could be varied

in order to examine the effectiveness of our solutions. Mobility models were implemented for both mobile nodes

and objects. Much previous work has been done on various mobility models [13, 3], however our focus here is to

examine the basic effects of our view management algorithm and subsequent optimizations rather than mimicking

accurate node movement. The boundary crossings made by nodes into domains with varying security requirements

were the pivotal concern. For the node mobility model, we used a slightly modified version of the random speed-

based mobility model [13]. Furthermore, we assumed the mobile nodes are initially distributed randomly in a

closed coverage area, which is further divided into a number of non-overlapping domains or regions, each of which

is associated with a security level (the number of which are varied depending on the experiments). The nodes

distributed in this coverage area are allowed to roam freely about it, (our simulator allows us to restrict the nodes’

mobility, depending on security requirements) with a velocity v and a direction Θ with respect to the positive x-

axis. The position of the node (x, y) is refreshed periodically as it crosses security domains while moving within the

network space. We experimented with a number of well known movement patterns including random walk, a quasi-

random distribution and restricting movement of nodes to a portion of the network. The border rule permitted

nodes to ’wrap around’ to the other side of the simulation plane when they hit the boundary. Mobile objects were

modelled on top of this whereby they were allowed to migrate to a particular node (node id) as oppose to a position

in (x,y) space. This was generally done in a random fashion, however each object contained a ’migration list’ which

allowed us to define which nodes it could possibly migrate to on each move. Each region and object instantiated

at startup was assigned a security level prior to each run. The regional MSAs were modelled as threads which

were assigned to a region, and responsible for implementing the functionality described in Fig.4. The main goal of

this simulation was to examine the overheads imposed on the system (the metrics being directory service update

overheads and communication overhead) by the view management algorithm under varying mobility conditions.

View approximation was also utilized as an optimization to the standard algorithm.

The experiments considered the overhead of the basic view management mechanisms with respect to the directory

service overhead involved in maintaining both state information pertaining to objects on the nodes as well as

location information corresponding to the mobile nodes themselves. The measurements consisted of a set of general

experiments to determine the overhead of the basic view management mechanisms, in terms of both directory

service and messaging overhead. The effects of fast and slow mobility were considered; on objects, nodes and a

combination of the two. Domain partitioning was varied in order to examine the impact of fine-grained vs. course

grained domains on view maintenance. Optimizations to the basic strategies were examined in the form of view

approximation and information management techniques (e.g. MSA caching). Security requirements were varied to

allow basic modelling of high and low security applications. Throughout the experiments scalability was also a key

concern both in terms of the number of objects and nodes.

15

Fig. 7: Directory update overhead with varying number of objects (left) and nodes (right).

Simulation Results

Basic System Performance: Fig.7 depicts the directory service update overhead of the architecture given an

increasing number of nodes (right) and objects (left). In increasing the number of objects (left), we used a fixed

number of mobile nodes, 4 security levels and a random distribution for migrating the objects. The runtime for

these experiments was 300 seconds, and the number of domains (regions) was varied between 8 and 200. It should

be noted that the view management algorithm implemented by each of the regional MSAs performed restoration

(SL Restore) whenever possible for these measurements. That is, whenever an object moved into a security domain

in which it’s SL could be restored (up to it’s maximum) depending on the domain restrictions - the restoration

was performed by the MSAs. Effectively, this represents the maximum overhead imposed by the view management

algorithm, as no optimizations were used (either caching or view approximation) and all updates were performed

at the directory service. The last line represents a measure of the DS overhead with no restoration being performed

by the MSAs, as expected the overheads are much lower and scale further. In reality, a cost falling somewhere in

between the two would be optimal depending on the application requirements.

As can be seen in Fig.7 (left), the DS overhead is independent of the number of domains to a large degree, given

that the number of security levels is fixed. DS saturation starts to occur at approximately 25,000 objects and some

optimizations are required for the system to scale beyond that. The performance results presented here intentionally

do not make any optimizations and show the characteristics of the simulation, later we include caching and other

techniques to reduce the DS overhead. Fig.7 (right) illustrates the directory performance with an increasing number

of mobile hosts. As can be seen, the number of directory updates is significantly less when considering the case

where node mobility dominates. This occurs because in the case of node mobility, the MSA performs a view refresh

on the whole node, in which case the directory updates are batched - making it less expensive than when individual

objects are migrating constantly, crossing security domains and where each update needs to processed individually.

Since there is no caching being employed for these results, the directory update costs are much higher for this type

of behavior.

Impact of View Approximation: Fig.8 examines the effect of the view approximation optimization described

16

Fig. 8: Effects of view approximation with varying mobility (left). Visible state as a result of view approximation (right).

in Section 3.1. Fig.8 (left) depicts the DS update overhead associated with varying the number of objects in the

system under different mobility conditions. Note that as the running time increases, the number of moves also

increases for objects (mobile objects are moving at approximately 3-4 times the speed of the nodes). For fast

mobility, the speed at which the objects and nodes move was increased to approximately three times the normal

rate and no view approximation was utilized. As can be seen the directory service overheads are much higher than

the standard case, as objects and nodes are rapidly moving in and out of security domains - possibly causing the

view to change each time. The second line shows the effect of view approximation, in which the simulator employs

and maintains the most conservative view for an object which moves within its profile domains. Here, the directory

service overheads can be reduced by up to 40% depending on the mobility patterns dictated by the application

(objects) and nodes. As a contrast, the third set of results shows the effects of slowing the mobility (approximately

three times less than the normal case) on directory update cost. The overheads are even lower, as the number of

view changes needed would be minimal due to the slow moving nature of the objects and nodes (keeping in mind

the number of regions are fixed for these measurements).

In Fig.8 (right) we illustrate the amount of visible state (for all objects) over a period of time where view

approximation is being employed. The state is represented as a % of the state that would have been visible had

view approximation not been used (100%). Note that some state would still obviously be hidden as part of the

normal behavior of the view maintenance algorithm but what is being showed here is the cost of employing the view

approximation optimization on what state an object has available (as oppose to what it could potentially have).

In the case where fast mobility is not employed, the effects of view approximation is minimal and the objects have

nearly the maximum possible visible state available to them.

Effects of Caching & Varying Security Requirements: Another optimization to the simulation model was to

add a rudimentary caching mechanism to the regional MSAs. The ability for each MSA to maintain a LRU-based

cache was added to try and ascertain the effect on directory service overhead and give some idea of the type of

loads we could expect in implementing this architecture. Some tweaking was done to the load-factor to improve

performance based on the mobility parameters being used. Fig.9 (left) depicts one of the measurements which

17

Fig. 9: Effects of caching on DS overhead (left). Overhead (DS overhead & messaging overhead) of varying securityrequirements (right).

were run with and without the new caching mechanism, a cache miss resulted in the MSA accessing the DS to

obtain the state information pertaining to the object. For this experiment, the following parameters were used;

objects=500,nodes=25,regions=8,SLmax=4 (4 levels). The improvement is fairly significant, netting gains of up to

35% under extreme mobility conditions. Similar relative improvements in directory service overhead were present

across a range of other measurements. Fig.9 (right) illustrates the cost involved in providing view management

for a typical high security application when compared to one with minimal requirements. Cost here was modelled

as the directory service overheads (query and update overhead) and meta-level messaging overheads involved in

running the view management algorithm. The high security application was modelled by using unconditional SL

restoration (having the maximal state visible at all times), and SLmax=12 (12 levels), whereas the low security

application utilized around 50% restoration and SLmax=3 (3 levels). In reality the object mobility (and security

characteristics) will be dictated by the application, and the view management schemes need only maintain these

parameters in an efficient manner. The figure simply illustrates two extreme cases and the relative costs involved

in maintaining and managing views for them.

Summary of Simulation Results: The basic set of measurements gave us an idea of the type of overheads that

would be imposed, with both an increasing number of objects and nodes. Obviously, efficient management of the

directory service is a vital component in providing view management for objects in highly mobile environments. In

addition, the measurements indicated that providing unconditional restoration of state was quite costly, however this

gave us an upper bound on the type of overheads the view management algorithm imposed on the system. In reality,

the restoration and reduction of security level would be based on policy, and tuned to the application requirements

which would fall somewhere in between the extreme cases presented here. The effect of our optimizations were

encouraging, with view approximation providing some good reduction in directory service overhead at the expense

of having some state being hidden which would be accessible under normal circumstances. This improvement was

most notable in a fast mobility scenario, where objects and nodes were moving rapidly in the network. Again, in

reality some compromise must be made between taking the most conservative view in doing view approximation and

providing applications with sensitive and sometimes necessary state information. Finally, a basic caching scheme

18

provided significant improvements in directory service overhead by allowing the meta-security actors to maintain

some state information locally, rather than querying and updating the directory service on every reduction or

restoration. Further more fine-grained experiments which map various application classes’ security requirements

to the characteristics of the objects in the system could be utilized to categorize the types of overheads involved

for some typical security requirements.

5.2 Prototype Implementation

Though the framework and ideas presented here are applicable to object-based distributed systems in general, our

prototype implementation is built on the CompOSE|Q middleware architecture [25]. This framework provides the

necessary runtime semantics for the base and meta-level actors described in the meta-architectural model [28].

The initial implementation focused on the basic access control mechanism for objects, and how they would be

implemented and managed in the directory service. Here we concentrated on providing the foundation for our

access control architecture, thereby defining the primitive access control mechanisms and fixed-node infrastructure.

The implementation of the underlying access control architecture consisted of a Meta-level Security Manager (MSA)

per node, the first-class capability objects (corresponding to each base actor), as well as a directory service (and

related interfaces) that serves as a repository for actor related attributes, e.g. location, access rights information

etc. In addition, the system implements a secure class loading mechanism to ensure that base-actors instantiated

are not spurious. Current and ongoing work involves utilizing the lessons learned from our simulation results into

integrating the view management subsystem and domain-based framework into this architecture.

The CompOSE|Q Middleware Architecture: The CompOSE|Q framework consists of a set of runtime kernels

that reside on individual nodes of the distributed system and a set of components that provide distributed systems

services to the application layer. The principal component of the node runtime kernel is a meta-level node manager

actor, which interfaces with components that deal with the communication subsystem and actor management.

The distributed middleware layer of CompOSE|Q contains metalevel services such as remote creation, distributed

snapshots, directory services, migration, soft real-time scheduling and QoS brokerage services. The access control

framework is implemented as a meta-level component within this architecture and provides protection for base-level

objects. The CompOSE|Q runtime [25] has been implemented in Java and is being tested on a variety of platforms &

mobile devices. Fig. 10 illustrates how the Meta-level security module is integrated with the CompOSE|Q runtime.

The Meta-Level Security Manager (MSA): The basic MSA design focused on the local MSA (LMSA) func-

tionality for non-mobile nodes. The prototype security modules have also been implemented in Java to facilitate

portability, flexibility through introspection and type-safety. In addition, it allows capabilities (defined as first-class

objects) to be implemented in an object-oriented manner and enables delegation of capabilities via sub-classing. We

define capability objects which encapsulate methods for the signing (using available signing algorithms), verification,

delegation and revocation of capabilities. We utilize Cryptix [8] to provide the necessary cryptographic libraries

for the framework. The following are some API calls available to the CompOSE|Q system, the MSA within the

CompOSE|Q environment invokes these methods at runtime:

public synchronized void sign (String sig, String alg);

19

Fig. 10: Interaction of Meta-level Services with the CompOSE|Q Runtime Environment

public synchronized boolean verify ();

public Capability delegaterights();

public void revokerights();

As demonstrated by the simulation results, directory service overhead can be significantly minimized by employing

caching at the regional (and local) MSAs. Each (local) MSA implements a caching mechanism on each node (with

the (regional) MSAs implementing caching per domain), that allows a table of rights to be maintained in order

to minimize directory accesses. Domain information (for DBAC) is stored in the actor’s annotation (additional

information or tags that can be stored by actors, which are only readable by meta-level entities), and contains the

security level of both the domain of creation (effectively SLmax) and the current domain of residence. This infor-

mation is also maintained by the MSA (and held in the directory service) in addition to the standard capabilities.

The MSA encapsulates the behavior of the security service on each node (basically serves as an interpreter for

security policy), and is responsible for creation, validation & management of capabilities. At present, the behavior

of the MSA is pre-defined but we are working on adding the ability to define customized user-policies on each

node (MSA). This is not a trivial matter, as inter-domain coordination of these policies must be dealt with (an

ability being implemented within a logical ’global’ MSA which communications and coordinates with the other

meta-security entities in the system). At present the MSA implements the following functionality:

• Step 1: Registration with the local Node Manager.

• Step 2: Installation of access rights for existing base-actors.

• Step 3: Message tagging.

• Step 4: Access rights checking (enforcement).

During the installation process (step 2), the MSA queries the Node Manager and (via the name service) obtains

a list of actors present on the given node. Based on the security policy at the MSA it installs access rights for

20

the actors (default rights if there are none specified), updates the directory service with the newly defined access

control information and caches the result locally. The MSA also handles installation of rights for newly created

actors. Object creation signals the MSA on the node of creation and the new capabilities are dynamically added to

the rights table. The enforcement (step 4) is carried out at the CompOSE|Q transport layer [25], which currently

uses TCP sockets for messaging and caches open connections (for re-use). The CompOSE|Q transport layer (See

Fig. 10) maintains two message queues on a node for all incoming and outgoing messages (on that node) called

SendPot and ReceivePot respectively. When an actor on a node sends a message, the message is put into the node’s

SendPot. The Router picks up messages from the SendPot, extracts the target of the message, and then consults

the NodeInfoManager to obtain the current location (node) of the target actor. If the location of the target actor is

local (i.e. on the same node), the Router puts the message directly into the node’s ReceivePot. If the target actor is

remote, the Router sends the message to the remote node. The RemoteMessageReceiver (RMR) on the target node

handles incoming messages. It extracts the message and puts it into the node’s ReceivePot. The Postman then

picks up the message and adds it to the target actor’s message queue. The MSA intervenes at this point via the

ACMessageHandler component. If access control is required for a particular application; a capability(s) is attached

to the outgoing message, before it arrives at the SendPot and the message is subsequently dispatched. Likewise,

at the receiving end, the message is extracted from the ReceivePot. The MSA inspects the incoming message; the

capability is verified and delivered to the target actor if access control can be granted. In the event of an access

control failure, an exception is generated by the MSA and returned to the application.

The directory service is an important part of the security framework, and hence optimizing performance for both

storing and accessing capabilities is of paramount importance. Our implementation of the directory utilizes the

Lightweight Directory Access Protocol (LDAP) [33], and in particular the OpenLDAP group’s slapd server (with

the Berkeley SleepyCat DB backend). Slapd is a stand-alone LDAP daemon that listens for LDAP connections on a

port, responding to the LDAP operations it receives over these connections. An interface to the Netscape Java API

was implemented that presented us with an abstraction to the set of required LDAP operations. The implemented

abstraction layer allows SSL connections to the LDAP directory server. A schema representing the necessary access

control information was implemented, and numerous optimizations were made to the caching policies and indexing

routines to maximize performance. The access control related information was maintained separately from the

standard runtime information (actor & node information etc.) required by CompOSE|Q.

Prototype Evaluation

The testbed for measuring the performance of our prototype utilized a network of Sun Ultra5 workstations (333

Mhz UltraSPARC IIi with 256KB external cache, Solaris 2.7, 128MB RAM). The system is implemented in Java

(JDK 1.2.2 with green threads). Performance results were obtained using JProbe Profiler 2.8. Execution times are

average results over 100 iterations of the various components and are represented without JVM induced overheads.

The main goal of these preliminary measurements were to ascertain what kind of overheads the security mechanisms

would place on both the runtime and communication subsystem when integrated with the CompOSE|Q framework.

(a) Meta-Level Security Manager

The execution times of the meta-level security actor (MSA) are summarized in Fig.11. The results are divided into

21

the MSA bootstrapping and the MSA operational overhead. To determine the startup overhead, we measured the

execution time of the MSA initialization & registration processes. InstallRights represents the time taken 4 for the

MSA to obtain a list of actors (local send & receive RTT) on its node and setup access rights for them (local store).

All times depicted here are for local operations (assuming that the required information is available in the local

cache) and do not include interactions with the directory service (provided later).

Fig.12 illustrates the overheads of the various MSA operations. On message send, we measure the raw processing

overhead (does not include cryptographic overhead of signing the capability) necessary to tag outgoing messages (i.e.

from when the message is intercepted by the MSA to when it is returned to the regular messaging system). Note that

these measurements do not include the overhead for message interception and re-insertion into the communication

subsystem. Verify represents the time taken to authenticate the capability (note that this measurement does not

include the cryptographic overhead, since it is dependent on the algorithm used to sign the capability), a comparison

of popular signing algorithms is currently in progress. Enforce is the primary checking mechanism, which examines

the access rights corresponding to an incoming message and authenticates it. We assume here that all data is

cached at the MSA (which is very likely for local sending actors); in the case of a cache miss, a directory service

operation is invoked.

Operation Exec. Time (µs)MSA Startup (total) 432- Registration() 110- InstallRights() 325

Fig. 11: MSA Startup Overheads.

Operation Exec. Time (µs)Message Tagging* (Msg Send) 140Message Check (Msg Receive) 203- Verify*() 11- Enforce() 192

Fig. 12: MSA Operational Overheads.

(b) Communication Overhead

Basic communication overheads are shown in Fig.13. The local message send result also reflects the overheads in-

volved in communication between local base-actors, as well as communication between the MSA and the CompOSE|Qruntime (in particular the Node Manager). The remote message send performance again depends a lot on the

caching techniques (both the socket cache, and remote actor cache) being used. A cache miss (if the Node Manager

is unable to locate an actor on it’s node via the cache), results in a directory service operation (c). To a large

extent, overheads imposed by our security framework are those imposed by the MSA (a). This effecively adds to

the communication overhead (the numbers shown in (a) reflect the total overhead), as the MSA acts as a ’filter’ in

maintaining access control on the node.

Operation Exec. Time (µs)Local Msg. Send 174Remote Msg. Send 239Message Receive 130

Fig. 13: Communication overheads.

Operation Exec. Time (µs)Adding Actor (with 14,234capability information)Adding Actor Attribute 3959Attribute Query 2141

Fig. 14: Directory service overheads.

(c) Directory Service Operations

As evidenced by our simulation results, the directory service [31] is a vital part of the access control framework,

4measured for 10 actors

22

and hence optimizing performance is a primary concern. In addition to optimizations discussed in [25] & [31],

preliminary indexing was done on both node/domain information as well as capability information associated with

each unique ActorID. In preliminary testing, the MSA imposed little overhead on the migration process, as most

of the processing is done at each local node. Typical overheads for our prototype implementation of the directory

service is provided in Fig.14. Further work on more effective caching techniques will help avoid expensive calls to the

directory service. During actor creation, the access control information created is currently inserted into the both

local cache and (remote) directory service. A significant improvement in creation response time can be achieved

by not updating the DS during the create operation. Instead, a lazy, collective update mechanism is implemented

whereby access rights for serveral newly created actors can be committed into the DS asynchronously. Care must

be taken to ensure that remote references to these newly created objects obtain accurate AC information.

6 Related & Future Work

This work incorporates a few different bodies of research from a number of areas in building a security solution

for mobile environments. A lot of work has been done on view maintenance for databases [29], which deals with

a similar problem in that the need for maintaining online access to data is necessary while on a mobile device.

Problems can occur due to being out of range as well as being bandwidth or resource limited. A lot of this

work focuses on tuning performance in such scenarios, looking at both the access times and communication costs

depending on how often this view is updated or materialized given the situation. This area of work, though being

in a different subject area is very similar in it’s goal in that the idea is how to efficiently manage a set of customized

views in a network consisting of mobile devices and a fixed infrastructure.

Wolfson et. al [30] discuss the need for various algorithms and strategies to maintain views via different com-

munication methodologies (point-to-point, broadcasting, multicasting). Additionally, the problem of maintaining

dynamic views in such an environment is discussed (allocating this view depending on where you are in the network).

Some general approaches are to design protocols that do not provide any guarantee that limits the consistency,

the other extreme being to ensure all views are perfectly synchronized with the source right across the network

(expensive). A lot of these issues which are pertinent to mobile databases can be mapped to object-based mobile

environments, even though the concept of a view is inherently different to what is being discussed in this paper.

Here we refer to the local state of an individual object, rather than to providing customized views of a centralized

repository such as a database. Work has also been done on fine-grained protection schemes for object databases

(ODBs) [5, 27, 12] to provide these efficient searching, browsing and processing while still maintaining control of

data and good performance.

The Ajanta Project [24] provides a programmatic system for development of agent-based applications over the

Internet. One main focus has been the use of policy-driven middleware as a tool for building secure distributed

collaboration environments using role-based security policies. Ajanta also has the notion of views, however in

this context it is the view of a user’s security policy which is specific to his/her role. The system also provides

dynamic updating of these views at runtime. The Ajanta framework provides very detailed notions of policy and

role management as well as support for structured, hierarchical collaboration environments. This sort of policy-

driven framework appears to fit well with the work we are doing, in that it could be used as a basis for describing

23

security policies and providing more abstract modelling of users and user applications, as well as more complex

inter-domain interactions. Additionally, integrating a role-based approach to our access control architecture is the

subject of future work, and Ajanta provides a good example applying role-based access control to a domain-based

environment.

There has been work in the area of mobility itself, classifying different types of mobility, it’s importance in

other areas of computing, development of formal models and algorithms and challenges [22], which served as

motivation for the work presented here. Roman, Murphy et. al discuss the difficulties introduced by distributed

computing infrastructures by the advent of mobile computing, which adds another layer of complexity on top

of already available solutions. One of the interesting concepts introduced here is the definition of physical and

logical mobility, which is similar (but more general) to the concepts of object and node mobility we examine here.

The importance of coordination in these two arenas is stressed, particularly in regard to location, tracking and

synchronization. Another area of interest is that of contexts which is similar to the idea of views which are discussed

here but more generally describes the location of a mobile host which in turn defines its environment (resources,

services etc.). The authors go on to mention the importance of security in such an environment and the tradeoffs

that occur between providing a secure environment in the presence of mobility (both node and object mobility)

and resource/environmental constraints. We take the notions presented here and address these various aspects

in our work, particularly with a focus to providing composable security services that are able to function in an

environment with logical and physical mobility and provide some form of context-sensitive ability.

In the work done by Riechmann and Hauck [21], a capability-based paradigm is presented that is based on

meta objects. These meta objects, being functionally similar to capabilities, are attached to object references and

control access to the corresponding objects. Here, Security Meta Objects (SMO) are attached on a per reference

basis to objects. Since objects can have many references, the overhead of such a system is potentially very high,

especially in a dynamic, distributed environment. We addressed the multidomain security problem in this paper

from a different perspective to traditional models. Work by Gomez [11] examined the problem of two systems in

two different security domains interacting in a secure manner. Here the focus was on the interactions between the

various inter-domain policies, and was addressed by using a multipolicy hierarchy to allow coexistence of various

individual policies. To this notion we added the concept of security levels and concentrated on maintaining a

certain consistent state as objects migrate from node-to-node, & transcend domains with differing security levels

etc.

The notion of object-based access control model is also one encountered in models built around the CORBA

Security Service (CS). Beznosov & Deng [4] discuss how (role-based) access control models can be incorporated into

the CS. The CORBA security model also supports security domains, but only as a collection of objects. We extend

this notion in our work, as well as making it a inherent part of the information stored with the objects themselves,

and utilize it as a flexible way of modelling mobility in a distributed environment. The Cherubim project [20], an

agent based dynamic security framework (implementing a set of CORBA compliant security services) provides the

notion of Active Capabilities [9], to protect and control access to the objects it is associated with. OASIS [14, 15]

implements RBAC for secure, independent, internetworking services and provides a strong policy-based language

for describing users and services. Our architecture is similar in it’s goals and distributed nature, but operates at a

24

slightly lower level. The model presented in this paper manipulates active objects, which in turn can be used to

manipulate services, applications, etc., and provides fine-grained access control. Delegation and revocation are not

tied to any particular authentication scheme in our model. In addition, since the delegation scheme doesn’t require

the delegate and the delegator to be in constant communication our model also supports disconnection by mobile

clients.

Further work is being done in extending the formal model as well as investigating the verification of interaction

semantics between the access control service and other services within the CompOSE|Q system. With the basic

framework presented here in place, we are working on the notion of using differing security policies in various

domains (e.g. based on user-defined security requirements, power constraints, processing constraints). Designing

and building a structured language to describe policies which can be interpreted by the meta-security entities is

also ongoing work. Dealing with on-the-fly modification to these policies at runtime is also of interest. Analyzing

the performance of customizable security protocols & algorithms that may be used as part of the framework (e.g.

cryptographic overheads of pluggable mechanisms used in our framework) in implementing these policies.

References

[1] G.A. Agha: ACTORS: A Model of Concurrent Computation in Distributed Systems. MIT Press, 1986.

[2] T. Aura: Distributed Access-Rights Managements with Delegations Certificates. Secure Internet Programming, pp.211-235, Springer, 1999.

[3] C. Bettstetter: Smooth is Better than Sharp: A Random Mobility Model for Simulation of Wireless Networks. ACMMSWiM’01, Rome, Italy, 2001.

[4] Konstantin Beznosov & Yi Deng: A Framework for Implementing Role-based Access Control Using CORBA SecurityService. CADSE, School of Computer Science, FIU - RBAC 99, VA

[5] E. Bertino, S. Jajodia, & P. Samarati: Access Control in object-oriented database systems: Some approaches and issues.Advanced Database Concepts and Resources Issues, pp.17-44, LNCS 759, Springer - Verlag, 1993

[6] T. Camp, V. Davis & J. Boleng: Mobility Models for Ad Hoc Network Simulations. Technical Report, 2001

[7] L. Cardelli: Abstractions for Mobile Computation. Secure Internet Programming: Security Issues for Mobile and Dis-tributed Objects. Lecture Notes in Computer Science, Vol. 1603, Springer, 1999. pp. 51-94.

[8] Cryptix Open-source Cryptographic Software Libraries: http://www.cryptix.org

[9] Roy H. Campbell, Tin Qian, Willy Liao & Zhaoyu Liu: Active Capability: A Unified Security Model for SupportingMobile, Dynamic and Application Specific Delegation White Paper, Dept. of CS, UIUC, IL, 1996

[10] Svend Frolund: Coordinating Distributed Objects: An Actor-Based Approach to Synchronization. MIT Press, 1996

[11] J. de J. Vasquez-Gomez: Modelling Multidomain Security. ACM New Security Paradigms Workshop II, 1993

[12] N. Gal-Oz, E Guhed & E.B. Fernandez: A model of methods access authorization in object-oriented databases. InProceedings of the 10th IFIP WG 11.3 Workshop on Database Security, pp.76-91, July 1996

[13] Z.J. Haas: A New Routing Protocol For Reconfigurable Wireless Networks Technical Report, Cornell University, 1997

[14] R.J. Hayton, J.M. Bacon & K. Moody: Access Control in an Open Distributed Environments.

[15] John H. Hine, Walt Yao, Jean Bacon & Ken Moody: An Architecture for Distributed OASIS Services

[16] S. Jajodia & B. Kogan: Integrating an object-oriented data model with multilevel security. In Proceedings of the IEEEComputer Society Symposium on Security and Privacy, pp.76-85, 1990.

[17] G. Karjoth, D.B. Lange, & M. Oshima: A Security Model for Aglets. IEEE Internet Computing, Vol. 1, No. 4, 68-77(July/August 1997).

[18] J. Kohl & C. Neuman: RFC 1510: The Kerberos Network Authentication Service (v5). September, 1993

[19] A. Murphy, G. Picco, & G.-C. Roman: Lime: A Middleware for Physical and Logical Mobility. Proceedings of the 21stInternational Conference on Distributed Computing Systems, 2000

25

[20] Tim Qian: Cherubim Agent Based Dynamic Security Architecture. Technical Report, Dept. of CS, UIUC, IL, 1998

[21] T. Riechmann and F. J. Hauck: Meta Objects for Access Control: Extending Capability-based Security. In Proceedingsof New Security Paradigms Workshop, Langdale, Cumbria, UK, 1997, pp.17-22

[22] G.-C. Roman, G.P. Picco & A. Murphy: A Software Engineering Perspective On Mobility. Future of Software Engi-neering, 22nd International Conference on Software Engineering, pp. 241-258, June 2000

[23] Ravi Sandhu, David Ferraiolo & Richard Kuhn: The NIST Model for Role-Based Access Control: Towards a UnifiedStandard. National Institute of Standards & Technology Lab (NIST)

[24] Anand Tripathi & Neeran Karnik: A Security Architecture for Mobile Agents in Ajanta. Proceedings of the InternationalConference on Distributed Computing Systems, April 2000.

[25] N. Venkatasubramanian, M. Deshpande, S. Mohapatra, S. Gutierrez-Nolasco & J Wickramasuriya: IEEE InternationalConference on Distributed Computer Systems (ICDCS-21), April 2001.

[26] N. Venkatasubramanian: An Adaptive Resource Management Architecture for Global Distributed Computing. Ph.Dthesis, UIUC, IL, 1998

[27] V.E. Jones: Access Control for Client-Server Object Databases. Ph.D thesis, UIUC, IL, 1997

[28] N. Venkatasubramanian, & C.L. Talcott: Integration of resource management activities in distributed systems. TechnicalReport, Stanford University Computer Science Department, 2001

[29] J. Widom: Special Issue On Materialized Views and Data Warehousing. Data Engineering Bulletin, IEEE ComputerSociety, Vol 18, No. 2, June 1995

[30] O. Wolfson, P. Sistla, S. Dao, K. Narayanan & R. Raj: View Maintenance in Mobile Computing. SIGMOD RECORD,Association of Computing Machinery Press, Dec. 1995

[31] J. Wickramasuriya & N. Venkatasubramanian: A Directory Enabled Middleware Framework for Distributed Systems.To appear in WORDS 2003

[32] J. Wickramasuriya & N. Venkatasubramanian: A Middleware Approach To Access Control For Mobile, ConcurrentObjects. To appear in DOA 2002

[33] M. Wahl, T. Howes & S. Kille: Lightweight Directory Access Protocol (v3). IETF RFC 2251, December 1997.

26