Mobile Computing, Security and Delegation Roy Campbelly
Daniel Sturmany
Theron Tockz
[email protected]
[email protected]
[email protected]
October 28, 1994 Abstract
Portable computers may operate in a variety of environments with di erent security and encryption schemes. Further, disconnection should not interfere with secure application communication. We present the design of a customizable framework for secure mobile communications. This framework incorporates authenticated message passing without the restructuring of applications: through the use of inheritance, communication classes preserve interfaces while adding security. A subframework supports secure communication. Each service determines the security measures it will use and the system ensures clients communicate using the correct protocol. To support disconnection, we present a subframework that permits the delegation of authority. We describe our implementation of this framework for Choices , an object-oriented operating system.
Introduction The long term success of networked mobile computing depends not only on innovative hardware and software, but also on developing \open" security architectures that ensure communication privacy, authentication, and delegation. In this paper, we argue that to make networked mobile computers e ective as a personal device in a complex society, the systems must employ security provisions to ensure reliability and privacy. For example, if nancial transactions are to be conducted by mobile communicating systems, secure authentication and privacy measures must be employed. We present results from our research on how such provisions can be built. The security provisions used in mobile computers must operate in a dynamic communication environment. While ideally one might propose to build a pervasive radio communication system through which all networked computers communicate, it is unlikely that such a system could be built in the near future to satisfy all communication requirements. Instead, we expect a networked mobile computer to operate using a variety of di erent communication technologies, for example using infra-red, cellular radio, or docking stations. Furthermore, the subnetworks created by these technologies may be physically distributed and may not geographically overlap. Thus, a computer may have to switch communications between di erent kinds of subnetwork and it may become disconnected as it moves. However, many applications expect a communication session that lasts to the completion of the application. Secure distributed computations initiated by a mobile computer may need authentication of the client to complete. For example, the purchase of stock shares should require an authorized digital signature at the time the transaction commits. Since the client ordering the transaction may be disconnected at commit time, the client must be able to delegate authority to a third party, in this case, a broker. Since the computer may be connected to a variety of di erent networks and each network may have its own unique provisions supporting security, clients must be able to adapt and use multiple security provisions. For example, while buying retail articles within a store, the computer should conduct transactions using the store's security provisions. However, when querying the results of an exam in a school, the computer may encounter very di erent security provisions. This research was partially funded by a grant from the National Security Agency. y Department of Computer Science, University of Illinois, 1304 W. Spring eld Ave, Urbana, z Sun Microsystems Inc, 2550 Garcia Ave, Mtn View, CA 94043
1
IL 61801
Applications running on the computer will be expected to access network services using any of the security provisions provided on the many networks to which the computer may be attached. Alternatively, a networked mobile computer user may insist on using a particular set of communication provisions that must be \tunneled" over the available communication networks. The applications should accommodate changes in security schemes imposed by changes in the network environment without requiring user intervention. Above all, if networked mobile computers are to become \ubiquitous" then the security provisions supported for communications should be easy for users to understand and transparent to the applications.
Delegation When a client disconnects from the network, it may wish certain functions to continue on fully-connected server hosts. Even when the mobile host is connected, it is more economical to use the more powerful server hosts for compute- or communication-intensive processing. Providing a server with a client's credentials or password allows it to act on the client's behalf, but requires unacceptable levels of trust in the servers not to abuse the user's priviledges, or worse, nancial assets. Thus, the ability to delegate limited authority is essential to realize security in a ubiquitous computing environment. A delegation is a temporary permit issued by the user or delegator and given to the server or delegate that authorizes the server to act on the user's behalf. The delegate uses the delegation \permit" to convince others it should be granted access as the user. However, the delegator may encode restrictions as part of the delegation that limit the delegate's powers. When a third party receives the delegation and a request from the delegate, it veri es that the request adheres to the delegator's restrictions. The combination of delegations and restrictions provides a powerful mechanism to transfer user's \identities" while maintaining strict control of user's priviledges. Delegation is a well understood problem [7, 8, 3] but there are special considerations for mobile systems that these existing approachs do not address. The requirements for a general delegation scheme include: Revocation: the delegator must have the ability to cancel delegations it has issued. Provided that a denial-of-service attack can be prevented, once a revocation is issued it should immediately disable all the corresponding delegations. Cascading: the delegate must have the option to create delegations on the delegator's behalf. These sub-delegations or cascaded delegations allow the delegate to invoke another service that in turn needs authority as the user. Since the service normally would not have access, it must be granted a temporary sub-delegation. Cascading delegations allow a transaction to proceed without the delegator having to authorize every possible delegate. Restriction: The delegator must be able to limit the rights granted by any delegation or cascaded sub-delegation. The rights of any sub-delegation are are the conjunction of all restrictions placed on all of the cascaded delegations. Some restrictions such as validity period are interpreted by the system, others are semantically valid only to the service being delegated. Delegation for mobile computers has the following additional requirements: Disconnected Delegates: Since a client may disconnect after issuing a delegation, delegations must succeed even if the delegator is currently not attached. Low Resource Usage: Typically, the processing and memory capacities of mobile hosts will be limited. It is crucial that bandwidth and host resource usage be minimized. Frequent Creation & Revocation: Delegations will be issued and revoked frequently as mobile hosts detach and reattach to the system. The delegation protocol must eciently handle the creation and revocation of delegations. Interoperability: Delegation should be as independent of the underlying protocols and system software as possible to promote interoperability. 2
Current delegation protocols fail to satisfy the requirements for mobile systems. Revocation is commonly handled by using fairly short lifetimes for delegations and \hot listing" revoked delegations that have not yet expired. In Kerberos [8] with its centralized authentication service, managing the many revoked delegations for a large system may be problematic. A failing of delegation protocols based on certi cates, such as the Distributed System Security Architecture [3] and Passports [7], is the very high computational and bandwidth requirements. This is due to the public-key nature of these systems. One nal problem with most delegation protocols is their dependence on a particular authentication protocol, limiting them to systems that support that style of authentication.
Dynamic Replacement To ensure security in a ubiquitous computing environment, either a single standard of secure communication must be accepted or clients must be able to adapt new protocols as they interact in di erent sub-networks. The latter is infeasible as the entire computing community would have to agree on one protocol: such a protocol would have very general and support all possible functionality. Besides being complex, such generality would be inecient. Furthermore, augmenting the protocol to accommodate additional features would be dicult: distribution of the new version would have to be made world-wide. Instead, our solution involves the use of a general object-oriented framework[1] for authentication and delegation. A framework is a collection of abstract classes that de nes the design of the system through informal speci cation of class interactions. Each abstract class has one or more concrete implementations that provide speci c performance or functionality. The system can be con gured or optimized by selecting appropriate combinations of concrete implementations. New functionality can be introduced into the system by extending the framework. An extended framework must preserve the interfaces and interactions of the old framework, but is free to add new interactions or interfaces either as new abstract classes or as subclasses of existing classes[1]. Thus, much as class inheritance extends class functionality, framework inheritance extends system functionality. We specify the components required for secure communication as a set of abstract classes. Speci cally, we have classes for the application interface and a class which adds authentication information to a message. These abstract classes may be specialized by a concrete extension of the framework to support a particular protocol. The rules for extending frameworks preserve interfaces, thereby allowing applications to work with di erent protocols. When subclassing existing classes to extend a framework, each subclass will include the entire interface of its superclass and may be used in place of the superclass. Through the use of dynamic code replacement, a client in a ubiquitous environment may utilize several authentication or delegation protocols, depending on the services that they must access. When a client needs a protocol, it may dynamically load the new authentication framework. Since interfaces are preserved, loading the new protocol will not adversely a ect the application. Thus, protocols may be varied based on purpose, performance, and compatibility. Besides loading a protocol from a stored library, new protocols may be negotiated as needed provided the negotiation is secure. Secure negotiation may be provided either through a very simple, universally known, protocol or through a trusted third party. A hybrid approach is also possible where trusted \translators" which understand a number of protocols may be accessed by clients. Thus, the clients would not have to store all possible protocols, but may use protocols they do know to acquire new protocols as needed.
Delegation for Mobile Systems The delegation protocol we have developed for the Choices secure communication framework meets the requirements for mobile computers. We depart from the traditional \permit" based approach to delegation where a delegate must present proof it owns the permit. Instead, the delegator issues instructions to a service indicating which delegates are authorized to act on behalf of the delegator. The delegation protocol consists of a sequence of authenticated messages exchanged between the delegator and the service being delegated. The service is responsible for maintaining all delegation information and uses a scheme similar to an access control list (ACL) to manage it. The delegator speci es the principals 3
authorized to act on the delegator's behalf and the service records this information in the list. The list entries are hierarchically organized, permitting delegates to cascade the delegation. Revoking a delegation requires only that the service remove the list entry, which also removes all cascaded delegations. To use a delegation the delegate sends a message to the service, authenticated as usual by the delegate, indicating it is acting on behalf of the delegator. The receiving side rst veri es the delegate's identity, then checks the hierarchical list to verify the delegate has been authorized to act on the delegator's behalf. If present in the list, the identity of the delegator is substituted for the identity of the delegate. Arbitrary strings representing rights or constraints can be associated with each list entry. For each message received from a delegate, the appropriate concatenation of rights or constraints from the cascaded delegation is available to the service. This permits the service to perform its own form of access control on each message. This delegation protocol has several advantages when compared to Kerberos or DSSA. First, there is no centralized authentication server that might be a bottleneck as in Kerberos. Second, there is no costly key generation step or large certi cates as in DSSA. Third, there is no communication necessary between the delegator and the delegate, permitting the delegate to be disconnected at the time of the delegation. Fourth, no particular authentication scheme is required for this protocol. This protocol requires only that messages are authenticated using whatever authentication primitives are available, enhancing interoperability with a variety of di erent systems. Fifth, since delegation information is distributed, the system is inherently load balanced.
Implementation Details Delegation was incorporated into Choices as an extension of the framework for secure communication. By subclassing existing communication classes, the extension preserves existing communicationinterfaces. Applications may choose to use delegation by simply changing the type declaration of their communication objects. Choices applications access the message passing communication framework through abstract classes. These abstract classes present interfaces for message fragmentation and reassembly, ow control, reliability, and message transport [4]. A message container is a receptacle for retrieving messages, and a message port is a send-only channel to a speci c container. Multiple ports may refer to a single container. Applications obtain ports from a Distributed Name Server (DNS). Whenever a container is created, a port that refers to the container is created and bound with a name in the DNS. Other applications throughout the distributed system use the name to obtain a local copy of the port. The DNS contains type and attribute information so that ports are constructed with concrete classes matching the containers' classes. For example, if a container is created with \exactly once" relability semantics, the DNS will ensure that the corresponding port is constructed using the \exactly once" concrete reliability class. Applications obtain message containers from a Container Creator server. This object accepts a user and system-administrator speci cation of the desired communication semantics and returns a suitable container. Subclasses of the abstract port and container specialize the message passing interface for authentication. An abstract class authentication protocol captures the behavior of di erent authentication protocols. Choices includes protocol objects implementing RSA public-key authentication [6], Kerberos [8, 5], and Fiat-Shamir zero-knowledge proofs [2] and these are implemented as specializations of the basic authentication classes. Once an appropriate authentication protocol is selected, the system guarantees, through the DNS and ContainerCreator attributes and typing, that the correct authentication subclasses and provisions are applied to messages sent to ports and retrieved from containers. The container creator builds an appropriate container for a given authentication protocol and the DNS registers an appropriate port for the container. Once created, the use of the speci c authentication instances for communication by the application is identical to using the communication framework without authentication. The system permits multiple implementations and delayed selection of a particular protocol until run-time. The authentication framework is extended for communication secrecy. Two new subclasses secure port and secure container supply the specialized application interface and a subclass of authentication protocol provides secure protocol s. The secure port and container subclasses interact with an instance of a secure protocol, which performs message encryption. This new subframework o ers the stronger guarantee that messages are readable only by the creator of a secure container. Since the Choices authentication protocols exchange a session key, minimalwork is necessary to implement secrecy. However, note that because secrecy is an extension it must preserve the authentication guarantees 4
provided by the parent framework. Thus, encryption using a Die-Helman key exchange would require a modi cation of the current Choices implementation. The framework for delegation is an extension to the framework for secure communication. Two abstract classes, port delegation and container delegation , provide the interface for delegation operations. The interface for a port delegation includes methods for creating new delegations and restricting delegate's rights, while the interface for a container delegation includes methods for verifying delegate's identities and rights. Multiple inheritance combines authentication and delegation into a delegated authenticated container and delegated authenticated port . The delegated authenticated container provides message retrieval, authentication and delegation: it inherits from authenticated container, which supports message authentication, and container delegation, which supplies the functionality for manipulating delegations. Multiple inheritance keeps the two orthogonal interfaces for authentication and delegation separate. A delegation protocol subclass of authentication protocol extends the protocol interface to support delegation ports and containers. The impact of our delegation framework on existing applications is minimal: a delegate communicates through a channel provided by the delegator and the system ensures messages from the channel look like messages from the delegator. Services that are delegated must be aware of rights restrictions placed on delegations. Obtaining the rights is simple; determining if the restrictions are met is application speci c. The delegation protocol is completely independent of the authentication protocol, interacting with it only through a speci c interface. This permits the delegation protocol to function regardless of the particular implementation used to communicate with the delegates or services. An authentication protocol may be chosen to suit the environment of the mobile host. For example, Kerberos has high startup but low permessage costs, while a zero-knowledge proof [2] has no startup but high per-message costs. The proper protocol can be chosen for the frequency of messages exchanged without a ecting the delegation protocol. Most of the restrictions placed on delegations are interpreted solely by the service being delegated. Since each service has di erent semantics for permissions, there is little for the system to do. Some restrictions are interpreted by the system and enforced for all delegations. One restriction is a validity period that speci es when a delegate is authorized to use the delegation. If a delegate attempts to use a delegation, the delegation and all parent delegations in a cascaded delegation are veri ed to ensure their validity. If any are invalid, the delegate's message is rejected. Another restriction is a prohibition from further cascading the delegation, or permitting delegation only to certain other services or clients. This permits the delegator to maintain control over the di usion of the delegation.
Conclusion To exploit fully the advantages of networked mobile computers, users must be able to trust that their transactions are secure. The ability to sign digitally documents or delegate this authority to another is necessary to support the wide range of applications proposed for the ubiquitous environment. However, providing a secure mobile computing environment presents challenges. Speci cally, mobile clients may need to adapt new security protocols as they change location. These new protocols, however, must not require modi cation of applications. We have shown how a well de ned framework for secure communication may be extended to support multiple protocols without modi cation of the application interface. Thus, code for a new protocol may be loaded dynamically and used with existing applications. Furthermore, in a mobile computing environment, clients will frequently connect and disconnect from sub-networks. Thus, delegation of authority is necessary in any such environment supporting secure communication. Many existing delegation schemes, such as Kerberos, the Distributed System Security Architecture, or Passports, are unsuitable for use under the conditions of a mobile computing environment. Our proposed delegation scheme requires no additional key generation, supports ecient creation and revocation of delegations, and allows the delegator to disconnect from the network after issuing a delegation.
References [1] L. Peter Deutsch. Design Reuse and Frameworks in the Smalltalk-80 Programming System. In Ted J. 5
[2] [3] [4] [5] [6] [7] [8]
Biggersta and Alan J. Perlis, editors, Software Reusability, volume II, pages 55{71. ACM Press, 1989. Amos Fiat and Adi Shamir. How to Prove Yourself: Practical Solutions to Identi cation and Signature Problems. In G. Goos and J. Hartmanis, editors, Lecture Notes in Computer Science 263, pages 186{194. Springer-Verlag, 1986. Morrie Gasser and Ellen McDermott. An architecture for practical delegation in a distributed system. In Proceedings of the Symposium on Security and Privacy, pages 20{30. IEEE, 1990. Nayeem Islam and Roy H. Campbell. Design considerations for shared memory multiprocessor message systems. In IEEE Transactions on Parallel and Distributed Systems, pages 702{712, November 1992. J. Kohl and C. Neuman. RFC 1510: The Kerberos Network Authentication Service (V5), September 1993. RSA Laboratories. RSAREF: A Cryptographic Toolkit for Privacy-Enhanced Mail: Library Reference Manual. Distributed with RSAREF source code, March 1992. Karen R. Sollins. Cascaded authentication. In Proceedings of the Symposium on Security and Privacy, pages 156{163. IEEE, 1988. Jennifer G. Steiner, Cli ord Neuman, and Je rey I. Schiller. Kerberos: An Authentication Service for Open Network Systems. In Proceedings of the Winter USENIX Conference, pages 191{202, February 1988.
6
