Multilevel Access Control for Environments with

Multilevel Access Control for Environments with Object & Node Mobility Jehan Wickramasuriya & Nalini Venkatasubramanian Dept. of Information & Computer Science University of California, Irvine Irvine, CA 92697-3425, USA {jwickram,nalini}@ics.uci.edu

Carolyn L. Talcott Computer Science Laboratory SRI International Menlo Park, CA 94025, USA [email protected]

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 distributed 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 methods. One of the challenges we tackle in this work is that of hiding sensitive information in insecure environments, by providing objects in the system a ’view’ of their state information, and subsequently managing this view. We present a middleware-based architecture for providing access control in such an environment 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 performance 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 messagepassing. 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 represents 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. 1 CompOSE|Q is based on a meta-architectural model that facilitates specifying and reasoning about the composability of multiple resource management services in open distributed systems.

3

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

Fig. 2: Representing an Object: An actor encapsulating a thread and state as well as a set of methods and acquaintances. The greyed out regions indicate state that may be hidden as part 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 acquaintances) 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. Using 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. LMSA (non-mobile nodes) 1. Encapsulates and inteprets security policy as part of its behavior (view management, delegation/revocation etc.). 2. Mutual authentication of meta-level communication. 3. Authenticate and establish secure connections with directory services (e.g. SSL-based). 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. RMSA (regional) 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). LMSA (mobile nodes) 1. Maintain local view of objects on the node.

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) Communication 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 management 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), l0 ) = α 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 ) α20 = SL Restore(α1 , l2 ) then α2 = α20 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 P roject such that; SL P roject(α, l) represents the information pertaining to security level l, which is empty if SL(α) < l: state(α) = join(l ∈ L0,L1,L2,L3) SL P roject(α, l) state(SL Reduce(α, l)) = join(l’ ∈ L0,L1,L2,L3) SL P roject(α, l0 )

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 ref resh 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 ref resh 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), f or 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(α0 ) f or α0 ∈ 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 α0 if; ∀α00 ∈ acq(msg)), SL cr(α00 ) ≤ SL(dom(α0 )) 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 9

(4)

View Management Algorithm view_refresh(n,dom) { 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)); } switch (event) { case 1: \\ Startup 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; case 2: \\ Object Migration 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; case 3: \\ Node Migration 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 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 unacceptable 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 3 The key notion here is that α not be allowed to leak acquaintances of higher SL to less secure domains, these acquaintances may be discarded (no restore) or held securely if necessary.

11

delegation_request (delegator_aid, delegatee_aid, rights, validity_period, cascadable, restrict_info) {

revocation_request (tgt_aid, rights) {

IF request is local THEN MSA validates request IF max(SL(rights)) β’).

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 optimizations. • Prototype implementation: basic underlying capability-based access control architecture. Design of metasecurity 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 speedbased 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 xaxis. 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 quasirandom 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 security requirements (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) functionality 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 SLm ax) and the current domain of residence. This information 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 MSA Startup (total) - Registration() - InstallRights()

Operation Message Tagging* (Msg Send) Message Check (Msg Receive) - Verify*() - Enforce()

Exec. Time (µs) 432 110 325

Fig. 11: MSA Startup Overheads.

Exec. Time (µs) 140 203 11 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 involved in communication between local base-actors, as well as communication between the MSA and the CompOSE|Q runtime (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 Local Msg. Send Remote Msg. Send Message Receive

Operation Adding Actor (with capability information) Adding Actor Attribute Attribute Query

Exec. Time (µs) 174 239 130

Fig. 13: Communication overheads.

Exec. Time (µs) 14,234 3959 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, 4 measured

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 communication 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 policydriven 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.211235, Springer, 1999. [3] C. Bettstetter: Smooth is Better than Sharp: A Random Mobility Model for Simulation of Wireless Networks. ACM MSWiM’01, Rome, Italy, 2001. [4] Konstantin Beznosov & Yi Deng: A Framework for Implementing Role-based Access Control Using CORBA Security Service. 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 Distributed 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 Supporting Mobile, 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. In Proceedings 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 IEEE Computer 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 21st International 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 Proceedings of 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 Engineering, 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 Unified Standard. National Institute of Standards & Technology Lab (NIST) [24] Anand Tripathi & Neeran Karnik: A Security Architecture for Mobile Agents in Ajanta. Proceedings of the International Conference on Distributed Computing Systems, April 2000. [25] N. Venkatasubramanian, M. Deshpande, S. Mohapatra, S. Gutierrez-Nolasco & J Wickramasuriya: IEEE International Conference on Distributed Computer Systems (ICDCS-21), April 2001. [26] N. Venkatasubramanian: An Adaptive Resource Management Architecture for Global Distributed Computing. Ph.D thesis, 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. Technical Report, Stanford University Computer Science Department, 2001 [29] J. Widom: Special Issue On Materialized Views and Data Warehousing. Data Engineering Bulletin, IEEE Computer Society, 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, Concurrent Objects. To appear in DOA 2002 [33] M. Wahl, T. Howes & S. Kille: Lightweight Directory Access Protocol (v3). IETF RFC 2251, December 1997.

26