A Security Architecture for Application Session Handoff - CiteSeerX

22 downloads 50447 Views 124KB Size Report
mented an application enabled with this security architecture and showed that it .... application session state is seamlessly moved from the desktop to the PDA in ...
A Security Architecture for Application Session Handoff Erik Skow, Jiejun Kong, Thomas Phan, Fred Cheng, Richard Guy, Rajive Bagrodia, Mario Gerla, and Songwu Lu Department of Computer Science The University of California at Los Angeles Los Angeles, CA 90095 {eskow,jkong,phantom,fred,rguy,rajive,gerla,slu}@cs.ucla.edu http://pcl.cs.ucla.edu/projects/imash/ Abstract— Ubiquitous computing across a variety of wired and wireless connections still lacks an effective security architecture. In our research work, we address the specific issue of designing and building a security architecture for Application Session Handoff, a functionality which we envision will be a key component enabling ubiquitous computing. Our architecture incorporates a number of proven approaches into the new context of ubiquitous computing. We employ the Bell-LaPadula and capability models to realise access control and adopt Public Key Infrastructure (PKI)-based approaches to provide efficient and authenticated end-to-end security. To demonstrate the effectiveness of our design, we implemented an application enabled with this security architecture and showed that it incurred low latency.

I. I NTRODUCTION The aim of ubiquitous computing is to provide mobile users “anytime, anywhere, any platform” access to computing services interconnected via a wide-area network such as the Internet. While much research has been performed to provide the infrastructure and application support for this goal, the issue of security has in general been difficult to address. Problems arise due to the highly heterogeneous nature of client devices intended to participate in the ubiquitous computing realm, especially mobile, wirelessly-connected platforms such as laptops and personal digital assistants. Such security issues have arisen in our Interactive Mobile Application Support for Heterogeneous Clients 1 (iMASH) research project [2]. iMASH is a multi-discipline collaborative effort between the UCLA Medical School and the Computer Science Department geared towards the design, implementation, and deployment of a computing infrastructure for the new UCLA hospital currently being built. In this environment physicians and staff workers will have wired and wireless ubiquitous access to medical record databases to hopefully enable more effective patient treatment through high information accessibility. To enable this vision, we have developed a wide array of application- and system-level support to provide users with a functionality called Application Session Handoff (ASH). In recent work we have demonstrated the importance of ASH to mobile computing: this novel functionality allows applications to have a transparently migrating session of both discrete and streaming data seamlessly follow the user around a number of heterogeneous clients. To facilitate this behaviour, a Middleware layer acts as a data conduit and handoff mediator to enable scalability and presentation transcoding. This work is funded by National Science Foundation award ANI-9986679.

However, despite successful implementation of a number of new capabilities, the issue for security has been difficult to resolve due to device heterogeneity constraints and lack of support in the iMASH infrastructure. This problem is all the more accentuated when one considers the importance of security in the legal and social context of medical records. Domain-critical functionality to address such high-priority issues include the following: (1) authentication and authorization of the users accessing shared system resources; (2) data privacy, data integrity, and data non-repudiation in network communications; and (3) definition of security semantics for our seamless session handoff functionality to support ubiquitous computing. In this paper we address these issues and contribute to mobile computing research by providing a number of application-layer protocols to support security for our ASH functionality. By providing efficient and effective security enforcement for ASH, we further strengthen its robustness. We believe ASH will be a key component leading to the convergence of heterogeneous mobile computing clients, and by augmenting its utility, we additionally provide a security framework that we envision can be generalisable to support future client-server applications for mobile computing. The specific challenges presented and addressed in this paper are to enforce effective access control of system resources and to provide end-to-end security for this Application Session Handoff without severely degrading the existing system’s performance. A security subsystem must be efficient enough to perform near-uninterrupted session handoff of real-time streaming data. To that end, we have implemented a security architecture that makes ASH resilient to a wide range of attacks, including impersonation, unauthorised access, passive eavesdropping, and malicious message alteration. Throughout our implementation we have utilised a number of known approaches to realise our design. First, to enforce access control, we have applied the well-known and proven Bell-LaPadula access control model to our application infrastructure. Additionally, we have augmented this model by using capabilities, an abstract representation of objects and the associated authorised operations on them, used in modern operating systems. Second, for network security, we employ a Public Key Infrastructure (PKI)-based scheme to enforce end-to-end security at the network transport layer. We use a push-pull model to realise the scheme. To demonstrate the effectiveness of our design, we have implemented a prototype application enabled with the security mechanism. With this implementation we shall show that our security architecture and protocols provide effective establishment and maintenance of secure channels between the clients,

