Abstract

We have implemented and deployed an access control mechanism that uses digitally-signed certificates to define and enforce an access policy for a set of distributed resources that have multiple, independent and geographically dispersed stakeholders. The stakeholders assert their access requirements in use-condition certificates and designate those trusted to attest to the corresponding user attributes. Users are identified by X.509 identity certificates. During a request to use a resource, a policy engine collects all the relevant certificates and decides if the user satisfies all the requirements. This paper describes the model, architecture and implementation of this system. It also includes some preliminary performance measurements and our plans for future development of the system.

Motivation: Distributed Computing Environments

In distributed computing environments such as research collaborations spanning several institutions, there may be independent and geographically dispersed individuals with authority to control access to the resources [18] . We wish to provide an automated system to allow these stakeholders to assert their authority over a resource in a flexible manner, consistent with the scope of their authority. Our immediate motivation is to enable sharing over open networks of valued resources within the scientific community generally, and for distributed collaboratories in the DOE2000 project [8] in particular.

The Department of Energy (DOE) supports a number of collaborative research environments in which people from universities and companies work with DOE national laboratory personnel and resources. The Lab resources consist of large scientific instruments such as electron microscopes or high-energy light sources; supercomputers or other high-end compute servers; and large-scale storage systems. Researchers from any of the groups may contribute software and data to be shared by other members of the group. The owners of software and data want to be able to securely store data or use their software on hardware that is owned by another entity. The owners of hardware resources want to be able to control their uses. These stakeholders may want to share with some, but not all members of the collaboratory. For example, commercial members may want to use common compute hardware, but share their data and results only with other members of their own organization.

Such an environment requires that the stakeholders be able to enforce access policy on their resources even when those resources are physically controlled by a different administrative domain. Each stakeholder must be willing to trust that the resource server will enforce access control, but the stakeholder should be able to flexibly specify access requirements for its resources.

Traditionally, stakeholders have relied on access control lists (ACLs), stored on the resource server, to express access policy. However, such ACLs typically require a central administrator to make all changes, which means both that the administrator must be trusted by all stakeholders and that the administrator is potentially a bottleneck to rapid updating of the policy. Also, ACLs usually require the server domain to maintain accounts and other administrative support for both stakeholders and users. These problems are all exacerbated when some or all stakeholders and users are administratively and geographically remote from the server.

Another problem that arises in distributed research environments is that there may be multiple principals from different administrative domains who need to have input to the access control policy for a single resource. The attempted execution of proprietary code (e.g., a large scientific modeling program) owned by a third party on a remote supercomputer is an example of such a multiply-controlled resource. The owner of the supercomputer may want to restrict the amount of run-time allotted to a user, and the author of the code may want to specify who may run the code. Getting permission to run the code, therefore, requires satisfying two separately administered policy requirements.

Multiple layers of management may wish to impose independent restrictions on the use of a large scientific instrument. For example, top-level administrators may have general restrictions based on nationality or membership in an organization, safety officers may require special training, and the principal investigator may have his own set of requirements for the project which has scheduled time on the instrument.

In these scenarios, the resource (data, instrument, computational or storage capacity) has multiple stakeholders and each stakeholder will impose conditions for access, called use-conditions, on the resource. All of the use-conditions must be met simultaneously in order to satisfy the requirements for access. Further, it is common that the principals in these scientific collaborations are geographically distributed and multi-organizational. Therefore, without reliable, widely deployed, and easily administered access control mechanisms it will not be feasible to administer a secure collaborative environment. The access control mechanism must allow secure, distributed management of policy-based access to resources and provide transparent access for authorized users and strong exclusion of unauthorized users, in an operating environment where stakeholders, users, and system/resource administrators may never meet face to face.

Goal: Policy-based Access Control

We want our access control mechanism to support, in a computer-based working environment, the same sort of distributed authority over resources that is used in non-computer group endeavors. Each stakeholder should be able to make its assertions (as it does now by signing a policy statement) without reference to a mediator, and especially without reference to a centralized system administrator who must act on its behalf. The mechanism must be dynamic and easily used by all concerned - stakeholders and users - while maintaining strong assurances. The solution should scale with the number of stakeholders, resources and users.

Specifically, the access control mechanism should be able to collect all of the relevant assertions (identity, stakeholder use-conditions, and corresponding user attributes) and make an unambiguous access decision requiring an absolute minimum of centrally administered configuration information. Once the policy-based decision is made, the resource server should be able to ensure compliance both on the part of the intended users and unauthorized parties. The mechanism should also be based on, and evolve with, emerging, commercially supplied, public-key certificate infrastructure components.

