Secure synthesis and activation of protocol translation agents

Transcription

1 Home Search Collections Journals About Contact us My IOPscience Secure synthesis and activation of rotocol translation agents This content has been downloaded from IOPscience. Please scroll down to see the full text Distrib. Syst. Engng (htt://ioscience.io.org/ /4/4/002) View the table of contents for this issue, or go to the journal homeage for more Download details: IP Address: This content was downloaded on 15/12/2015 at 17:41 Please note that terms and conditions aly.

2 Distrib. Syst. Engng 4 (1997) Printed in the UK PII: S (97) Secure synthesis and activation of rotocol translation agents Yen-Min Huang and Chinya V Ravishankar Deartment of Electrical Engineering and Comuter Science, The University of Michigan, Ann Arbor, MI , USA Received 29 July 1996 Abstract. Protocol heterogeneity is ervasive and is a major obstacle to effective integration of services in large systems. However, standardization is not a comlete answer. Standardized rotocols must be general to revent a roliferation of standards, and can therefore become comlex and inefficient. Secialized rotocols can be simle and efficient, since they can ignore situations that are recluded by alication characteristics. One solution is to maintain agents for translating between rotocols. However, n rotocol tyes would require O(n 2 ) agents, since an agent must exist for a source destination air. A better solution is to create agents as needed. This aer examines the issues in the creation and management of rotocol translation agents. We focus on the design of Nestor, an environment for synthesizing and managing RPC rotocol translation agents. We rovide rationale for the translation mechanism and the synthesis environment, with secific emhasis on the security issues arising in Nestor. Nestor has been imlemented and manages heterogeneous RPC agents generated using the Cicero rotocol construction language and the URPC toolkit. 1. Introduction Heterogeneity is an inevitable concomitant of distribution. It comlicates interaction between entities in a distributed system, and is a major obstacle to effective integration of services in large systems. Protocol heterogeneity often arises when systems are develoed in isolation, but a more imortant cause is that rotocols are secialized to meet alication-secific requirements. Standardization is not always a good answer, since standardized rotocols must target the general case in a roblem domain to revent a roliferation of standards. Such general rotocols can be comlex and inefficient. A strong case is made for alication-secific rotocols in [3, 4]. Such rotocols can be simle and efficient, since they can safely ignore conditions recluded by alication characteristics, but which more general rotocols must address. A good examle of this henomenon is the domain of remote-rocedure calls. Figure 1, which was modified from [5] to include synchronous RPC, illustrates various RPC rotocols available today. It is significant that these rotocols all differ significantly in their semantics, not simly in their mechanics. Desite this great variety, there will almost certainly be a continued need to build RPCs with new semantics, because it is unlikely that current RPCs address the requirements of all future alications. Further, RPCs customized to alication semantics will imrove throughut, resonse time, and failure resilience address: [email protected] Sun RPC NCA RPC Cedar RPC HRPC... Traditional RPC Synchronous RPC Broadcast RPC Sun Broadcast RPC NCA Broadcast RPC RPC Fault Tolerant RPC Asynchronous RPC Without Return Value NCA Maybe RPC Sun Batching RPC MIT Remote Pie NCA Broadcast/Maybe RPC Figure 1. The current RPC domain. With Return Value Stream RPC Future RPC ASTRA even for existing distributed alications. As distributed alications become more sohisticated, customized RPCs can also reduce the effort of alication develoment if they include more functionalities common to a secific class of alications. For examle, it is easier to imlement distributed transaction alications by using RPC with atomic transactions than by using traditional RPCs. Within emerging areas such as multimedia conferencing and distributed real-time alications, it is likely that more RPC rotocols will be designed and imlemented. Standardization of rotocols and interfaces is a common aroach to handing the roblem of heterogeneity. Good /97/ $19.50 c 1997 The British Comuter Society, The Institution of Electrical Engineers and IOP Publishing Ltd 191

3 Y Huang and C V Ravishankar examles of such standards are CORBA s general inter- ORB rotocol (GIOP) and internet inter-orb rotocol (IIOP) [6]. However, this aroach may not always work, articularly for legacy software, since it is unrealistic to exect that all existing software will be recoded to new standards. Another roblem is that standards must address the general case in a roblem domain, for otherwise, a searate standard will be required for each secific situation or context, leading to a roliferation of standards. Such generality rules out alication- or situation-secific customization, though communication atterns between alications can be quite secialized. For examle, [7] observes that over 95% of remote-rocedure calls do not cross machine boundaries, and rooses a customized, light-weight RPC machanism which is over three times as fast as native RPC. Also, a general-urose rotocol must be robust in the face of arbitrary rogram behaviour, while a rotocol customized to an alication can ignore behaviours that the rogrammer or comiler knows will never occur. Another solution to handling the roblem of rotocol heterogeneity is to maintain agents for translating between rotocols. However, an agent must exist for a source destination air in such a solution, requiring a total of n (n 1) agents for n different rotocol tyes. This is a clearly unaccetable rate of growth in the number of agents. CORBA s aroach [6] is to rovide for environmentsecific inter-orb rotocols (ESIOPs) to handle cases where certain distributed comuting infrastructures may already be in use. An examle is the DCE common inter-orb rotocol (DCE-CIOP) which is useful when existing alications use DCE. This aroach combines standardization with the use of redefined cross-domain maings. Thus, it aears not to scale well. Clearly, a better solution would be to create agents as needed Addressing heterogeneity This aer concentrates on the issues that arise in creating and executing rotocol-translation agents at client sites in a secure fashion. However, to rovide background, we outline the issues that motivate the agent synthesis aroach. Some of this exosition also aears in [1] and [3], which rovide details on how the agent synthesis rocess oerates in the case of RPC heterogeneities. The RPC domain is a good model of the more general issues of rotocol heterogenity, and we use it to illustrate more general issues. As figure 1 shows, different RPC rotocols are often designed to satisfy different alication requirements, making it hard for rograms built using different RPC rotocols to be interconnected directly. This difficulty greatly reduces the availability of software and resources in a large heterogeneously distributed environment, and increases the costs of develoing and maintaining distributed alications with multirotocol suort. This roblem is most acute when trying to integrate distributed alications from different sources. Some examles are integrating different distributed file systems, imlementing federated distributed databases, or grouing various scientific comutation servers. The same roblem also arises when building an alication with multile-rotocol suort, such as a client that can communicate with different name servers using different RPCs, or a server that must accet requests from many clients. We encountered this roblem whilst working on the client service model in the Cygnus distributed system [8]. The classical client server model requires the client both to identify servers as well as to seak the server rotocol. Therefore, clients are tyically able to interact only with a limited number of servers in such systems. The Cygnus system [8] solves this difficulty by introducing the client service model, in which clients request services, not servers. The maing from services to servers is erformed by Cygnus. Although the work on Cygnus was done indeendently of CORBA (and in fact, largely redates it), their resective aroaches have both similarities and differences. Cygnus and CORBA both resent the client with an object-oriented rogramming model which emhasizes transarency and hides many of the system details from the client, and in which object oerations may execute either locally or remotely. However, Cygnus comletely eliminates the notion of server, so that objects reresent service. Thus, when a service rovider (server) fails, Cygnus is often able to reconfigure the connection to another equivalent server, and continue the identical service. Cygnus also assumes that servers are comletely insular, so it may be required to oerate in an environment with little standardization. Since clients do not see servers at all, the Cygnus system must handle all rotocol heterogeneities. Since servers in Cygnus are insular, clients must conform to server rotocols. Cygnus uses agent synthesis as its solution to this difficulty. When a remote server must be contacted to obtain service, a rotocol secification is retrieved from the server site, and an agent is synthesized at the client site to ma to the server rotocol. In CORBA, standards exist for communications within and across ORBs [6]. Work is already in rogress [9, 10] on building effective imlementations of cross-orb communications using bridges and half-bridges, articularly for DCE environments. Rosenberry and Teague [11] discussed the interesting issue of the interoerability of DCE and windows NT domains, the two environments likely to be among the most ervasive in the future. However, in contrast to CORBA and other such efforts, Cygnus does not have the notion of ORBs. Any client server connection established as a result of a service request may be a connection between entities seaking different rotocols. Cygnus synthesizes code to handle such heterogeneity on demand. We have a full imlementation for handling heterogeneous remote-rocedure calls, and we observe no loss of erformance over native RPC (see section 3.4). We have built both customized RPCs with secialized semantics (multicast, at-most-once, call-back, asynchronous, etc) and cross-rpc (Sun, Aollo, Mach, NCS, etc) imlementations in our exeriments. For further details and examles see [1 3]. Another real issue with RPCs is that the cost of imlementing a new RPC system is usually much higher than it needs to be. Much develoment effort is often 192

4 Secure synthesis and activation of rotocol translation agents sent on redoing significant arts of suorting facilities, such as stub generators, name servers, and low-level communication functions. The main obstacle to reusing these comonents is that they are often tightly integrated with the RPC runtime, and modifications are often required to suort new RPC features. Therefore, without clever design of the RPC runtime interface and architecture, it would be imossible to rovide highly reusable RPC runtime comonents useful for a variety of RPC rotocols Our aroach: agent synthesis An agent synthesis scheme uses a synthesizer to generate imlementations of RPC agents from highlevel descritions, and is attractive because it meets our requirements well, and since much of the effort of coding agents can be saved. Also, there are fewer restrictions on the kinds of RPC agents that can be described and generated. Therefore, if designed roerly, a synthesis scheme can rovide a more general solution than existing aroaches [12 16], and with much lower agent develoment and maintenance costs. There is a major difference between our agent synthesis scheme and that of others [17, 18]: in addition to traditional stubs, we also generate imlementations of RPC rotocol machines as a art of the RPC runtime. In other words, for each different RPC rotocol, a different RPC runtime may be generated along with the necessary stubs. This synthesis caability can also be used for raid rototying of new RPC systems [3], which is very useful to RPC develoers. Our system rovides two services: customization and cross-rpc service. Customization suorts fast rototying of customized RPC systems and for exerimenting with new RPC features and semantics. This service is designed to hel rototye a new RPC system, including the RPC runtime, the stub generator, and the name server. Cross- RPC service suorts cross-rpc communication to increase software availability. This service assumes a common transort-layer rotocol between the client and the server machines, and rovides an interconnecting rogram that reserves the largest subset of RPC semantics common to the two RPCs. It is economical to rovide these two services in one system because cross-rpc service can be built on to of customized RPC service. The easiest way, and sometimes the only way, to erform cross RPC is to introduce intermediaries (RPC agents) to facilitate communication between clients and servers. RPC agents are gateways that can translate between different RPC rotocols. Therefore, imlementing RPC rotocols is the central task for building RPC agents, and the customized RPC service is designed for exactly this tye of task. Broadly seaking, our RPC agent synthesis scheme (see figure 2) has two comonents: a language to describe RPC rotocol constructions, and a runtime environment to synthesize and activate RPC agents automatically. Agents are synthesized by combining libraries with the imlementation code generated from the secifications. Our agent synthesis scheme is realized through three subsystems: a universal RPC toolkit (URPC toolkit) [3], a rotocol construction language (Cicero) [2], and a runtime suort system for agent synthesis and management (Nestor). The URPC toolkit rovides semanticsindeendent library functions, allowing rogrammers to rototye diversified new RPC systems with minimal coding effort. Cicero is an executable secification language designed for describing comlex rotocol constructions. Nestor is the subsystem integrating the URPC toolkit, Cicero, and other software utilities to erform agent synthesis and management for cross-rpc communication. To facilitate agent synthesis, Nestor also rovides suort for imorting rotocol constructions from remote hosts. This aer focuses on Nestor. 2. The mechanics of agent synthesis This section rovides an introduction to the mechanics of synthesizing agents for RPC rotocols using Nestor. Some of this discussion aears in [1], and is reroduced here to rovide a background for our discussion. The agent synthesis system comrises a secification language Cicero [2], the URPC toolkit for generating RPC runtimes [3], and Nestor, the environment in which the synthesis and activation of agents takes lace. This aer focuses on Nestor. Nestor facilitates the synthesis of agents with various RPC semantics. It rovides services for imorting and exorting secifications, and can activate and terminate agents for cross-rpc communication. Therefore, Nestor is resonsible for the entire lifecycle of RPC agents, i.e. their creation, activation and termination Secifications and agent synthesis Synthesizing agents involves two stes: (1) constructing necessary synthesis secifications, and (2) synthesizing agents from secifications. The first ste involves describing RPC semantics, interfaces and instructions for synthesis. The second ste involves generating code, comiling, and linking all the comonents and libraries to create executable images of agents. The first ste is accomlished by rogrammers manually, and the second ste is accomlished by Nestor with little or no intervention from rogrammers. To synthesize an RPC agent, three secifications are required: the RPC rotocol construction, the RPC interface secification and the RPC agent rofile secification. The RPC rotocol construction and the RPC interface secification together determine what agent will be synthesized. Secifically, the RPC rotocol construction (written in Cicero) describes the imlementation of RPC semantics. The RPC interface secification describes the RPC oeration interface, and is used to generate stubs to interface with the client, the server and the URPC runtime library. The agent rofile secification determines how an agent will be synthesized and managed. It contains instructions for synthesizing and managing agents. For examle, the agent rofile secification defines the synthesis environment, and the activation arameters for an agent. For each rotocol, two sets of these secifications are needed: one for the client agent and one for the server 193

5 Y Huang and C V Ravishankar RPC Protocol Construction RPC Agent Synthesis RPC Agent Management Nestor Figure 2. The RPC agent synthesis scheme. Stub Generator RPC stub RPC interface secification Agent link rotocol imlementation RPC semantics software ackaging utility libraries Cicero & C comilers RPC agent rofile secification RPC rotocol secification (construction) Figure 3. Secifications and comonents of an agent. agent. The remote interface secification and RPC rotocol construction language have already been described in [3] and [2] resectively, and RPC agent rofile secification will be described in section 2.3. Nestor uses a set of libraries and utility rograms to synthesize executable images of RPC agents. These libraries include the URPC and Cicero runtime libraries. The URPC runtime library rovides routines for constructing communication mechanisms between agents, and the Cicero runtime library suorts Cicero language constructions for describing the link rotocol of agents. The utility rograms used by Nestor consist of comilers for Cicero and C, stub generators, and a software ackaging utility (e.g. the UNIX make). Figure 3 illustrates how these secifications and utility rograms work together to synthesize an agent. The Cicero comiler comiles the RPC rotocol construction and oututs a C-code imlementation of the secified RPC semantics. This C code will be comiled by the native C comiler and linked with the libraries to imlement the link rotocol. The stub generator comiles the RPC interface secifications and generates the stub routines which interface with the client or server rogram, and with the link rotocol imlementation. For customized RPC service, Nestor uses the URPC stub generator to generate stubs to link with client and server rograms. For cross-rpc service, in addition to the URPC stub generator, Nestor exects stub generators from the native RPC facilities, which it uses to synthesize the native RPC stub for the agent. When a stub generator is not available, users are required to rovide RPC stubs. Finally, RPC stubs, libraries, and the link-rotocol imlementation are linked together to form an agent. This entire synthesis rocess is secified in the RPC agent rofile secification and controlled by the software ackaging utility Other related suort for agent synthesis There are two other kinds of suort related to agent synthesis: the secification-transfer suort and the agentmanagement suort. The secification-transfer suort facilitates imorting or exorting rotocol constructions between sites, and is useful since the rotocol constructions may not be available at the machine where an agent will be synthesized. For examle, a user may wish to erform a heterogeneous RPC using server RPC semantics, and the client agent construction for the server RPC rotocol may not be available at the client machine. To synthesize the client agent, the user can imort the client agent construction from the server. The transfer suort is introduced to encourage sharing RPC rotocol constructions in a large heterogeneous environment, so that rogrammers can use or customize existing rotocol constructions instead of writing new ones themselves. The ability to imort rotocol constructions from the outside not only reduces agent develoment costs, but also offers other advantages. It rovides immediate software availability after a rotocol construction is created or udated. Users would just imort the new secifications and synthesize local agents. It minimizes disturbance when udating existing RPCs and introducing new RPCs. Hence, RPC rotocol evolution is well suorted. It also offers the oortunity to synthesize secialized code to imrove erformance. Finally, it also makes the synthesis solution scalable, and makes each site fully autonomous. For details on how rotocols may be secified and used, see [1 3]. The agent-management suort is resonsible for controlling the activation, execution and the termination of agents. All these activities are secified in RPC agent rofile secifications. For examle, users can rovide the activation instructions for a newly synthesized agent in the RPC agent rofile secification, so that Nestor can automatically activate the synthesized agent. If an agent is linked with a client or server rogram, the agentmanagement suort can be used to activate the client and the server directly RPC agent rofile secification An RPC agent rofile secification consists of a list of attributes and values, defining how agents can be synthesized, activated and when they are to be terminated. The attributes currently suorted are listed below, and are categorized according to their usage. Figure 4 shows an examle RPC rofile secification. Identity related attributes s title: This attribute defines the name of an RPC agent rofile secification, and can be referred by rogrammers. This name, indeendent of the secification file name, is used to match u client and server agent rofile secifications. 194

6 Secure synthesis and activation of rotocol translation agents stitle = test role = client instance id = 0 sec server = taiei.eecs.umich.edu workdir = /users/yenmin/test sec ath = /users/yenmin/test imort list = test.rif test fsm.cic exort list = makecmd = maketest cl exec cmd = test cl time to live = 300 acls = end Figure 4. Examle RPC rofile secification. role: This attribute indicates the tye of the secification, i.e. whether it is for a client agent or a server agent. Environment related attributes sec server: This attribute contains the address of the host, which will articiate in transferring secifications. The direction of the transfer will be given by the user at the time of transfer. work dir: This attribute indicates the working directory where the agent will be synthesized and activated. sec ath: This attribute indicates the directory where the secifications are ket locally, so that Nestor can know the source and destination for the secification transfer. Transfer-suort related attributes imort list: This attribute lists the files that must be imorted before synthesizing a local agent. exort list: This attribute lists the files that can be exorted when synthesizing a remote agent. The imort list and exort list are rovided to suort automatic transferring a list of secifications. Synthesis and management related attributes make cmd: This attribute contains the command for synthesizing the agent. exec cmd: This attribute indicates the command for executing the agent. time to live: This attribute defines the lifetime of the agent. Security related attributes acls: This attribute contains the ACL for users who are allowed to synthesize or activate the agent from a given secification. 3. An agent synthesis scenario To describe how Nestor synthesizes agents, we will resent a cross-rpc service scenario where agents are synthesized and activated automatically. We also assume that the user has already discovered the server host address through the Nestor name service suort (see section 3.3 for details) Ste 1: secification construction The client and server rograms are built on to of SUN RPC and HP/Aollo NCS RPC resectively. To kee the examle simle, we assume that there is only one oeration (rintmsg()) exorted by the server, which dislays a given string. This oeration is defined in NCS interface definition language (NIDL) as follows [uuid(4448ecb d fe.da ), ort(dds:[19], i:[6677]), version(1)] interface rintmsg_intf { void rintmsg( handle_t [in] h, string0[1024] [in] msg, int [out] *result); To make the examle more interesting, let us assume that the client cannot be modified and must access this oeration through an existing SUN RPC interface, which is defined in SUN RPC interface definition language as follows rogram MESSAGEPROG { version MESSAGEVERS { int PRINTMESSAGE(string) = 1; = 1; = 99; We can see that although the client and the server can be interconnected logically, their RPC rotocols and RPC interfaces are different. To erform cross RPC, these heterogeneities must be resolved. In general, these will not be the only kinds of heterogeneities encountered. For examle, there may also be differences in rotocol semantics. For details on how these are resolved see [1 3]. Our rimary interest here is the mechanics of agent synthesis and activation. To focus on the synthesis mechanism, let us assume that the client has already obtained the RPC rotocol construction and RPC interface secification for the server. These two secifications are required when a server is exorted to the outside world, and may be stored as art of a name service database that covers a local domain. The RPC interface secification is defined by using our interface definition language, as follows [ atitle = rintmsg; version = 1.0; ] { int urc_rintmsg( [in] handle_t h, [in,string] char *msg, [out] int *result); Although our interface definition language has a different syntax, one can readily see that the above RPC interface secification can be easily derived from the server s remote interface definition. Figure 5 illustrates the structure of the client agent. The client agent consists of five arts: a SUN RPC server stub, a link-rotocol client stub, a iece of connector code, the SUN-RPC runtime library, and the URPC runtime library. The SUN RPC server stub is generated from the given interface definition by the SUN RPC stub generator. The link rotocol client stub is generated by the URPC stub generator from the RPC interface secification. The connector code is introduced to bind the server agent, resolve mismatches between interfaces, and to glue the native stub and link-rotocol stub together. For the client 195

7 Y Huang and C V Ravishankar Connector Code SUN RPC server stub Client SUN RPC runtime Client Agent main() { bind with server agent (URPC) run SUN RPC server code rintmsg_1() { urc_rintmsg() rintmsg_1() user code library urc_rintmsg() { client_rc()... URPC runtime client_rc() { client_m() link rotocol generated code link rotocol URPC client stub Server Agent Figure 5. A synthesized cross-rpc client agent. Nestor User Interface 1 Client Nestor IRSD AM 2,6 4,8 5, Ac Server Nestor IRSD NS AM 8 3,7 Figure 6. The agent synthesis rocess in Nestor. agent, the connector code consists of a main rogram for establishing bindings and a set of dummy server oerations which we will subsequently call the entry routines in the link-rotocol URPC client stub. The SUN RPC and URPC runtime libraries are assumed to be available on the client host. However, it is ossible that an imlementation of the client rotocol machine is not readily available. In this case, the imlementation of the client rotocol machine must either be generated from an imorted rotocol construction or coded by rogrammers. Finally, to roduce the client agent, Nestor will instruct the ackage utility to comile and link all these arts together. Due to symmetry, the server agent can be similarly synthesized Ste 2: agent synthesis and activation After all the secifications are in lace, the rogrammer instructs Nestor to synthesize agents. The stes in the agent synthesis and activation are shown as numbered arcs in figure 6. The Nestor runtime environment consists of two comonents: an internet RPC service daemon (IRSD), and an agent manager (AM). IRSD is a rocess that handles all synthesis requests, and is brought u at machine initialization time. It initializes itself by reading files containing configuration information, and the secifications of services exorted from the site. It then waits for requests from local clients and remote IRSDs. Uon receiving a request, IRSD forks off a coy of the AM to serve the request. The As AM is resonsible for synthesizing, executing and terminating an agent. To facilitate interaction between the user and Nestor, the user is rovided with a command-line interreter called the Nestor user interface (NUI). It allows the user to interact with Nestor by issuing commands. Initially, Nestor runs as an IRSD daemon on the local machine, and listens on well known orts. When the user first contacts the local Nestor instance, it creates an AM to handle the user s requests. The user issues the synthesis request to the client AM (ste 1). The client AM locates the client agent synthesis secifications and contacts the server-side Nestor instance (ste 2). The server-side Nestor instance now forks off an AM to handle the requests from the client AM. After the server AM verifies the client s requests, both the client and the server AM synthesize the agents (stes 3 5). After the agents are synthesized, the client AM notifies the server AM to activate the synthesized server agent (stes 6 and 7). After the server agent (As) is activated, the client agent (Ac) is activated, and the ort number used by the server agent is looked u by the client agent through the server-side URPC name server (stes 8 11). Now, the agents are ready to erform the secified heterogeneous RPC Name service suort Name service is not the focus of this work; therefore, for our system, we simly aly existing mechanisms as aroriate for our uroses. The Nestor name service suort hels a client contact a server by using two items of information: the server host address and the ort number of its agent. The server host address is discovered by using a global database which has knowledge of all available services in the network. The ort number is obtained through the server-side URPC name server. Nestor uses the URPC name service as its default RPC name-service mechanism to byass name-service heterogeneity roblems. For cross-rpc communication, different naming mechanisms may be used for the client and the server RPC systems. In our scheme, the differences in naming mechanisms are subsumed by RPC agents because the client and the server always contact their agents using It does not matter whether or not the database is distributed, or relicated. Here we treat it as a single entity. 196

8 Secure synthesis and activation of rotocol translation agents Table 1. Comarison of URPC-ATM1/UDP with SUN-RPC/UDP. URPC ATM1/UDP SUN-RPC/UDP Data size Local LAN Local LAN U Client Server M M b a null 2.68 ms 2.54 ms 2.68 ms 2.68 ms 1 K 3.59 ms 4.37 ms 3.74 ms 4.51 ms 2 K 5.08 ms 6.37 ms 5.86 ms 7.21 ms C Ac As M c Md M e S Table 2. Comarison of URPC-ATM1/TCP with SUN-RPC/TCP. URPC ATM1/TCP SUN-RPC/TCP Data size Local LAN Local LAN null 3.24 ms 3.19 ms 3.96 ms 3.64 ms 1 K 3.98 ms 5.02 ms 5.33 ms 5.55 ms 2 K 5.55 ms 6.61 ms 7.14 ms 7.36 ms the native RPC runtime suort. How the client agent locates the server agent is indeendent of the native naming mechanisms. Thus, Nestor rovides its own name service suort to locate agents without interfering with the native naming mechanism. This is advantageous because no exlicit maing is necessary between the native naming model and the Nestor naming model Performance A detailed discussion of the erformance of our agent synthesis system aears in [1, 3]. Here we reroduce some relevant numbers. Our data indicate that the erformance of our synthesized code is usually as good as that of native imlementations, and often better. There are two reasons for this somewhat non-intuitive result. First, customization can increase the semantic content of individual messages, and thus reduce the number of messages required. The benefit gained from customization obviously deends on the alication and the manner in which the customization is erformed, but can be significant. A second benefit can be a reduction in time for individual calls since customization results in imlementations tailored for secific situations, which do not incur the overhead resent in imlementations that address more general situations. To facilitate such erformance comarisons, we constructed an RPC (URPC- ATM1) with at-most-once failure semantics using a rotocol machine imlementation similar to that of SUN RPC. Comarisons of elased time were made between URPC- ATM1 and SUN RPC on different transort-layer rotocols (UDP and TCP), and the results are listed in tables 1 and 2. For a more detailed analysis of these results, see [1, 3]. 4. Security suort Security suort is necessary because Nestor oerates in a large heterogeneous distributed environment containing many different administrative domains. Any oint-to-oint communication in this environment may require messages to travel through many different administrative domains. C RPC client N c Nestor at client side S RPC server N s Nestor at server side A c client agent U Nestor user interface A s server agent M x messages Figure 7. Objects in Nestor. Without roer security mechanisms, Nestor users and service roviders are subject to various security attacks. To rovide reasonable rotection to Nestor users and service roviders, the following security issues must be addressed: maintaining the integrity of secifications: The RPC rotocol secifications are sent over the network, so the integrity of the secifications must be reserved. If a secification in transit were to be modified, the consequences would be otentially very serious. Controlling access to Nestor services: We may want to regulate the ermission to synthesize agents from any given secification. Providing secrecy for RPC communication: The integrity of messages between agents must be guaranteed. Although these issues are tyical in a distributed environment, the design of the security mechanism for Nestor requires secial attention in two areas: The security mechanism must handle the delegation relationshis between the client/server and their agents, and between the client and client/server Nestor instances. This delegation relationshi requires authentication through intermediaries, where traditional client server authentication rotocols [19 22] cannot be readily alied. The security mechanism must detect the imersonation of agent executable images, since agents may be synthesized well in advance of their use. The first ste in designing a security scheme is to examine the objects articiating in Nestor activities which may be subject to security attacks. These objects are shown in figure 7, and can be rocesses, executable images, or messages. Each rocess and its executable image are reresented by a circle in figure 7; messages assed between two rocesses are denoted by the symbol M subscrited with a label identifying the connection between the two rocesses (e.g. M a ). Our mechanism does not revent an intruder from exloiting existing security flaws in a system by becoming a sueruser [23]. This tye of attack is a general roblem for all systems, not just for Nestor. Our mechanism is based on the Needham Schroeder ublic-key rotocols [19] with three assumtions. The first assumtion is that ublic keys are distributed by trusted name servers whose ublic keys are known by Nestor. The second assumtion is that ublic keys of each client and Nestor instance are already advertised among name servers. 197

9 Y Huang and C V Ravishankar Table 3. Protection for messages. Table 4. Detection of imersonated objects. Message Protected by Object Imersonation detection scheme M a M b M d M c /M e digital signature digital signature session key encrytion native RPC system and kernel Client (U/C) Client Nestor () Server Nestor () Client agent (Ac) Server agent (As) digital signature digital signature digital signature session key encrytion/decrytion session key encrytion/decrytion The third assumtion is that the rivate keys of the user and Nestor instances involved are not comromised Protecting messages One of our major concerns is rotecting the integrity and secrecy of messages exchanged between machines. We assume that the local interrocess communication is secure. In other words, the integrity and the secrecy of local messages are guaranteed by the oerating system delivering them. The security mechanism design will focus on rotecting messages exchanged between machines. Two tyes of intermachine messages need to be rotected: messages assed between the client and server Nestor instances (M b ) and messages assed between agents (M d ). The schemes used for message rotection are summarized in table 3. Messages assed between the client and server Nestor instances are imortant because they may contain secifications and keys, whose unforgeability and accountability are imortant to both the client and the server. To deal with intermediaries, we adot the cascading authentication rotocol roosed in [24] to rotect these messages. The messages exchanged between Nestor instances are digitally signed [19] by the user and each Nestor instance, so that their integrity is rotected, and the client and each Nestor instance are identifiable. Therefore, under the cascading authentication rotocol, the messages M a must also be digitally signed even though they are assed locally. This security rotocol for exchanging messages between Nestor instances is discussed in section 4.5. The messages assed between agents (M d ) are rotected using shared session key encrytion/decrytion instead of the ublic-key encrytion. Shared key encrytion is used because keys can be created and distributed safely by Nestor instances, and shared key encrytion is about times faster than ublic-key encrytion [22]. A new session key is created and assed to the client and the server agents each time they are invoked. This shared session key is also used to imlement a challenge-resonse rotocol, which client and server agents use to authenticate each other. This security rotocol for rotecting messages is discussed in section Access control for Nestor services We use ACLs to control the access to Nestor services. The server-side Nestor instance authenticates a client by decryting the client s request which is digitally signed by the user and the client-side Nestor instance. Because this client authentication is a direct result of the digital-signature rotection scheme used for messages, no additional mechanism is necessary. Note that the Nestor ACL is not resonsible for controlling access to servers. It only controls access to Nestor services Protection against imersonated executable objects Protection against imersonation should consist of two arts: substitution revention and substitution detection. Substitution revention for executable objects deends mostly uon setting access rights carefully and removing security flaws, which are both functions of system administrators. Thus, here we focus uon substitution detection. Substitution detection involves detecting two forms of substitution: rocess imersonation and executable image substitution. Our substitution detection mechanism uses either ublic-key or session-key encrytion to detect imersonation of rocesses, and uses a digest function [25] to detect the imersonation of executable images (see table 4). The same digital signature scheme used in rotecting messages is also used for detecting the imersonation of the user (U), the RPC client (C) and Nestor rocesses (N c and N s ). When they fail to identify themselves through encryted messages, the receiving rocess detects ossible imersonation and closes the connection. The shared session key is used to detect the imersonation of agent rocesses. Since it is ossible to imersonate an agent after the agent is activated but before the client contacts it, the agent must be authenticated when contacted by the client. This authentication between the client and the Ac is accomlished through a tyical challenge-resonse rotocol using a shared session key encrytion/decrytion (see figure 9). However, the distribution of the session key requires articiation of the client rogram, which may be difficult. In such cases, the imersonation may not be detected. To ensure that the synthesized agent is indeed the one that is activated, Nestor can use a digest function to comute the digest of the binary image of an agent when A request is first encryted using the user s rivate key, and assed to the local Nestor instance. The local Nestor forwards the encryted request to the server-side Nestor by further encryting the message using its own rivate key and the server-side Nestor s ublic key. The serverside Nestor can decryt the message using its rivate key, the client-side Nestor s ublic key, and user s ublic key. This is the time that the intruder can register a malicious agent in the native name service to relace the genuine one. The digest is the result of a one-way digest function. In other words, it is comutationally imossible to comute the inut from a given digest (the outut). 198

10 Secure synthesis and activation of rotocol translation agents U { s I U k s M U { IU { N { M UTU k 1 2 s s k k k U { N c { U { I U M U T U k s k k U { U { N s { I U M 4 3 N s k s U k U k x ublic key of X s k x secret key of X K { encryted with K M x T x I x message sent by X timestam issued by X nonce id issued by X Figure 8. Security rotocol for assing messages between Nestor instances. the agent is synthesized. Before an agent is executed, the digest of its binary image is comuted and comared with the digest comuted when the agent was synthesized Cross-RPC authentication The native RPC runtime in a cross-rpc agent enables the agent to communicate with the client or server using native secure communication rotocols. Although different encrytion/decrytion schemes are subsumed by the native runtime in the agent, maing rincial identities across administration domains remains an issue. This identity-maing issue can be addressed differently deending on whether or not client and server RPCs use a common authentication rotocol. If client and server RPCs use a common authentication rotocol, such as Kerberos [21], then the client rincial can register directly in the server domain as a foreign entity, and can be authenticated through Kerberos security servers. Similarly, the Nestor instances can use Kerberos for authentication with each other and with the corresonding client or server. After mutual authentication, the client and all agents will be sulied with a shared session key by Kerberos security servers for secure communication. If there are no common identities, Nestor relies on a ublic key encrytion scheme for authenticating the client and Nestor instances. The authenticated client s identity must be maed into an equivalent rincial on the server side, which is the reselected identity for the server agent. This maing may or may not be ossible. Assuming an aroriate identity can be found, a session key shared between the client and the agents can be generated and distributed by the client-side Nestor. This session-key distribution rotocol is described and formally analysed in section Security rotocol between Nestor instances The security rotocol for exchanging messages between Nestor instances is illustrated in figure 8. Timestams and nonce numbers are introduced to guard against the relay attack and rocess imersonation (see section 4.3). The security rotocol between Nestor instances works as follows. When a user wishes to request a service, the Nestor user interface encryts the user s message with the user s rivate key and the client-side Nestor s ublic key before sending to the client-side Nestor. Uon receiving the user message, the client-side Nestor decryts the message using its own rivate key, and then re-encryts the user message with its rivate key and the server-side Nestor s ublic key before forwarding the message to the server-side Nestor. The server-side Nestor can decryt this message with its own rivate key, the client-side Nestor s ublic key, and user s ublic key. After the user s request is granted and rocessed, the rely message is returned, and the rely message is encryted with the user s ublic key, the client-side Nestor s ublic key, and the server-side Nestor s rivate key. The client-side Nestor unwras (decryts) the message with its rivate key, and asses the resulting message to the Nestor user interface. At the end, the Nestor user interface extracts the content of the rely message by decryting the message with his rivate key and the serverside Nestor s ublic key. A formal analysis of this rotocol can be found in section Security rotocol between agents Messages assed between agents are rotected using shared session key encrytion/decrytion. A new session key is created and assed to the client and the server agents each time they are invoked. This shared session key is also used to imlement a challenge-resonse rotocol, which client and server agents use to authenticate each other. The security rotocol between agents is basically a session key distribution rotocol. The session key is generated by the client-side Nestor uon client request. The session key is distributed using digitally signed messages to the client and the server-side Nestor. It is also assed to 199

11 Y Huang and C V Ravishankar C 1 k s k C { C { I C T c 4 k s k C {{ I C k A A c k A 2 3 k s k { { k A I T s k { I A k { k A N s A s k x s k x K { C S Ac ublic key of X secret key of X encryted with K RPC client RPC server client agent M x message sent by X T x timestam issued by X I x nonce id issued by X server side Nestor client side Nestor As server agent Figure 9. Security rotocol for assing messages between agents. client and server agents as one of the activation arameters. This distribution rotocol is illustrated in figure 9. This rotocol also uses timestams to guard against relay attack and nonce numbers as shared secrets for rocess imersonation detection (see section 4.3). Once the session key distribution is comleted, agents can use this session key to encryt/decryt messages. In section 5.2 there is a formal analysis of this rotocol. 5. Security rotocol analysis To analyse Nestor security rotocols, the logic roosed in [26] is used. All the analysis stes are also illustrated in the same notation and style as in [26]. The rules in figure 10 also aear in [26] and will be used for analysing our security rotocols Security rotocol between nestor instances Messages. R1 : R2 : R3 : R4 : R5 : R6 : R7 : R8 : R9 : R10 : P believes Q K P, P sees {X P believes Q said X K P believes Q, P sees {X s K P believes Q said X P believes Q Y P, P sees {X Y P believes Q said X P believes fresh (X), P believes Q said X P believes Q believes X P believes Q controls X, P believes Q believes X P believes X P believes fresh (X) P believes fresh (X,Y) P believes Q K P, P sees {X P sees X K P believes P, P sees {X K P sees X K P believes Q, P sees {X P sees X P sees (X,Y) P sees X Figure 10. Analysis rules. M1. U N c : {N s,u,{i u,m u,t u s u M2. N c N s : {N c {U{I u,m u,t u s u s M3. N s N c : {U{N s {I u,m s u M4. N c U : {N s {I u,m s u Idealized rotocol translation. M1. U N c : {{I u,m u,t u s u M2. N c N s : {{I u,m u,t u s u s M3. N s N c : {{{I u,m s u M4. N c U : {{I u,m s u Goals. G1 : N s believes U said M u G2 : N s believes fresh(m u ) G3 : N s believes U believes M u G4 : U believes N s said M G5 : U believes fresh(m ) G6 : U believes N s believes M 200

12 Secure synthesis and activation of rotocol translation agents Assumtions. K A1 : U believes N c A2 : U believes K N s A3 : U believes M u A4 : U believes I u A5 : U believes fresh(i u ) A6 : N c believes K N s K u A7 : U believes U A8 : N s believes Ku U A9 : N s believes K N c A10 : N s believes M A11 : N s believes fresh(m ) A12 : N s believes fresh(t u ) Protocol analysis. M1, R8 : N c sees {I u,m u,t u s u E1 M2, R8 : N s sees {{I u,m u,t u s u s E2 E2, A9, R2 : N s believes N c said {I u,m u,t u s u E3 A8, R2 : N s believes U said {I u,m u,t u E4 R10 : N s believes U said M u (G1) R12, R6 : N s believes fresh(i u,m u,t u ) E5 E5 : N s believes fresh(m u ) (G2) G1, G2, R4 : N s believes U believes M u (G3) M3, R8 : N c sees {{I u,m s Ku E6 M4, R8 : U sees {I u,m s E7 E7, A2, R2 : U believes N s said {I u,m E8 E8 : U believes N s said M (G4) E7, A4, R6 : U believes fresh(m ) (G5) G4, G5, R4 : U believes N s believes M (G6) 5.2. Security rotocol between agents Messages. M1. C N c : {C, {I c,t c s c K M2. N c N s : {N c {,I,T s K M3. N s N c : {{I a s M4. N c C : {{I c, s Ku Idealized rotocol translation. M1. C N c : {{I c,t c s c K M2. N c N s : {{A c As,I,T s K M3. N s N c : {I,A c As s M4. N c C : {{I c,c Ka A c s Ku Goals. G1 : A c believes A c As G2 : A s believes A c As G3 : C believes C Ka A c G4 : N s believes A c As G5 : N c believes N s believes A c As Assumtions. A1 : C believes K N c A2 : C believes fresh(i c ) A3 : C believes N c controls C Ka A c K A4 : N c believes N s A5 : N c believes Kc C A6 : N c controls A c As A7 : N c controls C Ka A c A8 : N c believes fresh(t c ) A9 : N c believes fresh(i ) A10 : N s believes K N c A11 : N s believes fresh(t ) A12 : N s believes N c controls A c As A13 : A c believes N c controls A c As A14 : A c believes fresh(a c As ) A15 : A c believes N c said A c As A16 : A s believes N s controls A c As A17 : A s believes fresh(a c As ) A18 : A s believes N s said A c As Protocol analysis. A14, A15, R4 : A c believes N c As believes A c E1, A13, R5 : A c believes A c A17, A18, R4 : A s believes N s m believes A c As As E2, A16, R5 : A s believes A c As M4, R8 : C sees {I c,c Ka A c s E3, R2 : C believes N c said {I c,c Ka A c A2, R6 : C believes fresh(c Ka A c ) E4, E5, R4 : C believes N c believes C Ka A c E6, A3, R5 : C believes C Ka A c M2, R8 : N s sees {A c As,I,T s E7, R2 : N s sees N c said {A c As,I,T E8, A11, R6 : N s believes fresh(a c As ) E8, E9, R4 : N s believes N c believes A c E10, A12, R5 : N s believes A c M3, R2 : N c believes N s said {I,A c As As As E1 (G1) E2 (G2) E3 E4 E5 E6 (G3) E7 E8 E9 E10 (G4) E11 201

13 Y Huang and C V Ravishankar A9, R6 : N c believes fresh(a c As ) E11, E12, R4 : N c believes N s 6. Conclusions believes A c As E12 (G5) Automating the generation of rotocol agents can be very useful in the resence of heterogeneity. This aer resents a method for automating the rocess of agent synthesis and activation. To illustrate our scheme, we rovide details for creating and managing remote-rocedure calls agents, since RPCs are the most widely used aradigm for interrocess communication. However, the techniques described in this aer aear to extend to other aradigms as well. Since security is of a articular concern in distributed environments, our scheme incororates security rotocols to guard against various kinds of attacks. The agent synthesis mechanisms in Nestor are currently oerational, and are being used in conjunction with the RPC agent synthesis mechanism described in [1]. We are currently comleting the imlementation of the security mechanisms. Acknowledgments This work was artly suorted by NASA and its Socioeconomic Data and Alications Center oerated by the Consortium for International Earth Sciences Information Networking. References [1] Huang Y and Ravishankar C V 1994 Designing an agent synthesis system for cross RPC communication IEEE Trans. Software Engng 20 [2] Yen-Min Huang and Ravishankar C V 1994 Linguistic suort for controlling rotocol execution Proc. 14th Int. Conf. on Distributed Comuting Systems [3] Huang Y and Ravishankar C V 1996 URPC: A universal RPC toolkit Comut. J. 39 [4] Felten E 1992 The case for alication-secific communication rotocols Proc. Intel Suercomuter Systems Division Technology Focus Conf [5] Ananda A L, Tay B H and Koh E K 1992 A survey of asynchronous remote rocedure calls Oerating Syst. Rev [6] Vinoski S 1997 CORBA: Integrating diverse alications within distributed heterogeneous environments IEEE Commun. Mag. 14 [7] Bershad B N, Anderson T E, Lazwoska E D and Levy H M 1990 Lightweight remote rocedure call ACM Trans. Comut. Syst [8] Rong Chang and Ravishankar C V 1994 A service acquisition mechanism for server-based heterogeneous systems IEEE Trans. Parallel Distrib. Syst. 5 [9] Zhonghua Yang and Vogel A 1996 achieving interoerability between CORBA and DCE alications using bridges Proc. IFIP/IEEE Int. Conf. on Distributed Platforms (London: Chaman and Hall) [10] Steinder M, Usok A and Zieliński K 1996 A framework for inter-orb request level bridge construction Proc. IFIP/IEEE Int. Conf. on Distributed Platforms (London: Chaman and Hall) [11] Rosenberry W and Teague J 1993 Distributing Alications Across DCE and Windows NT (Sebastaol, CA: O Reilly and Associates) [12] Bershad B N, Ching D T, Lazowska E D, Sanislo J and Schwartz M 1987 A remote rocedure call facility for interconnecting heterogeneous comuter systems IEEE Trans. Software Engng [13] Auerbach J 1990 TACT: A rotocol conversion toolkit IEEE J. Selected Areas Commun [14] Sun Microsystems 1991 Oen Network Comuting RPC Programming [15] Stamos J W and Gifford D E 1988 Imlementing remote evaluation IEEE Trans. Software Engng [16] Falcone J R 1987 A rogrammable interface language for heterogeneous distributed systems ACM Trans. Comut. Syst [17] Purtilo J M 1990 The Polylith software bus Technical Reort TR-2469 Comuter Science and Institute for Advanced Comuter Studies, University of Maryland [18] Gibbons P B 1987 A stub generator for multilanguage RPC in heterogeneous environments IEEE Trans. Software Engng [19] Needham R M and Schroeder M D 1978 Using encrytion for authentication large networks of comuters Commun. ACM [20] Birrel A D 1985 Secure communication using remote rocedure call ACM Trans. Comut. Syst [21] Steiner J G, Neuman B C and Schiller J I 1988 Kerberos An authentication service for oen network systems Proc USENIX Winter Conf [22] Lamson B, Abadi M, Burrows M and Wobber E 1991 Authentication in distributed systems: theory and ractice ACM Oerating Syst. Rev [23] Gram F T and Morris R H 1984 Unix oerating system security Technical Reort 8 AT&T Bell Laboratories Technical Journal [24] Sollins K R 1988 Cascaded authentication IEEE Sym. on Security and Privacy [25] Rivest R 1990 The MD4 message digest algorithm Technical Reort TM 434 Laboratory of Comuter Science MIT [26] Burrows M and Abadi M 1990 A logic of authentication ACM Trans. Comut. Syst