Fig. 1. A broad overview of the iMASH architecture.

Middleware Servers, and Application Server. Furthermore, through experimentation we shall show that our system does not unreasonably degrade the performance of our currently existing iMASH architecture. Finally, we explain how our security architecture can be generalised for future work within iMASH. The remainder of this paper is organised in the following manner: In II we present the iMASH architecture and discuss related research work. We present our security framework, including the access control and authorisation models, in III. To demonstrate our system, we present an implementation and its evaluation in IV. We conclude the paper in V with future work. II. I MASH BACKGROUND

AND

R ELATED W ORK

The iMASH architecture is depicted in Figure 1. At the top of the figure is an Application Server (AS) that provides services and data to a number of heterogeneous clients which may include wired desktop PCs and wireless mobile devices. We note that the AS is typically poorly suited to support such a myriad of clients. To improve the service availability of the AS, we introduce a Middleware layer between the AS and the clients. The idea of a middleware tier is not new, but in the context of iMASH, the Middleware Servers provide the system with scalability and new functionality, such as Application Session Handoff (ASH). The ASH capability allows users to experience a convergence of all their owned computing platforms. For example, suppose a user is working with an iMASH-enabled application on a wired desktop and then decides to move to a wirelessly connected PDA. By utilising the ASH functionality, the user’s application session state is seamlessly moved from the desktop to the PDA in a timely manner upon his request. This session state can include both discrete and streaming data across a variety of network interfaces and bandwidths. We note that the state consists of only the data structures and variables needed for an application to define a session and is never the entire process space, immediately differentiating this approach from that of process migration. The iMASH Middleware handles data transfer from the desktop on behalf of the user and can automatically adapt the content of moved data to fit the device

characteristics of the PDA (such as transcoding to fit the PDA’s CPU, bandwidth, and display). To the end user, the program appears as a continuously-living application across all platforms. In [14], [15] we demonstrated the utility of this functionality by enabling the Mozilla web browser and the Teaching File, a real-world medical multimedia program, to utilise ASH within the iMASH environment. In [16] we answered the question of scalability by designing a fully distributed Middleware Service layer composed of multiple autonomous Middleware Servers aggregated together. Other research efforts have explored the use of software architectures to support mobile computing behaviour, but none have addressed the issue of session handoff between heterogeneous clients. In [10] the authors presented the Rover Toolkit’s distributed object model to support programming for mobile devices. Active Networks [22] and ANTS [25] suggest the use of programmable network nodes that can be injected with capsules of code and data. The Mobiware Toolkit [1] provides facilities for delivering and and adapting data to match network conditions. In the BARWAN project [5] a network of workstations was used as a middleware tier to provide transcoding for multiple WWW clients. Finally, Application Data Services [9] allows users to transfer data from non-traditional network appliances, such as digital cameras, through a network infrastructure. Security in the context of middleware-based networking is relatively new. Charon [8] uses Kerberos [20] to provide authentication service to the network, and addresses device heterogeneity by exploiting the computation power available in the middleware. However, Kerberos is essentially an approach based on a centralised key distribution center (KDC). Every authentication request must be processed by the KDC (i.e., AS/TGS), thus incurs large workload to the KDC and poses a single point of system failure as well as DoS attack. We seek to authenticate mobile clients by the distributed middleware infrastructure rather than a centralised KDC, thus avoid single point of failure at running time.

III. S ECURITY A RCHITECTURE The iMASH security architecture is designed to provide ASH with the following features: (1) appropriate authentication of users and devices; (2) well-defined access control to system resources; and (3) secure communication between two arbitrary network entities. As a result, common security concerns, such as authentication, authorisation, message privacy, message integrity, non-repudiation, are addressed to make the system resilient to security attacks.

A. Design Rationales 1) Authentication and end-to-end security: To authenticate iMASH users and devices, we employ a certification-based approach leveraging the standard Public Key Infrastructure (PKI), which has been the foundation of several recent network security protocols such as IPsec IKE, TLS, and S-MIME. By setting

