# Cover Page {#cover-page .unnumbered}

U.S. Department of Energy Office of Science

Scientific Discovery through Advanced Computation Solicitation 01-06
[and]{.underline} LAB01-06

National Collaboratories and High Performance Networks

Security and Policy for Group Collaboration

A DOE SciDAC Collaboratory Middleware Project

**For the period May 1, 2001 -- September 31, 2006**

Principal Investigator (Laboratory)

Steven Tuecke

Mathematics and Computer Science Division, Argonne National Laboratory

Argonne, IL 60439

Tel: 630 252 8711

Fax: 630 252 5986

Email: tuecke@mcs.anl.gov

Principal Investigator (University)

Carl Kesselman

Information Sciences Institute, University of Southern California

4676 Admiralty Way, Suite 1001

Marina del Rey, CA 90292-6695

Tel: (310) 448-9338

Fax: (310) 823 6714

Email: carl@isi.edu

Other Senior Personnel

  ------------------ ----------------------------------------------------
  Ian Foster         Mathematics & Computer Science Division, Argonne
                     National Laboratory

  John Bresnahan     Mathematics & Computer Science Division, Argonne
                     National Laboratory

  Laura Pearlman     Information Sciences Institute, University of
                     Southern California

  Von Welch          Argonne National Laboratory/U.Chicago Computation
                     Institute

  Doug Engert        Electronics & Component Technologies Div., Argonne
                     Natl Laboratory

  Miron Livny        Dept of Computer Science, University of Wisconsin
                     Madison
  ------------------ ----------------------------------------------------

**Table of Contents**

[]{.mark}

