The typical user-level group considered in Enclaves is a distributed group, with members located in different places. The group membership changes dynamically, and the group typically exists for a relatively short time. Because of the group's exclusive membership and the openness of the Internet, the first line of defense in establishing a group and maintaining this exclusiveness is to properly authenticate the group leader and members.
Users wishing to participate in shared activities are initially equipped with seed secrets (such as passwords or public-key certificates) which are registered with the group leader. The process of obtaining these can be facilitated via another layer of indirection of authentication. In fact, to make the toolkit easy to use for a wide range of users, we try hard to minimize the infrastructure needed to run Enclaves. Thus, in a very common mode of group operation, it is often sufficient that users can be authenticated to the group leader via (long-term or one-time) passwords that are prearranged by out-of-band methods.
The design for the protocols to authenticate group members to the group leader, and among themselves, follows established practice, so we do not dwell on these protocols except by giving one example, as shown in Table 1. The notation {x}_K denotes x encrypted with K, and ``,'' denotes concatenation. We use M to denote a group member and L to denote the group leader.
Table 1: A simple authentication protocol
In message 1, the member requests joining the group. The leader checks the validity of the request message, and if satisfied, then checks the secure group policy to see if such a user can be admitted. If yes, it returns message 2, which includes the group key for communication among group members. If no, the leader returns a message ``authentication failed.'' Note that the checking of the group policy is not represented in the simple protocol description of Table 1, nor are the failure semantics. This protocol is implemented with a single RPC.
Synchronized clocks are not required to use Enclaves. If clocks may not be accurate, then random numbers (known as nonces) are used to prove freshness in a different, four-message authentication protocol shown in Table 2. Enclaves provides a random number generator, based on well-known algorithms [12]. In this situation, although three messages is the theoretical minimum for mutual authentication, the four-message protocol is simple to implement using two nested RPCs.
Table 2: A nonce-based authentication protocol
In designing the protocols, we followed the robustness principle [1] and the specific format of fail-stop protocols [10]. Therefore, the protocols are somewhat less efficient than they can be; optimizations are discussed later in this paper. We do not discuss the security of these protocols except by pointing out that, in Enclaves, a user name is an arbitrary string with no spaces, and is usually bound to a secret key (e.g., a password). Once a user initiates or joins a group, his or her name is also bound to a fully qualified host name (such as anchor.enclaves.com) and a particular port number. This implies that a user cannot have more than one instance that is active within the same group.
When a user is admitted to the group, the leader arranges a state transfer so that the new member catches up with existing members. Currently, the group state transferred includes the group membership list and references of all shared resources such as text files.
There can be numerous types of groups, which range from totally open ones, to moderately controlled ones, and to ultra-secret ones [9]. These groups have vastly different admission policies. When a leader initiates a group, it has the option to decide upon the particular admission policy for that group. The most commonly used policy in Enclaves is what we call leader controlled. In such a group, the leader has the authority to invite users to join the group, decides the access-control policy, and is in charge of all group-wide activities. For example, it is the group leader who announces membership changes. To represent the policy, we use a simple access control list containing pairs of user names and their keys. The group leader can make policy changes by modifying this list ``on-the-fly''.
During the course of our development, we found it difficult to present the various group policies with a suitable user interface such that a user can easily visualize the implications of the policy and can conveniently change it while still maintain some coherent access control semantics. A leader-controlled group policy, the default policy, is one of the easiest to implement.
The procedure of admitting a new member is depicted in Figure 3. Note that if nonces are used, then an extra, nested RPC should be added. It would be reasonable to delay the state-transfer process till a later time, e.g., when the user explicitly requests for some state information.
Figure 3: Admitting a new group member
When a member leaves the group, the leader initiates a group-key change protocol so that the departing user can no longer take part in group activities uninvited (using the residue group key). A key change may also be prompted when the group leader suspects a compromise somewhere. Such key updates are totally transparent to the users and in fact should be done periodically.
The group leader can invoke a program (or a protocol) to be run by a group member, and vice versa. Currently, no directly executable code is shipped across the network connecting the group members. Moreover, all such remotely executable programs are predefined, and security checking ensures that only these programs can be invoked. Security checks are also performed on parameters when these programs are invoked.
A directory service, serving at a well-known port on a well-known machine, provides a listing of currently active groups. This service may also restrict information dissemination to certain Internet sites and to users with certain privileges. Such a service is straightforward to implement and we do not discuss further details. Of course, a group site may want to run unadvertised. In our on-going work, this service is integrated into the world-wide-web browser technology, so that the service is located at a well-known URL.
 Need help? Use our Contacts page.
Last changed: 1 May 2002 aw |
|
Conference Index