up an iMASH certification authority (CA) and issuing certificates to valid users and devices, any two communicating entities may establish a temporary trust relationship via the unforgeable and globally verifiable certificates carried by each of the entities. Once the communicating entities are authenticated, we seek to ensure message privacy, message integrity, and nonrepudiation at or above the transport layer. This design rationale is especially effective for wireless clients which are vulnerable to passive eavesdropping and active alteration due to their broadcast communication channels. In our design, critical data is signed and encrypted at or above the transport layer before reaching the network. Hence, the data security of a network entity can only be broken at its standing site, and any break-ins and compromises occurring en route at the lower layers do not compromise its data security. Recent cryptanalysis [4], [21] has found evident weakness and loopholes in certain lower-layer network security protocols, such as the widely deployed 802.11 WEP. However, similar cryptanalysis [24] approves the transport layer security protocol family SSL/TLS/WTLS [19], [23], [26]. We have employed WTLS in the iMASH system to accomodate heterogeneous wired and wireless clients. Security loopholes in the lower layers do not compromise the end-to-end data security provided in the iMASH system. 2) Authorisation: Authenticated users are authorised to access the system resources. Two well-defined and proven concepts in system security research, namely the access control model and capability, are employed and extended in the context of ubiquitous computing to enforce system authorisation. Extended Bell-LaPadula (BLP) Access Control Model The BLP model [3] is one of the best-known and well-proven access control models for information systems. It defines the security system as a state machine. Each state  is a triple  

, where is a constant set of subjects, is a con stant set of objects, and is an access matrix. The access rights are taken from a finite set of allowed operations. In the BLP model, consists only of read and write. The BLP model is a Mandatory Access Control (MAC) model which restricts how subjects can pass access rights to other subjects. Subjects and objects are classified into a fixed lattice of security levels. As was shown in [3], it is guaranteed that information from a higher level is not exposed to the lower levels. Additionally, the simple rules in BLP model can be efficiently implemented with low cost. In iMASH, we offer a natural extension of BLP model by (i) defining four security levels: legal secret, secret, restricted,  and public; (ii) inserting network entities into subject set and object set ; (iii) inserting network communication operations send and receive into the access right set ; (iv) allowing highlevel subjects to receive/read data from low-level objects, allowing low-level subjects to send/write data to high-level objects; and (v) prohibiting other operations. Various access control matrices are stored in application servers and middleware servers to regulate ASH. As the result, it is guaranteed by the BLP model that high level information in our system would not be exposed to low level users and devices.

Capability We further augment the extended BLP model by another wellproven concept, the capability. Suppose all operations concerned have already been approved by the access control model; in this case a network entity can choose to handoff a session to a specific set of network entities by securely delivering its session capability to them. A capability [6], [7] is formally defined as an unforgeable pair made up of (i) a unique object identifier and (ii) a set of authorised operations as the interface associated with the object. Security in a capability-based model is enforced by three properties: (i) capabilities are unforgeable and tamper proof; (ii) system entities are able to obtain capabilities only by using authorised interfaces; and (iii) capabilities are only given to system entities that are authorised to hold them. Three well-known techniques, namely tagging, challenge-response, and segregation, have been widely used in modern operating systems to realise a capability. However, in a PKI-based security architecture, these three techniques cannot be directly used for ASH. We design and implement a practical mechanism to realise a capability by the well-defined [24] transport layer security protocols SSL/TLS/WTLS [19], [23], [26], where an initial session authentication handshake establishes a master secret for the session. This master secret is efficiently generated by the PRF function from three source data: (i) 128-bit random number generated by the server and the first 32-bit is current time on the server; (ii) 128-bit random number generated by the client and the first 32-bit is current time on the client; and (iii) a 160bit random pre-master-secret exchanged between the two communicating parties via certification. Based on the following three observations, we can conclude that the master secret is qualified to be the capability of the session: (i) The PRF function is basically a clone of the standard SHA1 or MD5 message digest function, except with the capacity of generating outputs with arbitrary length. (ii) The combination of current client time, current server time, and the random pre-master-secret is unique for all live sessions. Thus by the computational property of message digest functions, the output of the PRF function is computationally unique. (iii) The master secret is unforgeable and tamper proof, as claimed by the well-defined SSL/TLS/WTLS design. In our design, communication is protected by data encryption. In order to decrypt ASH messages, the anchor session must hold the corresponding session capability (i.e., the master secret), otherwise ASH is not possible. The design is efficient in computation and communication as it reuses the system resources without incurring extra overheads. B. Protocol Details 1) Authentication: Both the device and the user need to be authenticated before using iMASH-enabled system resources. Device authentication is done through certificates, and user authentication through certificate-derived user/password pairs. Device authentication, shown in Figure 2, begins when an iMASH-enabled device is activated. The iMASH client layer, ICL, starts and remains resident to handle all iMASH related