[**Cover Page i**](#cover-page)

[Abstract iii](#abstract)

[A. Narrative A--1](#narrative)

[A.1. Background and Significance A--1](#background-and-significance)

[A.1.a. The Problem: Enabling Collaborative Work
A--1](#the-problem-enabling-collaborative-work)

[A.1.b. Current State of Knowledge in Security and Policy Technologies
for Group Collaboration
A--2](#current-state-of-knowledge-in-security-and-policy-technologies-for-group-collaboration)

[A.1.c. Our Proposal: A New Group Security and Policy Infrastructure
A--3](#our-proposal-a-new-group-security-and-policy-infrastructure)

[A.1.d. Contributions A--4](#contributions)

[A.2. Preliminary Studies A--5](#preliminary-studies)

[A.2.a. Scalable Authentication: The Grid Security Infrastructure
A--5](#scalable-authentication-the-grid-security-infrastructure)

[A.2.b. Investigations of Policy A--6](#investigations-of-policy)

[A.3. Research Design and Methods A--7](#research-design-and-methods)

[A.3.a. Roles, Privileges, and Policy
A--7](#roles-privileges-and-policy)

[A.3.a.1. Community Authorization Service
A--7](#community-authorization-service)

[A.3.a.2. Restricted Delegation A--10](#restricted-delegation)

[A.3.a.3. Delegation Tracing A--10](#delegation-tracing)

[A.3.a.4. Policy Languages A--10](#policy-languages)

[A.3.a.5. Policy Evaluation API & SDK A--11](#policy-evaluation-api-sdk)

[A.3.a.6. Accounting A--11](#accounting)

[A.3.a.7. Policy-Based Resource Selection
A--11](#policy-based-resource-selection)

[A.3.b. Authentication Procedures to Support Dynamic Collaboration
Membership
A--12](#authentication-procedures-to-support-dynamic-collaboration-membership)

[A.3.b.1. Online Certificate Authority
A--13](#online-certificate-authority)

[A.3.b.2. Online Credential Repository
A--14](#online-credential-repository)

[A.3.b.3. Support for Multiple User Credentials
A--14](#support-for-multiple-user-credentials)

[A.3.b.4. Multi-Factor Authentication
A--14](#multi-factor-authentication)

[A.3.c. Managing Dynamic Resource Sets
A--14](#managing-dynamic-resource-sets)

[A.3.c.1. Subordinate Certificate Authorities for Domains
A--15](#subordinate-certificate-authorities-for-domains)

[A.3.c.2. Integration with Local Security Solutions
A--15](#integration-with-local-security-solutions)

[A.3.d. Integration of Security Into Collaborative Applications
A--15](#integration-of-security-into-collaborative-applications)

[A.3.d.1. Extensions to Standard APIs
A--16](#extensions-to-standard-apis)

[A.3.d.2. Tracking Standards A--16](#tracking-standards)

[A.3.d.3. Independent Data Unit Support
A--16](#independent-data-unit-support)

[A.3.d.4. Flexible Application of Message Protection
A--16](#flexible-application-of-message-protection)

[A.3.d.5. Integration Into Development Frameworks
A--17](#integration-into-development-frameworks)

[A.3.d.6. Improved Error Reporting and Logging
A--17](#improved-error-reporting-and-logging)

[A.3.e. Tasks and Milestones A--17](#tasks-and-milestones)

[A.3.f. Deliverables A--19](#deliverables)

[A.3.g. Connections, Technology Transfer, Application
A--20](#connections-technology-transfer-application)

[A.3.g.1. SciDAC and Other DOE Projects
A--20](#scidac-and-other-doe-projects)

[A.3.g.2. Standards Bodies and Open Source Consortia
A--21](#standards-bodies-and-open-source-consortia)

[A.3.h. Evaluation Criteria A--21](#evaluation-criteria)

[A.4. Subcontract or Consortium Arrangements
A--22](#subcontract-or-consortium-arrangements)

[B. Literature Cited B--1](#literature-cited)

[C. Budget and Budget Explanation C--1](#budget-and-budget-explanation)

[D. Other Support of Investigators
D--1](#other-support-of-investigators)

[E. Biographical Sketches E--1](#biographical-sketches)

[F. Description of Facilities and Resources
F--1](#description-of-facilities-and-resources)

# []{.mark}  {#section .unnumbered}

# Abstract

We propose a Collaboratory Middleware research project aimed at
providing the fundamental security and policy infrastructure required to
support the creation and operation of distributed, computationally
enabled collaborations.  This infrastructure will exploit innovative new
techniques to address challenging issues of scale, dynamics,
distribution, and role.   To reduce greatly the cost of adding new
members to a collaboration, we will develop and evaluate new techniques
for creating and managing credentials based on public key certificates,
including support for on line certificate generation, online certificate
repositories, and support for multiple certificate authorities.  To
facilitate the integration of new resources into a collaboration, we
will improve significantly the integration of local security
environments.  To make it easy to create and change the role and
associated privileges of both resources and participants of
collaboration, we will develop community wide authorization services
that provide distributed, scalable means for specifying policy.  These
services will make it possible for the delegation of capability from the
community to a specific user, class of user or resource.  Finally, we
will instantiate our research results into a framework that makes it
useable to a wide range of collaborative tools. The widespread adoption
of our Grid Security Infrastructure and Globus Toolkit technology
provides a natural dissemination and technology transfer vehicle for our
results.

# Narrative

## Background and Significance

We first define the problem that we wish to solve, and explain why it is
important; review the current state of knowledge and technology in this
area; and finally indicate the specific goals of the proposed research.

### The Problem: Enabling Collaborative Work

Today, scientific advances are rarely the result of an individual
toiling in isolation, but are typically the result of a collaborative,
team effort. We can find many examples of such collaborative teams in
areas of science of interest to the Department of Energy:

-   Particle physics experiments, such as BABAR, CMS, and ATLAS are
    designed and conducted by large, multinational teams. Individual
    members of the team might be responsible for the design of the
    detector, various pieces of software for on-line data collection,
    data preprocessing and event detection. Team members use shared data
    sets for analysis and may use community wide compute resources for
    data analysis.

-   Scientists studying global change perform extensive post-simulation
    analysis in order to attempt to understand the results of a
    simulation. While a small team may develop the simulation code,
    separate groups may configure and run the code to generate data
    about a specific phenomenon. At this point, the simulation data
    becomes a community resource that has a variety of uses.

-   New particle accelerators are being considered that would use
    Wakefield forces excited in a charged plasma gas to accelerate the
    beam on plasma, hence promising to provide accelerators with energy
    levels far exceeding those of current accelerator technologies.
    These new accelerators are being designed by collaborative teams
    that bring together theoretical physicists, computational scientists
    and experimentalists. During an experiment, using on the fly data
    analysis of experimental data coupled with on-demand simulation, the
    team must interact to determine if the experiment is proceeding
    correctly, and to understand the results in order to design the next
    set of experiments to be performed.

These examples illustrate four essential properties of collaborative
work:

-   *Geographical and Organizational Distribution*. Participants in a
    collaborative activity are distributed, both geographically and
    organizationally, as are the tools and resources used to perform the
    work of the collaboration (e.g., computers, data sets, storage
    devices, simulation programs).

-   *Large and Dynamic Scale*. Collaborations can scale in size from a
    few individuals, as is the case with the accelerator design
    collaboration, to literally hundreds or thousands of participants,
    which is the case of many high-energy physics experiments.
    Furthermore, the size of a collaboration is not static, but
    frequently varies over the lifetime of the collaborative task.
    Participants may join or leave, and resources may be added or
    removed

-   *Diverse Roles*. Collaborations may span areas of expertise, with
    members filling different roles within the collaboration. The role
    of a member may be fixed for the duration of the collaboration, or
    it may change during its lifetime. For example, in the case of
    climate modeling there are distinct roles of the simulation writer,
    the simulation runner, and the consumer of simulation data.

-   *Community resources*. The work of the team is enabled by providing
    team members with access to a variety of resources including
    computers, storage systems, datasets, applications, and tools. Thus
    in a real sense, a collaboration is not just the group of
    individuals participating in the activity, but the resources that
    can be used by members of the collaboration to conduct their work.

Collaborative work of the type described requires that two basic
infrastructure elements be in place:

-   One must have mechanisms for establishing and maintaining the
    structure of the collaboration. This includes means for identifying
    who is a member of the collaboration, what role they play, and what
    types of activities they are entitled to perform and what community
    resources are available to the collaboration. All of these factors
    may vary over time.

-   One must have available the means to perform the work of the
    collaboration: e.g., mechanisms for annotating and cataloging
    information so that it may be understood by members of the
    collaboration, electronic notebooks for sharing what processes had
    been followed, interfaces that make computing resources available
    for use, methods for discovering and initiating simulation codes,
    etc

Most previous work on collaboration tools has focused on the second
element to the exclusion of the first. Issues of structure are generally
handled in either a simplistic way or not at all. For example, both the
Diesel Combustion Collaboratory and Materials Microcharacterization
Collaboratory focused on mechanisms and basically ignored issues
relating to the evolution of membership and roles. Yet, as we explain
below, these issues [must]{.underline} be addressed in a comprehensive
manner before collaborative environments can be used to solve problems
of real consequence.

At the center of this problem of structure is determining the identity
of both participants and resources in a collaboration and, based on this
identity, determining the rights of the participant and resource. These
operations fall under the general heading of security technologies:
identity and role being implemented via authentication mechanisms, and
rights by authorization mechanisms \[38\]. Yet while many basic
mechanisms for authentication and authorization have been defined, the
issues of distribution, dynamics and scale discussed above complicate
their application to collaborative environments, posing major research
challenges that must be addressed.

In this proposal, we focus on this fundamental question of how to
structure collaborations. Our goal is to develop scalable, secure, and
usable methods and tools for defining and maintaining membership,
rights, and roles in group collaborations. Our concern is not with any
specific collaboration or collaboratory but rather with 1) understanding
the basic mechanisms required to structure a collaboration, 2)
developing infrastructure elements in the form of middleware services
and tools that implement the mechanisms, and 3) demonstrating the
validity of these methods within the context of a number of
demonstration collaboration environments. We tackle these questions from
the perspective of several year's extensive work with security
technologies that have found a large user community and been adopted
widely, the Grid Security Infrastructure (GSI). GSI also provides us
with a natural deployment and technology transfer vehicle for our work.

**Note 1**: The fundamental nature of the issues to be addressed here,
and the broad and continuing demand that we see from application and
tool development groups, leads us to propose this project as a five-year
project.

**Note 2**: The effort proposed here is not supported under any other
funding from DOE or elsewhere. The DARPA funding that supported initial
development of GSI terminates in FY2001; the DOE NGI funding that
supported initial policy work has terminated; and the DOE
Collaboratories work funding ("Collaboratory Infrastructure Framework")
that supported some initial work on DOE applications at ANL is being
recompeted under this call.

### Current State of Knowledge in Security and Policy Technologies for Group Collaboration

We review the "best practice" technologies available to address security
and policy issues in group collaborations, and use a critique of these
technologies to define the security and policy challenges we address in
this proposal.

The problems of authentication and authorization in distributed systems
have been extensively studied \[6, 26, 28, 39\]. Until recently, the
situation was simple if inadequate: most people used simple plaintext
passwords for authentication to remote sites, while more secure sites
used Kerberos \[40\]. Subsequently, technologies based on public key
mechanisms, such as Secure Shell (ssh), largely replaced the use of
plaintext passwords. However, while these technologies are quite
satisfactory for remote login to a single remote site, they do not
address fundamental requirements of collaboratories. For example,
Kerberos is difficult to deploy on all of the resources that may
participate in a large collaboration. But even if Kerberos were
ubiquitously deployed, it is further hindered by its requirement for
cross-realm trust agreements amongst all sites participating in the
collaboration, thus making it unsuitable for use by programs that use
resources at multiple sites in a coordinated fashion without repeated
authentication. Ssh is intended just for starting remote shells, and as
a result lacks an API that can be used to augment various collaborative
applications with the required security. Further, ssh\'s single sign-on
capabilities are limited, again due to its intended purpose.

More recently, there have been significant advances in security
technologies for distributed environments such as those required by the
types of collaborations that we are concerned with. Many of these
advances have occurred within the context of an emerging computing
environment that has come to be known as the Grid \[13\]. The Grid
concept is about *coordinated* *resource sharing and problem solving in
dynamic, multi-institutional virtual organizations* \[16\]. The sharing
that we are concerned with is not primarily file exchange but rather
direct access to computers, software, data, and other resources, as is
required by a range of collaborative problem-solving and
resource-brokering strategies emerging in industry, science, and
engineering. This sharing is, necessarily, highly controlled, with
resource providers and consumers defining clearly and carefully just
what is shared, who is allowed to share, and the conditions under which
sharing occurs. The resource sharing mechanisms provided by the Grid are
fundamental enabling technology for collaborative work environments.
Grid security technologies include the widely used Grid Security
Infrastructure (GSI, discussed in Section B.2.a below) as well as
systems such as CRISIS \[5\] and Legion \[47\].

The GSI system focuses primarily on authentication and message
protection \[11\] mechanisms, defining single sign-on algorithms and
protocols, cross-domain authentication protocols, and delegation
mechanisms \[18, 19, 22, 27\] for creating temporary credentials for
users and for processes executing on a user's behalf. In brief, a GSI
user first obtains (and must subsequently maintain secure) a public key
infrastructure (PKI) credential from a trusted entity called a
Certificate Authority (CA). The user can then:

-   Use their PKI credential to authenticate themselves once, after
    which they can access resources at multiple sites without repeated
    authentication. This [single sign on]{.underline} capability is
    critical to Collaboratory applications in which a single interaction
    may involve the coordinated use of resources at many locations.

-   Create temporary *proxy* credentials that can be passed to remote
    sites allowing operations to be performed at those remote sites on
    their behalf \[24, 44\]. This [delegation]{.underline} capability is
    also critical to Collaboratory applications, as it allows a program
    to operate remotely without compromising the user's permanent PKI
    credential.

Furthermore, individual sites can control what credentials are
acceptable and what Grid users are allowed to use local resources, a
capability that is similarly critical to the broad deployment of
Collaboratories and Grids:

-   What credentials are acceptable: a *policy file* at each site (or
    resource) indicates which CAs the site or resource is prepared to
    trust as a valid source of credentials. E.g., we might accept
    credentials issued by the ESnet CA, but not Podunk High School.

-   Who can do what: a *map file* at each site (or resource) indicates
    which users are allowed to access the resource(s), and maps each
    user to their local identity as known to the resource. E.g., a
    computer center might allow only "approved" users to access
    resources.

Another important technology, the Akenti system \[25, 42\], provides a
complementary set of capabilities concerned with authorization. Akenti
identifies a set of *stakeholders* with a resource, where each
stakeholder is allowed to place restrictions on who and how the resource
can be used. These restrictions are specified in terms of what
attributes a user must possess in order to perform specific requests. If
all of the stakeholders approve a request, then the request may be
performed. Akenti makes extensive use of PKI certificates for encoding
both user attributes as well as usage conditions. Akenti has been used
by the Diesel Combustion Collaboratory to control access to
collaboratory resources, such as simulation codes and data provided by
web servers. We discuss Akenti further in Section B.3.a.1 below.

### Our Proposal: A New Group Security and Policy Infrastructure

GSI's combination of single sign on, delegation, and local control over
policy represents a significant step forward relative to other
technologies: once a credential is obtained and policy and map files set
up, a user can use distributed resources in extremely flexible ways.
However, the unique characteristics of group collaboration introduce
additional demands in four areas, which we now review in general terms,
along with our proposed approach to addressing them; technical details
are provided in Section B.3.

*It must be straightforward to change collaboration membership.*
Membership tends to be highly dynamic in scientific collaborations. For
example, a researcher might want to induct a temporary visitor as an
"authorized" user of a remote resource. Another collaboration member
might want to enable her class to act as "observers" of an experiment.
Yet in GSI as defined above, "membership" is nowhere explicitly defined;
instead, it is implicit in the policy and map files at each site, which
are not easy to change. Furthermore, the (typically heavyweight)
operation of obtaining a PKI credential represents a significant
obstacle to rapid introduction of new members. These and other issues
combine to make management of membership and roles unacceptably unwieldy
in today's security solutions.

Building on GSI mechanisms, we will pioneer new techniques that reduce
dramatically the costs associated with group membership operations, so
that:

-   The cost of acquiring credentials, and the cost of managing
    credentials once acquired, are reduced dramatically. (The specific
    mechanisms that we will develop with this goal in mind include:
    Online credential generation, online credential repositories,
    support for multiple CAs.)

-   Authority for managing group membership can easily be re-assigned,
    so that for example a resource site can delegate this authority to
    an entity that implements group policies. (Group membership
    service.)

*It must be straightforward to add new resources to a collaboration.* As
the membership and goals of a collaboration change, so do the associated
resources. For example, a new user may integrate new resources. A new
project may require that certain datasets be made momentarily available
to an existing collaboration. The issues here are different from those
associated with membership, because authentication and authorization
mechanisms at a resource site must interface with local security
solutions.

Building on GSI mechanisms, we will develop new techniques that reduce
dramatically the costs associated with incorporating new resources into
collaborations, so that:

-   The cost of acquiring credentials for resources ("host
    certificates") are reduced dramatically. (Subordinate Certificate
    Authorities for Domains.)

-   We support integration with a wide variety of local security
    solutions, including AFS.

*It must be straightforward to create and change the role and associated
privileges of both resources and participants*. Not only membership but
also roles tend to change over time. For example, a new user is
progressively granted additional privileges as they gain experience;
another user "publishes" a private file, making it available to some of
her colleagues. Again, we face the difficulty that roles are nowhere
explicit in the GSI environment, but are instead implicit in the set of
policy and map files maintained by collaboration participants. In
addition, GSI's delegation mechanisms do not allow a user to limit what
"role" he wants a program to play.

Building again on GSI mechanisms, we will pioneer new techniques that
reduce dramatically the complexity of maintaining and modifying roles,
and increase substantially the range of roles that can be expressed, so
that:

-   Resource sites can delegate to others the authority to define roles
    and group membership, saying, for example, "I'll trust anyone your
    collaboration says is ok." (Community authorization services, and
    associated mechanisms and tools)

-   Users can exert tight control over what actions a process they
    create is allowed to perform at remote locations. (Restricted
    delegation, and associated mechanisms and tools.)

*Security services for structuring a collaboration must be integrated
into the overall workflow of the collaboration*. Security technologies
have a reputation for being complex and opaque, and developers of
collaboration software are often reluctant to adopt them for this
reason---or, alternatively, use them incorrectly in ways that compromise
security. It is hence critical that research advances and security
solutions such as those listed above be instantiated into a framework
that makes them easily useable within a wide range of collaborative
tools.

Building again on GSI mechanisms, we will improve the security tools
that developers have at their disposal, so that:

-   They can use high quality, feature rich, standards based, security
    APIs. (Track and extend standards, Independent Data Unit support,
    flexible application of message protection, and improved error
    reporting and logging.)

-   Security is automatically, and transparently enabled in the high
    level development tools that are often used. (Integration into
    development frameworks.)

### Contributions

We plan four distinct classes of contributions from the proposed work:

1.  [Technical innovations]{.underline}. We will advance knowledge in
    security and policy technologies via the definition and evaluation
    of new approaches to authentication, PKI management, authorization,
    policy definition, policy enforcement, and other key technical
    problems.

2.  [High-quality software]{.underline}. We will incorporate both our
    new techniques and "best of breed" techniques from other sources
    into high-quality software toolkits and libraries. We will leverage
    our leadership position in Grid security software to achieve wide
    dissemination and uptake of this software.

3.  [Innovative application concepts]{.underline}. We will work with DOE
    application groups to apply our security technologies in new and
    challenging ways, hence both contributing to the development of
    secure, workable DOE Collaboratory applications and obtaining
    guidance on our technology R&D directions.

4.  [Standards]{.underline}. We will continue to work actively with the
    GGF and IETF to transition new security ideas into standards
    wherever possible, and with industry to achieve adoption of those
    standards in products.

We believe that this four-pronged approach will allow us to achieve a
substantial and sustained impact on the practice of security and policy,
and the evolution of Collaboratory architectures. As illustrated in
Figure 1, we see this project making central contributions to an
emerging consensus-based Grid Architecture \[16\] and providing
essential services to a range of important DOE application projects.

![](media/image1.wmf){width="5.959722222222222in" height="1.725in"}

Figure 1: Grid architecture (on the left) and the role of the Security
and Policy for Group Collaboration project and its relationships with
other efforts (on the right). Shaded boxes represent complementary
proposals submitted to the SciDAC program.

## Preliminary Studies

During the past three years, we have conducted preliminary studies
focused on the creation, deployment, application, and evaluation of
usable PKI-based authentication and authorization technologies, and on
investigations of policy mechanisms.

### Scalable Authentication: The Grid Security Infrastructure

Over the past several years, Argonne National Laboratory (ANL) and the
University of Southern California (USC) have pioneered a new technology
that has proved tremendously powerful, useful, and influential. Our
Globus Toolkit \[12\] provides key Grid technologies that have been
adopted in such projects as the DOE-funded Particle Physics Data Grid
(www.ppdg.net), Earth System Grid, and MPICH-G2 \[10\] efforts; the DOE
ASCI DISCOM project \[4\]; the European Union Data Grid project; and the
NSF National Technology Grid, Grid Physics Network (www.griphyn.org),
Grid Application Development Software, and Network for Earthquake
Engineering Simulation (www.neesgrid.org) projects, as well as many
smaller-scale tool development efforts.

While the Globus Toolkit provides numerous important capabilities (e.g.,
remote access to computation, data movement, directory services,
resource brokering, co-allocation, quality of service), the underpinning
to all of these capabilities is a sophisticated security infrastructure.
The Globus Toolkit's public key infrastructure (PKI)-based Grid Security
Infrastructure (GSI) \[8, 15, 43\] has emerged as an essential
middleware component that has been integrated into many tools. GSI
shares with SSH and Kerberos the distinction of being a security
solution that has passed security review and been deployed at many
sites. As we explained above, GSI is characterized by its support for
single sign-on, delegation, and local control of site policies.

Our several years of experience with development, deployment, and
application of GSI have taught us much about what is needed in a
practical security solution for collaboratory applications. In
particular we have learned the importance of:

-   Simple, standards-based security solutions that are easily
    understood and reviewed by security personnel. Our success here is
    evidenced by the wide acceptance that we have gained for GSI
    technologies, at laboratories around the world.

-   Simple, standards-based interfaces and tools to facilitate
    integration of security into tools and applications. Here we have
    produced GSS-API \[30\] interfaces and various "helper" functions,
    as well as our security-enabled GlobusIO library. Our success here
    is evidenced by the wide range of GSI-enabled systems, ranging from
    FTP and SSH servers to Condor and Message Passing Interface
    implementations.

-   Working closely with application projects to understand their
    requirements. Our security solutions are in daily use by diverse
    application communities, and this experience motivates many of the
    new ideas to be developed in this project.

-   Standardizing new features in order to gain broad acceptance. The
    single sign-on and delegation capabilities of GSI are based on X.509
    Impersonation Certificates and the TLS Delegation Protocol, both of
    which are being standardized within the Global Grid Forum and the
    Internet Engineering Task Force by PI Tuecke and other senior
    personnel of this proposal.

GSI can be viewed as an experiment in Grid security. It has clearly been
tremendously successful. However, as discussed above, the GSI focuses
primarily on user/resource and process/process interactions. While this
is a necessary prerequisite, it falls short, as explained above, when we
turn to group collaboration. The base of understanding and technology
developed up to now provides us with a tremendous opportunity that we
can exploit with a focused effort.

### Investigations of Policy

Within the context of DOE NGI projects "Diplomat: Policy-Based Resource
Management for Next-Generation Internet Applications" and "Earth System
Grid", we have conducted three prototyping activities in order to gain
an understanding issues of policy specification and enforcement in
distributed environments.

In the first of these activities, we investigated how one entity can
delegate a subset of its rights to another entity in a general way. Such
restricted delegation is important in collaborative environments as it
provides a mechanism to deal with the dynamic membership of a
collaboration as rights can be delegated to new members as they are
added to the collaboration. In our prototype, we used Condor's ClassAds
\[33\] as a restriction policy language, and the Matchmaker as a policy
evaluation engine. We augmented GSI's X.509 proxy certificates to carry
restriction policy represented as a classified ad (ClassAd), which is
essentially a set of attribute/value pairs. For example, we might create
a certificate with a restriction that could only be used to start or
monitor a job on a particular host by specifying a host attribute. We
then augmented Globus resource management services to check the policy
carried by the certificate prior to filling a resource management
request. By using the Matchmaker library included as part of Condor, the
resource was able to ensure that the restrictions specified in the
certificate matched the attributes defined by the resource. We note that
this prototype differs from Akenti in that the delegated proxy
certificate carries the policy being enforced, not the resource.

An important question that arose from this work is that of how to name
the points at which policy is to be evaluated. In order to express a
restriction policy, one must be able to name the policy evaluation
points at which the policy will apply. This is a non-trivial problem, as
it effectively requires a globally unique naming scheme, with a priori
naming of dynamic policy evaluation points. We have developed initial
ideas on this topic, which we will expand in this project.

A second prototyping project, motivated by the preceding study, explored
the question of how to interface to policy mechanisms. This is germane
due to our requirement for integration of security services into
collaborative environments. Our preliminary work in this area has
focused on the design and prototype implementation of the Generic
Authorization and Access Control API (GAA) \[36, 37\]. Our
implementation of GAA enables a range of different policy languages and
engines to be plugged into the generic framework and has been designed
so as to interface with the authentication capabilities provided by the
GSI. The GAA is currently being pursued as an experimental standard
within the IETF.

The final aspect of our previous work addresses issues of global policy
specification. We have designed a *Community Authorization Service*
(CAS) that allows a user to request an operation be performed on behalf
of a community. This service is based on the concept of capabilities,
and on resource providers delegating to communities the authority to
define their own membership and community access control policies. A CAS
server for each community delegates rights to a requestor based on the
request and the requestors role within the community. This work is still
quite preliminary and is currently only being used to address issues of
file access control. However, we believe that the combination of CAS
with restricted delegation and standard interfaces to policy engines
provides a solution that addresses significant aspects of the specified
requirements for collaborative environment.

## Research Design and Methods

In section A.1.c, we introduced four fundamental issues that must be
addressed by a security and policy infrastructure to meet the
requirements of collaborative applications. We now provide detailed
technical discussion of what we will do to address each of these issues,
introducing the solutions we propose to research and develop under this
effort to meet these challenges, and providing details about these
proposed solutions. We also describe our specific tasks, milestones, and
deliverables during the life of this project.

### Roles, Privileges, and Policy

We talk first about the third of the issues raised above, namely
enabling the *creation and changing of roles and associated privileges
of both resources and participants.* Collaborative applications require
support for managing or evaluating the authorization policies of the
collaboration. Specific requirements include:

1)  Support for policies based on identities, roles, and group
    membership.

2)  Scalability to support collaborations with thousands of
    geographically and organizationally dispersed users and resources,
    and with billions of objects to be protected.

3)  Applicability in a unified fashion to diverse types of resources,
    including computers, storage, networks, and scientific instruments.

4)  Fine grained control over delegation of authorization rights. A
    collaboration member may have many processes or agents running on
    their behalf throughout the collaboration. In order to protect
    collaboration users and resources from accidental or malicious
    misuse of these delegated privileges, techniques are required for
    restricting the delegated privileges.

Based on our previous experience with GSI, policy, and a simple CAS,
under this research project we will design and implement a policy
management solution for collaborative applications. This solution will
include new components, along with extensions to GSI, including:

1)  A generalized [Community Authorization Service]{.underline} (CAS),
    which is able to handle diverse resource types, manage complex
    policies describing access to, and use of, a collaboration's
    resources, and scale to large collaborations.

2)  [Restricted delegation]{.underline} extensions to GSI, to enable the
    fine-grained delegation required by the generalized CAS.

3)  [Delegation tracing]{.underline} extensions to GSI, to enable
    further logging and control over the use of delegated credentials.

4)  Implement and compare multiple [policy languages]{.underline}, for
    expressing policies required by collaborations.

5)  Design and implement a [policy evaluation API]{.underline} that can
    be used by developers of tools and applications to add policy
    evaluation capabilities to their programs, for example for
    authorization.

6)  Design and implement tools for distributing and managing
    [accounting]{.underline} information, and allow this accounting
    information to be factored into the policies of a collaboration.

7)  Since users of a collaboration may have choices between use of
    different resources with different policies, [policy based resource
    selection]{.underline} techniques and tools will be developed to
    enable decisions to be made about which are the \"best\" resources
    to use.

Together, these new capabilities will provide a sophisticated yet
practical toolkit for managing roles, privilege, and policy in
collaboratory settings. We provide additional details on each of these
topics in the following.

#### Community Authorization Service

Consider the following situation: a collection of resource sites each
decides to make some amount of storage (or bandwidth or computing)
available to a high energy physics consortium. Where should decisions be
made concerning who in the consortium gets to use these resources? It
makes no sense for such fine-grained authorization decisions to be made
by the resource owners: they may know nothing about consortium's
policies or even membership. Instead, the resource owner needs to be
able to delegate authority for managing the resources that it has made
available to the community to a "community representative." This third
party can then dole out subsets of the allocated resources to community
members, based on community specific policies. These policies might
determine, for example, how much of a resource can be used by different
users. Or, in the case of a disk resource, policies might govern who can
write and read the disk.

We believe that flexible and secure mechanisms of this sort can be built
via relatively simple extensions to our Community Authorization Service
(CAS). First proposed \[35\], the basic idea is that the CAS manages the
policies that govern access to a collaboration's resources, granting
users capabilities conforming to these policies, which users can then
present to obtain access to resources. A resource owner delegates
authority by agreeing to accept these capabilities. GSI authentication
and delegation extensions, as described below, are also required to
enable the CAS to grant fine-grained access to community users.

A CAS operates as follows:

1)  The CAS has its own GSI *Community Identity Certificate* (*CIC*),
    which is a normal X.509 identity certificate signed by a CA that
    uniquely identifies that CAS to the users and resources. A resource
    grants access to a community by creating a local account to which
    the CIC maps. For example, to grant storage to a community, the
    storage resource administrator would configure the resource with a
    local account with permission to access the desired local storage,
    perhaps using quotas to constrain the size of the block, and then
    maps the CIC to that local account. The resource administrator then
    registers this account with CAS.

2)  Before a community user is able to gain access to the resource, that
    user must register with CAS. Registration involves supplying CAS
    with the user\'s credentials, and proving to a CAS administrator
    that the user should be part of the community. (Alternatively, a CAS
    could be configured to refer to a separate group membership
    server---perhaps an Akenti server---for this purpose.)

3)  CAS maintains an access control database that specifies who can
    access which community resources. Roles and groups can be used to
    structure the information in this database.

4)  As depicted in Figure 2, when a user wants to use a resource, that
    user authenticates with CAS, and tells CAS what operations it wants
    to perform on which resources. If the CAS access control database
    allows the request, then CAS will delegate back to the user a CIC
    Impersonation Certificate containing restrictions that allow this
    delegated CIC credential be used only for the stated purpose. In
    other words, the CAS uses GSI restricted Impersonation Certificates
    to grant a capability (in the operating system sense \[34\]) to the
    user.

5)  The user can then authenticate directly with the resource using the
    CIC\'s delegated credential. So the resource sees the request as if
    it were coming from the community\'s CIC. The resource also checks
    all requested operations against the restrictions carried by the
    delegated CIC. The delegation tracing extensions are important here
    as they provide a means for resource provides to identify the actual
    end user to whom the delegated CIC certificate was issued.

![](media/image2.wmf)

Figure 2: *Community Authorization Service (CAS)*. In order to gain
access to a CAS managed community resource, a user must first acquire a
capability from CAS, which is then used to authenticate to the resource.
Steps 3 and 4 can be repeated using the same capability until it
expires.

During the first year of the project, we will develop a basic CAS server
that supports simple group-based access control policies. In subsequent
years of the project, we will extend CAS functionality to support: more
scalable approaches for structuring CAS policies, including user roles,
resource groups, hierarchies of users, resources, and policies, etc.;
complex access control policies; prioritization, preemption, and
revocation of access; and integration of accounting information into the
policy decisions. Throughout the project we will apply and evaluate CAS
in the context of Data Grid applications, Access Grid applications,
bandwidth brokers, etc.---that is, the very user communities that have
motivated this project.

Some of the research questions that we expect to encounter during this
work include: What are appropriate policy languages for expressing
access control restrictions? How to consistently name the policy
evaluation points across varying resource types, to enable the
consistent expression of policy across these varying resource types?
What protocol should be used to request a capability from a CAS? How to
distribute and/or replicate a CAS for scalability, performance, and/or
reliability? How to scale the access control database to allow for
fine-grained access by large numbers of users to large numbers of
objects maintained on the resources?

*Comparison with Akenti*: Our capability-based CAS technology addresses
similar---but not identical---problems to the LBNL Akenti system \[25,
42\]. However, there are important differences in focus and approach. In
terms of focus, one major difference is that we are interested primarily
in supporting the centralized specification of community policies
governing collections of resources, such as who is allowed to read and
write replicated data in a Data Grid; Akenti, on the other hand, is
concerned primarily with expressing the use conditions that govern
access to individual resources. This different focus leads us to adopt
different technical approaches. For example, in Akenti every resource
must know about and trust the CA of every potential user, which seems to
us to be a significant obstacle to scalability. In CAS, a CAS server
must know about and trust the CA of every user, but individual resources
need know about only the CAS' CA. Similarly, the CAS server provides a
centralized location at which can be collected the various use
conditions that govern access to a resource; once these are verified,
the resource needs deal only with a single capability, rather than a
potentially large number of use conditions. Finally, a CAS capability
can in principle encode the right to perform a series of related
operations, which has the potential to improve scalability. We believe
that for these reasons CAS represents an interesting alternative---and
most likely complementary (e.g., a CAS could refer group membership to
an Akenti server, and an Akenti-based system could be extended to
support use conditions expressed in terms of capabilities)---technology
to Akenti. We are in constant contact with the Akenti group and will
work with them closely to ensure that our technologies move forward in a
coordinated fashion.

#### Restricted Delegation

A fundamental aspect of a security system for dynamic collaborations is
the ability for one entity to delegate the right to act on its behalf to
another entity \[18, 19, 22, 27\]. For example, in issuing a capability
to a user, the CAS is delegating to the user the right to access
resources on behalf of the CAS. And in starting a remote process, a user
delegates to that process the right to act on behalf of the user, for
example, to read the user\'s files and create additional processes on
the user\'s behalf. However, when an entity delegates rights, it is
inherently giving up some of its control over its resources to the other
entity. In order to limit the consequences of accidental or malicious
misuse of the delegated rights, an entity usually wants to restrict the
delegation to include the minimum necessary rights. For example, CAS may
wish to delegate the right only to read a particular file, and a user
may wish to restrict a remote process only to create additional
processes in specified locations.

GSI currently supports only a simple form of restricted delegation,
through the use of Impersonation Certificates \[44\]. Carrying forward
the previously described research that was started under past funding
(Section B.2.b), we will extend GSI\'s restricted delegation to support
much richer restriction policies. This new functionality will be used,
most notably, by CAS to place fine-grained restrictions on the
capabilities that it grants to users. But there are many other uses of
restricted delegation throughout Grid computing. For example, we can
restrict a super-scheduler only to start jobs in particular locations,
and restrict started processes to have access only to the resources that
the process requires to perform its function. We hope to explore these
and other applications as well.

This work will involve R&D in: defining extensions to X.509
Impersonation Certificates to carry the restriction policies; defining,
evaluating, and comparing restriction policy languages, including how
the policy behaves through multiple levels of delegation \[23\];
defining a unified way of naming the resources and objects to which the
restriction apply; extending GSS-API \[30, 46\] to allow applications to
add restriction policies when performing delegation, and access the
restriction policies from the credentials used for authentication;
implementing tools to evaluate restriction policies; and validating the
approach through use in CAS, remote job creation, etc.

#### Delegation Tracing

GSI Impersonation Certificates optionally allow for one entity that has
been delegated rights to further delegate those rights to another
entity. Such a capability is critical in a collaborative application.
For example, a user may wish to obtain a capability (i.e., a delegated
credential) from CAS, and then further delegate this capability to a
process that the user creates on a remote computer. This results in
delegation chains that may pass through resources in different
organizations. For example, entity A may delegate to entity B, who may
in turn delegate to entity C, etc. In evaluating such a delegated
credential, the authorizing party may want to know what entities the
delegated certificate passed through. For example, it way want to log
this information for audit purposes, or it may want to disallow
certificates that were delegated through some site that is knows was
compromised.

We will: extend X.509 Impersonation Certificates (ICs) to contain
additional information about the entities involved in the delegation of
the IC; extend GSS-API to allow this delegation trace information to be
retrieved by an application; extend the authorization policy language
evaluation to allow for this trace information to be used; and build
tools to log and audit the trace information.

#### Policy Languages

All of this authorization work hinges on the ability to define
appropriate policy languages, which have properties such as
expressivity, clarity, and provability. The definition of such policy
languages is a fertile area of research in the security community \[6,
7, 33, 37\]. Within this project, we will evaluate and compare various
existing policy languages for their applicability to the collaborative
applications being addressed by this project. Wherever possible, other
components of the our security and policy system will be built to be
neutral to the actual language employed, so that we can evolve over time
as new requirements are understood, and as the policy languages
themselves evolve.

#### Policy Evaluation API & SDK

Policies need to be evaluated at various points in a collaboratory. CAS
receives a capability requests from users, which must be evaluated to
determine if the users are authorized to perform the requested
operations, and thus if capabilities should be returned. Resources are
accessed using Impersonation Certificates containing restriction
policies, which must be evaluated by the resource to determine if the
requested operation is authorized. Users must evaluate resource policies
to determine whether to use a given resource, or to decide which
resources are best for their needs. Defining and implementing a common
API for evaluating policies would greatly assist the developers of these
various tools. Within this project, we will evaluate existing APIs for
this purpose \[1, 37\], and if necessary define a new one. Once we
choose an API, we will implement this as part of the Globus Toolkit.

#### Accounting

Accounting is the sibling of authentication and authorization. After a
resource has established the identity of a requestor (authentication),
and has decided to grant the resource request to that identity
(authorization), the resource will usually want to keep track of how
much of the resource the requestor consumed (accounting). Such
accounting information may be used for billing purposes, and/or to
constrain how much of a resource the requestor consumes.

Within the sort of collaboration addressed by this proposal, accounting
becomes a distributed problem. It is not sufficient that each resource
simply keep track of its own usage. Rather, a community may want to keep
track of how many community resources various members consume, and
perhaps restrict the usage of community resources by various members.
These requirements demand standard methods for describing resource usage
and standard protocols for distributing usage information.

Since CAS is the community authority that grants access to resources, it
must have access to all community accounting information in order to
allow the use of policies that restrict resource usage based on previous
consumption. However, all resource consumption is authenticated using a
CAS issued capability, which hinders the ability of the resource to tie
the accounting information back to a particular user directly. Further,
CAS may wish to issues a capability that allows for only limited
resource consumption by its holder. To address these issues, we propose
to tag each CAS capability with a Globally Unique ID (GUID), to be used
in two ways:

1)  Each resource logs consumption based on the GUID of the capability
    used to access the resource. By comparing the GUIDs in the resource
    accounting records with a CAS log of the GUIDs it issued to users, a
    complete picture of usage of community resources by its members can
    be reconstructed. Further, CAS can then be configured to use this
    resource consumption information in its access control policies.

2)  In order to constrain a particular capability to a limited amount of
    resource consumption, CAS can include the resource consumption
    policy into the capability. Resources can then track resource
    consumption for each GUID, and use this information to enforce the
    consumption policy attached to the capability.

Over the course of this project, we will gradually add these accounting
related capabilities to the system. We will start by defining an X.509
Impersonation Certificate extension to carry the GUID in the CAS issued
capability. Next, we will define GSS-API extensions for extracting this
GUID from a capability credential that is used to authenticate with a
resource. Then, we will define tools for allowing resources to log
usage, and protocols and tools for distributing this accounting
information back to the community. Next, we will implement mechanisms
that allow CAS to make access control decisions based on resource usage.
Finally, we will define the resource consumption policy language that
CAS will embed into capabilities, and implement tools to assist
resources in enforcing such policies.

Research questions addressed during this process include: What is the
best way to carry and extract the GUID from a capability? How to build a
scalable protocol for distributing accounting information? What access
control policy language extensions are needed to enable decisions based
on resource usage? What should be the policy language to be embedded in
capabilities for expressing resource consumption restrictions?

#### Policy-Based Resource Selection

A distinguishing feature of many advanced collaboratory applications is
that they select from and use resources from multiple administrative
domains. Yet the "best" choice depends on not only physical
characteristics of the individual systems but also the policies that
govern access to those systems. In addition, specialized resources such
as archival storage, supercomputers, and display devices used by
high-end applications of interest to DOE often also involve complex
policies. Experience shows that a major obstacle to the effective
development and use of advanced applications is the diverse policies
that govern resource use at different sites and in connecting networks.

We will hence develop a GSI-based policy-based resource management
architecture that allows resource owner and resource consumer policies
to be specified and consulted seamlessly at any stage during resource
discovery, allocation, and management. Our implementation will build on
broadly deployed security, resource discovery, and resource management
mechanisms provided by the Globus toolkit and Condor system \[31, 32\],
and will incorporate new policy language, policy template, policy
checking, and policy publication mechanisms to be developed in this
project. Interfaces to existing policy engines such as access control
lists and Akenti use-conditions will allow verification of policy
elements, while policy-enabled managers for differentiated services or
integrated services networks, data archives, supercomputer schedulers,
and disk caches (building, for example, on GARA mechanisms \[14, 17\])
will enable interesting application experiments.

This activity will build on a solid technology base and promising
results obtained under DOE NGI FY99-00 funding, as discussed in Section
B.2.b. In that project, we extended our resource management architecture
with Generic Authorization and Access control interfaces, hence laying
the groundwork for a highly flexible policy framework in which various
local and group policies can be invoked when making local authorization
and resource management decisions*.*

### Authentication Procedures to Support Dynamic Collaboration Membership

We now turn to the first of the issues raised in Section B.1.c, namely
technologies designed to enable rapid changes to collaboration
membership. We review the three primary steps involved in joining a
secure collaboration, point out "inefficiencies" and "obstacles" that
can arise during each step, and outline the new approaches that we
propose for overcoming these difficulties.

In order to join a secure collaboration, users and administrators must
perform the following operations.

*Credential acquisition*: Before a collaboratory user is able to
interact with other collaboratory users and resources, the user must
acquire one or more *identity credentials*. This credential is used
subsequently to identify that user to other participants and resources
of the collaboration. In a PKI based security system, such as GSI, this
identity credential takes the form of an X.509 certificate and its
associated public/private keys, which the user must have signed by a
Certificate Authority (CA). Existing approaches to identity credential
acquisition have the following problems, which this project will
address:

1)  The process of obtaining this credential from a Certificate
    Authority (CA) is generally a time consuming and bothersome process
    for the user, due to the Registration Authority checks that are
    generally performed by the CA. The administration and operation of
    the CA itself also requires considerable effort, again mostly due to
    the RA functions of the CA. The time delay required to get a
    credential from a CA is often measured in days, and often requires
    offline checking of, for example, the user\'s passport. However, our
    experience \[8\] has shown that the RA check performed by the CA is
    often redundant and unnecessary, since the collaboration
    participants will in any case perform the necessary identity checks
    to determine appropriate membership of the collaboration. In other
    words, since collaborations already perform an RA check to admit the
    user to the collaboration, there is no need to perform a second RA
    check as part of the credential acquisition from a CA. This insight
    leads us to propose a new approach based on the use of a lightweight
    *Online CA* that can issue credentials instantaneously, along with
    support in the CAS to help facilitate the identity checking that
    such a collaboratory will use instead.

2)  A user may already have a perfectly reasonable identity in the form
    of his or her local site login name. Managing a second identity in
    the form of an X.509 credential is a nuisance and error prone. We
    will again address this problem with the Online CA, which will allow
    a site\'s administrator to create a lightweight CA that issues
    identity credentials to users of that site, based on the user\'s
    proof of login to the site. Our collaborators at Michigan University
    have already explored this concept via a Kerberos-to-PKI gateway.

3)  In many situations, acquiring a credential from a traditional CA
    will be unavoidable, and even appropriate. However, once the X.509
    certificate is obtained, the user typically must store that
    credential on disk or smartcard, and take care to protect and not
    lose the credential\'s private key, else face another lengthy
    process of replacing it. This burden has proven to be a major
    obstacle to acceptance of PKI-based security systems by average
    users. We will address this problem through the development of an
    *Online* *Credential Repository*. Instead of having to worry about
    the day-to-day management and protection of his or her private key,
    the user can instead place the credential and keys into a secure
    repository, which is run by some other trusted party such as the
    user\'s site administrators. The user can then requests an
    impersonation credential from the repository, as necessary, while
    keeping his or her valuable identity credential safely locked up
    within the repository. Again, we have some experience with this
    concept in the form of the so-called "MyProxy" server that we
    designed in collaboration with a group of Portal developers.

*Obtaining authorization rights from resources*: Having acquired an
identity, the next obstacle faced by a user is obtaining the privileges
necessary to access resources that are part of the collaboration. This
becomes an increasingly onerous task as the number of resources grows,
as the user currently must often obtain privileges for each resource
independently. Likewise, as the number of users grows, it becomes
increasingly onerous on resource administrators to manage authorization
for all of these users. We will address these scalability issues through
development of the *Community Authorization Service (CAS)*, as described
above, which allows a user to obtain rights to use collaboratory
resources through a single registration with the CAS.

*Login (single sign-on)*: Before a user can authenticate into, and
participate in, a collaboratory, that user must login. GSI already
supports easy to use, single sign-on capabilities, as long as the user
has just one credential, and that credential is available on (i.e.,
encrypted on the disk of) the machine from which the login operation is
performed. We will address the following limitations in this approach:

1)  With the current proliferation of CAs, it will be inevitable that
    users will have multiple credentials signed by different CAs. This
    can be cumbersome and error prone for users to manage, for example
    to figure out which credential to use in a given circumstance. We
    will address this problem by developing tools for *managing multiple
    credentials*, and for choosing which credentials to be used in which
    circumstances.

2)  To assist in making credentials available to the user, regardless of
    that user\'s location relative to the credential, we will integrate
    this multiple credential handling with the Online Credential
    Repository and Online CA.

3)  Collaborations that require a high degree of security may demand
    *multi-factor authentication* in order to login. While GSI already
    has prototype support for cryptographic smartcards, this support
    will be improved, expanded to support more devices such as biometric
    readers, and made available as part of the standard GSI release.

#### Online Certificate Authority

A traditional Certificate Authority (CA) does three things: it assigns a
unique name or identity to the certificate requester, it binds that name
to the requester\'s key pair by signing the request, and it binds that
name to a real-world entity through its Registration Authority (RA)
process. While the first two steps are straightforward and easily
automated, the RA process is cumbersome to both users and CA
administrators, because it typically requires non-automated steps such
as checking the user\'s passport to validate the real-world entity. The
purpose of the RA process is two-fold: to enable re-issuance of the name
bound to a new key in the event of loss or compromise of the previous
key; and to allow for the name to contain semantic content that can be
evaluated by some other party based on its trust of the CA.

Our experience has shown that there are numerous situations where this
onerous, off-line RA process is not necessary. For example:

1)  If the user already has an existing identity in the form of a site
    login, this existing identity can be used to automate the RA
    process. In other words, the user can exploit his or her existing
    site login in order to automatically get an X.509 identity
    certificate that is signed by the site\'s CA.

2)  In many collaborations, the collaborative community runs its own
    Registration Authority process before admitting a user to the
    community. Therefore, there is no need for the CA issued name to
    contain any semantic content: the community will perform the
    necessary checks to allow an arbitrary name to be used by the user
    to gain access to the collaboration. Further, re-issuance of the
    name can be handled by the community RA with little additional
    overhead. Therefore, there is no need for the CA to perform any RA
    function. Rather, the CA just needs to guarantee that the name is
    unique, and only bound to the correct key pair. In this situation, a
    very lightweight CA can be run, which automatically issues uniquely
    named certificates.

We will develop a lightweight Online CA, which can address these two
situations. This Online CA is a service, with an associated client, that
allows for automatic issuance of identity certificates. This Online CA
can be set up to handle either the first case above, by requiring
authentication by the client using site login mechanisms (e.g.,
Kerberos, name/password, one-time-password, etc), or the second case
above, by not requiring any user authentication. In both cases, the
Online CA performs checks to guarantee that the name issued to the
requester is unique.

We do not believe that this Online CA will replace traditional CAs.
Rather, it will instead fill an important niche, by enabling the use of
security by communities for whom the high costs and burdens of a
traditional CA are unnecessarily onerous.

#### Online Credential Repository

Traditional PKI-based security systems store user identity credentials
on disk, encrypted with a password. Our experience with GSI\'s use of
this approach has shown that most users dislike managing their own
identity credentials in this manner. Doing so is error prone (and thus
less secure) and sometimes results in the credentials not being
available from where they are needed by the user.

We will address this problem by developing an online certificate
repository. This repository is a service that holds the user\'s X.509
identity certificate and private key. When the user needs to use the
credential, a client is used to authenticate with the repository using
local site security (e.g., Kerberos), name/password, one-time-password,
etc. In response, the repository will use the user\'s credential to
delegate an Impersonation Credential back to the client. This IC can
then be used to gain access to the community services.

As we noted above, these ideas have been explored in prototype form in
the MyProxy system. Our work here will build on, robustify, and extend
that work. We will also track and participate in the IETF SACRED working
group \[3\], which is addressing a similar problem.

#### Support for Multiple User Credentials

With the proliferation of CA\'s, users will likely have different
credentials for different purposes. In fact, the act of getting a
capability cert from CAS is basically that of obtaining another (limited
purpose) credential that the user must manage. We will develop tools,
and extend the online credential repository, to support handling of
multiple user credentials.

Aside from the database issues of managing multiple credentials, two
other issues must be addresses:

1)  When a user with multiple credentials wishes to gain access to a
    resource, the user must determine which credential to use to
    authenticate with the resource. The choice may be made from a
    database of identity credentials held by the user, or perhaps by
    using an existing identity credential to requests an appropriate
    capability credential from CAS, or some other identity credential
    from a credential repository. We will develop tools and methods to
    assist in this selection.

2)  Suppose the user wants to start a remote process, and delegate to
    that process rights to access various other resources, each of which
    requires a different delegated credential. We will develop tools and
    methods to assist clients in determining exactly which credentials
    need to be delegated.

#### Multi-Factor Authentication

Collaborations that require a high degree of security may demand
multi-factor authentication. While GSI already has prototype support for
smartcards which was developed under past funding, this support will be
improved, expanded to support more devices such as biometric readers,
and made available as part of the standard GSI release.

### Managing Dynamic Resource Sets 

We now turn to the second issue raised in Section B.1.c, namely enabling
addition of new resources to a collaboration. Resource providers who
want to contribute (or sell) resources to a collaboration are presented
with the following challenges:

1)  *Credential acquisition*: Before a resource can be contributed to a
    collaboration, the resource administrator must acquire a *host
    credential* for the resource, which is used to identify the resource
    to collaboration members. If an administrator must obtain
    credentials for many resources, the current approach of interacting
    with a CA to obtain each host credential separately can be an
    onerous task. We will address this issue by adding support to GSI
    for *Subordinate Certificate Authorities for Domains*, whereby the
    CA issues to the administrator of a set of resources a single
    subordinate CA credential, which in turn allows the administrator to
    generate the required host credentials without further interaction
    with the CA.

2)  *Integration into local system*: The Grid Security Infrastructure
    must integrate into local security solutions, such as Kerberos and
    AFS. While GSI is already fairly adept in this regard, improvements
    are needed to reduce this barrier to acceptance by resource
    providers.

3)  *Establishing authorization policies*: In order for users of the
    collaboration to use the resource, the resource provider must set up
    appropriate authorization policies. This is currently a cumbersome
    process for large collaborations, as per-user authorization policies
    must be maintained on each resource. We will address this
    scalability issue through the development of the *Community
    Authorization Service* (CAS), as described above, which allows a
    resource administrator to easily grant bulk access to a community,
    while letting a community service handle the fine grained
    authorization and prioritization within its CAS server.

#### Subordinate Certificate Authorities for Domains

Suppose that a resource provider has many individual resources that it
wants to make available to a collaboration. Currently that provider must
obtain a *host credential* separately from a CA for each individual
resource. Unfortunately, the Online CA approach described above cannot
be used to automate this process, because the name of the host
credential must contain semantic content (i.e., the DNS name of the
host), which in turn requires that the CA perform its Registration
Authority process to ensure that it is issuing the host credential to
the actual owner of the host. This makes host credential acquisition
time consuming and painful, both for the resource provider and for the
CA administrator.

Fortunately, the X.509 standard has a way of improving this situation. A
CA can issue a single subordinate CA credential to the resource
provider. However, this subordinate CA credential is restricted, using
the X.509 Name Constraints extension \[21\], to only allow host
credentials to be signed for hosts in a particular domain. The resource
provider can then use this subordinate CA credential to issue host
credentials with that domain, without further interaction with the
resource.

We will add support to GSI for this approach. Specifically, this
requires extension of GSI\'s certificate path validation algorithms to
check the X.509 Name Constraints extension. We will also provide simple
tools which a resource administrator can use to manage the subordinate
CA credential securely, and generate host credentials easily.

#### Integration with Local Security Solutions

Various resources may be protected using local security mechanisms, such
as Kerberos or DCE. If GSI is being used to authenticate into the
resource from the outside, this implies that approaches are needed to
enable the GSI credential to be used to acquire the necessary local
security system credential. For example, a storage resource provider may
use AFS filesystems locally, which requires that a local AFS credential
be required in order for the FTP daemon to can gain access to the files
of a particular user.

While GSI is already fairly adept in this regard, improvements are
needed to reduce this barrier to acceptance by resource providers. Past
funding paid for the development of a PKINIT implementation, which
allows a GSI PKI credential to be used to acquire a Kerberos ticket
\[45\]. Additional work is needed to PKINIT to make it easier to use,
and easier to integrate with resource services. We will also develop
similar tools to allow a GSI credential to be used to acquire an AFS
credential. In addition, these tools will be extended to evaluate the
restriction policies of delegated credentials, to ensure that the
credential can actually be used to acquire the Kerberos, DCE, or AFS
credential.

### Integration of Security Into Collaborative Applications

We now address the fourth and final issue raised in Section B.1.c,
namely the integration of security and policy technologies into tools
and applications. In order to support the successful integration of GSI
into collaborative applications, we propose to the following additional
work under this project:

1)  *Extensions to Standard APIs*: In order to integrate security into
    applications, developers of collaboration software require high
    quality, standards based, feature rich security APIs and SDKs. We
    will continue our ongoing work on the development and extension of
    standard APIs for security.

2)  *Tracking Standards*: Various security and policy standards are
    evolving in the Global Grid Forum, the Internet Engineering Task
    Force, and elsewhere. It is important that we contribute to, and
    track these standards. We will do so under this funding.

3)  *Independent Data Unit support*: Many collaborative applications
    (e.g., Access Grid, conferencing \[9\]) require authentication and
    message protection of non-TCP communication, such as UDP
    communication for multimedia, and store-and-forward messaging. We
    will extend GSI to include support for offline, unreliable,
    out-of-order, and/or multicast communication by adding support for
    Independent Data Units.

4)  *Flexible application of message protection*: Protecting
    communication often requires tradeoffs between performance and the
    level of protection. We will extend GSI to assist developers to
    understand what tradeoffs that are available to them, and to use
    policy to select appropriate tradeoffs.

5)  *Integration into development frameworks*: Collaboration application
    developers typically use high level development languages,
    libraries, and frameworks, such as Web browsers, Java, CORBA, .NET,
    Python, Perl, etc. We will assist in the integration of our security
    and policy solutions into various development frameworks that are
    important to collaboration developers.

6)  *Improving error reporting and logging*: Diagnosing problems that
    arise in the use of the security and policy tools require high
    quality error reporting and logging. We will improve this aspect of
    GSI, in order to make GSI more amenable to deployment in production
    collaboratories.

#### Extensions to Standard APIs

In order to integrate security into applications, developers of
collaboration software require high quality, standards-based,
feature-rich security APIs and SDKs. For example, an important element
of GSI's success is its use of the IETF standard Generic Security
Service (GSS) API \[30\]. Experience has proven that while this API is
good, it needs improvements. Work has already begun within the Global
Grid Forum, led by members of this proposal, to specify a first set of
extensions to GSS-API. Under this research project, we will carry these
(currently unfunded) efforts forward, and implement the resulting
extensions into GSI. Similar efforts will be carried out for other APIs
developed under this proposal, such as the GAA-API \[37\].

#### Tracking Standards

Members of this project are already working in the Global Grid Forum and
the Internet Engineering Task Force working to define and standardize
protocols and APIs for Grid security. Current GGF and IETF drafts
include:

1)  \"Internet X.509 Public Key Infrastructure Impersonation Certificate
    Profile\" \[44\]

2)  \"TLS Delegation Protocol\" \[24\]

3)  \"Internet X.509 Public Key Infrastructure Restricted Impersonation
    Certificate Profile\" \[41\]

4)  \"GSS-API Extensions\" \[46\]

It is critical that these, and other future work resulting from this
project, continue to be developed in community standards organizations
and that the tools that result from this project track these standards
as they evolve. We propose to do so under this project funding. (We note
that our current involvement, like other work in the security area, is
supported under projects for which funding is ending. Hence funding for
this project is essential if this work is to continue.)

#### Independent Data Unit Support

Many collaborative applications require \"protection of a generic data
unit (such as a file or message) in a way that is independent of the
protection of any other data unit and independent of any concurrent
contact with designated \'receivers\' of the data unit\" \[2\]. Such
protection can be used by collaborative applications to secure UDP
communication between interacting parties, by store-and-forward systems
such as email and instant messaging, and even for protecting files that
are stored on community storage systems. We propose to extend GSI to
support protection of Independent Data Units, likely through the
implementation and extension of existing standards such as
\"Cryptographic Message Syntax\" \[20\] and \"Independent Data Unit
Protection Generic Security Service Application Program Interface
(IDUP-GSS-API)\" \[2\].

#### Flexible Application of Message Protection

Protecting communication often requires tradeoffs between performance
and the level of protection. Improved encryption algorithms, perhaps
specialized to particular types of data, may change the tradeoff
available to collaboratory developers. And with the increasing
deployment of IPsec, which provides for host-to-host message protection,
even more tradeoffs will likely be possible in the near future. We
propose to extend GSI to assist developers to understand what tradeoffs
that are available to them, and to use policy to select appropriate
tradeoffs.

#### Integration Into Development Frameworks

Collaboration application developers typically employ a variety of tools
to build their systems. For example, Web browsers or Java clients may be
used to present graphical user interfaces to the users. Various services
of the collaboration may be implemented using other high level
development language, libraries, and frameworks, such as Java, Perl,
Python, MPI, CORBA, etc.

While it is beyond the scope of this proposal to integrate our security
infrastructure into all of these systems ourselves, we will prototype or
implement such integration for some of them (e.g., Java \[29\]), and
actively engage and assist other groups who wish to perform this
integration.

#### Improved Error Reporting and Logging

Diagnosing problems that arise in the use of the security and policy
tools require high quality error reporting and logging. For example, if
a user is unable to login to a collaboration, error messages and related
diagnostic tools should be able to assist the user in solving the
problem without further (costly) assistance. And if there is a security
breach of some sort in the collaboratory, high quality logging can be
invaluable to diagnosing and fixing the breach. We propose to improve
this aspect of GSI, in order to make GSI more amenable to deployment in
production collaboratories.

### Tasks and Milestones

In the project activity details below we show year 1 tasks in some
detail; activities for subsequent years will be detailed in the project
planning tasks that will take place in Q4 of the previous year. *Please
note that this plan overview is preliminary and subject to change of
technical and deployment approach.* Years indicated are from the
initiation of the project. This high level overview does not indicate
task duration - many of the tasks, once started, are ongoing. Some may
diminish in workload as the project proceeds, replaced by tasks that
will be identified in Year 2-5 project planning efforts.

  ------- ----------------- -------------------------------------------------------
  *Who*   ***Type***        ***Activity or Milestone***

                            ***YEAR 1 Q1-2***

  Joint   Coordinate        Develop project plan for Project Year 1

  ISI     Specification     Develop CAS server and client specifications

  ANL     Specification     Develop CAS protocol specification

  Joint   Development       Implement CAS server & client, with ACL-based policy
                            language

  Joint   Research          Prototype storage, compute, and bandwidth broker
                            resource services that accept CAS capabilities

  ISI     Research          Prototype policy evaluation API & SDK

  ISI     Research          Prototype simple ACL policy evaluator

          **Milestone**     **Demonstrate CAS in small testbed with multiple
                            resource types**

  ANL     Research          Prototype compute, storage, & bandwidth broker resource
                            servers that support CAS

  ANL     Standards         Propose standards for X.509 Impersonation Certificates

  ANL     Standards         Propose standards for TLS Delegation Protocol

  ISI     Standards         Propose standards for X.509 Restricted ICs

  ANL     Standards         Propose standards for Delegation Tracing

  ANL     Standards         Propose standards for GSS-API Extensions

  ISI     Research          Prototype Extended ACL policy evaluator

  UW      Research          Prototype ClassAd policy evaluator

                            

                            ***Year 1 Q3-4***

  ANL     Development       Implement and track all proposed standards

  ANL     Development       Implement restricted delegation extensions, with simple
                            attr/value restrictions

          **Deliverable**   **Deliver GSS-API, which tracks standards, and has
                            restricted delegation**

  ISI     Development       Incorporate restricted delegation into CAS

  Joint   Development       Incorporate proposed standards into CAS

          **Milestone**     **Demonstrate CAS, with restricted delegation, in
                            testbed with real application**

  ANL     Development       Improve error reporting and logging

  ANL     Development       Implement storage and compute resource services that
                            support CAS

          **Deliverable**   **Deliver CAS version 1, and supporting storage &
                            compute services**

  Joint   Research          Review and explore utility of more powerful policy
                            languages

  Joint   Coordinate        Develop project plan for Project Year 2

                            

                            ***YEAR 2***

  Joint   Standards         Finalize all standards

  Joint   Development       Implement all final standards

          **Deliverable**   **Deliver GSS-API with final standards**

  ISI     Specification     Re-evaluate CAS specifications, based on year 1
                            experience

  ISI     Development       Implement changes to CAS, based on revised
                            specifications

          **Milestone**     **Deploy CAS into real collaboration**

  Joint   Research          Evaluate policy languages for CAS, restricted
                            delegation, and resource discovery

  Joint   Development       Implement policy evaluation API & SDK

  Joint   Research          Prototype use of languages & API for extended CAS &
                            restricted delegation policies

  ANL     Development       Add accounting GUID to CAS capabilities, and use it for
                            resource usage logs

          **Deliverable**   **Deliver CAS version 2, and support storage & compute
                            services**

  ANL     Specification     Develop Online CA specification

  ANL     Development       Implement Online CA

          **Milestone**     **Demonstrate Online CA in friendly collaboration**

  ANL     Specification     Develop Online Crednetial Repository specification

  ANL     Development       Implement Online Credential Repository

          **Milestone**     **Demonstrate Online Credential Repository in friendly
                            collaboration**

  ANL     Development       Implement support for subordinate CAs for domains

  Joint   Coordinate        Develop project plan for Project Year 3

                            

                            ***YEAR 3***

  ANL     Development       Re-evaluate and implement changes to Online CA

          **Deliverable**   **Deliver Online CA version 1**

          **Milestone**     **Deploy Online CA into real collaborations**

  ANL     Development       Re-evaluate and implement changes to Online Credential
                            Repository

          **Deliverable**   **Deliver Online Credential Repository version 1**

          **Milestone**     **Deploy Online Credential Repository into real
                            collaborations**

  Joint   Research          Choose policy language(s)

  ISI     Development       Implement policy evaluation for the language(s)

  ISI     Development       Implement policy language(s) into CAS and restricted
                            delegation

          **Deliverable**   **Deliver CAS version 3**

          **Milestone**     **Deploy CAS with improved policy language support into
                            real collaboration**

  ANL     Development       Improve integration with Kerberos and AFS

  ANL     Development       Implement tools and protocol for distributing
                            accounting information

          **Deliverable**   **Deliver GSS-API, and miscellaneous supporting tools**

  ANL     Development       Add simple multiple credential handling to client and
                            Online Credential Repository

  ISI     Standards         Propose standards for policy languages, and policy
                            evaluation API

  Joint   Coordinate        Develop project plan for Project Year 4

                            

                            ***YEAR 4***

  ANL     Development       Implement tools for aggregating and analyzing community
                            accounting information

          **Deliverable**   **Deliver community accounting tools**

  ISI     Research          Extend policy language to support resource consumption
                            policies

  ISI     Development       Extend CAS and resources to support resource
                            consumption policies

  ISI     Research          Prototype CAS distribution and replication

          **Milestone**     **Deploy CAS with consumption policies**

  Joint   Research          Prototype policy based resource discovery and selection

  ANL     Development       Add multiple credential discovery

          **Milestone**     **Deploy Online Cred Repository with multiple
                            credential handling & discovery**

          **Deliverable**   **Deliver updated CAS, Online CA, Online Credential
                            Repository**

  Joint   Research          Prototype multi-factor authentication

  Joint   Standards         Propose standards for distributed accounting and
                            resource consumption policies

  Joint   Research          Prototype Independent Data Unit support

  Joint   Coordinate        Develop project plan for Project Year 5

                            

                            ***YEAR 5***

  ISI     Development       Implement CAS distribution and replication

          **Milestone**     **Deploy CAS with distribution and replication**

  Joint   Development       Implement policy based resource discovery and selection

  ANL     Development       Add multiple credential delegation

  Joint   Development       Implement and deploy multi-factor authentication

  Joint   Development       Implement and deploy Independent Data Unit support

  Joint   Development       Implement tools to assist in flexible application of
                            message protection

          **Deliverable**   **Deliver updated CAS, Online CA, Online Credential
                            Repository**

          **Deliverable**   **Deliver GSI with IDU support, multi-factor
                            authentication, supporting tools**
  ------- ----------------- -------------------------------------------------------

### Deliverables

As indicated in Section A.1.d (Contributions), and Section A.3.e (Tasks
and Milestones) this project will deliver:

-   A wide variety of research results relating to PKI infrastructure,
    delegation, policy, and integration of these capabilities into real
    tools and applications. We expect these results to generate
    considerable interest.

-   High-quality toolkits (APIs, SDKs, services, tools) incorporating
    the next-generation mechanisms developed as a result of our
    research, including a series of releases of CAS, Online CA, Online
    Credential Repository, GSS-API, and other related tools.

-   Protocols and API standards, for numerous aspects of the toolkits.

-   (In collaboration with Collaboratory Pilots and other DOE
    Applications) Large-scale deployment, application, and evaluation of
    security and policy mechanisms.

### Connections, Technology Transfer, Application

The widespread adoption of the security and Globus technologies that we
have developed to date (in particular, GSI, discussed in Section B.2.a
above, as well as the various elements of the Globus Toolkit, which use
GSI capabilities) provides us with a highly effective technology
transfer vehicle. Ongoing work aimed at simplifying Globus Toolkit use
and enabling binary distribution of individual components (e.g., GSI)
will facilitate this. The ease with which other groups can integrate GSI
mechanisms into tools provides an important and low-cost vehicle for
technology transfer to large user communities.

During this project, we will continue to enhance and promote these
technologies to the scientific community at large, within the context of
national/international Grid efforts and the larger SciDAC/DOE community,
with the goal of both obtaining additional input on requirements and
enabling large-scale evaluation in practical settings. We provide
details on these activities in the following, and also talk about our
work with international standards bodies.

#### SciDAC and Other DOE Projects

The PIs have played a leadership role in establishing a broad
national---and indeed international---consensus on the importance of
Grid concepts and on specifics of a Globus-based Grid architecture. A
wide range of projects have been established that together are
developing and applying Grid concepts to problems of tremendous
scientific importance (see Figure 1). These activities include "Data
Grid" projects in such areas as high energy physics, climate science,
and astronomy; "Computational Grid" projects concerned with access to
computation; and "Instrumentation Grid" projects concerned with access
to instrumentation. The present proposal is an essential and central
part of this overall project mix, which depend on the availability of
powerful, flexible, and simple security and policy mechanisms. *If this
project is not funded, these other efforts will face serious
difficulties.*

We foresee, in particular, close connections with a number of existing
DOE-funded technology and application projects, as well as with new
projects proposed under the SciDAC program. In brief, this project will
complement a range of projects that are collectively concerned with
developing, deploying, applying, and evaluating a DOE Science Grid
Collaboratory Software Environment. We outline here some of the major
connections.

The proposed "[DOE Science Grid]{.underline}" Collaboratory Pilot will
prototype, evaluate, apply, and refine an operational Grid
infrastructure across DOE laboratories. The DOE Science Grid project
looks to this project to provide the next-generation security mechanisms
that will provide the DOE community with uniform, high-performance,
convenient, and secure access to data. The DOE Science Grid project also
provides us with an effective deployment mechanism, ensuring for example
that GSI-enabled servers are deployed at DOE laboratories.

A submitted proposal from ESnet would establish DOE Certificate
Authority and information services, hence providing essential
infrastructure elements for a future DOE Science Grid. Our proposal
complements that activity by addressing essential security
infrastructure mechanisms needed to exploit the availability of these
services.

The proposed "[Enabling Technology Center for Scientific Data
Management]{.underline}" will, among other things, develop MPI-IO
interfaces to high-performance cluster file systems. We plan a
collaborative effort aimed at enabling high-performance, secure
GridFTP-based access to these systems.

The DOE-funded [Particle Physics Data Grid]{.underline} project is
focused on the application of Data Grid concepts to the needs of a
number of U.S.-based high energy and nuclear physics experiments. In
PPDG-1 (funded through FY2001), the PPDG team made heavy use of Globus
security technologies. In PPDG-2 (proposed as a SciDAC 01-06
Collaboratory Pilot), the PPDG team has chosen to adopt Globus
technologies as their core technology base. They are looking to this
project to provide them with the scalable security technologies needed
for large-scale Data Grids.

The DOE-funded [Earth System Grid]{.underline} project is focused on the
application of Data Grid concepts to the needs of climate researchers.
In ESG-1 (funded through FY2001), the ESG team both developed and made
heavy use of Globus security technologies, including our Community
Authorization Service. ESG-2 (proposed as a SciDAC 01-06 Collaboratory
Pilot) is looking to this project for next-generation security tools.

The proposed "[National Collaboratory to Advance the Science of High
Temperature Plasma Physics for Magnetic Fusion]{.underline}" will
provide another user community for our work, one concerned with
achieving high-performance access to fusion simulation data.