Approach: Certificate-based Distributed Security

Our approach to policy-based access control in a distributed environment is based on digitally signed documents, or certificates, that convey identity, authorization, and attributes. A digital signature can assert document validity without the physical presence of the signer or physical possession of documents signed in the author's handwriting. The result is that the digitally signed documents that provide the assertions of the stakeholders about a resource, or assertions of trusted authorities about attributes of a user, may be generated, represented, used, and verified independent of time or location.

Users are authenticated by presenting an X.509 identity certificate [17] and proving that they know the associated private key. These certificates are issued by certificate authorities (CA) that verify the connection between a person or system component and possession of a public key / private key pair. Stakeholders create and digitally sign use-condition certificates that define conditions that must be satisfied by a user before being given access to a resource. User attributes are asserted by "authorities" that provide assured information as digitally signed attribute certificates [11] . Both use-condition and attribute certificates may be stored local to the issuer as long as they can be provided by a server when they are needed to determine permissions during an access request.

Components that enable the use of these certificates include reliable mechanisms for generating, distributing, and verifying the digitally signed documents; mechanisms that match use-conditions and attributes to decide if access should be allowed; and access methods that enforce policy for the specific resource based on the access control decision. All of these mechanisms rely on public-key cryptography for digital signatures, a public-key infrastructure for certificate management and a protocol for secure, authenticated communication, such as the Secure Sockets Layer protocol (SSL) ( [25] , [26] ). (For a general introduction to public-key technology see [12] or [24] .)

A frequently asked question is how is the PKI-certificate approach is better than the well established DCE/Kerberos access control system. Kerberos and DCE allow remote users secure access to centralized resources. Access by users from multiple administration domains can be addressed by establishing cross-realm trust. In the DCE environment the policy about a set of resources is defined by an ACL in the realm which controls the resource. Only user identities and group memberships are assigned by the other realms. Since the PKI approach allows pieces of the access control policy to be stored in distributed certificates, it enables distributed stakeholders to more easily control their resources. It is also our expectation that PKI identity certificates will become more widespread than Kerberos identities since many enterprises are beginning to use them for employee identification.

Architecture and Implementation

We are implementing a certificate-based access control system called Akenti [1] , and initially deploying it in the DOE2000 Diesel Combustion Collaboratory [7] . Figure 1 shows the overview of the Akenti Architecture. The heart of this system is the Akenti policy engine, which gathers and verifies certificates and then evaluates the user's right to access to the requested resource based on these certificates. Figure 1 shows the major components of the run-time architecture. The client requests an operation on the resource and presents an identity certificate for authorization. The resource server authenticates the certificate and then asks the Akenti policy engine for an access decision. Akenti checks with a cache server for possibly cached certificates and if that fails, searches certificate directories across the internet. Akenti also logs all of its actions with a log server. Once Akenti has all the necessary certificates, it returns its access control decision to the resource server. The resource server then acts on that decision to perform or deny the operation on the resource on behalf of the client.

One other essential component of the Akenti infrastructure is the set of tools that generate certificates, query the policy and display the run-time operation of the system.

Implementation Refinements

Status

Over the past two years, we have implemented several Akenti-enabled servers. The prototype that has seen the most use is an Apache Web server with the SSLeay patches [3] and with Akenti replacing the standard access control module. It is being used as an access control gateway for a variety of Web-based resources within the Diesel Combustion Collaboratory [7] . This is a prototype collaboratory that involves two independent CAs and a number of government and commercial organizations scattered around the country. A single Akenti/Apache Web server is used to control access to two different image and data archives and a Web-based electronic notebook developed by Oak Ridge National Laboratory [14] . In these applications, the Akenti policy engine is called both by the Apache Web server and then again by the scripts that are used for fine-grained control of the resources. The Akenti policy engine is wrapped in a main program that is executed by scripts. Once the user has an identity certificate and the correct credentials, the access control is almost transparent.

We have also implemented a prototype CORBA ORB. Minor changes were made to the client side to find and present an identity certificate and to the server side to use one of the Object Management Group (OMG)-defined interceptors to call the Akenti policy engine.

Although we are just starting to evaluate Akenti, it appears to provide the sort of distributed management of access policy by multiple stakeholders that was our goal, while enforcing strong access control over the resources. In the case of remote references to resources, the additional overhead of Akenti does not seem to be unreasonable. We have invested considerable effort in creating user-friendly interfaces for the stakeholders. Currently we are rewriting the certificate generators. This is due partly to the rapid evolution of Java, and partly to our discovery that as we create policies for different sorts of resources and user populations, we find we need more flexibility and clarity in the certificate generator interfaces.