4

DCC

DCC

6

8

DCC

SCC 7

9

C_1

Fig. 2. Device authentication protocol: 1. WTLS handshake 2. NewDeviceChannel(DCC) 3. AckDeviceChannel

S_1

Fig. 3. User authentication per session: 4. Login 5. AckLogin 6. NewSessionChannel(SCC) 7. AckSessionChannel 8. NewDataChannel(SDC) 9. AckDataChannel

communication. The ICL contacts the MWS, using a WTLS class 3 authentication handshake to establish a secure device control channel (DCC). All communication is then encrypted with the computationally-unbreakable cipher scheme established by the WTLS handshake. If the device is authenticated and is approved by the access control matrices, the MWS registers the device in a local list. Once a device has created a DCC, it is considered part of the iMASH network and may participate in the following iMASH transactions: Users may (1) start sessions on the device, (2) pull a remote session to the device via ASH, or (3) push a session to the device via ASH after roaming to a remote place. Figure 3 depicts how users authenticate a new session to MWS. A secure session control channel (SCC) is established per session. The master secret used in SCC is obtained by applying the WTLS HMAC function to the master secret of the DCC. Though the DCC is shared by all sessions on the device, the one-way property of HMAC function prevents the sessions from knowing the secret of the DCC, thus ensures DCC’s privacy. With the SCC in place, a secure session data channel (SDC) is established per network connection to an Application Server. The ICL creates different session data channels (SDCs) from the same SCC. The procedure is again employing the one-way HMAC function to create different SDCs from the same SCC. After sending a start-full-session command, the user begins to use the iMASH services by spawning iMASH-enabled applications on his device. These applications are part of the session and will migrate when an ASH occurs. 2) ASH: The ASH is realised by two modes: ASH-push or ASH-pull. A push is used to move an ongoing local session to another device, whereas a pull is used to move a remote ongoing session to the local device. Because of spatial and other constraints, the two devices concerned may not be able to establish a directly-connected secure channel, or even may not have a means to directly communicate with each other. As both of them can communicate with the iMASH middleware, our architecture allows an ongoing session to be securely handoffed between them. ASH push   As depicted in Figures 4 and 5, session on device starts an ASH-push with (1) its ICL sending RequestPushableDevices(user) command to the MWS on behalf of the user; (2) After access control evaluation, the MWS responds with the list of qualified devices PushableDeviceList(deviceIDs); (3)

1 SCC 6

SDC 5

3 C_1

MWS 5

2

1

MWS

MWS

MWS

C_1

2

DCC

3

DCC 8

DCC SCC 4

SCC

7

C_2

S_1

Fig. 4. ASH-push: 1. RequestPushableDevices 2. PushableDeviceList 3. PushTo 4. PushRequest 5. NewSessionChannel(SCC) 6. PushAck 7. AckSessionChannel

C_1 S_1

10

9 C_2 S_1

Fig. 5. ASH-push: 8. HandoffToMe 9. SessionData 10. Cleanup

The user then  notifies the MWS about the desired destination PushTo( ,clientSession). The ICL also sends the current client session to the MWS. The client session contains the session capability and all the application state to bootstrap the iMASH application on the destination host, making ASH    possible. (4) The MWS then sends PushRequest( ) to , which may ack or nack according to its access control policy. (5)(6)(7) If the device chooses to ack, it establishes a new SCC with the MWS, and the MWS sends   an AckPush() back to . (8) Upon establishing the SCC, sends a handoffToMe(SessionID) message to the MWS. (9) On receipt of the handoff-to-me message, the MWS transfers the session  data over the SCC, (10) and sends a cleanup message to . The original device then removes the session and the new device reconnects all the active session SDCs. ASH pull As depicted in Figures 6 and 7, an ASH-pull begins   with (1)(2)(3)(4) a user authenticating on a new device up to the point where the SCC is established. This creates an an on the device. (5) The user then sends Rechor session questPullableSessions(user) to the MWS over the newly established SCC. (6) After access control evaluation, the MWS replies with a list of qualified sessions for the user PullableSesssionList(SessionIDs). (7) The user notifies the MWS with  the desired sessionID  handoffToMe( ). (8) The MWS then sends TransferSession( )  over the SCC of the selected session,  which is located at device . (9) The ICL on transfers the client to the MWS which relays them     session and its capability to , which in turn merges into . (10) Cleanup is similar   to the ASH-push: The MWS sends Cleanup() to , and on   reconnects all the active session SDCs. IV. I MPLEMENTATION AND E VALUATION The iMASH architecture is implemented largely in Java on both the client and the Middleware Server. The choice of Java allows the software to be ported with modest difficulty and facilitates the integration of client devices running on heterogeneous hardware/OS combinations into the iMASH environment. The only native libraries required are those for the encryption and WTLS authentication; these were utilised primarily for performance enhancement and were linked to the Java application via the Java Native Interface [11] set of libraries. Although the architecture is written in Java, the architecture is not tied to any Java-specific structures. iMASH allows for the possibility of clients or Middleware servers running iMASH

