Collaboratory Security Architecture and Services1

Description

The overall goal of this project is to provide an approach to access control that provides assured, policy-based access control for computer mediated resources such as data archives and instrument systems, that operate in wide area network environments, grid services such as QoS and bandwidth reservation, and potentially as a dine-grained, object method level access control system (such as might be used to implement "need to know" restrictions on databases).

Initial progress has been good, with the basic system ready for first release, and several prototype integrations demonstrated with different types of applications and security services.

Future work will focus on use of the policy engine as a stand-alone service, and as the core of emerging standards such as the IETF Generic Authentication and Authorization interface and Common Open Policy Service. security for mobile agents, access control for secure multicast groups, and as access control for grid services such as network QoS and CPU allocation systems such as Condor's Classads.

Background

DOE scientific resources - instruments, data, and collaborations - that are accessed via open networks require protection against unauthorized use. Akenti is designed to provide a flexible, easily managed mechanism, which strongly controls access to distributed resources, by widely distributed users.

Akenti is an access control system designed to address the issues raised in allowing restricted access to distributed resources which are controlled by multiple stakeholders. The stakeholders are the people with authority to grant access to resources and may be both physically and organizationally remote from the resource. Akenti enables these stakeholders to remotely and securely create and distribute instructions authorizing access to their resources.

Access control is a means for enforcing an authorization policy. In a client-server architecture, the clients (on behalf of users) attempt to access resources that are controlled by servers. A priori authorization decisions govern which users may access which servers for what purposes and under what conditions. These decisions are reflected in an access control policy. Akenti makes access control decisions based on one set of digitally signed documents that represent the authorization instructions and another set that represent user attributes. Existing public-key infrastructure and secure message protocols provide confidentiality, message integrity, and user identity authentication, during and after the access decision process.

 

Approach

