Task-Specific Restricted Delegation
Ian D. Alderman
Computer Sciences University of Wisconsin­Madison

Miron Livny
Computer Sciences University of Wisconsin­Madison

alderman@cs.wisc.edu

miron@cs.wisc.edu

Categories and Sub ject Descriptors: D.4.6 [Op erating Systems]: Security and Protection­Access controls, authentication ; C.2.4 [Computer-Communication Networks]: Distributed Systems­distributed applications General Terms: Management, Design, Security Keywords: Distributed batch computing, security, PKI A fundamental trade off exists within distributed batch computing systems b etween the numb er of participants (b oth users and resources) in each system and the security of the system. An increase in the numb er of participants can result in increased utilization of existing resources; however, as the numb er of participants grows, so does the amount of risk involved in participating in the system. Distributed batch computing systems are often organized into groups: We term a group of users and resources managed by a single entity an administrative domain. Trust within a domain is high; as the numb er of interop erating administrative domains increases, the level of trust b etween any two domains is likely to decline, reducing the trust each participant has in the system as a whole. There is a need for a security framework to restore trust in the system as a whole so that the b enefits of increased participation and utilization can b e realized. In order to make the multiple administrative domain environment more palatable to participants, we have taken the approach that the security mechanisms in a distributed batch computing infrastructure should b e consistent with the principle of least privilege. We summarize the design of a framework intended to reduce the numb er and scop e of assumptions that must b e made ab out the security of a distributed batch computing infrastructure. The framework includes mechanisms that p ermit the ability to verify task and data integrity, protect data confidentiality, restrict the use of delegated credentials to task-sp ecific, user sp ecified actions. These mechanisms are integrated by including authorization p olicy regarding task and credential usage in task metadata, applying signatures to task metadata, and integrating these signatures into delegated credentials. User sp ecified authorization p olicy determines where the task can move within the system and how the delegated credentials can b e used. This p olicy is enforced symmetrically, whenever processes in the task pathway communicate. The result protects user data, limits the exp osure of compute elements to attack, and increases
Copyright is held by the author/owner(s). HPDC'07, June 25­29, 2007, Monterey, California, USA. ACM 978-1-59593-673-8/07/0006.

audit capability. The ultimate goal of this framework is b oth to enhance the security of existing installations as well as to p ermit task sharing b etween administrative domains in situations where sharing is not currently feasible due to security risks, resulting in increased utilization of resources. Sp ecifically, the framework protects against intermediaries who do not protect the confidentiality or integrity of the tasks they handle and comp onents that misuse credentials. A user who submits a task sp ecifies an execution p olicy, defining a set of trusted compute elements on which the task can run, an access p olicy, defining a set of actions the task can p erform, and a delegation p olicy, defining a set of intermediaries that can handle the task. Enforcement is p erformed by a set of machines sp ecified by the user: the submitting host, trusted compute elements, and storage resources that store information used by the task. The intermediaries resp onsible for moving the task through the system are assumed to b e trustworthy for their role: moving the task through the system. The framework consists of a set of mechanisms which work together to enforce the restrictions. These mechanisms include digital signatures for task data and metadata, encrypted payloads for tasks, and restricted proxy certificates b ound to individual tasks. We have partially implemented a prototyp e of the framework using the Condor distributed batch computing system [3, 5]. Although the framework is describ ed in the context of Condor, we b elieve that it could b e adapted to a more general Grid environment. The main framework comp onents consist of signed ClassAds, tasksp ecific proxy certificates, and action authorization expressions, describ ed b elow. The ClassAd language is a simple language used within Condor and other systems to store metadata for tasks and resources. ClassAds are sets of name-value pairs; the values can contain expressions that can refer to names within the ClassAd, as well as names in other ClassAds. The ClassAd language defines the structure of ClassAds and the rules for expression evaluation. Signed ClassAds extend ClassAds by adding supp ort for applying and verifying digital signatures using X.509 private keys and certificates. Signed ClassAds are implemented by applying XML Signatures [1] to XML representations of ClassAds. File references can also b e included within the data that is signed. Signed ClassAds make it p ossible to cryptographically verify the authentication information associated with a task, and to establish a cryptographic link b etween the authentication information and the actual contents of the task as

