Internet Draft S. Tuecke
Document: draft-ietf-pkix-proxy-04 D. Engert
I. Foster
Initial Version March 2001 ANL
Revised October 2002 V. Welch
Expires April 2003 U. Chicago
M. Thompson
LBNL
L. Pearlman
C. Kesselman
USC/ISI
Internet X.509 Public Key Infrastructure
Proxy Certificate Profile
Status of this Memo
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them
other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html.
This document provides information to the community
regarding the profile of the X.509 Proxy Certificate. It
tuecke@mcs.anl.gov 1
X.509 Proxy Certificate Profile February 2003
Expires August 2003
defines a standard for implementing X.509 Proxy
Certificates.
Abstract
This document forms a certificate profile for Proxy
Certificates, based on X.509 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 impersonation within a PKI
based authentication system.
Table of Contents
1 Introduction.........................................3
2 Overview of Approach.................................5
2.1 Terminology..........................................5
2.2 Background...........................................6
2.3 Motivation for Impersonation.........................7
2.4 Motivation for Restricted Proxies....................9
2.5 Motivation for Unique Proxy Name....................10
2.6 Description Of Approach.............................11
2.7 Features Of This Approach...........................13
3 Certificate and Certificate Extensions Profile......15
3.1 Issuer..............................................15
3.2 Issuer Alternative Name.............................15
3.3 Serial Number.......................................15
3.4 Subject.............................................16
3.5 Subject Alternative Name............................16
3.6 Key Usage...........................................16
3.7 Extended Key Usage..................................17
3.8 Basic Constraints...................................18
3.9 The ProxyCertInfo Extension.........................18
4 Proxy Certificate Path Validation...................22
4.1 Basic Proxy Certificate Path Validation.............24
4.2 Using the Proxy Certificate Path Validation Algorithm29
5 Commentary..........................................30
5.1 Relationship to Attribute Certificates..............30
5.2 Kerberos 5 Tickets..................................35
5.3 Examples of usage of Proxy Restrictions.............36
tuecke@mcs.anl.gov 2
X.509 Proxy Certificate Profile February 2003
Expires August 2003
5.4 Delegation Tracing..................................37
6 Security Considerations.............................38
6.1 Compromise of a Proxy Certificate...................38
6.2 Restricting Proxy Certificates......................39
6.3 Relying Party Trust of Proxy Certificates...........40
7 References..........................................40
8 Acknowledgments.....................................41
9 Change Log..........................................42
10 Contact Information.................................46
11 Copyright Notice....................................47
12 Intellectual Property Statement.....................48
Appendix A. 1988 ASN.1 Module..........................48
1 Introduction
Use of a proxy credential[10] for impersonation is a
common technique used in security systems to allow entity
A to grant to another entity B the right for B to
authenticate with others as if it were A. In other words,
entity B is impersonating 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" [7].
In addition to simple, unrestricted impersonation, this
profile defines:
* A framework for carrying policies in Proxy Certificates
that allow impersonation 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 [4] 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
tuecke@mcs.anl.gov 3
X.509 Proxy Certificate Profile February 2003
Expires August 2003
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 impersonation 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.
Section 7 contains the references.
Section 8 contains acknowledgements.
Section 9 contains a log of changes made in each version
of this draft.
Section 10 contains contact information for the authors.
Section 11 contains the copyright information for this
document.
Section 12 contains the intellectual property information
for this document.
tuecke@mcs.anl.gov 4
X.509 Proxy Certificate Profile February 2003
Expires August 2003
This document was written under the auspices of the Global
Grid Forum Grid Security Infrastructure Working Group.
For more information on this and other related work, see
http://www.gridforum.org/2_SEC/GSI.htm.
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 RFC-2119 [1].
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 impersonation and delegation within
an X.509 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 "Certificate Authority", as defined by X.509 [7].
* 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.
tuecke@mcs.anl.gov 5
X.509 Proxy Certificate Profile February 2003
Expires August 2003
* PI: A "Proxy Issuer" is the End Entity Certificate or
Proxy Certificate that issued a Proxy Certificate.
* AC: An "Attribute Certificate", as defined by "An
Internet Attribute Certificate Profile for
Authorization" [4].
* AA: An "Attribute Authority", as defined in [4].
2.2 Background
Computational and Data "Grids" have emerged as a common
approach to constructing dynamic, inter-domain,
distributed computing environments. As explained in [6],
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) [5]. 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 [3], 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 [2]. GSI has emerged as the dominant
security solution used by Grid efforts worldwide.
This experience with GSI has proven the viability of
restricted impersonation as a basis for authentication and
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 impersonation. 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.
tuecke@mcs.anl.gov 6
X.509 Proxy Certificate Profile February 2003
Expires August 2003
2.3 Motivation for Impersonation
A motivating example will assist in understanding the role
impersonation 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 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 contacts
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 remote 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.
tuecke@mcs.anl.gov 7
X.509 Proxy Certificate Profile February 2003
Expires August 2003
* The agent running on Steve's laptop must mutually
authenticate with the file transfer service in order to
check the result of the transfers.
Impersonation 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.
Impersonation can be used to secure all of these
interactions:
* Impersonation allows for the private key stored on the
smartcard to be accessed just once, in order to create
the necessary impersonation credential, which allows
the client/agent program to impersonate Steve (that is,
authenticate 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 impersonation credential.
* The client program on the laptop can delegate to the
file transfer service the right to impersonate Steve.
This, in turn, allows the service to authenticate to
the storage hosts as if it were Steve in order to start
the file transfers.
tuecke@mcs.anl.gov 8
X.509 Proxy Certificate Profile February 2003
Expires August 2003
* When the transfer service authenticates to hosts to
start the file transfer, the service can delegate to
the hosts the right to impersonate Steve 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 impersonation
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 impersonate Steve 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 impersonation 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 the right to impersonate Steve 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
tuecke@mcs.anl.gov 9
X.509 Proxy Certificate Profile February 2003
Expires August 2003
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 [10].
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 impersonation 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.
tuecke@mcs.anl.gov 10
X.509 Proxy Certificate Profile February 2003
Expires August 2003
3) Derive the new identity from an existing identity.
In this document we use method #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 impersonation, 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
impersonation.
2.6 Description Of Approach
This document defines an X.509 "Proxy Certificate" or "PC"
as a means of providing for restricted impersonation
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.
tuecke@mcs.anl.gov 11
X.509 Proxy Certificate Profile February 2003
Expires August 2003
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
[4].
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. In order to make
the appropriate PC(s) and EEC available for path
validation, the authentication protocol using the PC (e.g.
TLS) MAY pass the entire PC and EEC chain as part of the
authentication protocol.
tuecke@mcs.anl.gov 12
X.509 Proxy Certificate Profile February 2003
Expires August 2003
2.7 Features Of This Approach
Using Proxy Certificates to perform delegation has several
features that make it attractive:
* Ease of integration
. Because a PC requires only a minimal change to path
validation, it is very easy to incorporate support
for Proxy Certificates into existing X.509 based
software. For example, SSL/TLS requires no protocol
changes to support authentication using a PC.
Further, an SSL/TLS implementation requires only
minor changes to support PC path validation, and to
retrieve the authenticated subject of the signing
EEC instead of the subject of the PC for
authorization purposes.
. Many existing authorization systems use the X.509
subject name as the basis for access control. Proxy
Certificates that perform impersonation can be used
with such authorization systems without
modification, since such a PC inherits its name and
rights from the EEC that signed it and the EEC name
can be used in place of the PC name for
authorization decisions.
* Ease of use
. Using PC for single sign-on helps make X.509 PKI
authentication easier to use, by allowing users to
"login" once and then perform various operations
securely.
. For many users, properly managing their own EEC
private key is a nuisance at best, and a security
risk at worst. One option easily enabled with a PC
is to manage the EEC private keys and certificates
in a centrally managed repository. When a user
needs a PKI credential, the user can login to the
repository using name/password, one time password,
etc. Then the repository can delegate a PC to the
user with impersonation rights, but continue to
tuecke@mcs.anl.gov 13
X.509 Proxy Certificate Profile February 2003
Expires August 2003
protect the EEC private key in the repository.
* Protection of private keys
. By using the remote delegation approach outlined
above, entity A can delegate a PC to entity B,
without entity B ever seeing the private key of
entity A, and without entity A ever seeing the
private key of the newly delegated PC held by entity
B. In other words, private keys never need to be
shared or communicated by the entities participating
in a delegation of a PC.
. When implementing single sign-on, using a PC helps
protect the private key of the EEC, because it
minimizes the exposure and use of that private key.
For example, when an EEC private key is password
protected on disk, the password and unencrypted
private key need only be available during the
creation of the PC. That PC can then be used for
the remainder of its valid lifetime, without
requiring access to the EEC password or private key.
Similarly, when the EEC private key lives on a
smartcard, the smartcard need only be present in the
machine during the creation of the PC.
* Limiting consequences of a compromised key
. When creating a PC, the PI can limit the validity
period of the PC, the depth of the PC path that can
be created by that PC, and key usage of the PC and
its descendents. Further, fine-grained policies can
be carried by a PC to even further restrict the
operations that can be performed using the PC. These
restrictions permit the PI to limit damage that
could be done by the bearer of the PC, either
accidentally or maliciously.
. A compromised PC private key does NOT compromise the
EEC private key. This makes a short term, or an
otherwise restricted PC attractive for day-to-day
use, since a compromised PC does not require the
user to go through the usually cumbersome and time
tuecke@mcs.anl.gov 14
X.509 Proxy Certificate Profile February 2003
Expires August 2003
consuming process of having the EEC with a new
private key reissued by the CA.
See Section 5 below for more discussion on how Proxy
Certificates relate to Attribute Certificates.
3 Certificate and Certificate Extensions Profile
This section defines the usage of X.509 certificate fields
and extensions in Proxy Certificates, and defines one new
extension for Proxy Certificate Information.
3.1 Issuer
The Proxy Issuer of a Proxy Certificate MUST be either an
End Entity Certificate, or another Proxy Certificate.
The Proxy Issuer MUST NOT have an empty subject field.
The issuer field of a Proxy Certificate MUST contain the
subject field of it's Proxy Issuer.
A Proxy Certificate MUST NOT be used to sign an End Entity
Certificate or a CA Certificate.
3.2 Issuer Alternative Name
The issuerAltName extension MUST NOT be present in a Proxy
Certificate.
3.3 Serial Number
The serial number of a Proxy Certificate (PC) SHOULD be
unique amongst all Proxy Certificates issued by a
particular Proxy Issuer. However, a Proxy Issuer MAY use
an approach to assigning serial numbers that merely
ensures a high probability of uniqueness.
For example, a Proxy Issuer MAY use a sequentially
assigned integer or a UUID to assign a unique serial
number to a PC it issues. Or a Proxy Issuer MAY use a
SHA-1 hash of the PC public key to assign a serial number
with a high probability of uniqueness.
tuecke@mcs.anl.gov 15
X.509 Proxy Certificate Profile February 2003
Expires August 2003
3.4 Subject
The subject field of a Proxy Certificate MUST be the
issuer field (that is the subject of the Proxy Issuer)
appended with a single Common Name component. The value
of the Common Name SHOULD be unique amongst all Proxy
Certificates with the same issuer. However, the Proxy
Issuer MAY use an approach to assigning Common Name values
that merely ensures a high probability of uniqueness. This
value MAY be the same value used for the serial number.
The result of this approach is that all subject names of
Proxy Certificates should be derived from the name of the
issuing EEC (it will be the first part of the subject name
appended with one or more CN components) and be unique.
3.5 Subject Alternative Name
The subjectAltName extension MUST NOT be present in a
Proxy Certificate.
3.6 Key Usage
If the issuer certificate includes the keyUsage extension,
then the Proxy Certificate MUST include a keyUsage
extension, which MAY further restrict the issuer's
keyUsage. The keyUsage extension MUST be critical if the
keyUsage extension in the issuer certificate is marked
critical.
If the issuer certificate does not include a keyUsage
extension, then the Proxy Certificate MAY include a
keyUsage extension to restrict the key usage of the Proxy
Certificate.
If the keyUsage extension is present in a Proxy
Certificate, it MUST conform to the following
restrictions:
. The keyCertSign bit MUST NOT be asserted.
tuecke@mcs.anl.gov 16
X.509 Proxy Certificate Profile February 2003
Expires August 2003
. The nonRepudiate bit MUST NOT be asserted.
The following restriction applies to each of these
bits: digitalSignature, keyEncipherment,
dataEncipherment, keyAgreement, cRLSign,
encipherOnly, decipherOnly. If this bit in the
issuer certificate is not asserted, then this bit in
the Proxy Certificate MUST NOT be asserted. If this
bit in the issuer certificate is asserted, or if the
issuer certificate does not include a keyUsage
extension, then this bit in the Proxy Certificate
MAY be either asserted or not asserted.
3.7 Extended Key Usage
If the issuer certificate includes the extKeyUsage
extension, then:
The Proxy Certificate MUST include an extKeyUsage
extension.
Any OID that is contained in the Proxy Certificate's
extKeyUsage extension MUST be present in the issuer
certificate's extKeyUsage extension.
The Proxy Certificate's extKeyUsage extension MAY omit
any OID that is present in the issuer certificate's
extKeyUsage.
If the issuer certificate's extKeyUsage extension is
critical, then the Proxy Certificate's extKeyUsage MUST
be critical.
If the issuer certificate's extKeyUsage extension is
not critical, then the Proxy Certificate's extKeyUsage
MAY be critical or non-critical.
If the issuer certificate does not include the extKeyUsage
extension, then the Proxy Certificate MAY include an
extKeyUsage extension to restrict the key usage of the
Proxy Certificate. In this case, the extKeyUsage
extension MAY be critical or non-critical.
tuecke@mcs.anl.gov 17
X.509 Proxy Certificate Profile February 2003
Expires August 2003
3.8 Basic Constraints
The cA field in the basic constraints extension MUST NOT
be TRUE.
3.9 The ProxyCertInfo Extension
A new extension, ProxyCertInfo, is defined in this
subsection. Presence of the ProxyCertInfo extension
indicates that a certificate is a Proxy Certificate and
whether or not the issuer of the certificate has placed
any restrictions on its use.
id-ce-proxy-cert-info OBJECT IDENTIFIER ::= { id-ce ?? }
ProxyCertInfo ::= SEQUENCE {
version INTEGER (0..MAX),
pCPathLenConstraint INTEGER (0..MAX) OPTIONAL,
proxyPolicy ProxyPolicy }
ProxyPolicy ::= SEQUENCE {
policyLanguage OBJECT IDENTIFIER,
policy OCTET STRING OPTIONAL }
If a certificate is a Proxy Certificate, then the
proxyCertInfo extension MUST be present, and this
extension MUST be marked as critical.
If a certificate is not a Proxy Certificate, then the
proxyCertInfo extension MUST not be present.
The ProxyCertInfo extension consists of one required and
four optional fields, which are described in detail in the
following subsections.
3.9.1 version
The version of this specification that this PC conforms
to. Currently this value MUST be 1. Future revisions of
this specification MAY change this.
tuecke@mcs.anl.gov 18
X.509 Proxy Certificate Profile February 2003
Expires August 2003
If a proxy certificate contains a version that is unknown
to a relying party the relying party MUST disregard the PC
and it's chain when making authorization decisions.
3.9.2 pCPathLenConstraint
The pCPathLenConstraint field, if present, specifies the
maximum depth of the path of Proxy Certificates that can
be signed by this Proxy Certificate. A
pCPathLenConstraint of 0 means that this certificate MUST
NOT be used to sign a Proxy Certificate. If the
proxyCertInfo extension is not present, or if the
pCPathLenConstraint is not present, then the proxy path
length is unlimited.
3.9.3 proxyPolicy
The proxyPolicy field specifies a policy on the use of
this certificate for the purposes of authorization. Within
the proxyPolicy, the policy field is an expression of
policy, and the policyLanguage field indicates the
language in which the policy is expressed.
The proxyPolicy field in the proxyCertInfo extension does
not define a policy language to be used for proxy
restrictions; rather, it places the burden on those
parties using that extension to define an appropriate
language, and to acquire an OID for that language (or to
select an appropriate previously-defined language/OID).
Because it is essential for the PI that issues a
certificate with a proxyPolicy field and the relying party
that interprets that field to agree on its meaning, the
policy language OID must correspond to a policy language
(including semantics), not just a policy grammar.
The policyLanguage field has two values of special
importance that MUST be understood by all parties
accepting Proxy Certificates:
* Impersonation, as defined by the oid value iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) ppl(21) id-ppl-
impersonation(1), indicates that this is an
tuecke@mcs.anl.gov 19
X.509 Proxy Certificate Profile February 2003
Expires August 2003
unrestricted proxy that inherits all rights from the
issuing PI. An unrestricted proxy is a statement that
the Proxy Issuer wishes to delegate all of its
authority to the bearer (i.e., to anyone who has that
proxy certificate and can prove possession of the
associated private key). For purposes of authorization,
this an unrestricted proxy effectively impersonates the
issuing PI.
* Independent, as defined by the oid value iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) ppl(21) id-ppl-
independent(2), indicates that this is an independent
proxy that inherits no rights from the issuing PI. This
PC MUST be treated as an independent identity by
relying parties. The only rights this PC has are those
granted explicitly to it.
For either of the policyLanguage values listed above, the
policy field MUST NOT be present.
Other values for the policyLanguage field indicates that
this is a restricted proxy certification and have some
other policy limiting it's ability to do impersonation. In
this case the policy field MAY be present and it MUST
contain information expressing the policy. If the policy
field is not present the policy MUST be implicit in the
value of the policyLanguage field itself.
Proxy policies are used to limit the amount of authority
delegated, for example to assert that the proxy
certificate may be used only to make requests to a
specific server, or only to authorize specific operations
on specific resources. This document is agnostic to the
policies that can be placed in the policy field.
Proxy policies impose additional requirements on the
relying party, because only the relying party is in a
position to ensure that those policies are enforced. When
making an authorization decision based on a proxy
certificate, it is the relying party's responsibility to
verify that the requested authority is compatible with all
policies in the PC's certificate path. In other words,
tuecke@mcs.anl.gov 20
X.509 Proxy Certificate Profile February 2003
Expires August 2003
the relying party MUST verify that the following three
conditions are all met:
1) If the PC includes a proxy policy, then the relying
party knows how to interpret the policy and the request
is allowed under that policy.
2) If the Proxy Issuer is an EEC, then the relying party's
local policies authorize the request for the entity
named in the EEC.
3) If the Proxy Issuer is another PC, then conditions (1),
(2), and (3) are met for the Proxy Issuer.
If these conditions are not met, the relying party MUST
either deny authorization, or ignore the PC and the whole
certificate chain including the EEC entirely when making
its authorization decision (i.e., make the same decision
that it would have made had the PC and it's certificate
chain never been presented). Note that this verification
MUST take place regardless of whether or not the PC itself
contains a policy, as other PCs in the signing chain MAY
contain conditions that MUST be verified.
The relying party MAY impose additional restrictions as to
which proxy certificates it accepts. For example, a
relying party MAY choose to reject all proxy certificates,
or MAY choose to accept proxy certificates only for
certain operations, etc.
Note that since a proxy certificate has a unique identity
it MAY also have rights granted to it from other sources
than it's issuer. This means that the rights granted to
the bearer of a PC are the union of the rights granted to
the PC identity with the intersection of the rights
granted to the identity of PI of the PC and the policy in
the PC.
For example, imagine that Steve is authorized to read and
write files A and B on a file server, and that he uses his
EEC to create a PC that includes the policy that it can be
used only to read or write files A and C. Then a trusted
attribute authority grants an Attribute Certificate
tuecke@mcs.anl.gov 21
X.509 Proxy Certificate Profile February 2003
Expires August 2003
granting the PC the right to read file D. This would make
the rights of the PC equal to the union of the rights
granted to the PC identity (right to read file D) with the
intersection of the rights granted to Steve, the PI,
(right to read files A and B) with the policy in the PC
(can only read files A and C). This would mean the PC
would have the following rights:
* Right to read file A: Steve has this right and he
issued the PC and his policy grants this right to the
PC.
* Right to read file D: This right is granted explicitly
to the PC by a trusted authority.
The PC would NOT have the following rights:
* Right to read file B: Although Steve has this right, it
is excluded by his policy on the PC.
* Right to read file C: Although Steve's policy grants
this right, he does not have this right himself.
In many cases, the relying party will not have enough
information to evaluate the above criteria at the time
that the certificate path is validated. For example, if a
certificate is used to authenticate a connection to some
server, that certificate is typically validated during
that authentication step, before any requests have been
made of the server. In that case, the relying party MUST
either have some authorization mechanism in place that
will check the proxy policies, or reject any certificate
that contains proxy policies (or that has a parent
certificate that contains proxy policies).
4 Proxy Certificate Path Validation
Proxy Certification path processing verifies the binding
between the proxy certificate distinguished name and proxy
certificate public key. The binding is limited by
constraints which are specified in the certificates which
comprise the path and inputs which are specified by the
relying party.
tuecke@mcs.anl.gov 22
X.509 Proxy Certificate Profile February 2003
Expires August 2003
This section describes an algorithm for validating proxy
certification paths. Conforming implementations of this
specification are not required to implement this
algorithm, but MUST provide functionality equivalent to
the external behavior resulting from this procedure. Any
algorithm may be used by a particular implementation so
long as it derives the correct result.
The algorithm presented in this section validates the
proxy certificate with respect to the current date and
time. A conformant implementation MAY also support
validation with respect to some point in the past. Note
that mechanisms are not available for validating a proxy
certificate with respect to a time outside the certificate
validity period.
Valid paths begin with the end entity certificate (EEC)
that has already been validated by public key certificate
validation procedures in RFC 3280[7]. The algorithm
requires the public key of the EEC and the EEC's subject
distinguished name.
To meet the goal of verifying the proxy certificate, the
proxy certificate path validation process verifies, among
other things, that a prospective certification path (a
sequence of n certificates) satisfies the following
conditions:
(a) for all x in {1, ..., n-1}, the subject of
certificate x is the issuer of proxy certificate x+1
and the subject distinguished name of certificate x+1
is a legal subject distinguished name to have been
issued by certificate x;
(b) certificate 1 is valid proxy certificate issued by
the end entity certificate whose information is given
as input to the proxy certificate path validation
process;
(c) certificate n is the proxy certificate to be
validated;
tuecke@mcs.anl.gov 23
X.509 Proxy Certificate Profile February 2003
Expires August 2003
(d) for all x in {1, ..., n}, the certificate was
valid at the time in question; and
(e) the certificate chain does not exceed the maximum
length specified by pCPathLenConstraint.
At this point we have no plans for a proxy issuer (that
is, an EEC or PC) to revoke the PCs that it has issued.
If this feature is needed in the future, the CRL
Distribution Point extension can be used in the PI
certificates to locate a CRL.
4.1 Basic Proxy Certificate Path Validation
This section presents the algorithm in four basic steps to
mirror the description of public key certificate path
validation in RFC 3280: (1) initialization, (2) basic
proxy certificate processing, (3) preparation for the next
proxy certificate, and (4) wrap-up. Steps (1) and (4) are
performed exactly once. Step (2) is performed for all
proxy certificates in the path. Step (3) is performed for
all proxy certificates in the path except the final proxy
certificate.
Certificate path validation as described in RFC 3280 MUST
have been done prior to using this algorithm to validate
the end entity certificate. This algorithm then processes
the proxy certificate chain using the end entity
certificate information produced by RFC 3280 path
validation.
4.1.1 Inputs
This algorithm assumes the following inputs are provided
to the path processing logic:
(a) information about the entity certificate already
verified using RFC 3280 path validation. This
information includes:
(1) the end entity name,
tuecke@mcs.anl.gov 24
X.509 Proxy Certificate Profile February 2003
Expires August 2003
(2) the working_public_key output from RFC 3280 path
validation,
(3) the working_public_key_algorithm output from RFC
3280,
(4) and the working_public_key_parameters output
from RFC 3280 path validation.
(b) prospective proxy certificate path of length n.
(c) acceptable-pc-policy-set: A set of acceptable
proxy certificate policy languages. The acceptable-pc-
policy-set contains the special value any-policy if the
user is not concerned about the proxy certificate
policy languages being checked during path validation
(in this case it is assumed the proxy certificate
policies are being checked at a later time before
authorization).
(d) the current time/date.
4.1.2 Initialization
This initialization phase establishes the following state
variables based upon the inputs:
(a) working_public_key_algorithm: the digital signature
algorithm used to verify the signature of a proxy
certificate. The working_public_key_algorithm is
initialized from the input information provided from
RFC 3280 path validation.
(b) working_public_key: the public key used to verify
the signature of a proxy certificate. The
working_public_key is initialized from the input
information provided from RFC 3280 path validation.
(c) working_public_key_parameters: parameters
associated with the current public key, that may be
required to verify a signature (depending upon the
algorithm). The proxy_issuer_public_key_parameters
tuecke@mcs.anl.gov 25
X.509 Proxy Certificate Profile February 2003
Expires August 2003
variable is initialized from the input information
provided from RFC 3280 path validation.
(d) working_issuer_name: the issuer distinguished name
expected in the next proxy certificate in the chain.
The working_issuer_name is initialized to the
distinguished name in the end entity certificate
validated by RFC 3280 path validation.
(e) max_path_length: this integer is initialized to n,
is decremented for each proxy certificate in the path.
This value may also be reduced by the
pcPathLenConstraint value of any proxy certificate in
the chain.
(f) proxy_policy_list: this list is empty to start and
will be filled in with the proxy policies in the chain.
Upon completion of the initialization steps, perform the
basic certificate processing steps specified in 4.1.3.
4.1.3 Basic Proxy Certificate Processing
The basic path processing actions to be performed for
proxy certificate i (for all i in [1..n]) are listed
below.
(a) Verify the basic certificate information. The
certificate MUST satisfy each of the following:
(1) The certificate was signed with the
working_public_key_algorithm using the
working_public_key and the
working_public_key_parameters.
(2) The certificate validity period includes the
current time.
(3) The certificate issuer name is the
working_issuer_name.
(4) The certificate subject name is the
working_issuer_name with a CN component appended.
tuecke@mcs.anl.gov 26
X.509 Proxy Certificate Profile February 2003
Expires August 2003
(b) The proxy certificate MUST have a ProxyCertInfo
extension. Process the extension as follows:
(1) The version field in the ProxyCertInfo extension
MUST be 1.
(2) If the pCPathLenConstraint field is present in
the ProxyCertInfo field and the value it contains is
less than max_path_length, set max_path_length to
it's value.
(3) The proxyPolicy field MUST be processed as
follows:
(i) If acceptable-pc-policy-set is not any-policy,
the OID in the policyLanguage field MUST be
present in acceptable-pc-policy-set.
(ii) The policy field and the OID in the
policyLanguage field must be appended to
proxy_policy_list.
(c) Recognize and process any other critical extension
present in the proxy certificate. Process any other
recognized non-critical extension present in the proxy
certificate.
If either step (a) or (b) fails, the procedure terminates,
returning a failure indication and an appropriate reason.
If i is not equal to n, continue by performing the
preparatory steps listed in 4.1.4. If i is equal to n,
perform the wrap-up steps listed in 4.1.5.
4.1.4 Preparation for next Proxy Certificate
(a) Verify max_path_length is greater than zero and
decrement max_path_length.
(b) Assign the certificate subject name to
working_issuer_name.
tuecke@mcs.anl.gov 27
X.509 Proxy Certificate Profile February 2003
Expires August 2003
(c) Assign the certificate subjectPublicKey to
working_public_key.
(d) If the subjectPublicKeyInfo field of the
certificate contains an algorithm field with non-null
parameters, assign the parameters to the
working_public_key_parameters variable.
If the subjectPublicKeyInfo field of the certificate
contains an algorithm field with null parameters or
parameters are omitted, compare the certificate
subjectPublicKey algorithm to the
working_public_key_algorithm. If the certificate
subjectPublicKey algorithm and the
working_public_key_algorithm are different, set the
working_public_key_parameters to null.
(e) Assign the certificate subjectPublicKey algorithm
to the working_public_key_algorithm variable.
If check (a) fails, the procedure terminates, returning a
failure indication and an appropriate reason.
If (a) completes successfully, increment i and perform the
basic certificate processing specified in 4.1.3.
4.1.5 Wrap-up Proceedures
(a) Assign the certificate subject name to
working_issuer_name.
(b) Assign the certificate subjectPublicKey to
working_public_key.
(c) If the subjectPublicKeyInfo field of the
certificate contains an algorithm field with non-null
parameters, assign the parameters to the
proxy_issuer_public_key_parameters variable.
If the subjectPublicKeyInfo field of the certificate
contains an algorithm field with null parameters or
parameters are omitted, compare the certificate
subjectPublicKey algorithm to the
tuecke@mcs.anl.gov 28
X.509 Proxy Certificate Profile February 2003
Expires August 2003
proxy_issuer_public_key_algorithm. If the certificate
subjectPublicKey algorithm and the
proxy_issuer_public_key_algorithm are different, set
the proxy_issuer_public_key_parameters to null.
(d) Assign the certificate subjectPublicKey algorithm
to the proxy_issuer_public_key_algorithm variable.
4.1.6 Outputs
If path processing succeeds, the procedure terminates,
returning a success indication together with final value
of the working_public_key, the
working_public_key_algorithm, the
working_public_key_parameters, and the proxy_policy_list.
4.2 Using the Proxy Certificate Path Validation Algorithm
Each Proxy Certificate contains a proxyPolicy field
containing a language identifier and policy. These
policies serve to indicate the desire of each issuer in
the proxy certificate chain, starting with the EEC, to
delegate some subset of their rights to the issued proxy
certificate. This chain of policies is returned by the
algorithm to the application.
The application MAY make authorization decisions based off
of the subject distinguished name of the proxy certificate
or off of one of the proxy certificates in it's issuing
chain or off of the EEC that serves as the root of the
chain. If an application chooses to use the subject
distinguished name of a proxy certificate in the issuing
chain or the EEC it MUST use the returned policies to
restrict the rights it grants to the proxy certificate. If
the application does not know how to parse any policy in
the policy chain it MUST not use, for the purposes of
making authorization decisions, the subject distinguished
name of any certificate in the chain prior to the
certificate in which the unrecognized policy appears.
tuecke@mcs.anl.gov 29
X.509 Proxy Certificate Profile February 2003
Expires August 2003
5 Commentary
This section provides non-normative commentary on Proxy
Certificates.
5.1 Relationship to Attribute Certificates
An Attribute Certificate [4] can be used to grant to one
identity, the holder, some attribute such as a role,
clearance level, or alternative identity such as "charging
identity" or "audit identity". This is accomplished by
way of a trusted Attribute Authority (AA), which issues
signed Attribute Certificates (AC), each of which binds an
identity to a particular set of attributes. Authorization
decisions can then be made by combining information from
the authenticated End Entity Certificate providing the
identity, with the signed Attribute Certificates providing
binding of that identity to attributes.
There is clearly some overlap between the capabilities
provided by Proxy Certificates and Attribute Certificates.
However, the combination of the two approaches together
provides a broader spectrum of solutions to authorization
in X.509 based systems, than either solution alone. This
section seeks to clarify some of the overlaps,
differences, and synergies between Proxy Certificate and
Attribute Certificates.
5.1.1 Types of Attribute Authorities
For the purposes of this discussion, Attribute
Authorities, and the uses of the Attribute Certificates
that they produce, can be broken down into two broad
classes:
1) End entity AA: An End Entity Certificate may be used to
sign an AC. This can be used, for example, to allow an
end entity to delegate some of its privileges to another
entity.
2) Third party AA: A separate entity, aside from the end
entity involved in an authenticated interaction, may
tuecke@mcs.anl.gov 30
X.509 Proxy Certificate Profile February 2003
Expires August 2003
sign ACs in order to bind the authenticated identity
with additional attributes, such as role, group, etc.
For example, when a client authenticates with a server,
the third party AA may provide an AC that binds the
client identity to a particular group, which the server
then uses for authorization purposes.
This second type of Attribute Authority, the third party
AA, works equally well with an EEC or a PC. For example,
unrestricted Proxy Certificates can be used to delegate
the EEC's identity to various other parties. Then when
one of those other parties uses the PC to authenticate
with a service, that service will receive the EEC's
identity via the PC, and can apply any ACs that bind that
identity to attributes in order to determine authorization
rights. Additionally PC with policies could be used to
selectively deny the binding of ACs to a particular proxy.
An AC could also be bound to a particular PC using the
subject or issuer and serial number of the proxy
certificate. There would appear to be great synergies
between the use of Proxy Certificates and Attribute
Certificates produced by third party Attribute
Authorities.
However, the uses of Attribute Certificates that are
granted by the first type of Attribute Authority, the end
entity AA, overlap considerably with the uses of Proxy
Certificates as described in the previous sections. Such
Attribute Certificates are generally used for delegation
of rights from one end entity to others, which clearly
overlaps with the stated purpose of Proxy Certificates,
namely single sign-on and delegation.
5.1.3 Delegation Using Attribute Certificates
In the motivating example in Section 2.3, PCs are used to
delegate Steve's identity to the various other jobs and
entities that need to act on Steve's behalf. This allows
those other entities to authenticate as if they were
Steve, for example to the mass storage system.
tuecke@mcs.anl.gov 31
X.509 Proxy Certificate Profile February 2003
Expires August 2003
A solution to this example could also be cast using
Attribute Certificates that are signed by Steve's EEC,
which grant to the other entities in this example the
right to perform various operations on Steve's behalf. In
this example, the reliable file transfer service and all
the hosts involved in file transfers, the starter program,
the agent, the simulation jobs, and the post-processing
job would each have their own EECs. Steve's EEC would
therefore issue ACs to bind each of those other EEC
identities to attributes that grant the necessary
privileges allow them to, for example, access the mass
storage system.
However, this AC based solution to delegation has some
disadvantages as compared to the PC based solution:
* All protocols, authentication code, and identity based
authorization services must be modified to understand
ACs. With the PC solution, protocols (e.g. TLS) likely
need no modification, authentication code needs minimal
modification (e.g. to perform PC aware path
validation), and identity based authorization services
need minimal modification (e.g. possibly to find the
EEC name and to check for any proxy policies).
* ACs need to be created by Steve's EEC, which bind
attributes to each of the other identities involved in
the distributed application (i.e. the agent, simulation
jobs, and post-processing job the file transfer
service, the hosts transferring files). This implies
that Steve must know in advance which other identities
may be involved in this distributed application, in
order to generate the appropriate ACs which are signed
by Steve's ECC. On the other hand, the PC solution
allows for much more flexibility, since parties can
further delegate a PC without a priori knowledge by the
originating EEC.
There are many unexplored tradeoffs and implications in
this discussion of delegation. However, reasonable
arguments can be made in favor of either an AC based
solution to delegation or a PC based solution to
delegation. The choice of which approach should be taken
tuecke@mcs.anl.gov 32
X.509 Proxy Certificate Profile February 2003
Expires August 2003
in a given instance may depend on factors such as the
software that it needs to be integrated into, the type of
delegation required, and religion.
5.1.4 Propagation of Authorization Information
One possible use of Proxy Certificates is to carry
authorization information associated with a particular
identity.
The merits of placing authorization information into End
Entity Certificates (also called a Public Key Certificate
or PKC) have been widely debated. For example, Section 1
of "An Internet Attribute Certificate Profile for
Authorization" (RFC 3281) states:
"Authorization information may be placed in a PKC
extension or placed in a separate attribute certificate
(AC). The placement of authorization information in
PKCs is usually undesirable for two reasons. First,
authorization information often does not have the same
lifetime as the binding of the identity and the public
key. When authorization information is placed in a PKC
extension, the general result is the shortening of the
PKC useful lifetime. Second, the PKC issuer is not
usually authoritative for the authorization
information. This results in additional steps for the
PKC issuer to obtain authorization information from the
authoritative source.
For these reasons, it is often better to separate
authorization information from the PKC. Yet,
authorization information also needs to be bound to an
identity. An AC provides this binding; it is simply a
digitally signed (or certified) identity and set of
attributes." ([4], Section 1)
Placing authorization information in a PC mitigates the
first undesirable property cited above. Since a PC has a
lifetime that is mostly independent of (always shorter
than) its signing EEC, a PC becomes a viable approach for
carrying authorization information for the purpose of
delegation..
tuecke@mcs.anl.gov 33
X.509 Proxy Certificate Profile February 2003
Expires August 2003
The second undesirable property cited above is true. If a
third party AA is authoritative, then using ACs issued by
that third party AA is a natural approach to disseminating
authorization information. However, this is true whether
the identity being bound by these ACs comes from an EEC
(PKC), or from a PC.
There is one case, however, that the above text does not
consider. When performing delegation, it is usually the
EEC itself that is authoritative (not the EEC issuer, or
any third party AA). That is, it is up to the EEC to
decide what authorization rights it is willing to grant to
another party. In this situation, including such
authorization information into PCs that are generated by
the EEC seems a reasonable approach to disseminating such
information.
5.1.5 Proxy Certificate as Attribute Certificate Holder
In a system that employs both PCs and ACs, one can imagine
the utility of allowing a PC to be the holder of an AC.
This would allow for a particular delegated instance of an
identity to be given an attribute, rather than all
delegated instances of that identity being given the
attribute.
However, the issue of how to specify a PC as the holder of
an AC remains open.
An AC could be bound to a particular instance of a PC
using the unique subject name of the PC, or it's issuer
and serial number combination.
Unrestricted PCs issued by that PC would then inherit
those ACs and independent PCs would not. PCs issued with a
policy would depend on the policy as to whether or not
they inherit the issuing PC's ACs (and potentially which
ACs they inherit).
While an AC can be bound to one PC by the AA, how can the
AA restrict that PC from passing it on to a subsequently
delegated PC? One possible solution would be to define an
extension to attribute certificates that allows the
tuecke@mcs.anl.gov 34
X.509 Proxy Certificate Profile February 2003
Expires August 2003
attribute authority to state whether an issued AC is to
apply only to the particular entity to which it is bound,
or if it may apply to PCs issued by that entity.
One issue that an AA in this circumstance would need to be
aware of is that the PI of the PC that the AA bound the AC
to, could issue another PC with the same name as the
original PC to a different entity, effectively stealing
the AC. This implies that an AA issuing an AC to a PC need
to not only trust the entity holding the PC, but the
entity holding the PC's issuer as well.
5.2 Kerberos 5 Tickets
The Kerberos Network Authentication Protocol (RFC 1510
[9]) is a widely used authentication system based on
conventional (shared secret key) cryptography. It
provides support for single sign-on via creation of
"Ticket Granting Tickets" or "TGT", and support for
delegation of impersonation rights via "forwardable
tickets".
Kerberos 5 tickets have informed many of the ideas
surrounding X.509 Proxy Certificates. For example, the
local creation of a short-lived PC can be used to provide
single sign-on in an X.509 PKI based system, just as
creation of short-lived TGT allows for single sign-on in a
Kerberos based system. And just as a TGT can be forwarded
(i.e. delegated) to another entity to allow for
impersonation in a Kerberos based system, so can a PC can
be delegated to allow for impersonation in an X.509 PKI
based system.
A major difference between a Kerberos TGT and an X.509 PC
is that while creation and delegation of a TGT requires
the involvement of a third party (the Kerberos Domain
Controller), a PC can be unilaterally created without the
active involvement of a third party. That is, a user can
directly create a PC from an EEC for single sign-on
capability, without requiring communication with a third
party. And an entity with a PC can delegate the PC to
tuecke@mcs.anl.gov 35
X.509 Proxy Certificate Profile February 2003
Expires August 2003
another entity (i.e. by creating a new PC, signed by the
first) without requiring communication with a third party.
The method used by Kerberos implementations to protect a
TGT can also be used to protect the private key of a PC.
For example, some Unix implementations of Kerberos use
standard Unix file system security to protect a user's TGT
from compromise. Similarly, the Globus Toolkit's Grid
Security Infrastructure implementation of Proxy
Certificates protects a user's PC private key using this
same approach.
5.3 Examples of usage of Proxy Restrictions
This section gives some examples of Proxy Certificate
usage and some examples of how the Proxy policy can be
used to restrict Proxy Certificates.
5.3.1 Example use of proxies without Restrictions
Steve wishes to perform a third-party FTP transfer between
two FTP servers. Steve would use an existing PC to
authenticate to both servers and delegate a PC to both
hosts. He would inform each host of the unique subject
name of the PC given to the other host. When the servers
establish the data channel connection to each other, they
use these delegated credentials to perform authentication
and verify they are talking to the correct entity by
checking the result of the authentication matches the name
as provided by Steve.
5.3.2 Example use of proxies with Restrictions
Steve wishes to delegate to a process the right to perform
a transfer of a file from host H1 to host H2 on his
behalf. Steve would delegate a PC to the process and he
would use Proxy Policy to restrict the delegated PC to two
rights - the right to read file F1 on host H1 and the
right to write file F2 on host H2.
The process then uses this restricted PC to authenticate
to servers H1 and H2. The process would also delegate a PC
to both servers. Note that these delegated PCs would
tuecke@mcs.anl.gov 36
X.509 Proxy Certificate Profile February 2003
Expires August 2003
inherit the restrictions of their parents, though this is
not relevant to this example. As in the example in the
previous Section, each host would be provided with the
unique name of the PC given to the other server.
Now when the process issues the command to transfer the
file F1 on H1 and to F2 on H2, these two servers perform
an authorization check based on the restrictions in the PC
that the process used to authenticate with them (in
addition to any local policy they have). Namely H1 checks
that the PC gives the user the right to read F1 and H2
checks that the PC gives the user the right to write F2.
When setting up the data channel the servers would again
verify the names resulting from the authentication match
the names provided by Steve as in the example in the
previous Section.
The extra security provided by these restrictions is that
now if the PC delegated to the process by Steve is stolen,
its use is greatly limited.
5.4 Delegation Tracing
A relying party accepting a Proxy Certificate may have an
interest in knowing which parties issued earlier Proxy
Certificates in the certificate chain and to whom they
delegated them. For example it may know that a particular
service or resource is known to have been compromised and
if any part of a Proxy Certificate's chain was issued to
the compromised service a relying party may wish to
disregard the chain.
A delegation tracing mechanism was considered by the
authors as additional information to be carried in the
ProxyCertInfo extension. However at this time agreement
has not been reached as to what this information should
include so it was left out of this document, and will
instead be considered in future revisions. The debate
mainly centers on whether the tracing information should
simply contain the identity of the issuer and receiver or
it should also contain all the details of the delegated
proxy and a signed statement from the receiver that the
proxy was actually acceptable to it.
tuecke@mcs.anl.gov 37
X.509 Proxy Certificate Profile February 2003
Expires August 2003
5.4.1 Site Information in Delegation Tracing
In some cases, it may be desirable to know the hosts
involved in a delegation transaction (for example, a
relying party may wish to reject proxy certificates that
were created on a specific host or domain). The
DelegationTrace extension could be modified to include the
PA's and Acceptor's IP addresses; however, IP addresses
are typically easy to spoof, and in some cases the two
parties to a transaction may not agree on the IP addresses
being used (e.g., if the Acceptor is on a host that uses
NAT, the Acceptor and the PA may disagree about the
Acceptor's IP address).
Another suggestion was, in those cases where domain
information is needed, to require that the subject names
of all End Entities involved (the Acceptor(s) and the End
Entity that appears in a PC's certificate path) include
domain information.
6 Security Considerations
In this Section we discuss security considerations related
to the use of Proxy Certificates.
6.1 Compromise of a Proxy Certificate
A Proxy Certificate is generally less secure than the EEC
that issued it. This is due to the fact that the private
key of a PC is generally not protected as rigorously as
that of the EEC. For example, the private key of a PC is
often protected using only file system security, in order
to allow that PC to be used for single sign-on purposes.
This makes the PC more susceptible to compromise.
However, the risk of a compromised PC is only the misuse
of a single user's privileges. Due to the path validation
checks made on a PC, a PC cannot be used to sign an EEC or
PC for another user.
Further, a compromised PC can only be misused for the
lifetime of the PC, and within the bound of the
tuecke@mcs.anl.gov 38
X.509 Proxy Certificate Profile February 2003
Expires August 2003
restriction policy carried by the PC. Therefore, one
common way to limit the misuse of a compromised PC is to
limit its validity period to no longer than is needed,
and/or to include a restriction policy in the PC that
limits the use of the (compromised) PC.
In addition, if a PC is compromised, it does NOT
compromise the EEC that created the PC. This property is
of great utility in protecting the highly valuable, and
hard to replace, public key of the EEC. In other words,
the use of Proxy Certificates to provide single sign-on
capabilities in an X.509 PKI environment can actually
increase the security of the end entity certificates,
because creation and use of the PCs for user
authentication limits the exposure of the EEC private key
to only the creation of the first level PC.
6.2 Restricting Proxy Certificates
The pCPathLenConstraint field of the proxyCertInfo
extension can be used by an EEC to limit subsequent
delegation of the PC. A service may choose to only
authorize a request if a valid PC can be delegated to it.
An example of such as service is a job starter, which may
choose to reject a job start request if a valid PC cannot
be delegated to it. By limiting the pCPathLenConstraint,
an EEC can ensure that a compromised PC of one job cannot
be used to start additional jobs elsewhere.
An EEC or PC can limit what a new PC can be used for by
turning off bits in the Key Usage and Extended Key Usage
extensions. Once a key usage or extended key usage has
been removed, the path validation algorithm ensures that
it cannot be added back in a subsequent PC. In other
words, key usage can only be decreased in PC chains.
The EEC could use the CRL Distribution Points extension
and/or OCSP to take on the responsibility of revoking PCs
that it had issued, if it felt that they were being
misused.
The use of the proxyPolicy field to restrict the rights of
a Proxy Certificate is shown in Section 6.6.
tuecke@mcs.anl.gov 39
X.509 Proxy Certificate Profile February 2003
Expires August 2003
6.3 Relying Party Trust of Proxy Certificates
The relying party that is going to authorize some actions
on the basis of a PC will be aware that it has been
presented with a PC, and can determine the depth of the
delegation and the time that the delegation took place.
It may want to use this information in addition to the
information from the signing EEC. Thus a highly secure
resource might refuse to accept a PC at all, or maybe only
a single level of delegation, etc.
The relying party should also be aware that since the
policy restricting the rights of a PC is the intersection
of the policy of all the PCs in it's certificate chain,
this means any change in the certificate chain can effect
the policy of the PC. Since there is no mechanism in place
to enforce unique subject names of PCs, if an issuer were
two PCs with identical names and keys, but different
rights this could allow the two PCs to be substituted for
each other in path validation and effect the rights of a
PC down the chain. Ultimately, this means the relying
party places trust in the entities that are acting as
Proxy Issuers in the chain to behave properly.
7 References
[1] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels," BCP 14, RFC 2119,
March 1997.
[2] Butler, R., D. Engert, I. Foster, C. Kesselman,
and S. Tuecke, "A National-Scale Authentication
Infrastructure," IEEE Computer, vol. 33, pp. 60-
66, 2000.
[3] Dierks, T. and C. Allen, "The TLS Protocol,
Version 1.0," RFC 2246, January 1999.
[4] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization," RFC 3281,
April 2002.
[5] Foster, I., C. Kesselman, G. Tsudik, and S.
Tuecke, "A Security Architecture for Computational
tuecke@mcs.anl.gov 40
X.509 Proxy Certificate Profile February 2003
Expires August 2003
Grids," presented at Proceedings of the 5th ACM
Conference on Computer and Communications
Security, 1998.
[6] Foster, I., C. Kesselman, and S. Tuecke, "The
Anatomy of the Grid: Enabling Scalable Virtual
Organizations," International Journal of
Supercomputer Applications, 2001.
[7] Housley, R., W. Polk, W. Ford, and D. Solo,
"Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL)
Profile," RFC 3280, April 2002.
[8] Jackson, K., S. Tuecke, and D. Engert, "TLS
Delegation Protocol," Internet Draft draft-ietf-
tls-delegation-00.txt, 2001
[9] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)," RFC 1510, September
1993.
[10] B. Clifford Neuman. Proxy-Based Authorization and
Accounting for Distributed Systems. In Proceedings
of the 13th International Conference on
Distributed Computing Systems, pages 283-291, May
1993.
8 Acknowledgments
We are grateful to numerous colleagues for discussions on
the topics covered in this paper, in particular (in
alphabetical order, with apologies to anybody we've
missed): Joe Bester, Randy Butler, Jarek Gawor, Keith
Jackson, Steve Hanna, Russ Housley, Stephen Kent, Bill
Johnston, Marty Humphrey, Sam Lang, Sam Meder, Clifford
Neuman, Frank Siebenlist, Gene Tsudik.
We are also grateful to members of the Global Grid Forum
(GGF) Grid Security Infrastructure working group (GSI-WG),
and the Internet Engineering Task Force (IETF) Public-Key
Infrastructure (X.509) working group (PKIX) for feedback
on this document.
tuecke@mcs.anl.gov 41
X.509 Proxy Certificate Profile February 2003
Expires August 2003
This work was supported in part by the Mathematical,
Information, and Computational Sciences Division
subprogram of the Office of Advanced Scientific Computing
Research, U.S. Department of Energy, under Contract W-31-
109-Eng-38 and DE-AC03-76SF0098; by the Defense Advanced
Research Projects Agency under contract N66001-96-C-8523;
by the National Science Foundation; and by the NASA
Information Power Grid project.
9 Change Log
draft-ietf-pkix-impersonation-00 (February 2001)
Initial submission.
draft-ietf-pkix-proxy-00 (July 2001)
Renamed to "Proxy Certificate", from "Impersonation
Certificate", due to overwhelming feedback from IETF
and GGF.
Added proxyRestriction field to ProxyCertInfo
extension.
Added delegationTrace field to ProxyCertInfo extension.
Updated to agree with draft-ietf-pkix-part1-08.
draft-ietf-pkix-proxy-01 (August 2001)
Changes related to delegation tracing: removed
delegationTrace field from ProxyCertInfo extension,
created DelegationTrace extension, added and modified
commentary sections related to delegation tracing.
Added issuerCertHash to proxyCertInfo extension and to
the path validation section.
draft-ietf-pkix-proxy-02 (February 2002)
Draft for Global Grid Forum 4 (Toronto)
Added concept of proxy group.
tuecke@mcs.anl.gov 42
X.509 Proxy Certificate Profile February 2003
Expires August 2003
Updated section on keyCertSign bit to reflect draft-
pkix-new-part1-07.
draft-ietf-pkix-proxy-02 (March 2002)
Draft for IETF.
Same version number (-02) as February 2002 for GGF4 but
with changes.
Globally changed "Proxy Authority" to "Proxy Issuer".
Changed example in Motivations section to use a
reliable file transfer service.
An EEC issuing a PC must have a non-empty subject name.
Proxy subject names are now non-empty and contain a
sequence of proxy identifiers. Changes to path
validation to reflect this.
subjectAltNames and issuerAltNames are now not present
PCs.
Renamed issuerCertHash to issuerCertSignature and
similarly with it's contents.
Added consideration to path validation for PC's with an
infinite path length (i.e. no pCPathLenConstraint).
draft-ggf-gsi-proxy-03 (July 2002)
Draft for GGF-5 (Edinburgh)
Renamed to draft-ggf-gsi-proxy-03
Changed formatting to meet GGF document format
requirements.
Added GGF copyright notice to beginning.
tuecke@mcs.anl.gov 43
X.509 Proxy Certificate Profile February 2003
Expires August 2003
Removed Internet Draft language from status section and
replaced with current text.
Added Copyright and Intellectual Property sections (12
& 13)
Removed Section 3.7.2: DelegationTrace Extension.
Renumbered subsections 3.7.1.x to 3.7.x. Removed
subsections in Section 6 related to this extension and
replaced with one subsection discussing it.
Proxy Certificate subject name is now issuer name
concatenated with a single unique component. Functional
changes to Sections 3 and 4 to reflect this, numerous
changes throughout the document including removal of
section 6.3.
Removed text stating the Proxy subject name should only
be used for path validation to leave door open for use
with attribute certificates.
Rewrote 2.6 so reflect that PCs now have unique
identities.
Added new section 2.5 (Motivation for Unique Proxy
Name)
Removed sections 2.7 (Proxy Issuer, not Certificate
Authority) and 2.8 (Names versus Subjects)
Renamed proxyRestrictions to proxyPolicy and made it a
required field. Numerous changes elsewhere to reflect
this change.
Removed issuerCertSignature since it is no longer
needed since PCs now have unique names.
Added previously deleted (accidentally?) text in 6.1
(keyCertSign Bit commentary).
Cleaned up pCPathLenConstraint checking in section 4 by
adding the max_pc_path_length variable.
tuecke@mcs.anl.gov 44
X.509 Proxy Certificate Profile February 2003
Expires August 2003
Removed the proxyGroup field to make document
restriction policy agnostic.
Added structure to Section 7 (Security Considerations)
and added some text about a relying party trusting all
issuers in a PC chain.
Removed sections 6.1 and 6.2 from commentary since the
PKIX draft is now an RFC and won't be changed.
Moved text from 6.3 to 3.9.4 and removed section 6.3.
Moved 6.4 to end of Commentary section.
Moved section 5 (Relationship to attribute certificate
to be first section of commentary).
Changed intro to commentary and added text to beginning
of section 2 to indicate that these two sections are
non-normative.
Changed text in 2.7 to indicate ease of integration
with existing authorization systems is true only in the
case of impersonation PCs.
Added text to new section 5.1.4 to indicate that
binding ACs to PCs indicates a trust of the PI.
Removed the pC bit - any certificate with a
proxyCertInfo extensions is now a PC.
draft-ggf-gsi-proxy-04 (August 2002)
Minor non-normative editorial corrections.
draft-ietf-pkix-proxy-03 (October 2002)
Name change for attempted inclusion as a PKIX WG
document. Based on draft-ggf-gsi-proxy-04 with changes
listed below.
Changed reference from "draft update to RFC 2459" to
RFC 3280.
tuecke@mcs.anl.gov 45
X.509 Proxy Certificate Profile February 2003
Expires August 2003
draft-ietf-pkix-proxt-04 (February 2003)
Rewrote section 4, Path Validation, to be additions to
RFC 3280 path validation instead of changes.
Added Appendix A with ASN.1 module.
Added oids for Impersonation and Independent policy
languages to section 3.9.3.
In section 3.6: keyusage extension in a proxy
certificate only has to be marked critical if marked
critical in the issuer's certificate. Previously it
always had to be marked critical.
10 Contact Information
Steven Tuecke
Distributed Systems Laboratory
Mathematics and Computer Science Division
Argonne National Laboratory
Argonne, IL 60439
Phone: 630-252-8711
Email: tuecke@mcs.anl.gov
Doug Engert
Argonne National Laboratory
Email: deengert@anl.gov
Ian Foster
Argonne National Laboratory & University of Chicago
Email: foster@mcs.anl.gov
Von Welch
University of Chicago
Email: welch@mcs.anl.gov
Mary Thompson
Lawrence Berkeley National Laboratory
Email: mrthompson@lbl.gov
Laura Pearlman
tuecke@mcs.anl.gov 46
X.509 Proxy Certificate Profile February 2003
Expires August 2003
University of Southern California, Information Sciences
Institute
Email: laura@isi.edu
Carl Kesselman
University of Southern California, Information Sciences
Institute
Email: carl@isi.edu
11 Copyright Notice
Copyright (C) The Internet Society (September 23, 2002).
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 Internet Society or other Internet
organizations, except as needed for the purpose of
developing Internet standards in which case the procedures
for copyrights defined in the Internet Standards 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 Internet Society or its
successors or assigns.
This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
tuecke@mcs.anl.gov 47
X.509 Proxy Certificate Profile February 2003
Expires August 2003
12 Intellectual Property Statement
The IETF 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. Information on the
IETF's procedures with respect to rights in standards-
track and standards-related documentation can be found in
BCP-11. 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 IETF Secretariat.
The IETF 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 standard. Please
address the information to the IETF Executive Director.
Appendix A. 1988 ASN.1 Module
PKIXproxy88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-proxy-cert-extns(25) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
-- IMPORTS NONE --
-- PKIX specific OIDs
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3)
tuecke@mcs.anl.gov 48
X.509 Proxy Certificate Profile February 2003
Expires August 2003
dod(6) internet(1) security(5) mechanisms(5)
pkix(7) }
-- modules
id-mod OBJECT IDENTIFIER ::= { id-pkix 0 }
-- private certificate extensions
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
-- private certificate extensions
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
-- Locally defined OIDs
-- The proxy certificate extension
id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 }
-- Proxy certificate policy languages
id-ppl OBJECT IDENTIFIER ::= { id-pkix 21 }
-- Proxy certificate policies languages defined in draft
id-ppl-impersonation OBJECT IDENTIFIER ::= { id-ppl 1 }
id-ppl-independent OBJECT IDENTIFIER ::= { id-ppl 2 }
-- The ProxyCertInfo Extension
ProxyCertInfoExtension ::= SEQUENCE {
version Version,
pCPathLenConstraint ProxyCertPathLengthConstraint
OPTIONAL,
proxyPolicy ProxyPolicy }
-- Only one possible version now
Version ::= INTEGER { v1(1) }
ProxyCertPathLengthConstraint ::= INTEGER
ProxyPolicy ::= SEQUENCE {
policyLanguage OBJECT IDENTIFIER,
policy OCTET STRING OPTIONAL }
tuecke@mcs.anl.gov 49
Datatracker
Report a datatracker bug
draft-ietf-pkix-proxy-04
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 3820.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |