GWD-I: multiple-credentials-requirements-03
R. Butler
D. Engert
K. Jackson
M. Lorch
R. Olson
V. Welch
Expires: January 2003
July 2002
Multiple Credentials: Scenarios and Requirements
Abstract
This document describes a number of scenarios where entities on Grids require multiple
credentials. It details the requirements these scenarios place on security infrastructures for
Grids.
Status of this Draft
This Grid Working Draft (GWD) is a product of the Grid Security Infrastructure (GSI)
working group of the Global Grid Forum. The latest version of this document may be
found on the GSI working group home page: http://www.gridforum.org/2_SEC/GSI.htm
Table of Contents
1
Introduction................................................................................................................3
2
Grid Security Overview ............................................................................................3
3
2.1
Grid Security Infrastructure................................................................................. 3
2.2
Kerberos ............................................................................................................... 3
2.3
Terminology ........................................................................................................ 4
Scenarios Involving Multiple Credentials ...............................................................4
3.1
Multiple Credentials Used Through a Super-Scheduler ...................................... 4
3.1.1
Simple Super-Scheduler Scenario ............................................................... 4
3.1.2
More Complex Super-Scheduler Scenario .................................................. 5
3.2
Attribute and Identity Credentials Used in User-to-User Collaboration
Scenarios .......................................................................................................................... 5
3.2.1
Asynchronous Collaboration ....................................................................... 6
3.2.2
Synchronous Collaboration ......................................................................... 6
3.2.3
Requirements ............................................................................................... 6
3.3
Requirements of Scenarios where Attribute/Identity Credentials are Stored on a
Centralized Server ........................................................................................................... 6
3.3.1
Simple Scenario ........................................................................................... 7
3.3.2
More Complex Scenario .............................................................................. 7
3.4
Multiple Resource Credentials ............................................................................ 8
3.5
Credentials for Multiple Purposes ....................................................................... 8
3.6
Credentials for Multiple Roles............................................................................. 8
3.7
Multiple Credentials in an Access Grid Session.................................................. 9
3.7.1
Discussion.................................................................................................... 9
3.8
Requirements for the delegation of credentials when bridging different
mechanisms ...................................................................................................................... 9
4
3.9
Multiple delegation scenario with identity certificates from multiple CAs ......10
3.10
User-to-user authentication with multiple credentials on one or both sides......11
Summary of Requirements .....................................................................................11
4.1
Language for Describing Credentials ................................................................11
4.2
Storage and Management of Multiple Credentials ............................................11
4.3
Delegation of multiple credentials .....................................................................11
4.4
Negotiation of credentials ..................................................................................12
4.5
Multiple credentials for authentication and/or authorization.............................12
5
Contact Information................................................................................................12
6
Security Considerations ..........................................................................................12
7
Intellectual Property Statement .............................................................................13
8
Full Copyright Notice ..............................................................................................13
9
References.................................................................................................................13
1 Introduction
With the increased number and complexity of Grids, users and resources on these Grids
will be required to have multiple credentials for a number of different reasons. This
document describes Grid computing scenarios that demonstrate the need for multiple
credentials and summarizes the resulting Grid Security requirements.
Section 2 gives an overview of current Grid Security mechanisms and explains the
terminology used throughout the rest of this document. Section 3 describes a number of
scenarios in typical Grid computing where entities require the use of multiple credentials
together with the specific requirements of each scenario. Section 4 summaries the
requirements brought out in the rest of the document. Section 5 has contact information
for the authors.
2 Grid Security Overview
In this section we describe the Grid Security mechanisms discussed later in this
document. We also introduce terminology that is used freely in the rest of the document.
While we attempt to give a general overview of the technologies involved, this section is
not meant to be an exhaustive introduction to the technologies and the reader is
encouraged to read the referred documents for a through understanding of the
mechanisms.
2.1 Grid Security Infrastructure
The Grid Security Infrastructure (GSI) is the primary security mechanism used by the
Globus ToolkitT M [XXX ref]. GSI authentication is based on the use of standard Public
Key Infrastructure(PKI) [XXX ref] technology. Specifically it uses X.509 certificates
[XXX ref] and private keys as credentials for authentication.
With standard X.509 identity certificates, the private key associated with the certificate is
kept encrypted and requires user interaction (i.e. the typing of a pass phrase) in order for
it to be decrypted and used. GSI adds the concept of Proxy Certificates [XXX ref], which
may be used like standard X.509 identity certificates for authentication. However Proxy
Certificates have a much shorter lifetime than normal X.509 identify certificates,
allowing their private key to be kept unencrypted and readily available for use.
2.2 Kerberos
Kerberos [XXX ref] is a well-known technology both inside and outside the Grid
community. The Globus Toolkit can also use Kerberos as an authentication mechanism
and it is in use by several major Grids. Users of a Kerberos authentication system
authenticate themselves to trusted servers known as Key Distribution Centers (KDCs)
and received a short-lived credential known as a ticket which serves as their credential.
2.3 Terminology
The following terms are used freely throughout the remainder of this document:
•
Identity Credential
A credential though which a trusted party certifies an entity’s identity
•
Attribute Credential
A credential which associates a set of attributes with a specific identity
•
Capability Credential
A credential that holds a capability which enables the presenter to perform a
specific function.
•
Credential
An electronic document or record that conveys information to be used for
authentication and authorization.
•
Delegation
The process of communicating a set of privileges or attributes from one identity to
another.
•
Proxy Certificate
A credential which is used to impersonate an entity for a limited time and possibly
with a limited set of the issuing entities abilities and privileges.
3 Scenarios Involving Multiple Credentials
The following subsections describe scenarios that exist in today’s Grids and would be
affected by entities that have multiple credentials. For each scenario we describe the
scenario and then lay out the requirements placed on the security mechanism.
3.1 Multiple Credentials Used Through a Super-Scheduler
A super-scheduler [XXX ref] is an entity that receives a description of a task from the
user and then acts on the user’s behalf to complete the task by coordinating all the
resources necessary. This requires the super-scheduler to be able to do a number of tasks
that require the user’s credentials, such as querying information servers to determine the
appropriate resources to use, verifying the user has permission to use the desired
resources and finally actually connecting to the resources and executing tasks as the user.
In order to enable this, the user delegates their credentials (or a subset of their credentials)
to the super-scheduler. The super-scheduler then uses the delegated credentials to
perform the needed operations.
3.1.1
Simple Super-Scheduler Scenario
In this scenario the user wants to have a super-scheduler co-schedule a collection of
resources on her behalf. The resources exist in different administrative domains, and
require different credentials for authentication.
Requirements:
•
The user needs a mechanism for storing and managing multiple credentials.
•
The super-scheduler needs a mechanism to determine what credentials a resource
is willing to accept.
•
Additionally, if the user is unwilling to initially delegate all of their credentials to
the super-scheduler, then the super-scheduler needs:
- a mechanism to communicate back to the user which credentials it needs once
this has been determined
- a method for acquiring the necessary credentials from the user
- a mechanism for storing and managing multiple credentials.
3.1.2
More Complex Super-Scheduler Scenario
This scenarios is similar to the simpler scenario, except one of the resources the superscheduler is acquiring requires the user to authenticate with both an identity credential
and a capability or attribute credential.
The additional requirements that this scenario adds to the simpler super-scheduler
scenario are:
•
The super-scheduler needs to be able to determine what additional credentials the
resource requires.
•
The super-scheduler needs a mechanism for acquiring the additional credentials.
•
The super-scheduler needs a mechanism to be able to present both, the identity
and capability or attribute credential for authentication and authorization.
3.2 Attribute and Identity Credentials Used in User-to-User
Collaboration Scenarios
Grid computing enables various levels of collaboration from single entities to large
organizations. For small ad-hoc collaborations with often only temporary existence, the
administrative overhead of delegation through traditional authorization mechanisms on
the resources can be very large. A distributed mechanism can enable entities to exchange
privileges directly to each other. If an entity can delegate a subset of its rights to another
entity and the receiving entity can combine these rights with other delegated or own
rights the entities can set up trust relationships that enable the sharing of data, program
and computational resources without the need for administrator intervention. Such a
transfer of privileges can be achieved through attribute credentials. An entity using such a
scheme would request grid services using multiple credentials, one identity credential
used for authentication as well as a set of attribute credentials for authorization.
Usage scenarios of attribute credentials can be grouped into two categories: synchronous
and asynchronous collaboration. Rights are either delegated from one entity to another
before they are used (asynchronous) or are combined on-line to achieve collaborative
usage of resources (synchronous).
3.2.1
Asynchronous Collaboration
We call a collaboration scenario asynchronous when the entities who are collaborating
are not requesting, delegating and using capabilities in an on-line fashion. These
scenarios prevent the quick negotiation of required credentials through direct interaction
and thus demand a mechanism to clearly specify what credentials are needed by whom, at
what point of time, and for what task and resource.
A sample scenario would be the collaboration of two researchers, John and Sam. John
owns a data file that Sam would like to have read access to. Sam would thus request a
credential from John that conveys a read privilege to his identity. John could issue and
transmit such a credential to Sam at any point in time. After the receipt of the credential
Sam can access the file by presenting the attribute credential together with his identity
credential to the resource.
3.2.2
Synchronous Collaboration
We call a collaboration scenario synchronous when the collaborating entities are
connected to each other when a grid service is requested (a conference call scenario).
Application of capabilities from the various owners to requests is only possible while the
owners are on-line. Such a scenario for example is the creation and execution of meta
programs through a collaborative composition environment like Symphony and Sieve
[LOR02, ISE97]. Depending on the acceptable use policies (AUPs) involved it may not
be possible for an entity holding access to a specific resource to delegate this access to
others but the policies may very well allow a synchronous collaboration where
capabilities are not delegated but rather combined at the time of access.
A sample scenario is the collaboration of two researchers, John and Sam, who try to solve
a problem together by creating a Grid meta program that combines resources to which
only one of the researchers has access. While some components of this meta program use
John’s privileges others may use Sam’s privileges for authorization.
3.2.3
Requirements
Grid security mechanisms supporting the introduced scenarios will have to provide:
•
support for the storage, management and presentation of multiple attribute
credentials in addition to identity credentials
•
a language to express authorization requirements, such that the system can
negotiate and intelligently select credentials needed for least privilege access
•
a protocol to allow for the negotiation and exchange of attribute credentials
•
a credential revocation mechanism for attribute credentials that come from a
variety of issuers
3.3 Requirements of Scenarios where Attribute/Identity Credentials
are Stored on a Centralized Server
Attribute/identity credentials (AICs) are defined as credentials that convey identity as
well as attributes bound to that identity. The restricted proxy certificates used by the
Community Authorization Service (CAS) [PEA02] (CAS credentials) are an example of
such credentials.
3.3.1
Simple Scenario
In this scenario the user (or a process running on a user’s behalf) has one or more identity
credentials but wants to authenticate to a resource that requires an AIC. The user needs to
determine this, locate the AIC server (AICS), authenticate to the AICS, retrieve the AIC
and then use it to authenticate to the resource which will then authorize the request based
on the attributes embedded in the AIC.
Requirements posed by this scenario:
•
The user needs a method of determining that the resource requires a AIC and what
AIC is required. Some possible methods are out-of-band (OOB) (e.g. community
knowledge), some form of information service (IS), or having this information
being communicated directly from the resource, possibly on a failed
authentication attempt.
•
A method of discovering where to go to get the AIC given the user’s existing
credentials (and possibly the resource the user is trying to talk to). It appears that
the same possible methods as above are reasonable: OOB, IS and directly from
resource.
•
A language to describe the AIC so that entities can talk about it. The user may
need to be told which AIC they need and they will need to request the AIC from
the AICS.
•
A method of storing the AIC along with other credentials the user already has.
There are a number of secondary issues here like being able to select credentials
in the store.
•
Selecting the right credential from the store to use for authentication. This
possible arises twice in this scenario, certainly when connecting to the resource
with user credentials and AIC and also possibly when connecting to the AICS if
the user has multiple credentials already. Possible options here would seem to
include out-of-band or some sort of information service.
3.3.2
More Complex Scenario
A slightly more advanced version of the above described scenario. In this version the user
is attempting to delegate to a remote resource all the credentials that it will need,
including an AIC.
Requirements posed by this scenario:
•
The user no longer has direct contact with the resource, so having the resource
communicate the needed credential is no longer an option. This would seem to
require that knowledge of the needed AIC being out of band or come from an IS.
•
The user needs to be able to delegate multiple credentials of different type (one or
more identity credentials and one or more AICs).
3.4 Multiple Resource Credentials
In this scenario a resource (host or a similar entity) has multiple identity credentials.
Users (or user agents) will attempt to authenticate to the host and perform mutual
authentication in the process. For mutual authentication to take place the resource will
need to determine which of its credentials is acceptable to the user and possibly even
which is the preferred credential.
Requirements posed by the scenario:
•
The resource needs some way of figuring out which credentials are acceptable
and/or preferable to the user.
•
The resource needs a method of storing and managing multiple credentials.
3.5 Credentials for Multiple Purposes
Sam has been issued multiple identity credentials for very specific functions. Certificate
#1 is to be used for authentication to an entity. That same certificate may also be used to
electronically sign a document. A second certificate may be used only to encrypt data and
the private key to this certificate has likely been escrowed. Thus since certificate #2’s
private key has been shared with some other entity, it cannot be trusted for
authentication/signature.
These two certificates were created by the same CA but yet Sam needs to be able to
distinguish between them so he can apply them correctly. The distinguished name field
(DN) in these certificates may or may not be identical.
In this scenario Sam needs to be able to manage his certificates and specify the correct
certificate for the specific function he wants to perform.
3.6 Credentials for Multiple Roles
This scenario is difficult as it seems to mix authentication and authorization together.
However, in some cases Sam may have multiple certificate levels. A level may be
represented by the amount of effort put forward to vet the identity of the
certificate/private key holder. Sam has a high level security clearance which means he
has been authorized to access highly restricted resources. Sam must authenticate to these
restricted resources via a high level (more trusted) certificate. Sam also has access to
resources that are at a lower security level. This may be things like his desktop or group
servers. These unrestricted systems are not trusted by the higher level resources and are
considered suspect. These systems may be running malicious software that is somehow
able to compromise Sam’s credentials. Thus Sam does not want to use his high level
certificate for authentication to a lower level resource. Sam will need multiple credentials
of differing levels and he will need to be able to distinguish between them. Again the DN
in the certificates may or may not be unique.
3.7 Multiple Credentials in an Access Grid Session
Jim is operating the Access Grid node at ANL for a collaborative debugging session on a
supercomputer code. Jim is on the local A/V staff and has the responsibility for
maintaining the AG node. Cathy and Sam are in the room to actually participate in the
debugging session. The session will take place in an AG Virtual Venue (a virtual room
that provides scoping services for the Access Grid) that holds the shared interactive
interface to the remote supercomputer where the work is being performed. Access to the
Venue is restricted only to authorized supercomputer users, because once in the Venue,
users have access to the supercomputer’s resources. That is, the shared interactive
supercomputer interfaces rely on the security mechanisms of the Venues infrastructure.
The Access Grid software uses the GSI to implement its authentication. Hence, Jim has
used his GSI identity credential to authenticate with the Access Grid Venue
infrastructure, and has been able to navigate to the entrance to the supercomputer venue.
However, his credential is not sufficient to enter the venue, since he is not a
supercomputer user. However, Cathy does have the necessary credentials to enter. Cathy
starts up her laptop computer, and runs the Access Grid laptop client software. She slaves
her laptop to the local Access Grid node software, and sees the entrance to the
supercomputer venue on her laptop interface. Cathy then uses the AG client software on
her laptop to delegate a proxy of her GSI identity credential, good for the two hours the
session is scheduled to last, into the local Access Grid node. The node is now able to
enter the supercomputer venue, and real-time displays of current load on the system and
available nodes appear on the AG display. Cathy’s laptop, still slaved to the node, enters
the venue and her personal supercomputer workspace appears. This scenario is related to
the synchronous collaboration scenarios discussed in section 3.2.2. Multiple identity
credentials are used in combination to enable collaborative work.
3.7.1
Discussion
In this scenario, we see an interactive, collaborative interface to a supercomputer that
relies upon the access control imposed by an Access Grid Virtual Venue. The Virtual
Venue has to be able to accept credentials from multiple users and use them to
authenticate to the resources made available to the users by the Venue and to shared
applications available through the venue. Further more, the user may need to have
multiple credentials, some that are used to authenticate to the Access Grid and authorize
his access to the Venue and other credentials which she will need to delegate to the
Venue to access the underlying Grid resources. In addition credentials may be used to
give users access permissions to collaborative AG sessions and show e.g. group
membership.
3.8 Requirements for the delegation of credentials when bridging
different mechanisms
Although delegation could be considered separate from authentication each mechanism
may have its own way of delegating, and may require authentication to be done using its
mechanism. This is surely the case with current GSI and Kerberos, complicating the
delegation process, since it requires both parties to have GSI and Kerberos credentials
which may not be possible.
Our extensions to GSSAPI [MED02] where the delegation is separate from the
authentication can help solve this but needs to be implemented such that the delegation of
a credential can be done using a context of another mechanism. i.e. delegate a proxy but
use a Kerberos context.
Credentials are normally tied to a location and should not be copied. Kerberos tried to do
this with channel bindings, but VPNs and NAT have made this impractical. Other
mechanisms may use other methods such as using a host process/credential during
delegation. So simply coping credentials should not be considered an option.
Since delegation of credentials could require processing on both the initiator and
acceptor, it implies that both sides will have to have an implementation of all the
mechanisms involved. This could also complicate the process if some intermediate
service only has one mechanism. This might be solvable by encapsulation of the
delegated credential having it carried by another mechanism in its delegate credential.
Such an approach appears feasible for Kerberos where the initiator requests a forwardable
ticket useable on the final server which is then encapsulated by a proxy certificate such
that it can be transferred to a second proxy certificate by intermediate servers which do
not need to understand Kerberos when the proxy certificate is delegated. The fact that in
Kerberos only the client needs to participate in the creation of the forwarded ticket is the
enabling feature for such encapsulation to work. It is different then a copy operation, as
the initiator can request the forwardable ticket only to be useable on the final acceptor,
not at the intermediate server.
However, such encapsulation will not work with the current or proposed GSI, as both the
initiator and acceptor are involved in the delegation and negotiate the contents the
delegated proxy credential. To enable GSI to support Kerberos credential encapsulations
the key which was created by the initiator would need to be sent along with the proxy
certificate. This would require protection of the key, e.g. through encryption. In the
current GSI the acceptor generates the key, originally to avoid encryption and meet U.S
export restrictions. It might even be possible to encapsulate a proxy certificate in a
kerberos forwardable ticket.
3.9 Multiple delegation scenario with identity certificates from
multiple CAs
When multiple delegations of a credential have to take place via a number of intermediate
servers, it can create problems if an intermediate server does not trust the certification
authority (CA) used by the end-entity. To support such a scenario the end entity (the user)
may have to supply identity certificates issued by a number of CAs such that all
intermediate servers can trust the end entities identity.
3.10 User-to-user authentication with multiple credentials on one or
both sides
The current user-to-user authentication is a subset of the more general authentication
scenario where each side can decide who to trust. It is in effect a simple authorization
decision. The current GSI implementation will accept any proxy with the same base
subject name, which indicates that came from the same user. The initiator and acceptor
will need to decide which of their many credentials they hold will be used for
authentication. The SSL/TLS protocol [TLS] does not help in this situation, as during the
handshake, each side sends a list of CAs it is willing to trust. The parties could then look
at the list and find a suitable certificate to use which is signed by a CA the other side
trusts. But this does not guarantee that the subject name will be acceptable. The concept
of user-to-user authentication needs to be expanded here to support a user who has
several credentials possibly from the same CA.
4 Summary of Requirements
This section pulls out and elaborates on requirements that appear in multiple scenarios
earlier in this document. These requirements are listed roughly in dependency order.
4.1 Language for Describing Credentials
A method is needed to describe credentials. This need exists for entities to negotiate
credential usage between them and for an entity to request a particular credential from
either a local storage mechanism or a remote credential service.
This language should include the underlying credential mechanism as well as particular
details about the credentials – e.g. identity, role, specific privileges, etc.
4.2 Storage and Management of Multiple Credentials
A method is needed for entities to store multiple credentials they own. Entities need to be
able to retrieve and manage their credentials based on different attributes of the
credentials, such as identity bound by the credentials, purpose of the credentials (e.g.
signing, encryption), capabilities granted by the credentials. Credentials in the storage
need to be not only individually retrievable, but also individually manageable in terms of
renewal.
4.3 Delegation of multiple credentials
A method is needed to delegate multiple credentials of various types. Delegation of
credentials that provides for the bridging of different mechanisms may require the ability
to encapsulate one credential in another credential. Further more, to support long
delegation chains a user may have to provide several, redundant credentials signed by
different certification authorities (to provide a common trust anchor for every entity or
process involved in the delegation).
4.4 Negotiation of credentials
Two entities, with possibly both having multiple credentials, need a method of
negotiating which credentials need to be used for authentication and also for
authorization. To authorize requests based on the least privilege principle entities need to
negotiate the exact subset of credentials necessary for a specific access.
4.5 Multiple credentials for authentication and/or authorization
The requirement for a user to present multiple credentials for authorization exists in a
number of the scenarios. This entails a user to present both an identity credential and an
attribute from another user or service (e.g. an attribute certificate or CAS credentials) in
order to perform a specific action.
5 Contact Information
Randy Butler
National Center for Supercomputing Applications
rbutler@ncsa.uiuc.edu
Doug Engert
Argonne National Laboratory
deengert@anl.gov
Keith Jackson
Lawrence Berkeley National Laboratory
krjackson@lbl.gov
Markus Lorch
Virginia Polytechnic Institute and State University
mlorch@vt.edu
Robert Olson
Argonne National Laboratory
olson@mcs.anl.gov
Von Welch
Distributed Systems Laboratory
University of Chicago and Argonne National Laboratory
welch@mcs.anl.gov
6 Security Considerations
This document is entirely devoted to the discussion of credentials used for security
purposes.
This document makes no recommendations about particular approaches or products for
managing credentials and should not be taken as a guide implementation or an
endorsement of any technology or product.
7 Intellectual Property Statement
The GGF takes no position regarding the validity or scope of any intellectual property or
other rights that might be claimed to pertain to the implementation or use of the
technology described in this document or the extent to which any license under such
rights might or might not be available; neither does it represent that it has made any effort
to identify any such rights. Copies of claims of rights made available for publication and
any assurances of licenses to be made available, or the result of an attempt made to obtain
a general license or permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the GGF Secretariat.
The GGF invites any interested party to bring to its attention any copyrights, patents or
patent applications, or other proprietary rights which may cover technology that may be
required to practice this recommendation. Please address the information to the GGF
Executive Director (see contacts information at GGF website).
8 Full Copyright Notice
Copyright (C) Global Grid Forum (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and
derivative works that comment on or otherwise explain it or assist in its implementation
may be prepared, copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright notice or references to the
GGF or other organizations, except as needed for the purpose of developing Grid
Recommendations in which case the procedures for copyrights defined in the GGF
Document process must be followed, or as required to translate it into languages other
than English.
The limited permissions granted above are perpetual and will not be revoked by the GGF
or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and
THE GLOBAL GRID FORUM DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE
USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."
9 References
[ISE97] Isenhour, P. L.; Begole, J. B.; Heagy, W. and Shaffer, C.
"Sieve: A Java-based collaborative visualization environment" In Late Breaking Hot
Topics Proceedings, IEEE Visualization'97, pages 13--16, Phoenix, AZ, Oct. 1997.
[LOR02] M. Lorch and D. Kafura, "Symphony - A Java-based Composition and
Manipulation Framework for Computational Grids", Proceedings of the 2nd IEEE/ACM
International Symposium on Cluster Computing and the Grid, May 2002, Berlin,
Germany
[MED02] S. Meder, V. Welch, S. Tuecke, D. Engert, “GSS-API Extentions” GGF
Internet Draft, http://www.gridforum.org/security/ggf4_2002-02/draft-ggf-gssextensions-05.pdf, February 2002
[PEA02] L. Pearlman, V. Welch, I. Foster, C. Kesselman, S. Tuecke
“A Community Authorization Service for Group Collaboration“, 2002 IEEE Workshop
on Policies for Distributed Systems and Networks
[TLS] IETF Transport Layer Security (TLS) Working Group,
http://www.ietf.org/html.charters/tls-charter.html, 2002-06-23