The proposed work complements work on Akenti at LBNL. As discussed in
Section B.3.a.1, we will continue to work closely with the LBNL group to
ensure compatibility of infrastructure and goals.

#### Standards Bodies and Open Source Consortia

Another important technology transfer vehicle for our work are
international standards bodies. Participants in this project are active
participants in the Global Grid Forum. We have already started efforts
within the Global Grid Forum (where Tuecke chairs the security working
group) on standardizing GSI extensions, with five draft RFCs being
presented at GGF1 in March 2001 and two of those being also presented to
the IETF. Within IETF, Engert is Kerberos chair and Neuman, Ryutov, and
Pearlman are developing GAA \[37\]. We will continue these efforts with
the goal of integrating the results of our work into standards. The IRTF
Authorization Working Group has also expressed strong interest in our
work and we have met with them on several occasions.

In order to further our overall goal of achieving broad adoption of open
standards/open source-based Grid infrastructure, we are investigating
the feasibility of establishing a [Consortium for Open Grid
Software]{.underline} (COGS), a body dedicated to the creation,
documentation, and distribution of high-quality open source Grid
software. Details are not finalized but we will continue to pursue this
goal over the next several months.

### Evaluation Criteria

We address specifically the special evaluation criteria described in the
call.

*Potential to make a significant impact in the effectiveness of SciDAC
applications researchers.* We address this issue in Sections B.1, and
point also to the strong letters of support from a set of application
groups, selected to be representative rather than complete.

