diff options
Diffstat (limited to 'doc/rfc/rfc3820.txt')
| -rw-r--r-- | doc/rfc/rfc3820.txt | 2075 |
1 files changed, 2075 insertions, 0 deletions
diff --git a/doc/rfc/rfc3820.txt b/doc/rfc/rfc3820.txt new file mode 100644 index 0000000..f4e6073 --- /dev/null +++ b/doc/rfc/rfc3820.txt @@ -0,0 +1,2075 @@ + + + + + + +Network Working Group S. Tuecke +Request for Comments: 3820 ANL +Category: Standards Track V. Welch + NCSA + D. Engert + ANL + L. Pearlman + USC/ISI + M. Thompson + LBNL + June 2004 + + + Internet X.509 Public Key Infrastructure (PKI) + Proxy Certificate Profile + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This document forms a certificate profile for Proxy Certificates, + based on X.509 Public Key Infrastructure (PKI) certificates as + defined in RFC 3280, for use in the Internet. The term Proxy + Certificate is used to describe a certificate that is derived from, + and signed by, a normal X.509 Public Key End Entity Certificate or by + another Proxy Certificate for the purpose of providing restricted + proxying and delegation within a PKI based authentication system. + + + + + + + + + + + + + + +Tuecke, et al. Standards Track [Page 1] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Overview of Approach . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2. Background . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.3. Motivation for Proxying. . . . . . . . . . . . . . . . . 5 + 2.4. Motivation for Restricted Proxies. . . . . . . . . . . . 7 + 2.5. Motivation for Unique Proxy Name . . . . . . . . . . . . 8 + 2.6. Description Of Approach. . . . . . . . . . . . . . . . . 9 + 2.7. Features Of This Approach. . . . . . . . . . . . . . . . 10 + 3. Certificate and Certificate Extensions Profile . . . . . . . . 12 + 3.1. Issuer . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 3.2. Issuer Alternative Name. . . . . . . . . . . . . . . . . 12 + 3.3. Serial Number. . . . . . . . . . . . . . . . . . . . . . 12 + 3.4. Subject. . . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.5. Subject Alternative Name . . . . . . . . . . . . . . . . 13 + 3.6. Key Usage and Extended Key Usage . . . . . . . . . . . . 13 + 3.7. Basic Constraints. . . . . . . . . . . . . . . . . . . . 14 + 3.8. The ProxyCertInfo Extension. . . . . . . . . . . . . . . 14 + 4. Proxy Certificate Path Validation. . . . . . . . . . . . . . . 17 + 4.1. Basic Proxy Certificate Path Validation. . . . . . . . . 19 + 4.2. Using the Path Validation Algorithm. . . . . . . . . . . 23 + 5. Commentary . . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 5.1. Relationship to Attribute Certificates . . . . . . . . . 24 + 5.2. Kerberos 5 Tickets . . . . . . . . . . . . . . . . . . . 28 + 5.3. Examples of usage of Proxy Restrictions. . . . . . . . . 28 + 5.4. Delegation Tracing . . . . . . . . . . . . . . . . . . . 29 + 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 30 + 6.1. Compromise of a Proxy Certificate. . . . . . . . . . . . 30 + 6.2. Restricting Proxy Certificates . . . . . . . . . . . . . 31 + 6.3. Relying Party Trust of Proxy Certificates. . . . . . . . 31 + 6.4. Protecting Against Denial of Service with Key Generation 32 + 6.5. Use of Proxy Certificates in a Central Repository. . . . 32 + 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 33 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 33 + 8.2. Informative References . . . . . . . . . . . . . . . . . 33 + 9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 34 + Appendix A. 1988 ASN.1 Module. . . . . . . . . . . . . . . . . . . 35 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 + Full Copyright Notice. . . . . . . . . . . . . . . . . . . . . . . 37 + + + + + + + + + +Tuecke, et al. Standards Track [Page 2] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +1. Introduction + + Use of a proxy credential [i7] is a common technique used in security + systems to allow entity A to grant to another entity B the right for + B to be authorized with others as if it were A. In other words, + entity B is acting as a proxy on behalf of entity A. This document + forms a certificate profile for Proxy Certificates, based on the RFC + 3280, "Internet X.509 Public Key Infrastructure Certificate and CRL + Profile" [n2]. + + In addition to simple, unrestricted proxying, this profile defines: + + * A framework for carrying policies in Proxy Certificates that + allows proxying to be limited (perhaps completely disallowed) + through either restrictions or enumeration of rights. + + * Proxy Certificates with unique names, derived from the name of the + end entity certificate name. This allows the Proxy Certificates + to be used in conjunction with attribute assertion approaches such + as Attribute Certificates [i3] and have their own rights + independent of their issuer. + + Section 2 provides a non-normative overview of the approach. It + begins by defining terminology, motivating Proxy Certificates, and + giving a brief overview of the approach. It then introduces the + notion of a Proxy Issuer, as distinct from a Certificate Authority, + to describe how end entity signing of a Proxy Certificate is + different from end entity signing of another end entity certificate, + and therefore why this approach does not violate the end entity + signing restrictions contained in the X.509 keyCertSign field of the + keyUsage extension. It then continues with discussions of how + subject names are used by this proxying approach, and features of + this approach. + + Section 3 defines requirements on information content in Proxy + Certificates. This profile addresses two fields in the basic + certificate as well as five certificate extensions. The certificate + fields are the subject and issuer fields. The certificate extensions + are subject alternative name, issuer alternative name, key usage, + basic constraints, and extended key usage. A new certificate + extension, Proxy Certificate Information, is introduced. + + Section 4 defines path validation rules for Proxy Certificates. + + Section 5 provides non-normative commentary on Proxy Certificates. + + Section 6 discusses security considerations relating to Proxy + Certificates. + + + +Tuecke, et al. Standards Track [Page 3] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + References, listed in Section 8, are sorted into normative and + information references. Normative references, listed in Section 8.1, + are in the form [nXX]. Informative references, listed in Section + 8.2, are in the form [iXX]. + + Section 9 contains acknowledgements. + + Following Section 9, contains the Appendix, the contact information + for the authors, the intellectual property information, and the + copyright information for this document. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 [n1]. + +2. Overview of Approach + + This section provides non-normative commentary on Proxy Certificates. + + The goal of this specification is to develop a X.509 Proxy + Certificate profile and to facilitate their use within Internet + applications for those communities wishing to make use of restricted + proxying and delegation within an X.509 Public Key Infrastructure + (PKI) authentication based system. + + This section provides relevant background, motivation, an overview of + the approach, and related work. + +2.1. Terminology + + This document uses the following terms: + + * CA: A "Certification Authority", as defined by X.509 [n2] + + * EEC: An "End Entity Certificate", as defined by X.509. That is, + it is an X.509 Public Key Certificate issued to an end entity, + such as a user or a service, by a CA. + + * PKC: An end entity "Public Key Certificate". This is synonymous + with an EEC. + + * PC: A "Proxy Certificate", the profile of which is defined by this + document. + + + + + + + + +Tuecke, et al. Standards Track [Page 4] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + * PI: A "Proxy Issuer" is an entity with an End Entity Certificate + or Proxy Certificate that issues a Proxy Certificate. The Proxy + Certificate is signed using the private key associated with the + public key in the Proxy Issuer's certificate. + + * AC: An "Attribute Certificate", as defined by "An Internet + Attribute Certificate Profile for Authorization" [i3]. + + * AA: An "Attribute Authority", as defined in [i3]. + +2.2. Background + + Computational and Data "Grids" have emerged as a common approach to + constructing dynamic, inter-domain, distributed computing + environments. As explained in [i5], large research and development + efforts starting around 1995 have focused on the question of what + protocols, services, and APIs are required for effective, coordinated + use of resources in these Grid environments. + + In 1997, the Globus Project (www.globus.org) introduced the Grid + Security Infrastructure (GSI) [i4]. This library provides for public + key based authentication and message protection, based on standard + X.509 certificates and public key infrastructure, the SSL/TLS + protocol [i2], and delegation using proxy certificates similar to + those profiled in this document. GSI has been used, in turn, to + build numerous middleware libraries and applications, which have been + deployed in large-scale production and experimental Grids [i1]. GSI + has emerged as the dominant security solution used by Grid efforts + worldwide. + + This experience with GSI has proven the viability of restricted + proxying as a basis for authorization within Grids, and has further + proven the viability of using X.509 Proxy Certificates, as defined in + this document, as the basis for that proxying. This document is one + part of an effort to migrate this experience with GSI into standards, + and in the process clean up the approach and better reconcile it with + existing and recent standards. + +2.3. Motivation for Proxying + + A motivating example will assist in understanding the role proxying + can play in building Internet based applications. + + Steve is an engineer who wants to use a reliable file transfer + service to manage the movement of a number of large files around + between various hosts on his company's Intranet-based Grid. From his + laptop he wants to submit a number of transfer requests to the + service and have the files transferred while he is doing other + + + +Tuecke, et al. Standards Track [Page 5] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + things, including being offline. The transfer service may queue the + requests for some time (e.g., until after hours or a period of low + resource usage) before initiating the transfers. The transfer + service will then, for each file, connect to each of the source and + destination hosts, and instruct them to initiate a data connection + directly from the source to the destination in order to transfer the + file. Steve will leave an agent running on his laptop that will + periodically check on progress of the transfer by contacting the + transfer service. Of course, he wants all of this to happen securely + on his company's resources, which requires that he initiate all of + this using his PKI smartcard. + + This scenario requires authentication and delegation in a variety of + places: + + * Steve needs to be able to mutually authenticate with the reliable + file transfer service to submit the transfer request. + + * Since the storage hosts know nothing about the file transfer + service, the file transfer service needs to be delegated the + rights to mutually authenticate with the various storage hosts + involved directly in the file transfer, in order to initiate the + file transfer. + + * The source and destination hosts of a particular transfer must be + able to mutual authenticate with each other, to ensure the file is + being transferred to and from the proper parties. + + * The agent running on Steve's laptop must mutually authenticate + with the file transfer service in order to check the result of the + transfers. + + Proxying is a viable approach to solving two (related) problems in + this scenario: + + * Single sign-on: Steve wants to enter his smartcard password (or + pin) once, and then run a program that will submit all the file + transfer requests to the transfer service, and then periodically + check on the status of the transfer. This program needs to be + given the rights to be able to perform all of these operations + securely, without requiring repeated access to the smartcard or + Steve's password. + + * Delegation: Various remote processes in this scenario need to + perform secure operations on Steve's behalf, and therefore must be + delegated the necessary rights. For example, the file transfer + + + + + +Tuecke, et al. Standards Track [Page 6] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + service needs to be able to authenticate on Steve's behalf with + the source and destination hosts, and must in turn delegate rights + to those hosts so that they can authenticate with each other. + + Proxying can be used to secure all of these interactions: + + * Proxying allows for the private key stored on the smartcard to be + accessed just once, in order to create the necessary proxy + credential, which allows the client/agent program to be authorized + as Steve when submitting the requests to the transfer service. + Access to the smartcard and Steve's password is not required after + the initial creation of the proxy credential. + + * The client program on the laptop can delegate to the file transfer + service the right to act on Steve's behalf. This, in turn, allows + the service to authenticate to the storage hosts and inherit + Steve's privileges in order to start the file transfers. + + * When the transfer service authenticates to hosts to start the file + transfer, the service can delegate to the hosts the right to act + on Steve's behalf so that each pair of hosts involved in a file + transfer can mutually authenticate to ensure the file is securely + transferred. + + * When the agent on the laptop reconnects to the file transfer + service to check on the status of the transfer, it can perform + mutual authentication. The laptop may use a newly generated proxy + credential, which is just created anew using the smartcard. + + This scenario, and others similar to it, is being built today within + the Grid community. The Grid Security Infrastructure's single sign- + on and delegation capabilities, built on X.509 Proxy Certificates, + are being employed to provide authentication services to these + applications. + +2.4. Motivation for Restricted Proxies + + One concern that arises is what happens if a machine that has been + delegated the right to inherit Steve's privileges has been + compromised? For example, in the above scenario, what if the machine + running the file transfer service is compromised, such that the + attacker can gain access to the credential that Steve delegated to + that service? Can the attacker now do everything that Steve is + allowed to do? + + A solution to this problem is to allow for restrictions to be placed + on the proxy by means of policies on the proxy certificates. For + example, the machine running the reliable file transfer service in + + + +Tuecke, et al. Standards Track [Page 7] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + the above example might only be given Steve's right for the purpose + of reading the source files and writing the destination files. + Therefore, if that file transfer service is compromised, the attacker + cannot modify source files, cannot create or modify other files to + which Steve has access, cannot start jobs on behalf of Steve, etc. + All that an attacker would be able to do is read the specific files + to which the file transfer service has been delegated read access, + and write bogus files in place of those that the file transfer + service has been delegated write access. Further, by limiting the + lifetime of the credential that is delegated to the file transfer + service, the effects of a compromise can be further mitigated. + + Other potential uses for restricted proxy credentials are discussed + in [i7]. + +2.5. Motivation for Unique Proxy Name + + The dynamic creation of entities (e.g., processes and services) is an + essential part of Grid computing. These entities will require rights + in order to securely perform their function. While it is possible to + obtain rights solely through proxying as described in previous + sections, this has limitations. For example what if an entity should + have rights that are granted not just from the proxy issuer but from + a third party as well? While it is possible in this case for the + entity to obtain and hold two proxy certifications, in practice it is + simpler for subsequent credentials to take the form of attribute + certificates. + + It is also desirable for these entities to have a unique identity so + that they can be explicitly discussed in policy statements. For + example, a user initiating a third-party FTP transfer could grant + each FTP server a PC with a unique identity and inform each server of + the identity of the other, then when the two servers connected they + could authenticate themselves and know they are connected to the + proper party. + + In order for a party to have rights of it's own it requires a unique + identity. Possible options for obtaining an unique identity are: + + 1) Obtain an identity from a traditional Certification Authority + (CA). + + 2) Obtain a new identity independently - for example by using the + generated public key and a self-signed certificate. + + 3) Derive the new identity from an existing identity. + + + + + +Tuecke, et al. Standards Track [Page 8] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + In this document we describe an approach to option #3, because: + + * It is reasonably light-weight, as it can be done without + interacting with a third party. This is important when + creating identities dynamically. + + * As described in the previous section, a common use for PCs is + for restricted proxying, so deriving their identity from the + identity of the EEC makes this straightforward. Nonetheless + there are circumstances where the creator does not wish to + delegate all or any of its rights to a new entity. Since the + name is unique, this is easily accomplished by #3 as well, by + allowing the application of a policy to limit proxying. + +2.6. Description Of Approach + + This document defines an X.509 "Proxy Certificate" or "PC" as a means + of providing for restricted proxying within an (extended) X.509 PKI + based authentication system. + + A Proxy Certificate is an X.509 public key certificate with the + following properties: + + 1) It is signed by either an X.509 End Entity Certificate (EEC), or + by another PC. This EEC or PC is referred to as the Proxy Issuer + (PI). + + 2) It can sign only another PC. It cannot sign an EEC. + + 3) It has its own public and private key pair, distinct from any + other EEC or PC. + + 4) It has an identity derived from the identity of the EEC that + signed the PC. When a PC is used for authentication, in may + inherit rights of the EEC that signed the PC, subject to the + restrictions that are placed on that PC by the EEC. + + 5) Although its identity is derived from the EEC's identity, it is + also unique. This allows this identity to be used for + authorization as an independent identity from the identity of the + issuing EEC, for example in conjunction with attribute assertions + as defined in [i3]. + + 6) It contains a new X.509 extension to identify it as a PC and to + place policies on the use of the PC. This new extension, along + with other X.509 fields and extensions, are used to enable proper + path validation and use of the PC. + + + + +Tuecke, et al. Standards Track [Page 9] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + The process of creating a PC is as follows: + + 1) A new public and private key pair is generated. + + 2) That key pair is used to create a request for a Proxy Certificate + that conforms to the profile described in this document. + + 3) A Proxy Certificate, signed by the private key of the EEC or by + another PC, is created in response to the request. During this + process, the PC request is verified to ensure that the requested + PC is valid (e.g., it is not an EEC, the PC fields are + appropriately set, etc). + + When a PC is created as part of a delegation from entity A to entity + B, this process is modified by performing steps #1 and #2 within + entity B, then passing the PC request from entity B to entity A over + an authenticated, integrity checked channel, then entity A performs + step #3 and passes the PC back to entity B. + + Path validation of a PC is very similar to normal path validation, + with a few additional checks to ensure, for example, proper PC + signing constraints. + +2.7. Features Of This Approach + + Using Proxy Certificates to perform delegation has several features + that make it attractive: + + * Ease of integration + + o Because a PC requires only a minimal change to path validation, + it is very easy to incorporate support for Proxy Certificates + 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. + + o 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. + + + + + + +Tuecke, et al. Standards Track [Page 10] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + * Ease of use + + o 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. + + o 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 + + o 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. + + o 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 + + o 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. + + + + + +Tuecke, et al. Standards Track [Page 11] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + o 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. + +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. + + + + + + + +Tuecke, et al. Standards Track [Page 12] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + 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. + + 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 document 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. + + + + + + + +Tuecke, et al. Standards Track [Page 13] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +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-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) + dod(6) internet(1) security(5) mechanisms(5) pkix(7) } + + id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } + + id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 } + + 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 two 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 + pCPathLenConstraint field is not present then the maximum proxy path + length is unlimited. End entity certificates have unlimited maximum + proxy path lengths. + + + + + +Tuecke, et al. Standards Track [Page 14] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +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 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. Authors of additional + policy languages are encouraged to publicly document their policy + language and list it in the IANA registry (see Section 7). + + + + + +Tuecke, et al. Standards Track [Page 15] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + 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 its issuer, 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, the relying + party MUST verify that the following three conditions are all met: + + 1) The relying party MUST know how to interpret the proxy policy and + the request is allowed under that policy. + + 2) If the Proxy Issuer is an EEC then the relying party's local + policies MUST authorize the request for the entity named in the + EEC. + + 3) If the Proxy Issuer is another PC, then one of the following MUST + be true: + + a. The relying party's local policies authorize the Proxy Issuer + to perform the request. + + b. The Proxy Issuer inherits the right to perform the request from + its issuer by means of its proxy policy. This must be verified + by verifying these three conditions on the Proxy Issuer in a + recursive manner. + + 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). + + 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 + + + +Tuecke, et al. Standards Track [Page 16] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + 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. 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, et al. Standards Track [Page 17] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + 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 [n2]. 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) for all certificates in the path with a pCPathLenConstraint + field, the number of certificates in the path following that + certificate does not exceed the length specified in that field. + + At this point there is no mechanism defined for revoking proxy + certificates. + + + + + + + +Tuecke, et al. Standards Track [Page 18] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +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, + + (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). + + (d) the current date and time. + + + + + + +Tuecke, et al. Standards Track [Page 19] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +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. + +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: + + + + + + +Tuecke, et al. Standards Track [Page 20] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + (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 its 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) Process other certificate extensions, as described in [n2]: + + (1) Recognize and process any other critical extensions present in + the proxy certificate. + + (2) Process any recognized non-critical extension present in the + proxy certificate. + + If either step (a), (b) or (d) 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, et al. Standards Track [Page 21] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + (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 Procedures + + (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 + 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. + + + + + + +Tuecke, et al. Standards Track [Page 22] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +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 ProxyCertInfo extension, which + always contains a policy language OID, and may also contain a policy + OCTET STRING. 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 on the subject + distinguished name of the proxy certificate or on one of the proxy + certificates in it's issuing chain or on 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. + + Application making authorization decisions based on 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. + + + + +Tuecke, et al. Standards Track [Page 23] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +5. Commentary + + This section provides non-normative commentary on Proxy Certificates. + +5.1. Relationship to Attribute Certificates + + An Attribute Certificate [i3] 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 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 + + + +Tuecke, et al. Standards Track [Page 24] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + 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.2. Delegation Using Attribute Certificates + + In the motivating example in Section 2, 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). + + + + + +Tuecke, et al. Standards Track [Page 25] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + * 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 + 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 + other factors. + +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" [i3] 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." + + + + + +Tuecke, et al. Standards Track [Page 26] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + 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. + + 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. + + 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 + + + +Tuecke, et al. Standards Track [Page 27] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + 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 [i6]) 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 (Key Distribution Center), 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. + +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. + + + + + + + +Tuecke, et al. Standards Track [Page 28] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +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. + + 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 + + + + + +Tuecke, et al. Standards Track [Page 29] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + 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. + +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 PC path validation checks, a PC cannot + be used to sign an EEC or PC for another user. + + + +Tuecke, et al. Standards Track [Page 30] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + 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 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. + +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. + + + + + +Tuecke, et al. Standards Track [Page 31] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + 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 to issue 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. + +6.4. Protecting Against Denial of Service with Key Generation + + As discussed in Section 2.3, one of the motivations for Proxy + Certificates is to allow for dynamic delegation between parties. This + delegation potentially requires, by the party receiving the + delegation, the generation of a new key pair which is a potentially + computationally expensive operation. Care should be taken by such + parties to prevent another entity from performing a denial of service + attack by causing them to consume large amount of resource doing key + generation. + + A general guideline would always to perform authentication of the + delegating party to prevent such attacks from being performed + anonymously. Another guideline would be to maintain some state to + detect and prevent such attacks. + +6.5. Use of Proxy Certificates with a Central Repository + + As discussed in Section 2.7, one potential use of Proxy Certificates + is to ease certificate management for end users by storing 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. and the + repository would then delegate a PC to the user with proxy rights, + but continue to protect the EEC private key in the repository. + + Care must be taken with this approach since compromise of the + repository will potentially give the attacker access to the long-term + private keys stored in the repository. It is strongly suggested that + some form of hardware module be used to store the long-term private + keys, which will serve to help prevent their direct threat though it + may still allow a successful attacker to use the keys while the + repository is compromised to sign arbitrary objects (including Proxy + Certificates). + + + + + +Tuecke, et al. Standards Track [Page 32] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +7. IANA Considerations + + IANA has established a registry for policy languages. Registration + under IETF space is by IETF standards action as described in [i8]. + Private policy languages should be under organizational OIDs; policy + language authors are encouraged to list such languages in the IANA + registry, along with a pointer to a specification. + + OID Description + --- ----------- + 1.3.6.1.5.5.7.21.1 id-ppl-inheritALL + 1.3.6.1.5.5.7.21.2 id-ppl-independent + +8. References + +8.1. Normative References + + [n1] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [n2] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 + Public Key Infrastructure Certificate and Certificate + Revocation List (CRL) Profile", RFC 3280, April 2002. + +8.2. Informative References + + [i1] Butler, R., Engert, D., Foster, I., Kesselman, C., and S. + Tuecke, "A National-Scale Authentication Infrastructure", + IEEE Computer, vol. 33, pp. 60-66, 2000. + + [i2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC + 2246, January 1999. + + [i3] Farrell, S. and R. Housley, "An Internet Attribute + Certificate Profile for Authorization", RFC 3281, April 2002. + + [i4] Foster, I., Kesselman, C., Tsudik, G., and S. Tuecke, "A + Security Architecture for Computational Grids", presented at + Proceedings of the 5th ACM Conference on Computer and + Communications Security, 1998. + + [i5] Foster, I., Kesselman, C., and S. Tuecke, "The Anatomy of the + Grid: Enabling Scalable Virtual Organizations", International + Journal of Supercomputer Applications, 2001. + + [i6] Kohl, J. and C. Neuman, "The Kerberos Network Authentication + Service (V5)", RFC 1510, September 1993. + + + + +Tuecke, et al. Standards Track [Page 33] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + + [i7] Neuman, B. Clifford, "Proxy-Based Authorization and + Accounting for Distributed Systems", In Proceedings of the + 13th International Conference on Distributed Computing + Systems, pages 283-291, May 1993. + + [i8] Narten, T. and H. Alvestrand. "Guidelines for Writing an IANA + Considerations Section in RFC", RFC 2434, October 1998. + +9. Acknowledgments + + We are pleased to acknowledge significant contributions to this + document by David Chadwick, Ian Foster, Jarek Gawor, Carl Kesselman, + Sam Meder, Jim Schaad, and Frank Siebenlist. + + 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): Carlisle Adams, Joe Bester, Randy + Butler, Keith Jackson, Steve Hanna, Russ Housley, Stephen Kent, Bill + Johnston, Marty Humphrey, Sam Lang, Ellen McDermott, Clifford Neuman, + 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. + + + + + + + + + + + + + + + + + + +Tuecke, et al. Standards Track [Page 34] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +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 + 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 + 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, et al. Standards Track [Page 35] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +Authors' Addresses + + 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 + + + Von Welch + National Center for Supercomputing Applications + University of Illinois + + EMail: vwelch@ncsa.uiuc.edu + + + Doug Engert + Argonne National Laboratory + + EMail: deengert@anl.gov + + + Laura Pearlman + University of Southern California, Information Sciences Institute + + EMail: laura@isi.edu + + + Mary Thompson + Lawrence Berkeley National Laboratory + + EMail: mrthompson@lbl.gov + + + + + + + + + + + + + + + + +Tuecke, et al. Standards Track [Page 36] + +RFC 3820 X.509 Proxy Certificate Profile June 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights 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; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Tuecke, et al. Standards Track [Page 37] + |