Internet X.509 Public Key Infraestructura (PKI) Proxy Certificate Profile
| Autor | The Internet Society |
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.
-
Introduction
Use of a proxy credential [i7] is a common technique used in security systems to allow entity A to grant to another entity B the right for B to be authorized with others as if it were A. In other words, entity B is acting as a proxy on behalf of entity A. This document forms a certificate profile for Proxy Certificates, based on the RFC 3280, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile" [n2].
In addition to simple, unrestricted proxying, this profile defines:
- A framework for carrying policies in Proxy Certificates that allows proxying to be limited (perhaps completely disallowed) through either restrictions or enumeration of rights.
- Proxy Certificates with unique names, derived from the name of the end entity certificate name. This allows the Proxy Certificates to be used in conjunction with attribute assertion approaches such as Attribute Certificates [i3] and have their own rights independent of their issuer.
Section 2 provides a non-normative overview of the approach. It begins by defining terminology, motivating Proxy Certificates, and giving a brief overview of the approach. It then introduces the notion of a Proxy Issuer, as distinct from a Certificate Authority, to describe how end entity signing of a Proxy Certificate is different from end entity signing of another end entity certificate, and therefore why this approach does not violate the end entity signing restrictions contained in the X.509 keyCertSign field of the keyUsage extension. It then continues with discussions of how subject names are used by this proxying approach, and features of this approach.
Section 3 defines requirements on information content in Proxy Certificates. This profile addresses two fields in the basic certificate as well as five certificate extensions. The certificate fields are the subject and issuer fields. The certificate extensions are subject alternative name, issuer alternative name, key usage, basic constraints, and extended key usage. A new certificate extension, Proxy Certificate Information, is introduced.
Section 4 defines path validation rules for Proxy Certificates.
Section 5 provides non-normative commentary on Proxy Certificates.
Section 6 discusses security considerations relating to Proxy Certificates.
References, listed in Section 8, are sorted into normative and information references. Normative references, listed in Section 8.1, are in the form [nXX]. Informative references, listed in Section 8.2, are in the form [iXX].
Section 9 contains acknowledgements.
Following Section 9, contains the Appendix, the contact information for the authors, the intellectual property information, and the copyright information for this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [n1].
-
Overview of Approach
This section provides non-normative commentary on Proxy Certificates.
The goal of this specification is to develop a X.509 Proxy Certificate profile and to facilitate their use within Internet applications for those communities wishing to make use of restricted proxying and delegation within an X.509 Public Key Infrastructure (PKI) authentication based system.
This section provides relevant background, motivation, an overview of the approach, and related work.
2.1. Terminology
This document uses the following terms:
- CA: A "Certification Authority", as defined by X.509 [n2]
- EEC: An "End Entity Certificate", as defined by X.509. That is, it is an X.509 Public Key Certificate issued to an end entity, such as a user or a service, by a CA.
- PKC: An end entity "Public Key Certificate". This is synonymous with an EEC.
- PC: A "Proxy Certificate", the profile of which is defined by this document.
- PI: A "Proxy Issuer" is an entity with an End Entity Certificate or Proxy Certificate that issues a Proxy Certificate. The Proxy Certificate is signed using the private key associated with the public key in the Proxy Issuer's certificate.
- AC: An "Attribute Certificate", as defined by "An Internet Attribute Certificate Profile for Authorization" [i3].
- AA: An "Attribute Authority", as defined in [i3].
2.2. Background
Computational and Data "Grids" have emerged as a common approach to constructing dynamic, inter-domain, distributed computing environments. As explained in [i5], large research and development efforts starting around 1995 have focused on the question of what protocols, services, and APIs are required for effective, coordinated use of resources in these Grid environments.
In 1997, the Globus Project (www.globus.org) introduced the Grid Security Infrastructure (GSI) [i4]. This library provides for public key based authentication and message protection, based on standard X.509 certificates and public key infrastructure, the SSL/TLS protocol [i2], and delegation using proxy certificates similar to those profiled in this document. GSI has been used, in turn, to build numerous middleware libraries and applications, which have been deployed in large-scale production and experimental Grids [i1]. GSI has emerged as the dominant security solution used by Grid efforts worldwide.
This experience with GSI has proven the viability of restricted proxying as a basis for authorization within Grids, and has further proven the viability of using X.509 Proxy Certificates, as defined in this document, as the basis for that proxying. This document is one part of an effort to migrate this experience with GSI into standards, and in the process clean up the approach and better reconcile it with existing and recent standards.
2.3. Motivation for Proxying
A motivating example will assist in understanding the role proxying can play in building Internet based applications.
Steve is an engineer who wants to use a reliable file transfer service to manage the movement of a number of large files around between various hosts on his company's Intranet-based Grid. From his laptop he wants to submit a number of transfer requests to the service and have the files transferred while he is doing other things, including being offline. The transfer service may queue the requests for some time (e.g., until after hours or a period of low resource usage) before initiating the transfers. The transfer service will then, for each file, connect to each of the source and destination hosts, and instruct them to initiate a data connection directly from the source to the destination in order to transfer the file. Steve will leave an agent running on his laptop that will periodically check on progress of the transfer by contacting the transfer service. Of course, he wants all of this to happen securely on his company's resources, which requires that he initiate all of this using his PKI smartcard.
This scenario requires authentication and delegation in a variety of places:
- Steve needs to be able to mutually authenticate with the reliable file transfer service to submit the transfer request.
- Since the storage hosts know nothing about the file transfer service, the file transfer service needs to be delegated the rights to mutually authenticate with the various storage hosts involved directly in the file transfer, in order to initiate the file transfer.
- The source and destination hosts of a particular transfer must be able to mutual authenticate with each other, to ensure the file is being transferred to and from the proper parties.
- The agent running on Steve's laptop must mutually authenticate with the file transfer service in order to check the result of the transfers.
Proxying is a viable approach to solving two (related) problems in this scenario:
- Single sign-on: Steve wants to enter his smartcard password (or pin) once, and then run a program that will submit all the file transfer requests to the transfer service, and then periodically check on the status of the transfer. This program needs to be given the rights to be able to perform all of these operations securely, without requiring repeated access to the smartcard or Steve's password.
- Delegation: Various remote processes in this scenario need to perform secure operations on Steve's behalf, and therefore must be delegated the necessary rights. For example, the file transfer service needs to be able to authenticate on Steve's behalf with the source and destination hosts, and must in turn delegate rights to those hosts so that they can authenticate with each other.
Proxying can be used to secure all of these interactions:
- Proxying allows for the private key stored on the smartcard to be accessed just once, in order to create the necessary proxy credential, which allows the client/agent program to be authorized as Steve when submitting the requests to the transfer service.
Access to the smartcard and Steve's password is not required after the initial creation of the proxy credential.
- The client program on the laptop can delegate to the file transfer service the right to act on Steve's behalf. This, in turn...
Para continuar leyendo
Solicita tu prueba