*The extent to which the project will test important collaborative
technologies.* This project will both develop pioneering new
technologies for security and policy in collaborative settings, and work
with application groups to explore the practicality of these
technologies in diverse settings.

*Extent to which the results of the project are extensible to other
program or discipline areas.* The entire goal of this project is to
develop and make available general-purpose security and policy
technologies of relevance to a wide range of program and discipline
areas. The letters of support indicate the breadth of relevance: see
also Section [B.3.g]{.mark}.

*Degree to which the project adheres to the management philosophy of
incorporating collaboration into the project execution.* As we explain
in Section [B.4]{.mark}, this project is highly distributed and
collaborative in nature, and its management structure and mechanisms are
designed with this in mind.

*The quality of the plan for ensuring interoperability and integration
with software produced by other SciDAC efforts.* Our focus on providing
basic mechanisms, and our work with application groups and standards
bodies to ensure widespread adoption of these mechanisms, will do much
to ensure interoperability and integration. In addition, as we explain
in Section B.3.g, we plan to work closely with a range of SciDAC
technology and application groups.

*The extent to which the project incorporates broad community
(industry/academia/other federal programs) interaction.* As we explain
in Section B.3.g, we have extremely strong connections with other
federal and international Grid efforts, via collaborations that we have
established and nurtured over several years. Outside DOE, we already
have a large user base and are building connections with Internet 2
(e.g., via their PKI lab at UW) and industry (e.g., Microsoft, Sun,
IBM). In addition, the Global Grid Forum that Foster co-founded provides
a wonderful vehicle for community interaction.