7000

ASH with encryption ASH without encryption

MWS

MWS 1

3 5

DCC

DCC

9

DCC

7

DCC SCC

SCC

SCC

2 4 6 C_1

8 C_2

C_1

11

10

Delay [milli-second]

6000 5000 4000 3000 2000 1000

C_2 0

S_1

S_1’

S_1

S_1

0

100

200

300

400

500

600

700

800

900 1000

Session data size [kilo-byte]

Fig. 6. ASH-pull: 1. Login 2. AckLogin 3. NewSessionChannel (SCC) 4. AckSessionChannel 5. RequestPullableSessions 6. PullableSessionList

length of secret (bit) 40 128 160

Fig. 7. ASH-pull: 7. HandoffToMe 8. TransferSession 9.10. SessionData 11. Cleanup

Fig. 8. Latency incurred from performing ASH-push with and without encryption from a 800Mhz PIII to a 200 Mhz Pentium Pro.

TABLE I

TABLE II

C OLLISIONS OF WTLS MASTER SECRETS

AVERAGE TIME FOR VARIOUS I MASH OPERATIONS ( MS )

number of master secret collisions (per dataset with the following amount of sessions) 500K 1000K 2000K 3000K 4000K 5000K 1 2 8 11 21 25 0 0 0 0 0 0 0 0 0 0 0 0

code written in other languages for performance or interoperability reasons. The only requirement is that the code follow the iMASH protocol, which has been designed in a languageneutral manner. A. Experiments on capability model To prove the feasibility of our design in III-A.2, we have generated a large number of real session master secrets from our WTLS implementation conforming to the WTLS standard [26]. The generated data are loaded into an Oracle8i database, and SQL queries are implemented and issued to check collisions on session master secrets. Table I shows the results for the cases where there are 0.5, 1, 2, 3, 4, 5 million of master secrets from different sessions. (i) The standard SSL/TLS/WTLS master secret is always 160bit (20-byte) and we did not find any collision on master secret for up to 5 million sessions. (ii) The session signature can also be message digest of the master secret. We check the 128-bit MD5 checksums of the session master secrets and there is no collision for up to 5 million sessions. (iii) To test the arithmetic relation between the number of collisions and the number of sessions, we decrease the master secret length to 40-bit only. The results show that only 1 collision occurs in the half million sessions, and 25 collisions in 5 million sessions 2 . The results demonstrate that the message digest functions and the WTLS PRF function are well-designed. In practice, a 160-bit WTLS master secret, its 160-bit SHA1 checksum, or its 128-bit MD5 checksum can be directly used as the session capability which is employed to regulate ASH among heterogeneous clients. There is no need to design and implement exIn the ideal case ofdesigning message digest and PRF functions, the prob when the function output is  -bit long. The chance ability of collision is of collision decreases exponentially as the output length increases linearly.