243


received. Because the authorization information sp ecified by the submitting user is included in the signed ClassAd, p olicy enforcement p oints can use signed ClassAds to make authorization decisions on b ehalf of the user. Audit mechanisms are strengthened by explicit association b etween a task and information ab out its origin, and b etween resources and the tasks they p erform. Signed ClassAds are used within the framework when a task is submitted to encapsulate the task which includes the sp ecification of task p olicy. Infrastructure comp onents sign this p olicy to signify their compliance with it. In addition, a signed ClassAd is produced when task completes, including task output which serves as a "receipt" for the task. Task-specific proxy certificates limit the usage of a proxy certificate to a sp ecific task. GSI proxy certificates. used for credential delegation in grid environments, can form delegation chains [2, 4, 6]. Proxy certificates contain supp ort for restricted delegation through a general p olicy mechanism. Policies are sp ecified as an arbitrary length sequence of bytes and a typ e. Our restriction mechanism links a proxy delegation chain to a particular task by including a signed ClassAd for a particular task in the p olicy field within the associated proxy delegation chain to produce a task-sp ecific restricted proxy certificate. By including a signed ClassAd in a proxy certificate, we are able to use the expressive p ower of ClassAds to sp ecify p olicy for the usage of the delegated certificate. The signed ClassAd contains conditions, describ ed in the following section, intended to limit the situations under which the delegated certificate can b e used for authorization of access to data, execution of tasks, and p erformance of additional delegation steps. The steps in creating a task-sp ecific proxy certificate are shown in Figure 1. The submitting user can sp ecify conditions on the actions p erformed in the task pathway using Action authorization expressions. The conditions are sp ecified as expressions in the ClassAd language and are evaluated by b oth parties to the action. The expressions limit which actions can b e p erformed on which ob jects by which principals. Action authorization expressions can exist for forwarding, execute, and access actions. The forwarding action expression sp ecifies the set of processes that the user accepts as trustworthy to preserve the availability of the task. The execute action expression sp ecifies the set of processes that the user accepts as trustworthy to p erform the computation correctly when given a valid task, and to preserve the confidentiality and integrity of the task input data, executable, and output data. The access action expression sp ecifies a set of acceptable data accesses, limited by directory prefix or file (including wild cards), a set of storage elements, a set of compute elements, and access typ e (read or write). Signed ClassAds, task-sp ecific proxy certificates, and action authorization expressions comprise a framework which is intended to facilitate trust by eliminating opp ortunities to abuse it, and to increase coop eration and utilization. This framework is designed to facilitate interop eration b etween multiple administrative domains, while decreasing the numb er and scop e of assumptions that need to b e made ab out the security of infrastructure comp onents.

Figure 1: The task-specific proxy certificate. Action authorization expressions limiting certificate usage are embedded within the signed ClassAd. http://www.w3.org/TR/2002/REC-xmldsig-core20020212/. I. Foster, C. Kesselman, G. Tsudik, and S. Tuecke. A security architecture for computational grids. In Proceedings of the Fifth ACM Conference on Computer and Communications Security, pages 83­92, 1998. M. Litzkow, M. Livny, and M. Mutka. Condor - a hunter of idle workstations. In Proceedings of the 8th International Conference of Distributed Computing Systems, June 1988. B. C. Neuman. Proxy-based authorization and accounting for distributed systems. In Proceedings of the 13th International Conference on Distributed Computing Systems, Pittsburgh, May 1993. D. Thain, T. Tannenbaum, and M. Livny. Condor and the grid. In F. Berman, G. Fox, and A. Hey, editors, Grid Computing: Making the Global Infrastructure a Reality. John Wiley & Sons Inc., April 2003. S. Tuecke, V. Welch, D. Engert, L. Pearlman, and M. Thompson. Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile. RFC 3820 (Prop osed Standard), June 2004.

[2]

[3]

[4]

[5]

[6]

1.

REFERENCES

[1] D. Eastlake, J. Reagle, and D. Solo. XML-Signature Syntax and Processing. W3C Recommendation, 2002.

244