*Quality and clarity of proposed work schedule and deliverables.*
Sections [B.3.e]{.mark} and [B.3.f]{.mark} provide a detailed work
schedule and set of deliverables.

*Knowledge of and coupling to previous efforts for collaborative
technologies such as DOE 2000.* We discuss in Section [B.2]{.mark}
results obtained under previous DOE funding. In Section B.3.a.1, we
describe the relationship of this work to the DOE2000-funded Akenti
system. We emphasize that GSI is already an integral part of DOE
security technologies, as evidenced by its adoption within the proposed
DOE Science Grid.

*Relevance of the proposed research to the terms of the announcement.*
We believe this is clear: we will develop and evaluate collaboratory
middleware services of direct relevance to a range of DOE-relevant
applications, and in so doing advance our knowledge of our how to
construct and operate these services.

*Uniqueness of the proposer\'s capabilities.* We do not believe that any
other team could come anywhere close to fielding a comparable
combination of expertise in Grid and security technologies and
collaboratory requirements, and, in particular, ability to produce
security technologies that are actually used by application groups.

Demonstrated usefulness of the research for proposals in other DOE
Program Offices as evidenced by a history of programmatic support
directly related to the proposed work. DOE's OBER and OHENP have
provided support for the Earth System Grid and Particle Physics Data
Grid projects (both of which build on Globus security technologies) and
continue to express strong support for further development of Grid
technologies.