Client Platform 200 Mhz 665 Mhz 800 Mhz Pentium Pro PIII PIII DCC handshake time (1024 bit certificate) DCC handshake time (2048 bit certificate User start new session time

347.4

188.27

159.83

537.73

221.18

165.083

27.10

23.55

14.67

tra network protocols to realise capability-based models when transport layer security implementations are available. B. Evaluation of ASH Push/Pull models In order to quantitatively analyse the performance of our system, we performed a number of experiments under varying scenarios. 1) Experiment 1: Device and user authentication times: In this experiment we measure the time required for various machines to perform device authentication and user authentication. The experiment involves measuring the computation overhead over 10 trials for each device. All machines were running Java 1.3.1 with RedHat Linux 7.0 on 100 Mbps Ethernet. A Pentium III 600 Mhz Middleware Server is used for all experiments, with all the clients listed in Table II. In WTLS, RSA is used as the public key cryptosystem and DES-CBC is used as the cipher scheme. Results in Table II show that device authentication can be costly on low end devices; on a 200 Mhz machine, it takes approximately 500 ms. This result is due to the computation overhead caused by RSA decryption in WTLS class 3 authentication. However, once the one-time cost of device authentication is paid at device bootstrapping time, SCCs can be established very quickly for each session; on average the latency was approximately 20 ms, which includes session initialization delay and the processing delay of executing the one-way WTLS HMAC function. 2) Experiment 2 & 3: Latency of ASH-push protocol: In experiment 2, the latency is measured to do a ASH-push from a 800 Mhz machine to a 200 Mhz machine. This experiment is designed to measure the iMASH overhead in performing ASH to a slow machine. This measurement is important because most of the work required for ASH is done at the target side.

The MWS is the same as the previous experiment. A 1-byte session data is transferred with the ASH-push to measure the overhead caused by the protocol. The average ASH-push latency is  over 10 trials, showing that the ASH protocol has not created unreasonable overhead for this particular hardware setup. To further quantify the latency, in experiment 3 we repeat the previous experiment while varying the session data that is transferred during ASH. The data size ranges from 1 byte to 1 megabyte. This experiment is performed with and without the WTLS cipher scheme turned on to show how much overhead is incurred by data encryption during ASH. Results in Figure 8 show reasonable ASH performance degradation for the tested session sizes up to a megabyte.

[1] [2] [3] [4]

[5]

[6] [7]

V. C ONCLUSION AND F UTURE W ORK The heterogeneity of modern mobile computing devices has made general security support in software infrastructures difficult. In this paper we do not suggest a general security scheme but rather focus our efforts on providing security support for Application Session Handoff. We believe the ASH functionality will serve an important role in the future convergence of multiple client devices to fulfill the ultimate goal of ubiquitous computing. ASH already provides important functionality in our iMASH research project, so augmenting its utility with security was a natural progression in our development efforts. Furthermore, by designing and implementing a security architecture for ASH, we lay the groundwork for generalising our security framework past ASH to other client-server aspects of the iMASH environment. Our design goal for the architecture is to provide security supports including appropriate authentication, well-defined access control, and strong end-to-end security for ASH without reducing scalability and hindering the fast handoff needed for discrete and streaming data. In order to answer this challenge, we selectively adopt several well-proven and widely-supported approaches, such as the PKI and the TLS to ensure authenticated end-to-end security, and the Bell-LaPadula model and access capabilities to regulate authenticated users in accessing the system resources. From our experiments, we have established a number of baseline metrics that are very encouraging. For the specific hardware and software testbed we utilised, we showed that clients can authenticate themselves and start new sessions in approximately 20 milliseconds after a one-time device bootstrapping cost. We can perform an Application Session Handoff under 100 ms which is tolerable by our real-time multimedia streaming applications. We anticipate extending our work in the future. We will investigate the use of more heterogeneous platforms and networks beyond the assortment we currently have. With 3G UMTS networks on the horizon, we look to determine how we can take advantage of these high-speed wireless interfaces while still providing security for low-bandwidth connections like cellular data. Additionally, we will research the utilisation of UDP data streams to support streaming data. Finally, we will look into integrating previous work with distributed middleware architectures into our security plans.

[8] [9]

[10]

[11] [12] [13] [14]

[15]

[16]

[17]

[18] [19] [20] [21] [22] [23] [24] [25] [26]

