rfc3820

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 int