## Subcontract or Consortium Arrangements

The proposed research will be performed by a multi-institutional team
comprising staff at Argonne National Laboratory, USC's Information
Sciences Institute, and the University of Wisconsin. (We note that we
expect each institution to be funded directly by MICS: no subcontracts
are involved.) We indicate in Section B.3.e the specific tasks to be
undertaken by each participant; here, we summarize expertise and major
areas of contribution:

-   ANL provides expertise in distributed computing and networking, and
    will contribute to development of both security and policy
    technologies. Argonne's Distributed Systems Laboratory has an
    international reputation as a leader in "Grid" technologies. Engert,
    Foster, and Tuecke have all worked on both security technology and
    applications to DOE science disciplines for several years.

-   USC/ISI provides expertise in distributed computing and networking,
    and will contribute to development of both security and policy
    technologies. USC/ISI has an international reputation as a leader in
    "Grid" technologies. Kesselman and Pearlman have worked on security
    technology and applications to science disciplines for several
    years.

-   UW provides expertise in distributed computing, and will contribute
    to the development of policy technologies technologies. Livny has an
    international reputation due to his pioneering work on the Condor
    distributed computing system. He has worked closely with the physics
    community for several years.

The participants have a long and fruitful history of joint work in a
number of areas, including security and policy, and form in many
respects a single "virtual laboratory." Hence, we are able to adopt a
fairly informal management structure and focus our energies on
maximizing the effectiveness of our internal collaborative processes and
our interactions with other groups.