When problems occur, the logging facility is now both complete enough and sufficiently accessible that a practiced user can figure out what credential is missing, expired, etc. Probably the biggest problem with the logging information is that there can be too much of it, and sorting out the real cause of the problem is sometimes difficult. This is an area of ongoing development.

Vulnerabilities

The major vulnerability of the system derives from the fact that while stakeholders and their repositories are named in the authority file on the server, the use-condition and attribute certificates they depend on are maintained on distributed, "trusted" servers. If those certificate servers are not secure, then certificates could be deleted, resulting in an unintended access control policy. The type of failure depends on the type of certificates that are missing. If none of a stakeholder's use-condition certificates is available there will be a complete denial of access. If only some of a stakeholder's use-condition certificates are missing, the access could be greater than it should be. And if an attribute certificate is missing, specific users may get more or less access than they should.

The problem where a missing use-condition certificate allows greater permission than desired, can be solved by requiring the stakeholder to put all the use-conditions into one certificate. If that certificate is missing all access is denied. This constraint will produce more complicated use-condition certificates which may make the policy harder to understand.

The fact that a missing attribute certificate could permit too much access was revealed when comparing Akenti to KeyNote (see Section 9). The current use-conditions allow negative constraints, e.g., not belonging to some proscribed group. If that group certificate is missing, the user may get access to a resource that should be denied. To prevent this, use-conditions must always phrased in terms of positive conditions, so that attribute certificates will always increase access.

As we gain more operational experience, we will be better able to assess the importance of each of these vulnerabilities and the trade-offs required to address them.

Performance Measurements

The performance of a system composed of a client and a remote server using Akenti access control is often dominated by factors that are not controllable by the system designer. Nevertheless, it is valuable to measure the system performance in order to characterize the variables and to optimize those that can be influenced by the system.

Two variabilities arise from the fact that this is a distributed system: the network transmission time between the client and server, and the network transmission time plus the server response time between Akenti and the certificate servers. Performance factors under loose control by the stakeholder are the number of certificates required to make an access decision and the volume of data that is passed between the client and server. Finally, there is the overhead directly attributable to Akenti which includes the time associated with establishing an SSL connection and encrypting the data between the client and server, and the time spent in the Akenti policy engine gathering and verifying certificates.

The measurements in this paper are for file fetches between a Java SSL-enabled client an Akenti/Apache Web server. The client, server and all the certificate servers are on a 100 Mb/s LAN. The document sizes varied between 1KB and 1MB in order to evaluate the overhead of the SSL encryption. The SSL keys are 128-bit keys. The number of certificates that were required to permit access varied between a minimum of one use-condition certificate and two identity certificates and a more average case that required two use-condition certificates, one attribute certificate, and four identity certificates. We also took measurements with and without Akenti server caching enabled.

Average times to fetch a document from a Secure Akenti server.

	No caching			Caching
	Akenti (seconds)	SSL/network (seconds)	Total (seconds)	Akenti (seconds)	SSL/ network (seconds)	Total (seconds)
Min-acc
1K	0.86	0.65	1.51	0.20	0.65	0.85
1M	0.90	1.75	2.65	0.22	2.02	2.34
Ave-acc
1K	2.26	0.73	2.96	0.115	0.646	0.762
1M	2.24	1.96	4.00	.188	1.77	1.96

On the server side, Akenti does extensive logging of each logical step in the policy engine. This measurement excludes the server side time spent in the Apache server and SSL encryption. The times in Table 1 are the times in the Akenti policy engine (Akenti), the total socket read time the client saw (Total) and the difference between the two which can mostly be accounted for by SSL overhead (SSL/network).

The test program fetched the same file 10 times and then calculated the mean fetch time. The data from the client program was combined with the matching server log entries to determine the values in Table 1. Each case was run several times in succession to average over variations in the network load. Thus each number is the average of about 30-40 file fetches.

Several observations can be made from this data. As the files get bigger, the SSL encryption times tend to dominate the overhead. However, SSL can be configured to do only authentication and message integrity checking if encryption is not needed, which would reduce this time. As more certificates are required to grant access, the times in the Akenti policy engine increase. We can see from the Akenti log files that the major categories of time in the policy engine are fetching certificates and verifying signatures. In the minimum certificate case about 79% of the total time was spent fetching certificates and 9% was spent on signature verification. In the average certificate case, about 83% of the time was in fetching certificates and 8% was spent in certificate verification. Failing to find a certificate, such as an optional attribute, took more than twice the time of successfully finding one. The rest of the time was split between reading authority files, parsing the use-conditions and general program overhead.

