Request for Comments: 3820 ANL
Category: Standards Track V. Welch
NCSA
D. Engert
ANL
L. Pearlman
USC/ISI
M. Thompson
LBNL
June 2004
Internet X.509 Public Key Infrastructure (PKI)
Proxy Certificate Profile
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document forms a certificate profile for Proxy Certificates,
based on X.509 Public Key Infrastructure (PKI) certificates as
defined in RFC 3280, for use in the Internet. The term Proxy
Certificate is used to describe a certificate that is derived from,
and signed by, a normal X.509 Public Key End Entity Certificate or by
another Proxy Certificate for the purpose of providing restricted
proxying and delegation within a PKI based authentication system.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Approach . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Background . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Motivation for Proxying. . . . . . . . . . . . . . . . . 5
2.4. Motivation for Restricted Proxies. . . . . . . . . . . . 7
2.5. Motivation for Unique Proxy Name . . . . . . . . . . . . 8
2.6. Description Of Approach. . . . . . . . . . . . . . . . . 9
2.7. Features Of This Approach. . . . . . . . . . . . . . . . 10
3. Certificate and Certificate Extensions Profile . . . . . . . . 12
3.1. Issuer . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Issuer Alternative Name. . . . . . . . . . . . . . . . . 12
3.3. Serial Number. . . . . . . . . . . . . . . . . . . . . . 12
3.4. Subject. . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5. Subject Alternative Name . . . . . . . . . . . . . . . . 13
3.6. Key Usage and Extended Key Usage . . . . . . . . . . . . 13
3.7. Basic Constraints. . . . . . . . . . . . . . . . . . . . 14
3.8. The ProxyCertInfo Extension. . . . . . . . . . . . . . . 14
4. Proxy Certificate Path Validation. . . . . . . . . . . . . . . 17
4.1. Basic Proxy Certificate Path Validation. . . . . . . . . 19
4.2. Using the Path Validation Algorithm. . . . . . . . . . . 23
5. Commentary . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Relationship to Attribute Certificates . . . . . . . . . 24
5.2. Kerberos 5 Tickets . . . . . . . . . . . . . . . . . . . 28
5.3. Examples of usage of Proxy Restrictions. . . . . . . . . 28
5.4. Delegation Tracing . . . . . . . . . . . . . . . . . . . 29
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 30
6.1. Compromise of a Proxy Certificate. . . . . . . . . . . . 30
6.2. Restricting Proxy Certificates . . . . . . . . . . . . . 31
6.3. Relying Party Trust of Proxy Certificates. . . . . . . . 31
6.4. Protecting Against Denial of Service with Key Generation 32
6.5. Use of Proxy Certificates in a Central Repository. . . . 32
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 33
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. Normative References . . . . . . . . . . . . . . . . . . 33
8.2. Informative References . . . . . . . . . . . . . . . . . 33
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 34
Appendix A. 1988 ASN.1 Module. . . . . . . . . . . . . . . . . . . 35
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Full Copyright Notice. . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction
Use of a proxy credential [i7] is a common technique used in security
systems to allow entity A to grant to another entity B the right for
B to be authorized with others as if it were A. In other words,
entity B is acting as a proxy on behalf of entity A. This document
forms a certificate profile for Proxy Certificates, based on the RFC
3280, "Internet X.509 Public Key Infrastructure Certificate and CRL
Profile" [n2].
In addition to simple, unrestricted proxying, this profile defines:
* A framework for carrying policies in Proxy Certificates that
allows proxying to be limited (perhaps completely disallowed)
through either restrictions or enumeration of rights.
* Proxy Certificates with unique names, derived from the name of the
end entity certificate name. This allows the Proxy Certificates
to be used in conjunction with attribute assertion approaches such
as Attribute Certificates [i3] and have their own rights
independent of their issuer.
Section 2 provides a non-normative overview of the approach. It
begins by defining terminology, motivating Proxy Certificates, and
giving a brief overview of the approach. It then introduces the
notion of a Proxy Issuer, as distinct from a Certificate Authority,
to describe how end entity signing of a Proxy Certificate is
different from end entity signing of another end entity certificate,
and therefore why this approach does not violate the end entity
signing restrictions contained in the X.509 keyCertSign field of the
keyUsage extension. It then continues with discussions of how
subject names are used by this proxying approach, and features of
this approach.
Section 3 defines requirements on information content in Proxy
Certificates. This profile addresses two fields in the basic
certificate as well as five certificate extensions. The certificate
fields are the subject and issuer fields. The certificate extensions
are subject alternative name, issuer alternative name, key usage,
basic constraints, and extended key usage. A new certificate
extension, Proxy Certificate Information, is introduced.
Section 4 defines path validation rules for Proxy Certificates.
Section 5 provides non-normative commentary on Proxy Certificates.
Section 6 discusses security considerations relating to Proxy
Certificates.
References, listed in Section 8, are sorted into normative and
information references. Normative references, listed in Section 8.1,
are in the form [nXX]. Informative references, listed in Section
8.2, are in the form [iXX].
Section 9 contains acknowledgements.
Following Section 9, contains the Appendix, the contact information
for the authors, the intellectual property information, and the
copyright information for this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [n1].
2. Overview of Approach
This section provides non-normative commentary on Proxy Certificates.
The goal of this specification is to develop a X.509 Proxy
Certificate profile and to facilitate their use within Internet
applications for those communities wishing to make use of restricted
proxying and delegation within an X.509 Public Key Infrastructure
(PKI) authentication based system.
This section provides relevant background, motivation, an overview of
the approach, and related work.
2.1. Terminology
This document uses the following terms:
* CA: A "Certification Authority", as defined by X.509 [n2]
* EEC: An "End Entity Certificate", as defined by X.509. That is,
it is an X.509 Public Key Certificate issued to an end entity,
such as a user or a service, by a CA.
* PKC: An end entity "Public Key Certificate". This is synonymous
with an EEC.
* PC: A "Proxy Certificate", the profile of which is defined by this
document.
* PI: A "Proxy Issuer" is an entity with an End Entity Certificate
or Proxy Certificate that issues a Proxy Certificate. The Proxy
Certificate is signed using the private key associated with the
public key in the Proxy Issuer’s certificate.
* AC: An "Attribute Certificate", as defined by "An Internet
Attribute Certificate Profile for Authorization" [i3].
* AA: An "Attribute Authority", as defined in [i3].
2.2. Background
Computational and Data "Grids" have emerged as a common approach to
constructing dynamic, inter-domain, distributed computing
environments. As explained in [i5], large research and development
efforts starting around 1995 have focused on the question of what
protocols, services, and APIs are required for effective, coordinated
use of resources in these Grid environments.
In 1997, the Globus Project (www.globus.org) introduced the Grid
Security Infrastructure (GSI) [i4]. This library provides for public
key based authentication and message protection, based on standard
X.509 certificates and public key infrastructure, the SSL/TLS
protocol [i2], and delegation using proxy certificates similar to
those profiled in this document. GSI has been used, in turn, to
build numerous middleware libraries and applications, which have been
deployed in large-scale production and experimental Grids [i1]. GSI
has emerged as the dominant security solution used by Grid efforts
worldwide.
This experience with GSI has proven the viability of restricted
proxying as a basis for authorization within Grids, and has further
proven the viability of using X.509 Proxy Certificates, as defined in
this document, as the basis for that proxying. This document is one
part of an effort to migrate this experience with GSI into standards,
and in the process clean up the approach and better reconcile it with
existing and recent standards.
2.3. Motivation for Proxying
A motivating example will assist in understanding the role proxying
can play in building Internet based applications.
Steve is an engineer who wants to use a reliable file transfer
service to manage the movement of a number of large files around
between various hosts on his company’s Intranet-based Grid. From his
laptop he wants to submit a number of transfer requests to the
service and have the files transferred while he is doing other
things, including being offline. The transfer service may queue the
requests for some time (e.g., until after hours or a period of low
resource usage) before initiating the transfers. The transfer
service will then, for each file, connect to each of the source and
destination hosts, and instruct them to initiate a data connection
directly from the source to the destination in order to transfer the
file. Steve will leave an agent running on his laptop that will
periodically check on progress of the transfer by contacting the
transfer service. Of course, he wants all of this to happen securely
on his company’s resources, which requires that he initiate all of
this using his PKI smartcard.
This scenario requires authentication and delegation in a variety of
places:
* Steve needs to be able to mutually authenticate with the reliable
file transfer service to submit the transfer request.
* Since the storage hosts know nothing about the file transfer
service, the file transfer service needs to be delegated the
rights to mutually authenticate with the various storage hosts
involved directly in the file transfer, in order to initiate the
file transfer.
* The source and destination hosts of a particular transfer must be
able to mutual authenticate with each other, to ensure the file is
being transferred to and from the proper parties.
* The agent running on Steve’s laptop must mutually authenticate
with the file transfer service in order to check the result of the
transfers.
Proxying is a viable approach to solving two (related) problems in
this scenario:
* Single sign-on: Steve wants to enter his smartcard password (or
pin) once, and then run a program that will submit all the file
transfer requests to the transfer service, and then periodically
check on the status of the transfer. This program needs to be
given the rights to be able to perform all of these operations
securely, without requiring repeated access to the smartcard or
Steve’s password.
* Delegation: Various remote processes in this scenario need to
perform secure operations on Steve’s behalf, and therefore must be
delegated the necessary rights. For example, the file transfer
service needs to be able to authenticate on Steve’s behalf with
the source and destination hosts, and must in turn delegate rights
to those hosts so that they can authenticate with each other.
Proxying can be used to secure all of these interactions:
* Proxying allows for the private key stored on the smartcard to be
accessed just once, in order to create the necessary proxy
credential, which allows the client/agent program to be authorized
as Steve when submitting the requests to the transfer service.
Access to the smartcard and Steve’s password is not required after
the initial creation of the proxy credential.
* The client program on the laptop can delegate to the file transfer
service the right to act on Steve’s behalf. This, in turn, allows
the service to authenticate to the storage hosts and inherit
Steve’s privileges in order to start the file transfers.
* When the transfer service authenticates to hosts to start the file
transfer, the service can delegate to the hosts the right to act
on Steve’s behalf so that each pair of hosts involved in a file
transfer can mutually authenticate to ensure the file is securely
transferred.
* When the agent on the laptop reconnects to the file transfer
service to check on the status of the transfer, it can perform
mutual authentication. The laptop may use a newly generated proxy
credential, which is just created anew using the smartcard.
This scenario, and others similar to it, is being built today within
the Grid community. The Grid Security Infrastructure’s single sign-
on and delegation capabilities, built on X.509 Proxy Certificates,
are being employed to provide authentication services to these
applications.
2.4. Motivation for Restricted Proxies
One concern that arises is what happens if a machine that has been
delegated the right to inherit Steve’s privileges has been
compromised? For example, in the above scenario, what if the machine
running the file transfer service is compromised, such that the
attacker can gain access to the credential that Steve delegated to
that service? Can the attacker now do everything that Steve is
allowed to do?
A solution to this problem is to allow for restrictions to be placed
on the proxy by means of policies on the proxy certificates. For
example, the machine running the reliable file transfer service in
the above example might only be given Steve’s right for the purpose
of reading the source files and writing the destination files.
Therefore, if that file transfer service is compromised, the attacker
cannot modify source files, cannot create or modify other files to
which Steve has access, cannot start jobs on behalf of Steve, etc.
All that an attacker would be able to do is read the specific files
to which the file transfer service has been delegated read access,
and write bogus files in place of those that the file transfer
service has been delegated write access. Further, by limiting the
lifetime of the credential that is delegated to the file transfer
service, the effects of a compromise can be further mitigated.
Other potential uses for restricted proxy credentials are discussed
in [i7].
2.5. Motivation for Unique Proxy Name
The dynamic creation of entities (e.g., processes and services) is an
essential part of Grid computing. These entities will require rights
in order to securely perform their function. While it is possible to
obtain rights solely through proxying as described in previous
sections, this has limitations. For example what if an entity should
have rights that are granted not just from the proxy issuer but from
a third party as well? While it is possible in this case for the
entity to obtain and hold two proxy certifications, in practice it is
simpler for subsequent credentials to take the form of attribute
certificates.
It is also desirable for these entities to have a unique identity so
that they can be explicitly discussed in policy statements. For
example, a user initiating a third-party FTP transfer could grant
each FTP server a PC with a unique identity and inform each server of
the identity of the other, then when the two servers connected they
could authenticate themselves and know they are connected to the
proper party.
In order for a party to have rights of it’s own it requires a unique
identity. Possible options for obtaining an unique identity are:
1) Obtain an identity from a traditional Certification Authority
(CA).
2) Obtain a new identity independently - for example by using the
generated public key and a self-signed certificate.
3) Derive the new identity from an existing identity.
In this document we describe an approach to option #3, because:
* It is reasonably light-weight, as it can be done without
interacting with a third party. This is important when
creating identities dynamically.
* As described in the previous section, a common use for PCs is
for restricted proxying, so deriving their identity from the
identity of the EEC makes this straightforward. Nonetheless
there are circumstances where the creator does not wish to
delegate all or any of its rights to a new entity. Since the
name is unique, this is easily accomplished by #3 as well, by
allowing the application of a policy to limit proxying.
2.6. Description Of Approach
This document defines an X.509 "Proxy Certificate" or "PC" as a means
of providing for restricted proxying within an (extended) X.509 PKI
based authentication system.
A Proxy Certificate is an X.509 public key certificate with the
following properties:
1) It is signed by either an X.509 End Entity Certificate (EEC), or
by another PC. This EEC or PC is referred to as the Proxy Issuer
(PI).
2) It can sign only another PC. It cannot sign an EEC.
3) It has its own public and private key pair, distinct from any
other EEC or PC.
4) It has an identity derived from the identity of the EEC that
signed the PC. When a PC is used for authentication, in may
inherit rights of the EEC that signed the PC, subject to the
restrictions that are placed on that PC by the EEC.
5) Although its identity is derived from the EEC’s identity, it is
also unique. This allows this identity to be used for
authorization as an independent identity from the identity of the
issuing EEC, for example in conjunction with attribute assertions
as defined in [i3].
6) It contains a new X.509 extension to identify it as a PC and to
place policies on the use of the PC. This new extension, along
with other X.509 fields and extensions, are used to enable proper
path validation and use of the PC.
The process of creating a PC is as follows:
1) A new public and private key pair is generated.
2) That key pair is used to create a request for a Proxy Certificate
that conforms to the profile described in this document.
3) A Proxy Certificate, signed by the private key of the EEC or by
another PC, is created in response to the request. During this
process, the PC request is verified to ensure that the requested
PC is valid (e.g., it is not an EEC, the PC fields are
appropriately set, etc).
When a PC is created as part of a delegation from entity A to entity
B, this process is modified by performing steps #1 and #2 within
entity B, then passing the PC request from entity B to entity A over
an authenticated, integrity checked channel, then entity A performs
step #3 and passes the PC back to entity B.
Path validation of a PC is very similar to normal path validation,
with a few additional checks to ensure, for example, proper PC
signing constraints.
2.7. Features Of This Approach
Using Proxy Certificates to perform delegation has several features
that make it attractive:
* Ease of integration
o Because a PC requires only a minimal change to path validation,
it is very easy to incorporate support for Proxy Certificates