Our management structure will operate as follows. PI Tuecke will serve
as primary point of contact with DOE. Tuecke, Kesselman, and Livny will
operate as a Management Council.

Our internal collaborative processes will make extensive use of shared
code repositories, webs, and email lists (which are already in place)
and Access Grid technology and telephone for multi-site discussions. The
Management Council will meet via Access Grid or telephone at least
weekly to discuss progress and coordinate activities. Regular meetings
involving project staff conducted on Access Grid and in person will be
used to plan future activities.

Interactions with the larger SciDAC community will be structured in
terms of an alpha testing program, which is already in place and proving
very successful; development of documentation and tutorials on specific
security Toolkit components; and involvement in coordination/outreach
activities such as the Global Grid Forum.

# Literature Cited

1\. \"Authorization (AZN) API,\" Open Group Technical Standard C908,
2000.

2\. Adams, C., \"Independent Data Unit Protection Generic Security
Service Application Program Interface (IDUP-GSS_API,\" RFC 2479,
December 1998.

3\. Arsenault, A. and Farrell, S., \"Securely Available Credentials -
Requirements,\" IETF Internet Draft draft-ietf-sacred-reqs-01.txt,
February 2001.

4\. Beiriger, J., Johnson, W., Bivens, H., Humphreys, S. and Rhea, R.,
Constructing the ASCI Grid. in *Proc. 9th IEEE Symposium on High
Performance Distributed Computing*, (2000), IEEE Press.

5\. Belani, E., Vahdat, A., Anderson, T. and Dahlin, M. The CRISIS Wide
Area Security Architecture. in *Proceedings of the 8th Usenix UNIX
Security Symposium*, January 1998.

6\. Blaze, M., Feigenbaum, J., Ioannidis, J. and Keromytis, A., \"The
Keynote Trust Management System, Version 2,\" IETF RFC 2704, September
1999.

7\. Blaze, M., Feigenbaum, J. and Lacy, J.S. Decentralized Trust
Management. in *Proc. of the IEEE Conference on Security and Privacy*,
1996.

8\. Butler, R., Engert, D., Foster, I., Kesselman, C., Tuecke, S.,
Volmer, J. and Welch, V. Design and Deployment of a National-Scale
Authentication Infrastructure. *IEEE Computer*, *33* (12). 60-66.

9\. DeFanti, T. and Stevens, R. Teleimmersion. in Foster, I. and
Kesselman, C. eds. *The Grid: Blueprint for a New Computing
Infrastructure*, Morgan Kaufmann, 1999, 131-155.

10\. Foster, I. and Karonis, N. A Grid-Enabled MPI: Message Passing in
Heterogeneous Distributed Computing Systems. in *Proc. SC\'98*, 1998.

11\. Foster, I., Karonis, N.T., Kesselman, C., Koenig, G. and Tuecke, S.
A Secure Communications Infrastructure for High-Performance Distributed
Computing. in *Proc. 6th IEEE Symp. on High Performance Distributed
Computing*, 1997, 125\--136.

12\. Foster, I. and Kesselman, C. Globus: A Toolkit-Based Grid
Architecture. in Foster, I. and Kesselman, C. eds. *The Grid: Blueprint
for a New Computing Infrastructure*, Morgan Kaufmann, 1999, 259-278.

13\. Foster, I. and Kesselman, C. (eds.). *The Grid: Blueprint for a New
Computing Infrastructure*. Morgan Kaufmann, 1999.

14\. Foster, I., Kesselman, C., Lee, C., Lindell, R., Nahrstedt, K. and
Roy, A., A Distributed Resource Management Architecture that Supports
Advance Reservations and Co-Allocation. in *Proc. International Workshop
on Quality of Service*, (1999), 27-36.

15\. Foster, I., Kesselman, C., Tsudik, G. and Tuecke, S. A Security
Architecture for Computational Grids. in *ACM Conference on Computers
and Security*, 1998, 83-91.

16\. Foster, I., Kesselman, C. and Tuecke, S. The Anatomy of the Grid:
Enabling Scalable Virtual Organizations. *Intl. J. Supercomputer
Applications*, *(to appear)*.

17\. Foster, I., Roy, A. and Sander, V., A Quality of Service
Architecture that Combines Resource Reservation and Application
Adaptation. in *Proc. 8th International Workshop on Quality of Service*,
(2000).

18\. Gasser, M. and McDermott, E., An Architecture for Practical
Delegation in a Distributed System. in *Proc. 1990 IEEE Symposium on
Research in Security and Privacy*, (1990), IEEE Press, 20-30.

19\. Hardjono, T. and Ohta, T. Secure End-to-End Delegation in
Distributed Systems. *Computer Communications*, *17* (3). 230-238.

20\. Housley, R., \"Cryptographic Message Syntax,\" RFC 2630, June 1999.

21\. Housley, R., Ford, W., Polk, W. and Solo, D., \"Internet X.509
Public Key Infrastructure Certificate and CRL Profile,\" IETF, RFC 2459,
1999.

22\. Howell, J. and Kotz, D., End-to-End Authorization. in *Proc. 2000
Symposium on Operating Systems Design and Implementation*, (2000),
USENIX Association.

23\. Howell, J. and Kotz, D., A Formal Semantics for SPKI. in
*Proceedings of the Sixth European Symposium on Research in Computer
Security (ESORICS 2000)*, (2000), 140-158.

24\. Jackson, K., Tuecke, S. and Engert, D., \"TLS Delegation
Protocol,\" Internet Draft draft-ietf-tls-delegation-00.txt, February
2001.

25\. Johnston, W. and Larsen, C., \"A Use-Condition Centered Approach to
Authenticated Global Capabilities: Security Architectures for
Large-Scale Distributed Collaboratory Environments,\" Lawrence Berkeley
National Laboratory, Technical Report 3885, 1996.

26\. Kaufman, C., Perlman, R. and Speciner, M. *Network Security.
Private Communication in a Public World*. Prentice Hall, 1995.

27\. Kortesniemi, Y., Hasu, T. and Partanen, J., A Revocation,
Validation and Authentication Protocol for SPKI-Based Delegation
Systems. in *Network and Distributed System Security Symposium*, (2000).

28\. Lampson, B., Abadi, M., Burrows, M. and Wobber, E., Authentication
in Distributed Systems: Theory and Practice. in *Proceedings of the
Symposium on Operating System Principles*, (1991).

29\. Laszewski, G.v., Foster, I., Gawor, J. and Lane, P. A Java
Commodity Grid Toolkit. *Concurrency: Practice and Experience*, *13*.

30\. Linn, J., \"Generic Security Service Application Program Interface,
Version 2,\" IETF, RFC 2078, 1997.

31\. Litzkow, M., Livny, M. and Mutka, M. Condor - A Hunter of Idle
Workstations. in *Proc. 8th Intl Conf. on Distributed Computing
Systems*, 1988, 104-111.

32\. Livny, M. High-Throughput Resource Management. in Foster, I. and
Kesselman, C. eds. *The Grid: Blueprint for a New Computing
Infrastructure*, Morgan Kaufmann, 1999, 311-337.

33\. Livny, M., Matchmaking: Distributed Resource Management for High
Throughput Computing. in *Proceedings of the Seventh IEEE International
Symposium on High Performance Distributed Computing*, (1998), IEEE
Press.

34\. Mullender, S.J. and Tanenbaum, A.S. The Design of a
Capability-Based Distributed Operating System. *The Computer Journal*,
*T29*. 289-299.

35\. Neuman, B.C., Proxy-Based Authorization and Accounting for
Distributed Systems. in *Proceedings of the 13th International
Conference on Distributed Computing Systems*, (1993), 283-291.

36\. Ryutov, T., Gheorghiu, G. and Neuman, C. An Authorization Framework
for Metacomputing Applications. *Cluster Computing*, *2*. 165-175.

37\. Ryutov, T. and Neuman, C., Representation and Evaluation of
Security Policies for Distributed System Services. in *Proceedings of
the DARPA Information Survivability Conference & Exposition*, (2000).

38\. Sandhu, R., Coyne, E., Feinstein, H. and Youmanet, C. Role-Based
Access Control Models. *IEEE Computer*, *29* (2).

39\. Schneier, B. *Applied Cryptography*. Wiley, 1996.

40\. Steiner, J., Neuman, B.C. and Schiller, J., Kerberos: An
Authentication System for Open Network Systems. in *Proc. Usenix
Conference*, (1988), 191-202.

41\. Thompson, M., Engert, D. and Tuecke, S., \"Internet X.509 Public
Key Infrastructure Restricted Impersonation Certificate Profile,\"
Global Grid Forum draft-ggf-x509-res-delegation-01.txt, February 2001.

42\. Thompson, M., Johnston, W., Mudumbai, S., Hoo, G., Jackson, K. and
Essiari, A. Certificate-based Access Control for Widely Distributed
Resources. in *Proc. 8th Usenix Security Symposium*, 1999.

43\. Tuecke, S., \"Grid Security Infrastructure (GSI) Roadmap,\" Grid
Forum Draft draft-ggf-gsi-roadmap-02.txt, February 2001.

44\. Tuecke, S., Engert, D. and Thompson, M., \"Internet X.509 Public
Key Infrastructure Impersonation Certificate Profile,\" Internet Draft
draft-ietf-pkix-impersonation-00.txt, February 2001.

45\. Tung, B., Wray, J., Medvinsky, A., Hur, M. and Trostle, J. Public
Key Cryptography for Initial Authentication in Kerberos.

46\. Welch, V., Tuecke, S. and Engert, D., \"GSS-API Extensions,\" Grid
Forum Draft draft-ggf-gss-extensions-01.txt, February 2001.

47\. Wulf, W.A., Wang, C. and Kienzle, D., \"A New Model of Security for
Distributed Systems,\" Department of Computer Science, University of
Virginia 1995.

# Budget and Budget Explanation

# Other Support of Investigators

# Biographical Sketches

# Description of Facilities and Resources