Internet Draft S. Tuecke Document: draft-ietf-pkix-impersonation-00.txt D. Engert ANL M. Thompson LBNL Expires: July 2001 February 2001 Internet X.509 Public Key Infrastructure Impersonation Certificate Profile Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document forms a certificate profile for Impersonation Certificates, based on X.509 PKI certificates as defined in draft- ietf-pkix-new-part1-04.txt (the draft update to RFC 2459), for use in the Internet. The term Impersonation 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 Impersonation Certificate for the purpose of providing impersonation within a PKI based authentication system. Tuecke, Engert, Thompson Expires July 2001 1 Internet Draft X.509 Impersonation February 2001 Table of Contents Internet X.509 Public Key Infrastructure Impersonation Certificate Profile.............................................................1 Status of this Memo.................................................1 Abstract............................................................1 Table of Contents...................................................2 1. Introduction...................................................3 2. Overview of Approach...........................................4 2.1. Terminology..................................................4 2.2. Background...................................................4 2.3. Motivation for Impersonation.................................5 2.4. Description Of Approach......................................7 2.5. Impersonation Authority, not Certificate Authority...........8 2.6. Names Versus Subjects........................................9 2.7. Features Of This Approach....................................9 3. Certificate and Certificate Extensions Profile................11 3.1. Issuer & Issuer Alternative Name............................11 3.2. Subject & Subject Alternative Name..........................11 3.3. Key Usage...................................................11 3.4. Extended Key Usage..........................................12 3.5. Basic Constraints...........................................12 3.6. Impersonation Certificate Information.......................12 4. Certificate Path Validation...................................13 5. Relationship to Attribute Certificates........................16 5.1. Types of Attribute Authorities..............................16 5.2. Delegation Using Attribute Certificates.....................17 5.3. Propagation of Authorization Information....................17 5.4. Impersonation Certificate as Attribute Certificate Holder...18 6. Commentary....................................................19 6.1. keyCertSign Bit in the Key Usage Basic Extension............19 6.2. nonRepudiate Bit in the Key Usage Basic Extension...........20 6.3. Subject Name of an Impersonation Certificate................20 6.4. Carrying Along the End Entity Subject.......................21 6.5. Delegation Tracing..........................................21 6.6. Restricted Impersonation Certificate........................22 6.7. Certificate Policies Extension..............................22 6.8. Kerberos 5 Tickets..........................................22 7. Security Considerations.......................................24 8. References....................................................25 9. Acknowledgments...............................................25 10. Contact Information...........................................26 Tuecke, Engert, Thompson Expires July 2001 2 Internet Draft X.509 Impersonation February 2001 1. Introduction Impersonation is a common technique used in security systems to allow entity A to grant to another entity B the right for B to authenticate with others as if it were A. In other words, entity B is impersonating entity A. This document forms a certificate profile for Impersonation Certificates, based on the draft update to RFC 2459, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile" [7]. Section 2 provides an overview of the approach. It begins by defining terminology, motivating Impersonation Certificates, and giving a brief overview of the approach. It then introduces the notion of an Impersonation Authority, as distinct from a Certificate Authority, to describe how end entity signing of an Impersonation Certificate is different from end entity signing of another end entity certificate, and therefore why this approach does not violate the end entity signing restrictions contained in the X.509 keyCertSign field of the keyUsage extension. It then continues with discussions of how subject names are used by this impersonation approach, and features of this approach. Section 3 defines requirements on information content in Impersonation 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. One new certificate extensions, impersonation certificate, is introduced. Section 4 defines path validation rules for Impersonation Certificates. Section 5 discusses the relationship of Impersonation Certificates Attribute Certificates. Section 6 provides commentary on various design choices, open issues, related work, and future directions. Section 7 discusses security considerations relating to Impersonation Certificates. Section 8 contains the references. Section 9 contains acknowledgements. Section 10 contains contact information for the authors. This document was written under the auspices of the Global Grid Forum Security Working Group. For more information on this and other related work, see http://www.gridforum.org/security. Tuecke, Engert, Thompson Expires July 2001 3 Internet Draft X.509 Impersonation February 2001 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. 2. Overview of Approach The goal of this specification is to develop an X.509 Impersonation Certificate profile, to facilitate their use within Internet applications for those communities wishing to make use of impersonation within an X.509 PKI authentication based system. This section provides relevant background, motivation, an overview of the approach, and related work. 2.1. Terminology This document uses the following terms: * CA: A "Certificate Authority", as defined by X.509 [7]. * EEC: An "End Entity Certificate", as defined by X.509. That is, it is an X.509 Public Key Certificate issued to an end entity, such as a user or a service, by a CA. * PKC: An end entity "Public Key Certificate". This is synonymous with an EEC. * IC: An "Impersonation Certificate", the profile of which is defined by this document. * IA: An "Impersonation Authority" is the issuer of an Impersonation Certificate, as defined below. * AC: An "Attribute Certificate", as defined by "An Internet Attribute Certificate Profile for Authorization" [4]. * AA: An "Attribute Authority", as defined in [4]. 2.2. Background Computational and Data "Grids" have emerged as a common approach to constructing dynamic, inter-domain, distributed computing environments. As explained in [6], large research and development efforts starting around 1995 have focused on the question of what protocols, services, and APIs are required for effective, coordinated use of resources in these Grid environments. In 1997, the Globus Project (www.globus.org) introduced the Grid Security Infrastructure (GSI) [5]. This library provides for public key based authentication and message protection, based on standard X.509 certificates and public key infrastructure, the SSL/TLS protocol [3], and delegation using impersonation certificates similar to those profiled in this document. GSI has been used, in turn, to build numerous middleware libraries and applications, which Tuecke, Engert, Thompson Expires July 2001 4 Internet Draft X.509 Impersonation February 2001 have been deployed in large scale production and experimental Grids [2]. GSI has emerged as the dominant security solution used by Grid efforts worldwide. This experience with GSI has proven the viability of impersonation as a basis for authentication and authorization within Grids, and has further proven the viability of using X.509 Impersonation Certificates, as defined in this document, as the basis for that impersonation. This document is one part of an effort to migrate this experience with GSI into standards, and in the process clean up the approach and better reconcile it with existing and recent standards. 2.3. Motivation for Impersonation A motivating example will assist in understanding the role impersonation can play in building Internet based applications. Steve is an engineer, who wants to run a set of simulation jobs on idle workstations on his company's Intranet based Grid. From his laptop he wants to invoke the jobs, and then have an agent process running on his desktop workstation monitor the jobs while he is traveling to a conference. As the jobs complete, the agent should automatically archive the results to the companies mass storage system, and after all the jobs are complete it should run a post- processing job which summarizes the simulation results from all of the archived data sets. Later, Steve will reconnect to the agent to get the results for inclusion in a report. 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 authenticate with several remote workstations to start the simulation jobs. * Steve needs to be able to authenticate with his desktop workstation to start the agent running. * That agent needs to be delegated the rights to authenticate with the various workstations, in order to monitor the progress of the simulations. * The simulation jobs on each workstation need to authenticate between each other. * As simulations complete, the agent needs to move the resulting data from the workstations to the company's mass storage system. In order to perform this move efficiently, it needs to orchestrate a third party data transfer directly between the workstation and the mass storage system. This requires authentication between the agent and the workstations and mass storage system, as well as authentication between the Tuecke, Engert, Thompson Expires July 2001 5 Internet Draft X.509 Impersonation February 2001 workstations and the mass storage system. * The agent needs to start the post-processing job, which must be delegated rights to authenticate with the mass storage system in order to retrieve the data. * When Steve later reconnects his laptop to the network, a program running on the laptop must mutually authenticate with the agent in order to retrieve the summary of results. Impersonation is a viable approach to solving two (related) problems in this scenario: * Single sign-on: Steve wants to enter his smartcard password (or pin) once, and then run a program that will start all of the simulation jobs and the remote agent. 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 agent needs to be able to authenticate on Steve's behalf with the various workstations and the mass storage system, and must in turn delegate rights to the post-processing job to authenticate on Steve's behalf with the mass storage system. Impersonation can be used to secure all of these interactions: * Impersonation allows for the private key stored on the smartcard to be accessed just once, in order to create the necessary impersonation credential, which allows the starter program to impersonate Steve (that is, authenticate as Steve) when starting the various jobs and the agent. Access to the smartcard and Steve's password is not required after the initial creation of the impersonation credential. * The starter program on the laptop can delegate to the agent the right to impersonate Steve. This, in turn, allows the agent to authenticate to the workstations as if it were Steve in order to start the simulation jobs, and to the mass storage system to archive the data as if it were Steve. * The starter program on the laptop can delegate to the simulation jobs the right to impersonate Steve. This, in turn, allows the simulation jobs to authenticate with each other, in order to prove to each other that they are all part of Steve's simulation. * When the agent starts the post-processing job, the agent can delegate to it the right to impersonate Steve. This allows the post-processing job to authenticate as Steve to the mass storage system in order to gain access to the data sets. Tuecke, Engert, Thompson Expires July 2001 6 Internet Draft X.509 Impersonation February 2001 * When the laptop reconnects to the agent to get the final results, it can perform mutual authentication. The agent will use its delegated impersonation credential in this interaction. The laptop may use a newly generated impersonation credential, which is just created anew using the smartcard. While this example may seem somewhat contrived, similar applications are already being built today within the Grid community, with the Grid Security Infrastructure's single sign-on and delegation capabilities, built on X.509 impersonation, being employed to provide authentication services to these applications. 2.4. Description Of Approach This document defines an X.509 "Impersonation Certificate" or "IC" as a means of providing for impersonation with an X.509 PKI based authentication system. An Impersonation 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 IC. 2. It can only sign another IC. 3. It has its own public and private key pair, distinct from any other EEC or IC. 4. It has no distinct identity of its own. After an IC is used for authentication, the identity that is used for authorization is that of the EEC that signed the IC. The IC effectively inherits the subject or subjectAltName from its signing EEC. 5. It contains a new X.509 extension to identify it as an IC, and uses other X.509 fields and extensions to enable proper path validation and use of the IC. The process of creating an IC is as follows: 1. A new public and private key pair is generated. 2. An unsigned IC request is created, conforming to the profile described in this document. 3. The IC request is signed by the private key of the EEC, or by another IC. During this process, the unsigned IC is verified to ensure that it is valid (e.g. it is not an EEC, the IC fields are appropriately set, etc). When an IC 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 IC request from entity B to entity A over an integrity checked channel, then entity A performs step #3 Tuecke, Engert, Thompson Expires July 2001 7 Internet Draft X.509 Impersonation February 2001 and passes the IC back to entity B. (Note: There is a related draft that describes how this delegation approach can be incorporated into the TLS protocol [8].) Path validation of an IC is very similar to normal path validation, with a few additional checks to ensure, for example, proper IC signing constraints. In order to make the appropriate IC(s) and EEC available for path validation, the authentication protocol using the IC (e.g. TLS) may pass the entire IC and EEC chain as part of the authentication protocol. 2.5. Impersonation Authority, not Certificate Authority A common initial reaction against the approach described in this document is, "You are using the end entity certificate (EEC) as a CA!" However, this is not the case. To understand why, one must first understand what a CA does. In issuing an EEC, a CA performs two primary functions: 1. Naming: The CA assigns a (generally unique) "Name" to the end entity to which it issues an EEC. This Name is contained in the subject or subjectAltName field of the issued EEC. 2. Key to Name binding: By singing an EEC with the CA's private key, the CA is providing a means to allow an authenticating party to verify that the holder of a particular private key should be associated with (bound to) a particular Name. In addition, a CA usually has an associated Registration Authority, which performs the checks necessary to bind the Name to the real world entity (e.g. person, computer, etc) that is to be the bearer of that Name. The reason for doing all of this is to allow for authorization decisions to be made, based at least in part on these CA issued Names. In other words, after the public key authentication operation has determined the Name of the authenticating party, then that Name can be used as the basis for deciding what the entity is allowed to do. (Note: Attribute certificates are discussed below.) The critical difference between using an EEC to sign an Impersonation Certificate, versus using an EEC to sign another EEC, is that an Impersonation Certificate does NOT define a new Name. Rather, Impersonation Certificate inherits the name from the EEC that signs it. The next section describes this inheritance in more detail. In effect, the IC simply provides another route to validating the Key to Name binding that the CA has established with an EEC. It allows entity A to give to entity B the ability to establish this binding, and thus allows B to establish itself as a proper bearer of A's Name. Tuecke, Engert, Thompson Expires July 2001 8 Internet Draft X.509 Impersonation February 2001 For this reason, we use the term "Impersonation Authority", rather than "Certificate Authority", to refer to the issuer of an Impersonation Certificates. 2.6. Names Versus Subjects In X.509 certificates, the subject (or subjectAltName) is used for two distinct purposes: 1. In an End Entity Certificate, the subject is the Name that the CA has issued, as described in the previous section. This Name is typically used for authorization purposes. 2. In a CA Certificate, the subject is also used for path validation. That is, the issuer field in an EEC or CA Certificate must match the subject field of a CA Certificate, in order for the signing path to be established. As stated previously, an IC does not have its own Name, but rather it inherits its Name from its signing EEC (or more accurately, from the EEC that signed the first IC in the IC chain). In practice what this means is that the subject field of an IC is only used for purpose #2. The only purpose of the subject field of an IC is to establish the signing path that eventually leads to an EEC. The implication of this is that after an IC is used for authentication, the IC subject should not be used for authorization. Instead, the IC signing chain should be followed to find the EEC that signed this IC chain, and the subject from that EEC should be used as the identity (or Name) for authorization purposes. To discourage mistakes in this area, this Impersonation Certificate profile defines that the IC subject (actually its subjectAltName) is just a pseudo-randomly generated string. Further, the subject of the EEC is not maintained anywhere in the IC, which forces the authenticating party to properly retrieve the subject from the EEC. 2.7. Features Of This Approach Using Impersonation Certificates to perform delegation has several features that make it attractive: * Ease of integration * Because an IC requires only a minimal change to path validation, it is very easy to incorporate support for Impersonation Certificates into existing X.509 based software. For example, SSL/TLS requires no protocol changes to support authentication using an IC, and only small changes to support delegation of an IC [8]. Further, an SSL/TLS implementation requires only minor changes to support IC path validation, and to retrieve the authenticated subject of the signing EEC instead of the subject of the IC. Tuecke, Engert, Thompson Expires July 2001 9 Internet Draft X.509 Impersonation February 2001 * Many existing authorization systems use the X.509 subject name as the basis for access control. Impersonation Certificates require no change to such authorization systems, since an IC inherits its name from the EEC that signed it. * Ease of use * Using IC for single sign-on helps make X.509 PKI authentication easier to use, by allowing users to "login" once and then perform various operations securely. * For many users, properly managing their own EEC private key is a nuisance at best, and a security risk at worst. One option easily enabled with IC 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 an IC to the user, but continue to protect the EEC private key in the repository. * Protection of private keys * By using the remote delegation approach outlined above, entity A can delegate an IC 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 IC held by entity B. In other words, private keys never need to be shared or communicated by the entities participating in a delegation of an IC. * When implementing single sign-on, using an IC 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 IC. That IC 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 IC. * Limiting consequences of a compromised key * When creating an IC, the IA can limit the validity period of the IC, the depth of the IC path that can be created by that IC, and key usage of the IC and its descendents. This permits the IA to limit any damage that could be done by the bearer of the IC, either accidentally or maliciously. Additional extensions will be proposed to even further reduce exposure to a compromised IC private key. * A compromised IC private key does NOT compromise the EEC private key. This makes an IC attractive for day-to-day use, since a compromised IC does not require the user to go through Tuecke, Engert, Thompson Expires July 2001 10 Internet Draft X.509 Impersonation February 2001 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 Impersonation Certificates relate to Attribute Certificates. 3. Certificate and Certificate Extensions Profile This section defines the usage of X.509 certificate fields and extensions in Impersonation Certificates, and defines one new extension for Impersonation Certificate Information. 3.1. Issuer & Issuer Alternative Name The Impersonation Authority (i.e. the issuer) of an Impersonation Certificate MUST be either an End Entity Certificate, or another Impersonation Certificate. If the Impersonation Authority Certificate has a non-empty subject field, then the issuer field of the Impersonation Certificate MUST contain the subject of the Impersonation Authority Certificate. Otherwise, if the Impersonation Authority Certificate has an empty subject field, but non-empty subjectAltName, then the issuer field of the Impersonation Certificate MUST be an empty sequence, the issuerAltName MUST be the subjectAltName of the Impersonation Authority Certificate, and the issueAltName MUST be critical. 3.2. Subject & Subject Alternative Name The subject field of an Impersonation Certificate MUST be an empty sequence. The subjectAltName extension of an Impersonation Certificate MUST be an otherName, using the impersonationCertName OID (?) and an IA5String (?) containing the name of the Impersonation Certificate. The subjectAltName extension MUST be critical. The subjectAltName of an Impersonation Certificate SHOULD only be used for path validation. As such, the string chosen for the subjectAltName of an Impersonation Certificate is arbitrary, but SHOULD be (statistically) unique in order to enable path validation. 3.3. Key Usage If the issuer certificate includes the keyUsage extension, then the Impersonation Certificate MUST include a keyUsage extension, which MAY further restrict the issuer's keyUsage. If the issuer certificate does not include a keyUsage extension, then the Impersonation Certificate MAY include a keyUsage extension to restrict the key usage of the Impersonation Certificate. Tuecke, Engert, Thompson Expires July 2001 11 Internet Draft X.509 Impersonation February 2001 The keyUsage extension MUST be critical. If the keyUsage extension is present in an Impersonation Certificate, it must conform to the following restrictions: The keyCertSign bit MUST NOT be asserted. The following restriction applies to each of these bits: digitalSignature, nonRepudiate, keyEncipherment, dataEncipherment, keyAgreement, cRLSign, encipherOnly, decipherOnly. If this bit in the issuer certificate is not asserted, then this bit in the Impersonation Certificate MUST NOT be asserted. If this bit in the issuer certificate is asserted, or if the issuer certificate does not include a keyUsage extension, then this bit in the Impersonation Certificate MAY be either asserted or not asserted. See the commentary in section 6 for more information on the keyCertSign and nonRepudiate bits. 3.4. Extended Key Usage If the issuer certificate includes the extKeyUsage extension, then: The Impersonation Certificate MUST include an extKeyUsage extension. Any OID that is contained in the Impersonation Certificate's extKeyUsage extension MUST be present in the issuer certificate's extKeyUsage extension. If the issuer certificate's extKeyUsage extension is critical, then the Impersonation Certificate's extKeyUsage MUST be critical. If the issuer certificate's extKeyUsage extension is not critical, then the Impersonation Certificate's extKeyUsage MAY be critical or non-critical. If the issuer certificate does not include the extKeyUsage entension, then the Impersonation Certificate MAY include a extKeyUsage extension to restrict the key usage of the Impersonation Certificate. In this case, the extKeyUsage extension MAY be critical or non-critical. 3.5. Basic Constraints The cA field in the basic constraints extension MUST NOT be TRUE. 3.6. Impersonation Certificate Information One new extension is defined: id-ce-impersonation-cert-info OBJECT IDENTIFIER ::= { id-ce ?? } Tuecke, Engert, Thompson Expires July 2001 12 Internet Draft X.509 Impersonation February 2001 ImpersonationCertInfo ::= SEQUENCE { iC BOOLEAN DEFAULT TRUE, iCPathLenConstraint INTEGER (0..MAX) OPTIONAL} If a certificate is an Impersonation Certificate, then the impersonationCertInfo extension MUST be present, the iC field MUST be TRUE, and this extension MUST be marked as critical. An Impersonation Certificate MUST NOT be used to sign an End Entity Certificate or a CA Certificate. If a certificate is not an Impersonation Certificate, then the impersonationCertInfo extension MAY be present, and MAY appear as a critical or non-critical extension. In this case, if this extension is present, then iC MUST be FALSE. The iCPathLenConstraint field, if present, specifies the maximum depth of the path of Impersonation Certificates which can be signed by this End Entity Certificate or Impersonation Certificate. An iCPathLenConstraint of 0 means that this certificate MUST not be used to sign an Impersonation Certificate. If the impersonationCertInfo extension is not present, or if the iCPathLenConstraint is not present, then the impersonation path length is unlimited. 4. Certificate Path Validation The Certificate Path Validation algorithm described in Section 6 of draft-ietf-pkik-new-part-04 [7] must be modified to accommodate Impersonation Certificates. Changes are needed to: 1. check the generalized signing chains involving CAs, End Entity Certificates, and Impersonation Certificates; 2. handle the use of subjectAltName and issuerAltName in the certificate path; 3. handle the iCPathLenConstraint in the impersonationCertInfo extension. 4. check the key usage and extended key usage extensions. Changes to section 6.1.2, Initialization: (j) This step defines the working_issuer_name to be a distinguished name. However, because an IC uses the issuerAltName, the working_issuer_name variable needs to be generalized to accommodate not just a distinguished name, but any of the valid issuerAltName/subjectAltName types. (new) working_certificate_type: This can be one of CA, EEC, or IC. A certificate type of CA is determined by the basicConstraints extension or as verified out-of-band. A Tuecke, Engert, Thompson Expires July 2001 13 Internet Draft X.509 Impersonation February 2001 certificate type of IC is determined by the impersonationCertInfo extension. Otherwise, the certificate type is EEC. (new) valid_ic_key_usage & ic_key_usage_criticality: These are used to verify that the key usage of an IC is a subset of the key usage of the certificate that signed that IC, and that the criticality of this extension never diminishes. These variables are not initialized or used until the first EEC or IC is encountered in the path validation algorithm with this extension. (new) valid_ic_ext_key_usage & ic_ext_key_usage_criticality: These are used to verify that the extended key usage OIDs of an IC is a subset of the extended key usage OIDs of the certificate that signed that IC, and that the criticality of this extension never diminishes. These variables are not initialized or used until the first EEC or IC is encountered in the path validation algorithm with this extension. Changes to section 6.1.3, Basic Certificate Processing: (a)(4) The comparison of the certificate issuer name with the working_issuer_name must be generalized to support comparison between any of the valid issuerAltName types. (a)(new) The certificate type is CA and the working_certificate_type is CA, or the certificate type is EEC and the working_certificate_type is CA, or the certificate type is IC and the working_certificate_type is EEC or IC. (b) & (c) This step checks the Name Constraints defined by the CA. However, since an IC does not define a new Name, these checks should be skipped if the certificate type is IC (as specified in a impersonationCertInfo extension). (new) If certificate type is IC, and valid_ic_key_usage has been initialized, then verify that: (1) all bits that are asserted in the keyUsage extension of the certificate are also asserted in the valid_ic_key_usage; (2) if ic_key_usage_criticality is true, then the keyUsage extension is critical (new) If certificate type is IC, and valid_ic_ext_key_usage has been initialized, then verify that: (1) all OIDs that are in the extKeyUsage extension in the certificate are also in the valid_ic_ext_key_usage; (2) if ic_ext_key_usage_criticality is true, then the extKeyUsage extension is critical. Changes to section 6.1.4, Preparation for Certificate i+1: Tuecke, Engert, Thompson Expires July 2001 14 Internet Draft X.509 Impersonation February 2001 (c) Adjust this to assign the subjectAltName to working_issuer_name, if the subject is empty. This is done to accommodate the use of subjectAltName and issuerAltName by ICs. (k) This step verifies that the certificate is a CA certificate. However, it is not general enough to support an IC. So change this step to simply assign the certificate type to the working_certificate_type. The necessary CA, EEC, and IC signing constraints check has been added to the Basic Certificate Processing section above. (m) This step resets the max_path_length if pathLenConstraint is present in the certificate. This needs to be generalized to support iCPathLengthConstraint from the impersonationCertInfo extension, as follows: Reset max_path_length as follows: (1) If certificate type is CA, and pathLenConstraint is present in the certificate and is less than max_path_length, then set max_path_length to the value of pathLenConstraint. (2) If certificate type is EEC, and iCPathLenConstraint is not present in the certificate, then set max_path_length to n. (3) If certificate type is EEC, and iCPathLenConstraint is present in the certificate, then set max_path_length to the value of iCPathLenConstraint. (4) If certificate type is IC, and iCPathLenConstraint is present in the certificate and less than max_path_length, then set max_path_length to the value of iCPathLenConstraint. (n) Since keyCertSign is currently defined to be equivalent to being a CA, this check needs to be changed to accommodate ICs, as follows: If certificate type is CA, and a key usage extension is present and marked critical, verify that the keyCertSign bit is set. (new) If certificate type is EEC or IC, and the key usage extension is present, then set valid_ic_key_usage to keyUsage, and set ic_key_usage_criticality to the keyUsage criticality. (new) If certificate type is EEC or IC, and the extended key usage extension is present, then set valid_ic_ext_key_usage to extKeyUsage, and set ic_ext_key_usage_criticality to the extKeyUsage criticality. At this point we have no plans for an IA (that is, an EEC or IC) to revoke the ICs that it has issued. If this feature is needed in the future, the CRL Distribution Point extension can be used in the IA certificates to locate a CRL. Tuecke, Engert, Thompson Expires July 2001 15 Internet Draft X.509 Impersonation February 2001 5. Relationship to Attribute Certificates An Attribute Certificate [4] can be used to grant to one identity, the holder, some attribute such as a role, clearance level, or alternative identity such as "charging identity" or "audit identity". This is accomplished by way of a trusted Attribute Authority (AA), which issues signed Attribute Certificates (AC), each of which binds an identity to a particular set of attributes. Authorization decisions can then be made by combining information from the authenticated End Entity Certificate providing the identity, with the signed Attribute Certificates providing binding of that identity to attributes. There is clearly some overlap between the capabilities provided by Impersonation 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 Impersonation Certificate and Attribute Certificates. 5.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 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 an IC. For example, Impersonation Certificates can be used to delegate the EEC's identity to various other parties. Then when one of those other parties uses the IC to authenticate with a service, that service will receive the EEC's identity via the IC, and can apply any ACs that bind that identity to attributes in order to determine authorization rights. There would appear to be great synergies between the use of Impersonation 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 Impersonation Certificates as described in the previous sections. Such Attribute Certificates are Tuecke, Engert, Thompson Expires July 2001 16 Internet Draft X.509 Impersonation February 2001 generally used for delegation of rights from one end entity to others, which clearly overlaps with the stated purpose of Impersonation Certificates, namely single sign-on and delegation. 5.2. Delegation Using Attribute Certificates In the motivating example above, ICs are used to delegate Steve's identity to the various other jobs and agents 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 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 IC based solution: * All protocols, authentication code, and identity based authorization services must be modified to understand ACs. With the IC solution, protocols (e.g. TLS) likely need no modification, authentication code needs minimal modification (e.g. to perform IC aware path validation), and identity based authorization services need no modification. * 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). 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 IC solution allows for much more flexibility, since parties can further delegate an IC 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 an IC based solution to delegation. The choice of which approach should be taken in a given instance may depend on factors such as the software that it needs to be integrated into, the type of delegation required, and religion. 5.3. Propagation of Authorization Information One possible use of Impersonation Certificates is to carry authorization information associated with a particular identity. Tuecke, Engert, Thompson Expires July 2001 17 Internet Draft X.509 Impersonation February 2001 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" states: "Authorization information may be placed in a PKC extension or placed in a separate attribute certificate (AC). The placement of authorization information in PKCs is usually undesirable for two reasons. First, authorization information often does not have the same lifetime as the binding of the identity and the public key. When authorization information is placed in a PKC extension, the general result is the shortening of the PKC useful lifetime. Second, the PKC issuer is not usually authoritative for the authorization information. This results in additional steps for the PKC issuer to obtain authorization information from the authoritative source. For these reasons, it is often better to separate authorization information from the PKC. Yet, authorization information also needs to be bound to an identity. An AC provides this binding; it is simply a digitally signed (or certified) identity and set of attributes." ([4], Section 1) Placing authorization information in an IC mitigates the first undesirable property cited above. Since an IC has a lifetime that is mostly independent of (always shorter than) its signing EEC, an IC becomes a viable approach for carrying authorization information. The second undesirable property cited above is true. When 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 an IC. 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 ICs that are generated by the EEC seems a reasonable approach to disseminating such information. 5.4. Impersonation Certificate as Attribute Certificate Holder In a system that employs both ICs and ACs, one can imagine the utility of allowing an IC 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, Attribute Certificates place the following restriction on the holder of the AC: Tuecke, Engert, Thompson Expires July 2001 18 Internet Draft X.509 Impersonation February 2001 "For all GeneralName fields in this profile the otherName (except as noted below), x400Address, ediPartyName and registeredID options MUST NOT be used. The use of Kerberos [KRB] principal names, encoded into the otherName, SHOULD however, be supported using the krb5PrincipalName OID and the KerberosName syntax as defined in [PKINIT]." ([4], Section 4.2) This implies that an Impersonation Certificate cannot be the holder of an Attribute Certificate, because ICs use an otherName of impersonationCertName. This restriction would need to be relaxed in order to allow for this use of ICs and ACs. 6. Commentary This section provides commentary on various design choices, open issues, related work, and future directions for Impersonation Certificates. 6.1. keyCertSign Bit in the Key Usage Basic Extension This Impersonation Certificate profile does not change the definition of the keyCertSign bit of the keyUsage extension. This definition states: "The keyCertSign bit is asserted when the subject public key is used for verifying a signature on certificates. This bit may only be asserted in CA certificates. If the keyCertSign bit is asserted, then the cA bit in the basic constraints extension (see 4.2.1.10) MUST also be asserted. If the keyCertSign bit is not asserted, then the cA bit in the basic constraints extension MUST NOT be asserted." [7] Likewise, the cA basic constraints definition asserts: "If the cA bit is asserted, then the keyCertSign bit in the key usage extension (see 4.2.1.3) MUST also be asserted." [7] In other words, the keyCertSign and cA fields are redundant, as currently defined. However, one could reasonably argue the case that in an Impersonation Certificate, the keyCertSign bit of the keyUsage basic extension should be asserted, but that the cA basic constraints field should be FALSE. Unfortunely, this would require the definitions for keyCertSign and cA to be changed in the X.509 Certificate and CRL Profile, which is likely a non-trivial endeavor. Therefore, we have chosen a more expedient route, which does not change these definitions. However, if it were decided that the best approach was to modify the keyCertSign definition, a suitable definition might be: The keyCertSign bit is asserted when the subject public key is used for verifying a signature on certificates. If the Tuecke, Engert, Thompson Expires July 2001 19 Internet Draft X.509 Impersonation February 2001 keyCertSign bit is asserted, and the cA bit in the basic constraints extension is true, then the iC bit in the impersonationCertInfo extension MUST be false, and the public key MUST only be used to verify the signature on end entity certificates (i.e. certificates on which both the cA bit and iC bit are false). If the keyCertSign bit is asserted, and the cA bit in the basic constraints extension is false, then the public key MUST only be used to verify the signature of Impersonation Certificates (i.e. certificates on which the cA bit is false, and the iC bit is true). 6.2. nonRepudiate Bit in the Key Usage Basic Extension One alternative for the nonRepudiate bit is that is MUST NOT be asserted. It seems, on the surface, and impersonation and non- repudiation are at odds with one another. However, this decision is postponed until further discussion with others who are more familiar with the use of this bit. 6.3. Subject Name of an Impersonation Certificate The subject name of an IC is only used for path validation. This IC profile uses a randomly generated subjectAltName to provide a (statistically) unique subject name for the IC. Another possibility for naming the IC is to use a subject field that is derived from the subject of the IA. In fact, this is the approach taken in the current Grid Security Infrastructure implementation. For example, the IC subject field could be the EEC subject field, extended with the addition of a new AttributeType and Value component of impersonationLevel:nnnn where impersonationLevel is a new AttributeType, and nnnn is the depth of the IC signing path. The issuer field would contain the subject field of the IA that signed the IC. In this scheme the path validation process would check that the subject and issuer names match up the chain and the impersonationLevel values increase by one at each subsequent delegation. One advantage of this approach is that some current implementations of path validation, such as OpenSSL-0.9.6, do not support the use of subjectAltName and issuerAltName. Thus for practical purposes it is arguably better to use the subject name and the impersonationLevel:nnnn scheme. A disadvantage of this approach is that it is reliant on the DN convention used by the subject field. This limits Impersonation Certificates such that they can only be used for EECs that use the subject field. If an EEC instead uses subjectAltName, with a null subject field, then this approach does not work. For this reason, this approach was rejected for this Impersonation Certificate profile. Tuecke, Engert, Thompson Expires July 2001 20 Internet Draft X.509 Impersonation February 2001 6.4. Carrying Along the End Entity Subject Another suggestion was to include the subject of the signing EEC as an informational field in the IC. This would allow an authorizing process to use only information in the final IC in the chain to determine identity, and not need to walk the chain in order to find out the subject (or subjectAltName) of the EEC that the IC is derived from. This approach was rejected for the following reasons: * It would be easy to spoof this informational field. For example, an IC with an informational subject of "Steve" could be used to create an IC with an informational subject set to "Doug". This leaves us with two alternatives: * We can augment the path validation to check that this informational field of the IC is the same as in the signing IC or EEC. But this is not desirable, as it complicates the path validation. * But if we do not valide this field, we cannot trust the contents of this informational field. But then there is no point in including this informational field. * Upon closer examination, there is a lot of information in the certificate chain that may be needed during authorization, such as the number of levels of delegation, the CA (or multiple levels of CAs) who signed the original EEC, the constraints and keyUsage values of the signing EEC, possibly Certificate Policies associated with CAs or IAs. All of these require essentially the same amount of work as retrieving the subject of the EEC that signed the IC, so why threat the EEC subject specially by including it in an information field. In the end, just including the EEC subject name does not seem to be sufficiently useful to justify the addition of another field and the work of verifying that name during the path validation. Therefore, to determine the identity of an IC for authorization purposes, the subject of the EEC must be retrieved directly from the EEC in the signing chain. This approach also has the beneficial side effect of further stressing that an Impersonation Certificate has no identity of its own, but rather inherits it from its signing EEC. 6.5. Delegation Tracing A more complex scheme for understanding and then judging the delegation level is "delegation tracing", in which each entity (e.g. server) that requests an IC includes its own certificate chain in the new IC. Thus the entity relying on the final IC can see what servers/sites have been involved in the delegation process and use this information in its decision to trust the IC. Tuecke, Engert, Thompson Expires July 2001 21 Internet Draft X.509 Impersonation February 2001 It has been observed that some sites are not willing to trust ICs that have passed through other specified sites. Delegation tracing would enable those sites to accept or reject an IC. A separate draft is being developed with defines X.509 extensions to Impersonation Certificates to hold this delegation tracing information. Depending upon further input from the community, delegation tracing may be rolled into a future version of this draft, or will remain separate. 6.6. Restricted Impersonation Certificate Another future goal of delegation using ICs is to allow the EEC to limit the use of an IC for specific authorization purposes. Since most delegated certificates are intended to allow a server or agent to perform certain actions on behalf of the EEC, it makes sense to limit the use of the IC for those purposes. One suggestion for doing this is to define a restrictedRights extension that would only be allowed in an IC. (Or this could be part of the Impersonation Certificate Information extension.) It could include a resource name and access rights that would be recognized by the relying entity (e.g. the application that grants access to the resource), but could be opaque to the authentication protocol. One could also embed an Attribute Certificate in the IC, which would grant rights to the holder and be signed by the EEC which had those rights. In either case the only rights that would be granted to the holder of the IC would be the explicitly granted rights in the restirctedRights extension, or whatever rights the holder of a particular attribute certificate is granted. 6.7. Certificate Policies Extension One could imagine some interesting things to do with the Certificate Policies extension. For example: * One could define policies for creation of an Impersonation Certificate. For example, was the IC created locally or remotely? * An alternate approach to defining restricted Impersonation Certificates would be use the Certificate Policies extension to carry the OIDs of various Impersonation Certificate Policies. For example, an Impersonation Certificate policy might state that an the IC can only be used within a limited scope of machines, or for a limited set of uses. 6.8. Kerberos 5 Tickets The Kerberos Network Authentication Protocol (RFC 1510 [9]) is a widely used authentication system based on conventional (shared secret key) cryptography. It provides support for single sign-on Tuecke, Engert, Thompson Expires July 2001 22 Internet Draft X.509 Impersonation February 2001 via creation of "Ticket Granting Tickets" or "TGT", and support for delegation of impersonation rights via "forwardable tickets". Kerberos 5 tickets have informed many of the ideas surrounding X.509 Impersonation Certificates. For example, the local creation of a short-lived IC can be used to provide single sign-on in an X.509 PKI based system, just as creation of short-lived TGT allows for single sign-on in a Kerberos based system. And just as a TGT can be forwarded (i.e. delegated) to another entity to allow for impersonation in a Kerberos based system, so can an IC can be delegated to allow for impersonation in an X.509 PKI based system. A major difference between a Kerberos TGT and an X.509 IC is that while creation and delegation of a TGT requires the involvement of a third party (the Kerberos Domain Controller), an IC can be unilaterally created without the active involvement of a third party. That is, a user can directly create an IC from an EEC for single sign-on capability, without requiring communication with a third party. And an entity with an IC can delegate the IC to another entity (i.e. by creating a new IC, 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 an IC. 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 Impersonation Certificates protects a user's IC private key using this same approach. Looking at developments with Kerberos 5 tickets also can inform us about potential future directions for Impersonation Certificates. For example: * Kerberos tickets have two simple mechanisms for allowing their use to be restricted: a time period during which the ticket is valid (the "starttime" and "endtime" fields of a ticket), and a host address which restricts the host on which the ticket may be used (the "caddr" field of a ticket). An X.509 IC also has a validity period, but does not have a host restriction field, though it could be easily added via an X.509 extension. While these particular restrictions have a variety of limitations and problems, they points toward a future of more general restriction policies that might be included in an IC and/or Kerberos 5 ticket. * The Microsoft implementation of Kerberos 5 has (not without controversy) used the "authorization-data" field in the Kerberos ticket to encode authorization information into the ticket. A similar approach could be taken with X.509 Impersonation Certificates, by encoding the authorization information into an X.509 extension in an IC. This approach allows for a user's normal, long-lived identity certificate to be used to create a short-lived authorization certificate that can be delegated as Tuecke, Engert, Thompson Expires July 2001 23 Internet Draft X.509 Impersonation February 2001 necessary. Merits of this approach versus Attribute Certificates are discussed in Section 5. 7. Security Considerations An Impersonation Certificate is generally less secure than the EEC that issued it. This is due to the fact that the private key of an IC is generally not protected as rigorously as that of the EEC. For example, the private key of an IC is often protected using only file system security, in order to allow that IC to be used for single sign-on purposes. This makes the IC more susceptible to compromise. However, the risk of a compromised IC is only the misuse of a single user's privileges. Due to the path validation checks made on an IC, an IC cannot be used to sign an EEC or IC for another user. Further, a compromised IC can only be misused for the lifetime of the IC. Therefore, one common way to limit the misuse of a compromised IC is to limit their validity periods to no longer than is needed. In addition, if an IC is compromised, it does NOT compromise the EEC that created the IC. 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 Impersonation 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 ICs for user authentication limits the exposure of the EEC private key to only the creation of the first level IC. The iCPathLenConstraint field of the impersonationCertInfo extension can be used by an EEC to limit subsequent delegation of the IC. A service may choose to only authorize a request if a valid IC 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 IC cannot be delegated to it. By limiting the iCPathLenConstraint, an EEC can ensure that a compromised IC of one job cannot be used to start additional jobs elsewhere. An EEC or IC can limit what a new IC can be used for by turning off bits in the Key Usage and Extended Key Usage extensions. However, once a key usage or extended key usage has been removed, the path validation algorithm ensures that it cannot added back in a subsequent IC. In other words, key usage can only be decreased in IC chains. The EEC could use the CRL Distribution Points extension and/or OCSP to take on the responsibility of revoking ICs that it had issued, if it felt that they were being misused. The relying party that is going to authorize some actions on the basis of an IC will be aware that it has been presented with an IC, and can determine the depth of the delegation and the time that the Tuecke, Engert, Thompson Expires July 2001 24 Internet Draft X.509 Impersonation February 2001 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 an IC at all, or maybe only a single level of delegation. Future extensions being considered address the issues of the relying party wanting to know what hands the delegation has passed through (using delegation tracing as discussed above), and the issuer wanting to restrict the IC to only limited actions (using restricted ICs as discussed above). 8. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. [2] Butler, R., D. Engert, I. Foster, C. Kesselman, and S. Tuecke, "A National-Scale Authentication Infrastructure," IEEE Computer, vol. 33, pp. 60-66, 2000. [3] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0," RFC 2246, January 1999. [4] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization," Internet Draft draft-ietf-pkix- ac509prof-06.txt, January 2001. [5] Foster, I., C. Kesselman, G. Tsudik, and S. Tuecke, "A Security Architecture for Computational Grids," presented at Proceedings of the 5th ACM Conference on Computer and Communications Security, 1998. [6] Foster, I., C. Kesselman, and S. Tuecke, "The Anatomy of the Grid: Enabling Scalable Virtual Organizations," International Journal of Supercomputer Applications, 2001. [7] Housley, R., W. Ford, W. Polk, and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile," Internet Draft draft-ietf-pkik-new-part1-04.txt (update to RFC 2459), January 1999. [8] Jackson, K., S. Tuecke, and D. Engert, "TLS Delegation Protocol," Internet Draft draft-ietf-tls-delegation-00.txt, 2001. [9] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)," RFC 1510, September 1993. 9. Acknowledgments We are grateful to numerous colleagues for discussions on the topics covered in this paper, in particular (in alphabetical order, with apologies to anybody we've missed): Joe Bester, Randy Butler, Carl Tuecke, Engert, Thompson Expires July 2001 25 Internet Draft X.509 Impersonation February 2001 Kesselman, Keith Jackson, Stephen Kent, Bill Johnston, Ian Foster, Marty Humphrey, Clifford Neuman, Gene Tsudik, Von Welch. 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. 10. Contact Information Steven Tuecke Distributed Systems Laboratory Mathematics and Computer Science Division Argonne National Laboratory Argonne, IL 60439 Phone: 630-252-8711 Email: tuecke@mcs.anl.gov Doug Engert Argonne National Laboratory Argonne, IL 60439 Email: deengert@anl.gov Mary Thompson Lawrence Berkeley National Laboratory Email: mrthompson@lbl.gov Tuecke, Engert, Thompson Expires July 2001 26