In the case when caching is enabled and a valid capability certificate is found, the time in the policy engine is about 0.11 seconds. The variation that appears in these times in Table 1 is the result of the capability timing out and having to be reestablished. The caching lifetimes of cached use-condition and identity certificates is generally longer than that for capabilities, so cached versions of those certificates may be used when reestablishing the capability.

For a Web server that is mainly fetching documents, caching by the Akenti policy engine provides a big performance benefit, since there are usually several clustered access to documents in the same general protection domain. If Akenti is being used by a server where the pattern of accesses is isolated, the caching may actually be a disadvantage, since cache misses and subsequent cache updates are relatively costly.

Document fetch with and without Akenti access control

	With Akenti (seconds)	No Akenti (seconds)
1Kbyte	0.76	0.02
1Mbyte	1.96	0.75

The corresponding time that it took to fetch 1KB and 1MB files using the same client program but a standard Apache web server with no access control was about 0.02 seconds for the 1KB file and between 0.69 and 0.80 seconds for the 1MB file. (See Table 2.) For Web servers, that most meaningfully compares to the 0.76 and 1.96 second times for an average set of access constraints from a caching Akenti server. Obviously, the target applications for Akenti access control are ones where there is something important to protect and the granularity of the access checking is fairly large, e.g., a large document to be fetched, or a substantial process is to be started on the resource machine.

Another case where the Akenti overhead is not too severe is accessing a Web document that requires the parallel fetching of many secure components. For example, a document where all its parts are in the same protected tree. In this case the browser and the server fetch in parallel, and since Akenti has no trouble working in parallel and sharing the same cache, the net result of such a clustered fetch is not too much worse than the secure fetching of one document. For example, for a document containing 10 images, the html frame is retrieved in 4 seconds, the first three images appear after 8 seconds and the rest of the images appear at 10 seconds. The corresponding behavior for such a page with no access control is for all the images to appear after about 1 second.

Related Work

Currently there are several other projects working with signed certificates to enable access control decisions. One of the earliest attempts to define standards was the Simple Public Key Infrastructure (SPKI) [9] IETF draft proposal by Ellison, et al. This work proposed a standard for authorization certificates, name certificates and access control lists that are all represented by a formalized key-word, value syntax called S-expressions. An authorization certificate consists of an issuer, represented by a public key; a subject also represented by a public key; an optional delegation field; the actions that are authorized; and an optional set of real-time constraints on the certificate. We chose not to base Akenti on authorization certificates, but on policy and use-condition certificates instead. Our decision sidesteps the problem of revoking authorization certificates, and makes the policy more explicitly stated and thus easier for multiple stakeholders to understand. Our design also only allows only one level of delegation, rather than the possibility of delegation on each certificate. Again this makes the policy more restrictive, but easier to discover.

Pekka Nekander and Jonna Partanen of Helsinki University of Technology have used the SPKI-style certificates to carry access permissions with Java code, rather than relying on local access control configuration files [21] . They argue that maintaining a local security configuration on each machine on which a Java class might be executed does not scale to large numbers of machines and classes. This argument is parallel to our observation that requiring all users to have accounts and to be entered into ACLs on each resource server does not scale to separately administered distributed compute resources.

Nekander's and Partanen's system uses authorization certificates to grant a Java class (or JAR file) specific permissions. If the machine on which the class is to be executed accepts the signer of the certificate, the class is allowed to perform the actions. This type of access decision supports the Java security model which grants access to code on the basis of where it came from rather than who caused it to be executed. However, the focus in Akenti is on allowing access to resources, which are referenced through a resource server, by specified classes of users. Thus it is more natural to base access decisions on authenticated identity certificates matched against policy requirements at the time of resource use.

The PolicyMaker [5] and KeyNote [4] trust management systems present a very generalized approach to specifying and interpreting security policies, credentials and trust relationships. Both of these systems share with Akenti the goal of putting all the policy and credential information into signed certificates that can be stored in a distributed fashion. These certificates are then gathered together by a policy engine module or daemon at the time of resource access and interpreted to allow or deny the access. PolicyMaker certificates are much more generalized than Akenti's as they consist of programs written in a general programming language. Since an access policy is represented by the set of all such certificates, it may be very hard to understand the overall access policy for a resource. The KeyNote system settled on a C-like expression and regular expression syntax for describing conditions, similar to that which Akenti uses. However, in an Akenti application the policy for a resource use is spelled out in a few authority files and use-condition certificates which make explicit what actions users or classes of user have while in an authorization credential system such as KeyNote, all the assertions combine to imply a policy.

