A Formal Framework for Agent Itinerary Specification ... - CiteSeerX

A Formal Framework for Agent Itinerary Specification, Security Reasoning and Logic Analysis Shiyong Lu Department of Computer Science Wayne State University, Detroit, MI 48202 [email protected]

Abstract Mobile agent technology supports object migration from one site to another autonomously and proactively, performing its designated location-dependent tasks. Although the concept of proactive mobility has recently been demonstrated in several research prototypes, there is a lack of formal treatment of such mobility from the perspective of a distributed programming language. How to specify, model and reason about travel itineraries of mobile agents is fundamentally important for the development of secure and reliable mobile agent systems. In this paper, first, we introduce an itinerary language, MAIL, to model the mobile behavior of proactive agents. The language is structured and compositional so that an itinerary can be constructed recursively from primitive itineraries. We then define the operational semantics of the language in terms of a set of inference rules and prove that MAIL is expressive enough for most migration patterns. Finally, we show that MAIL is amenable to formal methods to reason about mobility and verify correctness and safety properties.

1. Introduction As an important factor in nature, mobility stems from a desire to move either toward resources or away from scarcity. For the same reason, there is a trend of computing in ever-increasing mobility in which computers continue their network operations while physically changing their locations, and logical computing objects move from system to system autonomously performing their designated tasks in a networked world. The autonomous nomadic computing objects are often referred to as mobile agents. In contrast to traditional client/server-based distributed systems in which the computing objects are stationary, a mobile agent system features an agent that can migrate from

Cheng-zhong Xu Department of Electrical and Computer Engineering Wayne State University, Detroit, MI 48202 [email protected]

one site to another proactively (that is, not the environment but the agent itself will initiate migration according to its own itinerary), performing location-dependent computations or other functionalities such as load balancing, fault masking, data locality exploitation, service customization. Although none of these individual advantages represents an overwhelming motivation for the adoption of mobile agents, their aggregate advantages facilitate many network services and application. Because of the unique properties of autonomy and proactive mobility, mobile agents have been the focus of much speculation and hype in both academia and industry in the past decade. However, the promised deployment has not been materialized in an industrial setting. There are many reasons for this. A primary concern is security. From the perspective of servers, there is nothing more risky than providing docking services to remote general-purpose executables. Since an agent migrates with its code as well as data and running states, its privacy and integrity also need to be protected from attacks by sites in the itinerary. Readers are referred to [8] for a recent comprehensive survey of security measures for both security requirements. This paper focuses on itinerary-related security issues for server protection. In general, when a server receives an agent, it not only needs to know how the agent would function, but also if the agent is supposed to visit this server according to its itinerary. Answers to the second question require a formal treatment of the agent proactive mobility. The mobility of an agent introduces a new dimension to traditional distributed systems and therefore imposes a new challenge on the specification and modeling of reliable and secure mobile agent systems. In a networked world, one is obligated to specify not only how to execute the designated tasks of an agent, but also where (its mobility) to execute them. For example, an agent might need to visit more than one site to complete its tasks and these visits must be carried out in some particular order. To model the behavior of an agent, the semantics of an agent migration operation needs to be formalized. For example, for a migration of agent a

from site s1 to site s2 , the semantics should reflect the fact that the location of a is now moved from s1 to s2 and a is ready to execute any s2 -dependent computational tasks. Formal specification and modeling of mobility provides a solid foundation for the analysis of agent security and reliability. For example, given a security policy of “if an agent visits site e, then it must not visit site f ”, can we analyze the migration pattern of agent a and see if it will violate such a policy during run time? Current programming languages such as C++ and Java do not provide the facilities to specify the migration and communication patterns of an agent. Classic process algebras like Milner’s CCS [15] have been widely used to model parallel and distributed systems. However, modeling mobility is not part of their formalisms. There are recent extensions of process algebras to cope with dynamically reconfigurable process networks and with the possibility of process migration. Examples include π-calculus [16] and join calculus [7]. There are other mobility models like Mobile UNITY [14, 19] and transient connectors [23] that extend Chandy and Misra’s UNITY [2] to provide a programming notation of location to capture the notion of mobility. For example, each process in the Mobile UNITY model exists at a specified location denoted by a program parameter λ. Process migration is modeled by the assignment of λ to different location values. These models facilitate the analysis of the properties of mobile distributed systems. However, they are limited to the mobility of passive agents (or processes). Passive agents are non-autonomous in migration and their moves are initiated by their running environments. The concept of proactive mobility of agents was demonstrated in recent research prototypes; see [9] for an comprehensive review. They developed various programming constructs for the representation of agent itineraries, including parallel, sequential, and conditional visits [21, 22, 24]. Previous studies illustrated the programmability and expressiveness of itinerary constructs mostly by examples. There exist few formal treatments of agent behaviors with respect to their proactive mobility. Loke, et al. defined an algebra for programming the agent itineraries [10]. Their work was limited to a formal specification of itinerary constructs. Picco, et al. applied Mobile UNITY to modeling and analysis of mobile agents and fine-grained code mobility [13, 18]. Their focus was on the development of formal semantic specification of mobility constructs (e.g. move, clone, activate, and deactivate) and agent itineraries were left unspecified. To develop a secure and reliable mobile agent system, in this paper, we develop a foundation for specifying, modeling and reasoning about agent proactive mobility. Focus is on two agent itinerary properties: correctness and safety. An itinerary is correct if it satisfies a given agent visit ordering constraint. A system state configuration is safe with respect to an initial configuration if it is reachable

