Internet DRAFT - draft-ietf-pkix-proxy-06.txtdraft-ietf-pkix-proxy
draft-ietf-pkix-proxy-06.txtdraft-ietf-pkix-proxy
Internet Draft S. Tuecke
Document: draft-ietf-pkix-proxy-06 D. Engert
I. Foster
Initial Version March 2001 ANL
Revised May 2003 V. Welch
Expires November 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 defines a standard for
implementing X.509 Proxy Certificates.
tuecke@mcs.anl.gov 1
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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..................................................5
2.2 Background...................................................5
2.3 Motivation for Proxying......................................6
2.4 Motivation for Restricted Proxies............................8
2.5 Motivation for Unique Proxy Name.............................9
2.6 Description Of Approach.....................................10
2.7 Features Of This Approach...................................11
3 Certificate and Certificate Extensions Profile................13
3.1 Issuer......................................................14
3.2 Issuer Alternative Name.....................................14
3.3 Serial Number...............................................14
3.4 Subject.....................................................14
3.5 Subject Alternative Name....................................15
3.6 Key Usage and Extended Key Usage............................15
3.7 Basic Constraints...........................................15
3.8 The ProxyCertInfo Extension.................................15
4 Proxy Certificate Path Validation.............................19
4.1 Basic Proxy Certificate Path Validation.....................20
4.2 Using the Path Validation Algorithm.........................25
5 Commentary....................................................26
5.1 Relationship to Attribute Certificates......................26
5.2 Kerberos 5 Tickets..........................................31
5.3 Examples of usage of Proxy Restrictions.....................32
5.4 Delegation Tracing..........................................33
6 Security Considerations.......................................34
6.1 Compromise of a Proxy Certificate...........................34
6.2 Restricting Proxy Certificates..............................34
tuecke@mcs.anl.gov 2
X.509 Proxy Certificate Profile May 2003
Expires November 2003
6.3 Relying Party Trust of Proxy Certificates...................35
7 References....................................................36
8 Acknowledgments...............................................36
9 Change Log....................................................37
10 Contact Information.........................................42
11 Copyright Notice............................................43
12 Intellectual Property Statement.............................44
Appendix A. 1988 ASN.1 Module....................................44
1 Introduction
Use of a proxy credential[10] 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" [7].
In addition to simple, unrestricted proxying, this profile defines:
* A framework for carrying policies in Proxy Certificates that
allow 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 [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 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.
tuecke@mcs.anl.gov 3
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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.
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.
tuecke@mcs.anl.gov 4
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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 "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.
* 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" [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
tuecke@mcs.anl.gov 5
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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
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 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.
tuecke@mcs.anl.gov 6
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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.
* 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:
tuecke@mcs.anl.gov 7
X.509 Proxy Certificate Profile May 2003
Expires November 2003
* 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.
tuecke@mcs.anl.gov 8
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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 [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 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:
tuecke@mcs.anl.gov 9
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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
tuecke@mcs.anl.gov 10
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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 [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.
2.7 Features Of This Approach
Using Proxy Certificates to perform delegation has several features
that make it attractive:
* Ease of integration
tuecke@mcs.anl.gov 11
X.509 Proxy Certificate Profile May 2003
Expires November 2003
. 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 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 proxy
rights, but continue to 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.
tuecke@mcs.anl.gov 12
X.509 Proxy Certificate Profile May 2003
Expires November 2003
. 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 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.
All Proxy Certificates MUST include the Proxy Certificate
Information (ProxyCertInfo) extension defined in this section and
the extension MUST be critical.
tuecke@mcs.anl.gov 13
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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 its Proxy Issuer.
If the Proxy Issuer certificate has the KeyUsage extension, the
Digital Signature bit MUST be asserted.
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.
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 to each Proxy
Certificate bearer amongst all Proxy Certificates with the same
issuer.
tuecke@mcs.anl.gov 14
X.509 Proxy Certificate Profile May 2003
Expires November 2003
If a Proxy Issuer issues two proxy certificates to the same bearer,
the Proxy Issuer MAY choose to use the same Common Name for both.
Examples of this include Proxy Certificates for different uses
(e.g. signing vs encryption) or the re-issuance of an expired Proxy
Certificate.
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 are 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 are unique to each bearer.
3.5 Subject Alternative Name
The subjectAltName extension MUST NOT be present in a Proxy
Certificate.
3.6 Key Usage and Extended Key Usage
If the Proxy Issuer certificate has a Key Usage extension, the
Digital Signature bit MUST be asserted.
This draft places no constraints on the presence or contents of the
key usage and extended key usage extension. However, section 4.2
explains what functions should be allowed a proxy certificate by a
relying party.
3.7 Basic Constraints
The cA field in the basic constraints extension MUST NOT be TRUE.
3.8 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 ?? }
tuecke@mcs.anl.gov 15
X.509 Proxy Certificate Profile May 2003
Expires November 2003
ProxyCertInfo ::= SEQUENCE {
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 be absent.
The ProxyCertInfo extension consists of one required and four
optional fields, which are described in detail in the following
subsections.
3.8.1 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.8.2 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
tuecke@mcs.anl.gov 16
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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,
defined in Appendix A, that MUST be understood by all parties
accepting Proxy Certificates:
* id-ppl-inheritAll indicates that this is an 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.
* id-ppl-independent 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
its ability to do proxying. 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 based on rights that proxy certificate
inherited from it's issuer, it is the relying party's
tuecke@mcs.anl.gov 17
X.509 Proxy Certificate Profile May 2003
Expires November 2003
responsibility to verify that the requested authority is compatible
with all policies in the PC's certificate path. In other words,
the relying party MUST verify that the following three conditions
are all met:
1) The relying MUST party know how to interpret the policy and the
request is allowed under that policy.
2) If the Proxy Issuer is an EEC and the right to perform the
requested action is being inherited from the EEC by the proxy
policy, 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 by means other than inheritance from
it's issuer via its proxy policy. The rights granted to the bearer
of a PC are the union of the rights granted to the PC identity and
the inherited rights. The inherited rights consist of the
intersection of the rights granted to the PI identity intersected
with the proxy 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 granting the PC the right to read file D.
tuecke@mcs.anl.gov 18
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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.
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
tuecke@mcs.anl.gov 19
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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;
(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 there is no mechanism defined for revoking proxy
certificates.
4.1 Basic Proxy Certificate Path Validation
tuecke@mcs.anl.gov 20
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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,
(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-language-set: A set of proxy
certificate policy languages understood by the policy evaluation
code. The acceptable-pc-policy-language-set MAY contain the
special value id-ppl-anyLanguage (as defined in Appendix A) if
the path validation code should not check the proxy certificate
policy languages (typically because the set of known policy
languages is not known yet and will be checked later in the
authorization process).
tuecke@mcs.anl.gov 21
X.509 Proxy Certificate Profile May 2003
Expires November 2003
(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 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 key usage extensions, extended key usage
extensions and proxy policies in the chain.
Upon completion of the initialization steps, perform the basic
certificate processing steps specified in 4.1.3.
tuecke@mcs.anl.gov 22
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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.
(b) The proxy certificate MUST have a ProxyCertInfo extension.
Process the extension as follows:
(1) 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.
(2) If acceptable-pc-policy-language-set is not id-ppl-
anyLanguage, the OID in the policyLanguage field MUST be
present in acceptable-pc-policy-language-set.
(c) The tuple containing the certificate subject name,
policyPolicy, key usage extension (if present) and extended key
usage extension (if present) must be appended to
proxy_policy_list.
(d) 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.
tuecke@mcs.anl.gov 23
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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.
(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.
(f) If a key usage extension is present, verify that the
digitalSignature bit is set.
If either check (a) or (f) fails, the procedure terminates,
returning a failure indication and an appropriate reason.
If (a) and (f) complete 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.
tuecke@mcs.anl.gov 24
X.509 Proxy Certificate Profile May 2003
Expires November 2003
(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
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 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
tuecke@mcs.anl.gov 25
X.509 Proxy Certificate Profile May 2003
Expires November 2003
chain prior to the certificate in which the unrecognized policy
appears.
Application making authorization decisions based off of the
contents of the proxy certificate key usage or extended key usage
extensions MUST examine the list of key usage, extended key usage
and proxy policies resulting from proxy certificate path validation
and determine the effective key usage functions of the proxy
certificate as follows:
* If a certificate is a proxy certificate with a proxy policy of
id-ppl-independent or an end entity certificate, the effective
key usage functions of that certificate is as defined by the key
usage and extended key usage extensions in that certificate. The
key usage functionality of the issuer has no bearing on the
effective key usage functionality.
* If a certificate is a proxy certificate with a policy other than
id-ppl-independent, the effective key usage and extended key
usage functionality of the proxy certificate is the intersection
of the functionality of those extensions in the proxy
certificate and the effective key usage functionality of the
proxy issuer.
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.
tuecke@mcs.anl.gov 26
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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 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
tuecke@mcs.anl.gov 27
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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.2 Delegation Using Attribute Certificates
In the motivating example in Section Error! Reference source not
found., 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.
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
tuecke@mcs.anl.gov 28
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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 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.3 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
tuecke@mcs.anl.gov 29
X.509 Proxy Certificate Profile May 2003
Expires November 2003
PC becomes a viable approach for carrying authorization information
for the purpose of delegation..
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.4 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 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.
tuecke@mcs.anl.gov 30
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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 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
proxying in a Kerberos based system, so can a PC can be delegated
to allow for proxying 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
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.
tuecke@mcs.anl.gov 31
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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 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.
tuecke@mcs.anl.gov 32
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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.
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). An 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.
tuecke@mcs.anl.gov 33
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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 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
tuecke@mcs.anl.gov 34
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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.
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.
tuecke@mcs.anl.gov 35
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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 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,
David Chadwick, Jarek Gawor, Keith Jackson, Steve Hanna, Russ
tuecke@mcs.anl.gov 36
X.509 Proxy Certificate Profile May 2003
Expires November 2003
Housley, Stephen Kent, Bill Johnston, Marty Humphrey, Sam Lang, Sam
Meder, Clifford Neuman, Jim Schaad, 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.
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.
tuecke@mcs.anl.gov 37
X.509 Proxy Certificate Profile May 2003
Expires November 2003
draft-ietf-pkix-proxy-02 (February 2002)
Draft for Global Grid Forum 4 (Toronto)
Added concept of proxy group.
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 38
X.509 Proxy Certificate Profile May 2003
Expires November 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.
Removed the proxyGroup field to make document restriction policy
agnostic.
tuecke@mcs.anl.gov 39
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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.
draft-ietf-pkix-proxy-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.
tuecke@mcs.anl.gov 40
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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.
draft-ietf-pkix-proxy-05 (April 2003)
Removed version field from ProxyCertInfo extension
Restrictions on contents of key usage and extended key usage
removed and placed as burden to relying party(4.2 and 3.6).
Path validation (4.1.3) now outputs proxy_policy_list as a list
of tuples containing subject name, policy oid, policy field, key
usage extension and extended key usage extension
Number of fixes to ASN module from Jim Schaad.
Changes policy language OID name from "id-ppl-impersonation" to
"id-ppl-inheritall".
Fixed discrepancy between ASN.1 module and 3.9.2: id-ppl-
independent and id-ppl-inheritall now refer to the whole OID.
Clarified that a proxy issuer must have digitalSignature
asserted if its certificate includes the keyUsage extension.
Accepted text from David Chadwick globally getting rid of the
term "impersonation" and replacing with "proxying".
Reformatted document to be less indented and be more in line
with other IDs.
Numerous clarifications to draft based on Jim Schaad's comments.
Effected sections: 3, 3.1, 3.4, 3.7, 3.9.3, 4, 5.4.1
Expanded PKI acronym in abstract and section 2.
Shorten title of section 4.2 to allow it to fit in table of
contents.
tuecke@mcs.anl.gov 41
X.509 Proxy Certificate Profile May 2003
Expires November 2003
draft-ietf-pkix-proxy-06 (May 2003)
Renamed "id-ppl-inheritall" to "id-ppl-inheritAll" (capitalizing
the "a") for consistency.
In section 4, renamed "acceptable-pc-policy-set" to "acceptable-
pc-policy-language-set" for clarity.
In section 4, renamed "any-policy" to "id-ppl-anyLanguage" for
clarity.
Added an OID for id-ppl-anyLanguage to Appendix A.
Clarified text in 4.1.3 (c).
Clarified Proxy Issuer definition in 2.1.
Changed "MUST not be present" to "MUST be absent" second to last
paragraph of section 3.8.
Removed OID definitions from 3.8.2 and added pointer to Appendix
A.
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
tuecke@mcs.anl.gov 42
X.509 Proxy Certificate Profile May 2003
Expires November 2003
Email: welch@mcs.anl.gov
Mary Thompson
Lawrence Berkeley National Laboratory
Email: mrthompson@lbl.gov
Laura Pearlman
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 43
X.509 Proxy Certificate Profile May 2003
Expires November 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)
proxy-cert-extns(25) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
-- IMPORTS NONE --
-- PKIX specific OIDs
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
-- private certificate extensions
tuecke@mcs.anl.gov 44
X.509 Proxy Certificate Profile May 2003
Expires November 2003
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-anyLanguage OBJECT IDENTIFIER ::= { id-ppl 0 }
id-ppl-inheritAll OBJECT IDENTIFIER ::= { id-ppl 1 }
id-ppl-independent OBJECT IDENTIFIER ::= { id-ppl 2 }
-- The ProxyCertInfo Extension
ProxyCertInfoExtension ::= SEQUENCE {
pCPathLenConstraint ProxyCertPathLengthConstraint
OPTIONAL,
proxyPolicy ProxyPolicy }
ProxyCertPathLengthConstraint ::= INTEGER
ProxyPolicy ::= SEQUENCE {
policyLanguage OBJECT IDENTIFIER,
policy OCTET STRING OPTIONAL }
END
tuecke@mcs.anl.gov 45