KeyNote certificates also differ from Akenti's in the principle of "assertion monotonicity" which means that each assertion will increase the permitted actions. Akenti permits a use-condition to specify negatives, e.g., that a person may not be a member of a given group. Then if the corresponding certificate that identifies the person as a member of the proscribed group is not found, the person may be granted more permissions than were intended by the stakeholder. Future versions of Akenti should close this loophole.

A more specific use of identity certificates for authorization can be found in the Globus Project [15] , a joint research project between Argonne National Laboratory and the University of Southern California's Information Sciences Institute (USC/ISI). Globus is developing a software infrastructure for distributed computational and informational resources, and is experimenting with using X.509 identity certificates to provide a one-time per session sign-on to a distributed set of resources. [13]

The Globus infrastructure provides a gateway server at each site. The server on the client side accepts and verifies a user's identity certificate and creates a temporary proxy certificate to represent the user to other Globus servers. The server at the resource site authenticates the certificate that it receives and maps the identity into a local user ID. The resident operating system then performs access control as usual. This solution was motivated by the early use of Globus to provide remote access to supercomputers. The administrators of the supercomputing sites were not interested in relying on a new access control mechanism. The Globus solution allows a user to authenticate once per session by presenting an identity certificate. However, each user must still have a local user ID and account with each resource server. We are working with the Globus group to integrate Akenti as an alternative access control mechanism for those sites that want distributed policy management.

Future Work

There are two general directions for future work on Akenti. One is to implement the policy engine as a daemon in addition to the current library module approach. The second is to improve the syntax of the various certificates. Our intent is to define an XML-based (Extensible Markup Language) [10] format for our certificates. XML has the advantages of presenting self-describing documents and being widely used by various scientific disciplines. There are tools available for validating an XML document against its document type definition (DTD) which may be useful to the interface programs that are used to create the certificates. Our goal is to use a standard syntax which may be familiar to the people who have to write and understand the policy.

There are several applications which we intend to integrate with Akenti. We plan to use Akenti to make access decisions for a network-bandwidth quality of service (QoS) framework that is being developed at LBNL [16] . In order to conform to the standards of the QoS community, a policy server should communicate via the COPS (Common Open Policy Service) [6] protocol. This is one of the motivations for implementing Akenti as a server that will respond to requests for access control decisions. COPS is a statefull protocol that, among other things, allows the resource server to upload or download policy documents. This feature gives us the option of keeping the authority files with the resource tree and uploading them to the Akenti server, allowing it to be a stateless decision maker.

We are currently integrating Akenti security with a secure mobile agent system that is being developed at LBNL [19] . This system customizes the Java security model to enforce policy-based access control on mobile Java agents.

Another possibility is to implement the proposed standard Generic Authorization and Access control API [23] with Akenti. To do so would require adding some additional library interfaces.

Both COPS and GAA expect the policy module to be able to make decisions based on the time of day, the location of the requestor and, in the case of COPS, on some level of allowed quotas for the resource. In our current model, Akenti simply copies strings that represent actions from the use-condition certificates and returns them to the resource server which interprets them. The concepts of a time during which a user may use the resource, an allowed IP address or domain from which the request may come, and a quota for use of resources must be added to the policy engine. To accomplish this, Akenti will need to define a convention for naming the use-conditions for time, location and quotas and then checking for compliance. The last case requires getting a value for the amount of resources used from the resource server and storing it as an auxiliary certificate.

Conclusions

In a larger view, useful security is very much a risk management, deployment and user ergonomics issue. Once it has been determined what level of security is required, the hard problem is integrating that level of security into the end-user (e.g., scientific) environment so that it will be used, trusted to provide the protection that it claims, easily administered, and genuinely useful in the sense of providing new functionality that supports distributed organizations and operation. As large enterprises establish public key infrastructures and people become accustomed to using an identity certificate to authenticate themselves rather than a multitude of passwords, certificate-based access control will seem natural and be more easily understood.

Akenti facilitates the decentralized creation and management of policy certificates and the use of these certificates to make secure policy-based access control decisions. Distributed certificates permit the decentralized administration of shared resources which is an important goal in a collaborative research environment. We believe that our prototype Akenti implementation has demonstrated the viability of such a distributed system.