• an independent certificate analyzer ("Akenti") that locates and verifies all of the information necessary to determine stakeholder use-conditions and user attributes that satisfy those use-conditions ( http://www.itg.lbl.gov/Akenti )
• encode all required information in digitally signed documents that are generated and managed in the trust domain of the author ( http://www.itg.lbl.gov/Akenti/docs/specs.html#PolicyModelOverview )
• the client use model is that of an access control decision maker:
• client connection to application server / security gateway is by secure protocol (e.g., SSL)
• security protocol typically authenticates user and can pass client / user credentials to Akenti
• the identity of the resource is passed to Akenti
• Akenti then
• identifies and validates all stakeholder use-conditions
• locates and verifies user attributes (that will satisfy the use-conditions)
• passes the Yes/No answer to the security protocol (the secure connection fails to complete if answer is "no")
• passes a capability to the resource that contains all of the verified certificates - these certificates may contain information related to "run-time" actions like read-write-modify, object ids, etc. that are monitored by the service provider / security gateway

Technical Progress

• Akenti prototype is operational and has been deployed in several testbed environments.It is used in the Diesel Combustion Collaboratory ( http://www-collab.ca.sandia.gov/Diesel/ui/security.shtml ) to allow restricted Web access to several kinds of information. It is used locally at LBL to allow restricted access to download the Akenti code ( http://www.itg.lbl.gov/Akenti/downoad.html . It has been integrated with a collaboratory camera management system to control access to a remote camera (http://www.itg.lbl.gov/Akenti/sc98/akenti_apps.pdf).
• Akenti has been integrated with several security protocols
• We have implemented SPKM ( http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2025.txt ) for secure communications between end peers. This can be incorporated as an underlying mechanism for Generic Security Service as GSS/SPKM similar to GSS/Kerberos. Also, the security context establishment is coupled with Akenti access control for authorization decisions as a part of the protocol itself. This enables both authentication and authorization before connecting end peers.
• We have two applications that use the SSL protocol. Our Apache web server uses the SSLeay patches to Apache, and the CORBA application uses the SSL enabled OrbixWeb daemon. In each case, SSL is set up to require a client side ID certificate, which can be passed from the SSL connection to the server and then to Akenti to be used for making access control decisions.
• Integrated with several standard server / gateway mechanisms
• we have developed an Akenti enhanced Apache Web server that uses the SSLeay patches ( http://www.apache-ssl.org) to Apache to get the client ID certificate. We have replaced the Apache standard access control module with one that calls Akenti, thus replacing the standard Web user and password access control with one implemented by Akenti and based on the ID certificate the user passed in, and the distributed Use Conditions that have been created by the stakeholders for the documents.
• A pilot integration of Akenti with a CORBA ORB using the Object Management Group (OMG) defined interceptor mechanism has been built. Using the SSL-enabled version of Iona's Orbix ( http://www.iona.com ), the identity of the client and the name of the CORBA object that is being invoked can be passed to Akenti at the time the invocation is attempted. Akenti uses this information, along with a authority file for the objects and whatever use conditions exist for the object to allow or deny access to an object. Access can be controlled on the object name, and, optionally, on the object and method being invoked.
• Demonstrated in several prototype applications
• We are using the Akenti/Apache Web server to secure a prototype Image Library ( https://imglib.lbl.gov ) and a prototype implementation of a secure file uploading facility. ( https://imglib.lbl.gov/shared ) In both of these applications, the Web server uses Akenti to grant access to existing files and to the scripts that are used to create new files. Then the scripts call Akenti directly to check on fine-grained access before modifying the data on the server.
• We demonstrated the use of Akenti to control access to a collaboratory instrument resource. Remote camera controller software was modified to check the access rights of all incoming requests with Akenti. This involved changing the original connection between the client and the server to an SSL connection that presented and verified the client's identity. This identity was then used by Akenti to check the clients access to the camera. The two sides of the camera controller software then negotiated a shared key, that was used on subsequent UDP command messages to verify that each command was allowed.secure access to remote, collaboratory camera controller. See (http://www.itg.lbl.gov/Akenti/sc98/akenti_apps.pdf) for more details.
• Technology issues
• We have dealt with the problems of debugging the policy and use conditions and educating the users and stakeholders by providing several methods for the remote user to monitor what the Akenti server is doing. We have written an applet that talks to the logging monitor on the secure resource machine and provides a real-time graphical display of the steps taken to check a user's access to a secure resource. ( http://imglib.lbl.gov/StartMonApplet.html ); We have provided a cgi-script that will display the policy imposed by stakeholders on resources. Both of these facilities are available to anyone who has basic access to the resource tree. They do not need to have access to the specific resource they are querying. In a thoroughly debugged setup, these functions can be viewed as a security hole and disabled. But when a system is being set up and stakeholders are learning how to set up use conditions, they have proven extremely useful.
• Akenti supports multiple certification authorities (CAs) for X.509 certificates. This is necessary in a collaboratory environment where the user's may wish to use identity certificates issued by their own organizations.
• In order to achieve acceptable performance, certificates and capabilities (a package of analyzed certificates for a resource) are cached, as limited by stakeholder policy, so that if a client makes successive references to the same resources, the certificate gathering and verifying steps need to be done only once.
• We have Java GUIs to assist stakeholders and attribute certifiers to generate and manage their use conditions and attribute certificates. ( http://www.itg.lbl.gov/Akenti/docs/stakeholder.html )

Future Work

• Continue to develop the secure mobile agent framework. We will add support for location-independent secure communication between the agents via synchronous, asynchronous, peer-to-peer, and multicast messages. We will investigate a code/class caching scheme to reduce network overhead on code transmission. And finally we will experiment with giving separate identities to individual agents or groups of agents by allowing them to carry their private keys as they migrate. Agents containing private keys are at risk from malicious hosts who might be able to extract the keys from the agent code, but there are several applications that require agents to be strongly authenticated,. We will investigate several proposed approaches to protect against such attacks.
• Integrate Akenti with the Condor ClassAds mechanism for secure, policy-based CPU scheduling. Analyze the possibility of incorporating ClassAd structures in use condition and attribute certificates or be used by Akenti. This will facilitate evolving Condor Classads into signed entities. Once these two steps are accomplished, we will explore incorporating security into Condor using Akenti and SSL.
• Integrate Akenti with the CLIQUES secure group communication protocol for policy-based group communication membership. The CLIQUES protocol is allows for a distributed key generation and distribution. It currently has no secure way of verifying who should be allowed to join the protocol. We propose to investigate using Akenti capability certificates to gain access to the CLIQUE key generation protocol.
• Investigate how Akenti could be used to implement some of the proposed access control standards, such as GAA and COPS.
• The Generic Authorization and Access control API (GAA API) ( http://www.ietf.org/internet-drafts/draft-ietf-cat-acc-cntrl-frmw-01.txt ; this is a work in progress and may be supplanted by later drafts) of the IETF's Common Authentication Technology working group defines a functional interface for checking access. We would need to add some additional interfaces to our current Akenti library to provide these interfaces.
• The IETF COPS (Common Open Policy Service) protocol defines a standard way to exchange information between a policy server and its clients. Akenti in its current form provides policy-based decisions. It can be transformed into a policy server by making it a stand-alone process and by adding the ability to maintain persistent state as defined in the COPS specification ( http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-rap-cops-05.txt ; this is a work in progress and may be supplanted by later drafts). As a policy server, Akenti would communicate with clients using the COPS protocol. COPS is under development by the IETF's RSVP Admission Policy working group .
• Both of these standards would require expanding the types of use conditions that Akenti recognizes to include time of day restrictions, user location restrictions (IP address) and coarse-grained resource allocation limits.
• Provide Akenti as a secure, stand-alone access control service. Akenti currently is implemented as a library module which applications access via a local procedure call. We plan to make it a stand-alone process able to serve multiple remote clients by allowing clients to upload their initial policy information via secure connections (following authentication and access control to prevent use by unauthorized clients). We may want to provide both COPS protocol modules for clients who need to maintain state, and a simple LDAP protocol module for stateless access control requests.

In order to provide a reliable (constantly available) service, we will investigate approaches to redundant servers by using the results of the CLIQUES secure reliable multicast work, and/or thought the use of the secure mobile agents noted above.

• Provide secure, policy-based use of reservable resources in a distributed computing environment. In such an environment, scarce shared resources such as premium network bandwidth (see, e.g., the IETF's DiffServ work at http://www.ietf.org/html.charters/diffserv-charter.html ), large-scale computing nodes, and storage systems will all have to be scheduled, often long in advance of use. The providers of these resources have an interest in controlling who is allowed to use them. The criteria for use will vary; what is important is to ensure that the criteria are always enforced and cannot be modified or evaded. Akenti offers a flexible method of expressing tamper-resistant usage criteria in the form of use-condition certificates and as such will be an integral component of a bandwidth reservation system currently under development. The bandwidth reservation system will use Akenti to enforce elements of access control policy other than physical capacity, e.g., allocation of bandwidth based on the type of traffic and the time of day. As such, the work to include semantic understanding of time-of-day and resource allocation restrictions to Akenti, noted above, will be of particular use to the bandwidth reservation system, although it will by no means exhaust the possible policy elements the system will have to take into account.
• Investigate the use of Akenti as a standard policy server within the Internet2 Quality of Service Backbone (QBone). The Internet2 project is committed to supporting quality of service as part of the network infrastructure. They have established a quality of service working group to design and implement the necessary components for QoS. We will consult with this working group to determine what its requirements are for policy-based access control and whether an Akenti server will satisfy those requirements.
• Provide a pure Java implementation of Akenti in order to provide multi-platform (e.g. Windows) support and to investigate possible use in Java-based embedded control systems. This may require having two copies of the codebase, one in C++ and one in Java, so it should not be started until we are sure the fundamentals of the implementation are not going to change.

Relationship to Other Projects

• As noted in the text there are several projects that are collaborators and several that are experimental users.
• Akenti is providing the access control system for laboratory data in the Diesel Collaboratory.
• Akenti is under consideration for access control in the Syracuse WebFlow, gird computing project.
• We are exploring ways to use Akenti to provide policy based access control for Globus.
• Akenti will provide the policy based access control for the ESNet bandwidth reservation project.
• In a collaboration with U. Wisc., Akenti is being integrated with the Condor ClassAd CPU resource scheduling mechanism.
• Akenti has been integrated with the ORNL Electronic Notebook to provide policy based access control.
• Akenti has been integrated with the DOE2000 Collaboratory remote camera control system.
• Akenti is being integrated with a secure CORBA ORB to provide object and method level access control for on-line instrument systems.
• We are investigating the issues in using Akenti to provide group access control for the CLIQUES secure multicast system.

Publications

Akenti home page.

http://www.itg.lbl.gov/security/Akenti

 

"Authorization and Attribute Certificates for Widely Distributed Access Control," William Johnston, S. Mudumbai, and M. Thompson. IEEE 7th International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises - WETICE, Stanford, CA. June, 1998.

A paper on the goals and design of the Akenti Distributed Access Control system.

http://www.itg.lbl.gov/security/Akenti/cert.based.access.control.ieee.pdf

 

"Design and Implementation Issues for a Distributed Access Control System"

A paper on the design and implementation of the Akenti Distributed Access Control system (Submitted to Fourteenth Annual Computer Security and Applications Conference).

http://www.itg.lbl.gov/security/Akenti/akenti_design_implementation_issues_csac.pdf

 

"Overview of Akenti"

A summary prepared for Supercomputing 98.

http://www.itg.lbl.gov/security/Akenti/sc98/akenti.pdf

 

"Overview of Akenti applications"

A summary prepared for Supercomputing 98.

http://www.itg.lbl.gov/security /Akenti/sc98/akenti_apps.pdf

 

"Overview of the Anchor toolkit"

A document prepared for Supercomputing 98, describing a mobile agent architecture that will incorporate Akenti.

http://www.itg.lbl.gov/security/Akenti/sc98/anchor.pdf

 

Other papers and talks are cited at http://www-itg.lbl.gov/Akenti