according to the agent itinerary. Reasoning and assurance of these itinerary properties are extremely important for mobile agent applications in a coalition environment where the servers are generally cooperative and trustworthy, although the mobile agents launched from different sites may have different levels of trustiness. This itinerary reasoning work complements proofcarrying-code (PCC) and state appraisal security measure for server protection. The PCC measure due to Necula [17] was applied to safety checking of mobile agents with respect to their codes. The state appraisal measure due to Farmer, et al. [6] allows a site to run an agent-carried state appraisal function to test whether its state is corrupted or not. This paper focuses on correctness and safety reasoning with respect to agent itineraries. The primary contributions of this paper are: 1. We introduce an itinerary language, MAIL, to specify the mobile behavior of proactive agents. The language is structured and compositional so that an itinerary can be constructed recursively from primitive itineraries. 2. We define the operational semantics of MAIL in terms of a set of inference rules and prove that MAIL is expressive enough for most migration patterns. Specifically, it is complete in the sense that it can specify any itinerary of a regular trace model (to be defined later). 3. We show that MAIL is amenable to formal methods to reason about mobility and verify correctness and safety properties. For a mobile agent system, we prove that the set of reachable system state configurations from a given initial configuration is finite and that the problem of checking whether such a mobile agent system is safe with respect to the initial configuration is decidable. 4. We show that for a given agent visit ordering constraint, the problem of checking if an itinerary satisfies the constraint can be solved in polynomial time. The rest of the paper is organized as follows. Section 2 defines the syntax of MAIL. Section 3 describes the operational semantics of MAIL in terms of a set of inference rules which provides a foundation for mobility reasoning, correctness and security verification. Section 4 demonstrates the expressiveness of MAIL. Section 5 introduces an itinerary temporal constraint language, MAILC, and shows that the itinerary satisfaction checking problem is decidable. Finally, Section 6 concludes the paper and points out some potential future work.

2. Syntax of MAIL A mobile agent is a sort of special object that has its own autonomy. It behaves like a human agent, working for

clients in pursuit of its own agenda. In contrast to other objects that are definable in current object-oriented programming languages, a mobile agent has its defining trait ability to travel from one machine to another proactively in open and distributed systems like the Web, carrying its code, data and running state. This motivates us to define an itinerary language to allow one to specify the itinerary that an agent will follow during its travel. Informally, an itinerary specifies the sites that an agent will visit and the ordering of visiting them. Some examples of informal descriptions of itineraries are as follows: • Visit s1 , s2 , · · · , sn in that order. • Visit s1 and then, if x > 0 visit s2 else visit s3 . • Visit s1 and s2 concurrently (by making a clone of the agent) and then visit s3 . As a general language for itineraries, we provide constructs to support the specifications of different kinds of itineraries: sequential, conditional, concurrent, and loop itineraries. We formally define MAIL in the sequel. First, we list the syntactic sets associated with MAIL: • • • •