R EFERENCES O. Angin, A. Campbell, M. Kounavis, and R. Liao. “The Mobiware Toolkit: Programmable Support for Adaptive Mobile Networking,” IEEE Personal Communications, August 1998. R. Bagrodia, M. Gerla, S. Lu, R. Meyer, D. Valentino, and L. Zhang. “Supporting Nomadic Healers,” UCLA Technical Report 200021, 2000. D. Bell and L. LaPadula. “Secure Computer System: Unified Exposition and Multics Interpretation,” Mitre Corporation ESD-TR-75-306, 1976. N. Borisov, I. Goldberg, and D. Wagner. “Intercepting Mobile Communications: The Insecurity of 802.11,” In Proceedings of the 7th International Conference on Mobile Computing and Networking, July 2001 in Rome Italy. E. Brewer, R. Katz, E. Amir, H. Balakrishnan, Y. Chawathe, A. Fox, S. Gribble, T. Hodes, G. Nguyen, V. Padmanabhan, M. Stemm, S. Seshan, and T. Henderson. “A Network Architecture for Heterogeneous Mobile Computing,” IEEE Personal Communications, October 1998. J.B. Denis and E. van Horn. “Programming Semantics for Multiprogrammed Computations,” Communications of the ACM, vol. 9, no. 3, pp. 143-145, 1966. R. S. Fabry. “Capability-Based Addressing,” Communications of the ACM, vol. 17, no. 7, pp. 403-412, 1974. A. Fox and S. Gribble. “Security on the Move: Indirect Authentication Using Kerberos,” In Proceedings of the 1996 ACM/IEEE International Conference on Mobile Computing and Networking, 1996. Andrew Huang, B. Ling, J. Barton, and A. Fox. “Making Computers Disappear: Appliance Data Services,” In Proceedings of the 7th ACM/IEEE International Conference on Mobile Computing and Networking, July 2001, in Rome, Italy. A. Joseph, A. deLespinasse, J. Tauber, D. Gifford, and M. Kaashoek. “Rover: A Toolkit for Mobile Information Access,” In Proceedings of the 15th ACM Symposium on Operating Systems Principles (SOSP 95), 1995. S. Liang. The Java Native Interface, Addison Wesley Longman, 1999. D. Milojicic, F. Douglis, F., Y. Paindaveine, R. Wheeler, and S. Zhou. “Process Migration Survey,” ACM Computing Surveys, June 2000. B. Noble, M. Satyanarayanan, D. Narayanan, J. Tilton, J. Flinn, and K. Walker. “Agile Application-Aware Adaptation for Mobility,” In Proceedings of the 16th ACM Symposium on Operating System Principles, 1997. T. Phan, K. Xu, R. Guy, and R. Bagrodia. “Handoff of Application Sessions Across Time and Space,” In Proceedings of the IEEE International Conference on Communications (ICC 2001), Helsinki, Finland, June 2001. pcl.cs.ucla.edu/papers/ T. Phan, R. Guy, J. Gu, and R. Bagrodia. “A New TWIST on Mobile Computing: Two-Way Interactive Session Transfer,” In Proceedings of the IEEE Workshop on Internet Applications (WIAPP 2001), San Jose, CA, July 23-24, 2001. T. Phan, R. Guy, and R. Bagrodia. “A Scalable, Distributed Middleware Service Architecture to Support Mobile Internet Applications,” In Proceedings of the ACM Wireless Mobile Internet Workshop (WMI 2001), Rome, Italy, July 21, 2001. Richard Rashid, Daniel Julin, Douglas Orr, Richard Sanzi, Robert Baron, Alessandro Forin, David Golub, and Michael Jones. “Mach: A System Software Kernel,” In Proceedings of the 34th Computer Society International Conference (COMPCON), 1989. R. Sandhu. “A Lattice Interpretation of the Chinese Wall Policy,” In Proceedings of the 15th NIST-NCSC National Computer Security Conference, 1992. Netscape Communications Corporation “SSL 3.0 Specification.” G. Steiner, B. Neuman, and J. Schiller. “Kerberos: An Authenticated Service for Open Network Systems,” USENIX Winter, January 1988. A. Stubblefield, J. Ioannidis, and A. Rubin. “Using the Fluhrer, Mantin, and Shamir Attack to Break WEP,” AT&T Labs Report TD-4ZCPZZ, www.cs.rice.edu/˜astubble/wep_attack.pdf D. Tennenhouse and D. Wetherall. “Towards an Active Network Architecture,” Computer Communications Review, April 1996. T. Dierks and C. Allen. “The TLS Protocol, version 1.0,” www.ietf.org/rfc/rfc2246.txt D. Wagner and B. Schneier. “Analysis of the SSL 3.0 protocol (revised version),” In Proceedings of the 2nd USENIX Workshop on Electronic Commerce, 1996. D. Wetherall, U. Legedza, and J. Guttag. “Introducing New Internet Services: Why and How,” IEEE Network Magazine, July 1998. “Wireless Transport Layer Security specification,” www1.wapforum.org/tech/documents/ WAP-261-WTLS-20010406-a.pdf