S: a set of sites. Let s, s1 , s2 , · · ·, range over S. Z: a set of channels. Let α, β, γ, · · ·, range over Z. V: a set of variables. Let X, Y, Z, · · ·, range over V. C: a set of boolean expressions. Let c, c1 , c2 , · · ·, range over C. • E: a set of arithmetic expressions. Let e, e1 , e2 , · · ·, range over E. • Ξ: a set of signals. Let ξ, ξ1 , ξ2 , · · ·, range over Ξ. • I: the set of itineraries definable in MAIL. Let i, i1 , i2 , · · ·, range over I. A visit for an agent a is a site s ∈ S. A visit s for an agent a intuitively specifies “executing a at site s”. The capability of specifying where to execute agent actions is the motivation of mobile-agent programming paradigm. Definition 2.1 (Itinerary) An itinerary is defined as follows: (1) skip and stop are empty and error itineraries respectively, (2) α?X, α!e, signal(ξ) and wait(ξ) are primitive communication itineraries, (3) every visit s ∈ S is a primitive site-visiting itinerary, (4) if i1 and i2 are itineraries and c is a condition, then i1 ; i2 , if c then i1 else i2 and i1 k i2 are itineraries, and (5) if i is an itinerary and c is a condition, then while c do i is an itinerary. 2 We summarize it by the following BNF notation: i ::= skip | stop | s | α?X | α!e | signal(ξ) | wait(ξ) | i1 ; i2 | i1 k i2 | if c then i1 else i2 | while c do i

where “::=” should be read as “is defined as” and the symbol “|” as “or”. Informally, i1 ; i2 and i1 ||i2 represent sequential and parallel visit patterns, respectively; if c then i1 else i2 represents a conditional visit and while c do i a visit loop. While α?X and α!e are asynchronous sending and receiving primitives in which channel α is used as a buffer, signal(ξ) and wait(ξ) are synchronous sending and receiving primitives. The MAIL language is structured and compositional so that an itinerary can be constructed recursively from primitive constructs. In Section 4, we will show that MAIL is expressive enough for most migration patterns. In particular, it is regular-complete in the sense that it can specify any itineraries of regular trace model. Two itinerary examples are graphically shown in Figure 1, in which ⊗ represents concurrent construct, and ⊕ with guards represents conditional construct. x> 5

1

x< = 5

2

3

6

x> 5

4

5

(a) 1;((if x > 5 then 2 else 3) || (4;5));6

3

2

x< = 5

4

(b) (while x > 5 do (2; 3)); 4

Figure 1. Two itinerary examples

3. Operational semantics of MAIL In the following, we will define the operational semantics of MAIL in terms of a set of inference rules. Using this set of inference rules, one can derive the semantics of the execution of an itinerary i by an agent a. First, we introduce the following notations and assumptions. • Σ: the set of states of a mobile agent system. The definition of what counts as a state is not important to us, i.e., any notion of a state is allowed here. Let σ, σ1 , σ2 , · · · range over Σ. • We assume the evaluation of a condition c in a state σ is defined by function: δ: C × Σ → {true, f alse}. Therefore, δ(c, σ) represents the truth value of c in state σ. • A: a set of agents in the system. Let a, a1 , a2 , · · · range over A. • We assume the semantics of an agent a visiting a site s is given by function ρ: A × S × Σ → Σ. Hence, after agent a visits site s starting at state σ, the resulting state will be ρ(a, s, σ). We abbreviate it by ρ(s, σ) when a is understood from the context. Function ρ models the semantics of an agent’s action at a particular site. This semantics can be derived from the definition of conventional programming languages that are used to specify an agent’s action.

1. Skip rule:

(σ,{(a,s,skip),···}) → (σ,{···})

2. Visit rule:

(σ,{(a,i,s),···}) → (ρ(a,s,σ),{···})

3. Migrate rule:

s1 6= s2 (σ,{(a,s1 ,s2 ),···}) → (σ,{(a,s2 ,s2 ),···})

4. Sequential rule 1: 5. Sequential rule 2: 6. Receive rule: 7. Send rule:

(i = s)

(σ,{(a,s,skip;i2 ),···}) → (σ,{(a,s,i2 ),···}) (σ,{(a,s,i1 ),···} → (σ 0 ,{a,s0 ,i01 ),···}) (σ,{(a,s,i1 ;i2 ),···}) → (σ 0 ,{(a,s0 ,i01 ;i2 ),···})

head(α) = n (σ,{(a,s,α?X),···}) → (σ[n/X][tail(α)/α],{(a,s,skip),···})

(σ,{(a,s,α!e),···}) → (σ[α@[σ(e)]/α],{(a,s,skip),···})

8. Synchronization rule:

(σ,{(a,s1 ,signal(ξ);i1 ),(a,s2 ,wait(ξ);i2 ),···}) → (σ,{(a,s1 ,i1 ),(a,s2 ,i2 ),···})

9. Conditional rule 1:

δ(c,σ) = true (σ,{(a,s,if c i1 else i2 ),···}) → (σ,{(a,s,i1 ),···})

10. Conditional rule 2:

δ(c,σ) = f alse (σ,{(a,s,if c i1 else i2 ),···}) → (σ,{(a,s,i2 ),···})

11. Parallel rule 1: 12. Parallel rule 2: 13. Interleave rule:

(σ,{(a,s,i1 ki2 ),···}) → (σ,{(a,s,(i1 ;signal(ξ))|||(i2 ;wait(ξ)),···}) (σ,{(a,s,i1 ),···}) → (σ,{(a,s,i11 ||| i12 ),···}) (σ,{(a,s,i1 ;i2 ),···}) → (σ,{(a,s,i11 ||| (i12 ;i2 )),···}) (σ,{(a,s,i1 ||| i2 ),···}) → (σ,{(a,s,i1 ),(a,s,i2 ),···})

14. Loop rule 1:

δ(c,σ) = true (σ,{(a,s,while c do i),···}) → (σ,{(a,s,i;while c do i),···})

15. Loop rule 2:

δ(c,σ) = f alse (σ,{(a,s,while c do i),···}) → (σ,{···})

Figure 2. Operational semantics of MAIL • L ::= 2A×S×I , the set of layouts of a system. Each layout is a set of tuples (aj , sj , ij ) (aj ∈ A, sj ∈ S, ij ∈ I, j = 1, · · ·) that specifies an agent (or its clone) aj is located at site sj with an itinerary ij . Let l, l1 , · · · range over L. Note that L is infinite since I is infinite.

The skip rule describes the semantics of executing a skip itinerary. Intuitively, it states that “after the execution of itinerary skip by agent a, the state component of the configuration will not change, but (a, s, skip) will be deleted from the layout component”. The rule has no hypothesis, so it is an axiom. Similar interpretations hold for other rules.

• Ω ::= Σ × L, the set of configurations of a system. Each configuration is a pair (σ, l) where σ ∈ Σ and l ∈ L. Ω defines the state space of the whole system. It is infinite since L is infinite. However, it will be shown that given an initial configuration, a system can only reach a finite set of configurations. Only this set of reachable configurations are our concern for a particular system.

The visit rule describes the semantics of executing itinerary i at site s by agent a when i is a primitive itinerary s. Intuitively, it states that “after the execution of primitive itinerary i (i = s) at site s, the state component is transformed into ρ(a, s, σ), and (a, s, s) will be deleted from the layout component”.

The set of inference rules that defines the operational semantics of MAIL is formalized in Figure 2. We will show the expressiveness of MAIL in terms of its regular completeness in Section 4. We explain each rule as follows:

The migrate rule describes the semantics of migrating agent a from site s1 to site s2 for primitive itinerary s2 (s1 6= s2 ). It models the semantics of mobility of an agent: agent a is located at site s1 originally, to execute primitive itinerary s2 where s2 6= s1 , a has to migrate to site s2 , which results the change of the configuration to one that reflects the new location of agent a while the state component

remains unchanged. The sequential rule 1 describes the semantics of executing a sequential composition of two itineraries skip; i2 by agent a. Its interpretation is obvious. The sequential rule 2 describes the semantics of executing a sequential composition of two itineraries i1 ; i2 by agent a where i1 6= skip. It says that “if there exists a configuration transition such that σ is transformed to σ 0 , and layout {(a, s, i1 ), · · ·} is transformed to {(a, s0 , i01 ), · · · , } (specified in the hypothesis), then there exists a configuration transition such that σ is transformed to σ 0 , and {(a, s, i1 ; i2 ), · · ·} is transformed to {(a, s0 , i01 ; i02 ), · · ·}. The receive and send rules describe the semantics of the two asynchronous communication primitives α?X and α!e. The receive rule describes the semantics of receiving a value n from channel α when agent a executes itinerary α?X at site s. The hypothesis specifies that the head of channel α is value n, and the conclusion of the rule specifies that the state of the system will be transformed into state σ[n/X][tail(α)/α], which represents the resulting state of σ after X is assigned with value n and the head element is deleted from α. In addition, (a, s, α?X) is transformed into (a, s, skip). The send rule describes the semantics of sending arithmetic expression e to channel α when agent a executes itinerary α!e at site s. The hypothesis is empty, and the conclusion of the rule specifies that the state of the system will be transformed into state σ[α@[σ(e)]/α], which represents the resulting state of σ after σ(e), the evaluation of arithmetic expression e in state σ, is appended to the end of channel α. In addition, (a, s, α!e) is transformed into (a, s, skip). The synchronization rule describes the semantics of the two synchronous communication primitives signal(ξ) and wait(ξ), which are closely related to send and receive introduced in [1]. Two agent instances need to synchronize between them before either of them can proceed. The conditional rule 1 and 2 describe the semantics of executing a conditional itinerary if c i1 else i2 by agent a when c is evaluated to be true (δ(c, σ) = true) or false (δ(c, σ) = f alse) respectively. The parallel rule 1 and 2 describe the semantics of operator k in terms of the semantics of a new operator ||| and signal(ξ) and wait(ξ). The semantics of ||| is described next. The interleave rule describes the semantics of parallel operator |||. Intuitively, a clone of a is made, and in the resulting configuration, one instance of a is associated with i1 , and the other is associated with i2 . Finally, the Loop rule 1 and 2 describe the semantics of executing a loop itinerary while c do i: if c is evaluated to be true, then while c do i is reduced to c; while c do i; otherwise, the execution of the itinerary terminate successfully,

and it is deleted from the resulting layout. This semantics is closely related to the one for while statement in an imperative programming language. Essentially, the set of rules listed in Figure 2 defines a relation between two configurations →⊆ Ω × Ω. We denote c1 → c2 if (c1 , c2 ) ∈ →. Each relationship c1 → c2 models a possible one-step computation which transforms configuration c1 to c2 . Therefore, an MAIL language specifies a transition system [20], which is a graph in which nodes represent configurations, and edges represent → relationships between configurations. However, the corresponding transition system is infinite since the number of configurations Ω in the system is infinite. Fortunately, Theorem 3.1 shows that, given an initial configuration, a system can only reach a finite set of configurations. This implies that all systems specified in MAIL are amenable to model checking technique [3, 5, 11] to verify their important correctness and safety properties. This is an attractive property of MAIL, in addition to its expressiveness that will be shown in the next section. Theorem 3.1 Let c be an arbitrary configuration of a transition system specified in MAIL. The set of configurations that c can reach is finite. Proof: See [12].

2

As a result of Theorem 3.1, numerous verification problems can be defined for mobile agent systems. More importantly, these problems are decidable and can be solved using existing model checking techniques [3, 11]. We give some examples here and leave further development to future work. Definition 3.2 (Invariant) Given a condition con, we say con is an invariant of a transition system with respect to initial configuration c iff for each c0 = (σ 0 , l0 ) such that c ; c0 , we have δ(con, σ 0 ) = true. 2 Corollary 3.3 The problem of checking if a condition con is an invariant of a transition system specified in MAIL with respect to initial configuration c is decidable. Definition 3.4 (Safety) A safety partition of Ω, the set of configurations of a system, is a pair (S, IS) such that (1) S ∪ IS ≡ Ω and (2) S ∩ IS ≡ Φ. S and IS are called the set of safe and unsafe configurations respectively. A system is safe w.r.t. an initial condition c iff for each c0 such that c ; c0 we have c0 ∈ S, and unsafe otherwise. 2 Although for a particular system, the definition of safe configurations is application-dependent, the following corollary shows that it is decidable to check whether a system is secure or not; see [12] for proof. Corollary 3.5 The problem of checking whether a mobile agent system is safe or not with respect to initial configuration c is decidable.

4. Expressiveness of MAIL In this section, we study the expressiveness of MAIL in terms of the trace model. Imagine we are observing the execution of a particular itinerary i by an agent a, and we record the sites that are visited by agent a and the order that this set of sites are visited. When the execution terminates, we get a sequence of visited sites, called a trace of itinerary i. Given an itinerary i, it is natural to model i by traces(i) – the set of all traces that itinerary i can perform. We call traces(i) as the trace model of i. For example, traces((a; b)) = {< a, b >}, and traces((a k b)) = {< a, b >, < b, a >}. We define a set of rules needed to calculate the trace models for all possible MAIL itineraries. Definition 4.1 (Trace models of itineraries) The model of an itinerary is defined as follows.

trace

workflow temporal constraint language CON ST R [4]. Using MAILC, we can specify that an agent must visit site s1 before it visits site s2 , and the visit of site s cause some other site to be visited or not visited, etc (more examples are shown below). These constraints are believed to be sufficient for the needs of itinerary reasoning, and they are far beyond of the capabilities of current available agent systems. In the following, we define MAILC and show that the itinerary satisfaction checking problem is decidable. Definition 5.1 (Itinerary constraint language) We define a formula of itinerary constraint langauge MAILC has the following form: A ::= T | F | s | s1 ⊗ s2 | A1 ∧ A2 | A1 ∨ A2 | ¬A We also define the implication connective as A1 → A2 ::= ¬A1 ∨ A2 . 2 Example 5.2 The following examples illustrate some possible constraint expressions and their meanings:

• traces(skip) = {}, traces(stop) = φ. • traces(v) = {< v >} where v is a visit. • traces(i1 ; i2 ) = traces(i1 ) ˆ traces(i2 ).

• e: e must be visited eventually.

• traces(if c i1 else i2 ) = traces(i1 ) ∪ traces(i2 ). • traces(i1 k i2 ) = traces(i1 ) ./ traces(i2 ).

• e ∧ f : both e and f must be visited (in any order) eventually.

• traces(while c do i) = traces(i)∗ .

• e ∨ f : at least one of e and f will be visited eventually.

where _, ∪, ./, and ∗ represent concatenation, union, interleaving, and Kleen closure respectively. 2 Definition 4.2 (Regular trace model) We define regular trace models over a set of sites S as follows: (1) φ and {v} are regular trace models where v ∈ S, (2) if i1 and i2 are regular trace models, then i1 ∪i2 , i1 ˆ i2 , i1 ./ i2 , i∗1 are regular trace models, and (3) a regular trace model is obtained only by applying the above two rules in a finite number of times. 2

• ¬e ∨ ¬f : at least one of e and f will not be visited. • e ⊗ f : one must first visit e and then visit f (possibly visit other sites in between). • ¬(e ⊗ f ): one must not visit e before visiting f . • e → f : if e is visited, then f must be visited (either before or after visiting e). • e → (e ⊗ f ): if e is visited, a visit of f must occur after some visit of e. • e → (f ⊗ e): if e is visited, a visit of f must precede some visit of e.

Theorem 4.3 shows that any regular trace model can be expressed by a MAIL itinerary.

2

Theorem 4.3 (Regular completeness) For each regular trace model m over a set of sites S, there exists an itinerary I such that traces(I) = m.

Definition 5.3 (Itinerary satisfaction) Given an itinerary I and a constraint expression C, we say I satisfies C (denoted by I |= C) iff traces(I) |= C. 2

2

The following theorem shows that itinerary satisfaction checking can be performed in polynomial time.

Proof: See [12].

5. Itinerary reasoning One important aspect of an agent system is the temporal constraints concerning the order of site visits, and the satisfaction checking problem of itineraries associated with temporal constraints. In this section, we propose an itinerary constraint language, MAILC, which is based on

Theorem 5.4 (Itinerary satisfaction checking) Given an itinerary I specified in MAIL and a constraint expression C specified in MAILC, the time complexity of checking if I |= C is O(m*n) where m is the size of I and n is the size of C. Proof: See [12].

2

6. Conclusions and future work We have defined the syntax and operational semantics of MAIL, a mobile agent itinerary language that allows one to specify the mobile behavior of an agent. MAIL is structured and compositional. It is also expressive in the sense that it can specify any itinerary of a regular trace model. We have proved that for any initial system configuration, the set of reachable configurations defined by a MAIL itinerary is finite and that the problem of checking whether such a mobile agent system is secure with respect to the initial configuration is decidable. We have also developed a constraint language for the specification of temporal constraints concerning the order of site visits. The MAIL language has been successfully implemented in a featured Naplet [24] mobile agent system. Currently, MAIL supports static itineraries only; that is, the initial itinerary associated with an agent cannot be changed during its life cycle, although its actual path is determined dynamically. Extension of MAIL to support dynamic itineraries would further our understanding of mobile agent systems in which itineraries and communication interplay together. For example, two mobile agents might pass from one to another not only primitive values and communicating channels, but also itineraries as well. It is still not clear what the semantics would be for passing an itinerary from one agent to another since by doing so, the former might affect the navigational behavior of the later.

References [1] A. Bonner and M. Kifer. Concurrency and communication in transaction logic. In Joint International Conference and Symposium on Logic Programming, pages 142–156, 1996. [2] K. M. Chandy and J. Misra. Parallel Program Design: A Foundation. Addison-Wesley, 1988. [3] E. Clarke, O. Grumberg, and D. Peled. Model Checking. MIT Press, 1999. [4] H. Davulcu, M. Kifer, C. R. Ramakrishnan, and I. V. Ramakrishnan. Logic based modeling and analysis of workflows. In Proceedings of the ACM Symposium on Principles of Database Systems, pages 25–33, Seattle, WA, USA, June 1998. [5] W. Emmerich and N. Kaveh. Model checking distributed objects. In Proc. of the 4th International Software Architecture Workshop, Limerick, Ireland, June 2000. [6] W. Farmer, J. Guttman, and V. Swarup. Security for mobile agents: Authentication and state appraisal. In Proc. of the 4th European Symposium on Research in Computer Security (ESORICS ’96), pages 118–130, September 1996. [7] C. Fournet, G. Gonthier, J.-J. Levy, L. Maranget, and D. Remy. A calculus of mobile agents. In Proceedings of Int’l Conference on Concurrency Theory (CONCUR’96), pages 406–421, 1996.

[8] S. Fu and C.-Z. Xu. Mobile codes and security. In Handbooks of Information Security. Wily & Sons, 2005. [9] R. Gray, G. Cybenko, D. Kotz, and D. Rus. Mobile agents: Motivations and state-of-the-art systems. In J. Bradshaw, editor, Handbook of Agent Technology. AAAI/MIT Press, 2000. [10] S. W. Loke, H. Schmidt, and A. Zaslavsky. Programming the mobility behavior of agents by composing itineraries. In Proc. of the 5th Asian Computing Science Conference (ASIAN’99), pages 214–226, 1999. [11] S. Lu and S. Smolka. Model checking the secure electronic transaction (SET) protocol. In Proc. of the 7th IEEE International Symposium on Modeling, Analysis and Simulation of Computer and Telecommunication Systems, pages 358–365, College Park, MD, USA, October 1999. [12] S. Lu and C.-Z. Xu. Mail: A mobile agent itinerary language for correctness and safety reasoning. Technical Report TR-DMSL-2004-02, Wayne State University, Detroit, MI 48202, 2004. [13] C. Mascolo, G. Picco, and G.-C. Roman. A fine-grained model for code mobility. In Joint Proc. of the 7th European Software Engineering Conf. and the 6th ACM Int’l Symp. on Foundations of Software Engineering, 1999. [14] P. McCann and G.-C. Roman. Compositional programming abstractions for mobile computing. IEEE Transactions on Software Engineering, 24(2):97–110, February 1998. [15] R. Milner. A calculus of communicating systems. Volume 92 of Lecture Notes in Computer Science, 1980. [16] R. Milner, J. Parrow, and D. Walker. A calculus of mobile processes (parts i and ii). Information and Computation, 100:1–77, 1992. [17] G. C. Necula. Proof-carrying code. In Proc. of the 24th ACM Symposium on Principles of Programming Languages, pages 106–119, Paris, France, Jan. 1997. [18] G. Picco, G.-C. Roman, and P. McCann. Expressing code mobility in mobile unity. In Proc. of 6th European Software Engineering Conf. (ESEC/FSC’970), 1997. [19] G.-C. Roman, P. McCann, and J. Plunn. Mobile UNITY: Reasoning and specification in mobile computing. ACM Trans. on Software Engineering and Methodology, 6(3), July 1997. [20] A. Roscoe. The Theory and Practice of Concurrency. Prentice Hall, 1998. [21] M. Strasser and K. Rothermel. Reliability concepts for mobile agents. International Journal of Cooperative Information Systems, 7(4):355–382, 1998. [22] A. Tripathi, N. Karnik, T. Ahmed, and et al. Design of the Ajanta system for mobile agent programming. Journal of Systems and Software, May 2002. [23] M. Wermelinger and J. Fiadeiro. Connectors for mobile programs. IEEE Transactions on Software Engineering, 24(5):331–341, May 1998. [24] C.-Z. Xu. Naplet: A flexible mobile agent framework for network-centric applications. In Proc. of the 2nd Int’l Workshop on Internet Computing and E-Commerce (In conjunction with IEEE IPDPS’2002), April 2002.