Public Key Technology Policy Requirements for Grid Identification.
October 11,2000
1. Abstract (Grid Identity Requirements for Interoperable PKIs)
Grid entities, (Users/Resources/Services), have a need to identify themselves to each other. For a user, their identity may serve to aid in authentication, authorization, auditing and accounting to a Grid resource. Establishment of the identity of a Grid resource is equally important. A user’s access of the grid is virtual; in fact they may never actually see or even know where exactly these resources are located. In this sort of environment authentication of the resource to the user, and of authentication of the user to the resource is a precursor to the two-way establishment of trust.
This paper attempts to document the requirements for a grid enabled PKIs. The intention is to develop community policy that allows grid resource managers to accept authentication certificates generated by and or for different Grid. Further it is a goal to reduce the number of authentication certificates a grid user has to posses in order to authenticate to multiple Grids. These certificates will be used for the authentication of users and resources in a Grid computing environment. The private key associated with a certificate might be used for signing, such things as software and non-legal documents.
This effort is related to efforts within the US Federal Bridge Certification Authority to bridge top-level federal agency PKI certificate policies.
2. Status of this Memo
This memo provides information for the Grid Forum community. This memo does not specify a Grid Forum standard of any kind. Distribution of this memo is unlimited.
3. Terminology
Relying Party – A person or agency who has received information that includes a certificate and a digital signature verifiable with reference to a public key listed in the certificate, and is in a position to rely on them. [FBCA]
Certification Authority (CA) – An authority trusted by one or more users to issue and manage X.509 Public Key Certficates and CARLS or CRLs. [FBCA]
Certificate Revocation List – A list maintained by a CA of the certificates which it has issued that are revoked prior to their stated expiration date. [FBCA]
Certification Authority Revocation List – A signed, time-stamped list of serial numbers of CA public key certificates, including cross-certificates that have been revoked. [FBCA]
Subscriber – an entity that (1) is the subject named or identified in a certificate issued to that entity, (2) holds a private key that corresponds to the public key listed in the certificate, and (3) does not itself issue certificates to another party. This includes, but is not limited to, and individual or network device. [FBCA]
Registration Authority – An entity that is responsible for identification and authentication of certificate subjects, but does not sign or issue certificates (i.e., a Registration Authority is delegated certain tasks on behalf of an authorized CA). [FBCA]
Certificate Policy – a specialized form of administrative policy tuned to electronic transactions performed during certificate management. A Certificate Policy addresses all aspects associated with the generation, production, distribution, accounting, compromise recovery and administration of digital certificates. Indirectly, a certificate policy can also govern the transactions conducted using a communications systems protected by a certificate based security system. By controlling critical certificate extensions, such policies and associated enforcement technology can support provision of the security services required by particular applications. [FBCA]
certificate – A digital representation of information which at least (1) identifies the certification authority issuing it, (2) names or identifies it’s Subscriber, (3) contains the Subscriber’s public key, (4) identifies it’s operational period, and (5) is digitally signed by the certification authority issuing it. [FBCA]
Computational Grid (Grid) - A dynamic collection of heterogeneous compute resources and devices spread across multiple administrative domains that are accessible through a set of well-defined Grid APIs. Users of the Grid harvest its advanced computing power, data, sensors, and people. This document describes the requirements for the creation and use of a digital Grid identification based on Public Key technology, for authentication and signature within a Computational Grid.
4. Grid PKI Policy Requirements
In this section we attempt to document policy requirements for interoperable Public Key Infrastructures by laying out issues and requirements for both the Relying Parties and Subscribers.
4.1. Relying Parties (RP) Requirements
An RP needs to:
· Entity Verification - Know how an entity’s identity is verified and tied to a public/private key pair. For some grids it will be fine to accept email from a user as proof they are who they say they are while other sites might require in-person verification and additional steps.
· Private Key Verification - Understand how a CA verifies a user’s possession of their private key. A user authenticates by using the private key mate to the public key, which is bound to their certificate, to correctly answer a challenge. ?????????/
· Certificate Profiles - Understand fields within a certificate (profiles) and what extensions are supported. The X.509 format defines standard field in the certificate and also describes a standard way to add extensions. Standard fields within the certificate however could be interpreted in various ways making them ambiguous. In addition some Grids may define extensions that have no meaning to any other Grid.
· Certificate AUP - Understand the Authorized Use Policy (AUP) for a certificate, or rather what functions a certificate can be used for. Certificates may be approved only for authentication to a specific set of resources. Some may be used only for signature and still others may be authorized for encryption use only. It is important from an RP’s perspective to understand what the CA authorized the certificate for since some capabilities may require more extensive controls.
· CP Accessibility - Know where a CP is published. At some point RPs and users may need to review the CP and it needs to be accessible especially since CPs are expected change over time.
· Liability - Understand liability issues, theirs, subscribers, CA’s, RA’s. If an RP accepts a certificate what is their liability, what risks are they taking? Same questions for a user that is using a certificate, what is their liability for accepting a certificate, protection of the private key, risks accepted, etc.?
· Obligations - Understand their obligations with respect to how they verify a CA’s signature. If they trust a CA then how do they make sure they are have the correct signature for the CA?
· Resource Certificates - Understand how they request and deploy resource certificates and keys. In the case of GSI there is a two-way authentication handshake between the resource and the user. The user is interested in making sure that the resource they requested is the one they accept.
· Revocations -An RP will need to understand its responsibilities with respect to revoked certificates. Just exactly how to they verify the status of a user’s or a CA’s certificate? An RP must understand what happens when a cert has been revoked. A certificate is revoke because of real or suspected compromise. RPs will not wish to allow the use of a certificate that has been compromised and will need to clearly understand the window of risk they have. In addition they need to know CRL and CARL update frequency so that they use only up-to-date information when checking certificate validity status. Also obviously they need to know how to access revocation lists.
· CA Compromise Plans - What are the CA’s procedures for compromise notification? What does this mean to the RP, do they need to kick everyone off the system, deny authentication request or what?
· Other Obligations - The RP needs to understand the obligations of the CA, RA, and subscribers such as, how a user protects their private key or how quickly must a subscriber notify the CA of a compromised private key.
· Distinguished Names - An RP must be able to trust that the Distinguished Name presented in the certificate is in-fact unique. The subscriber’s DN in the certificate is the tag or link to a user database. If that value is not unique then RPs will not have confidence in mapping to a local account and thus cannot accept the certificate for authentication.
· CA Security Controls - Know what are the physical and personnel access controls to the RA and CA. If the CA and RA functions are not well protected then it does not matter how many controls you have in vetting the identity of a certificate subscriber. Without CA controls, unauthorized personnel could generate valid looking certificates for which an RP has not way to distinguish from
· CA Archive Policy - Security incidents will need to be followed up on and in order to do this an RP will need to understand CA audit archival process. How long are certificates and audits of the RA/CA process archived and how are archives protected?
4.2. Subscribers Requirements:
· Key Management - Subscribers would generally like to manage the minimal number of certificate that provide them access to their Grid communities and resources. Thus they would like to use a NASA certificate to access an NSF sponsored Grid for example. Alternatively some subscribers will require multiple credentials, perhaps one for development, one for production, one for authentication, one for encryption or one for this grid and one for that. Thus there should be a straight forward way for a subscriber to manage their certificates.
· Portability of credentials among their workstations.
· Security Delegation - In the case of workbenches or portals users will need to delegate authority to a 3rd party to do work on their behalf. In these situations it is important to limit that delegated authority to only what is required.
· Grid users may link together resources from different Grids through applications, building their own virtual Grid.
· Acceptance Barriers - If our community of researchers and academics is to embrace this new technology the entry barriers must be low and the gain must be high. Therefore credentials need to be relatively easy to obtain and this may impact policy and procedures.
5. Other Topics
6. Advice to Grid PKI Developers
Developing and deploying a Public Key Infrastructure is not a simple task. PKIs are more than just the technology; in fact policy is the heart and soul of a successful PKI. The Grid needs to realize that the real power of a PKI can only be achieved by careful and deliberate community policy decisions. This document represents a list of Grid PKI policy requirements…………..
7. Acknowledgements
8. References
[FBCA] X.509 Certificate Policy for the Federal Bridge Certification Authority
[NCSA} National Computational Science Alliance Certificate Policy
http://world.std.com/~cme/usenix.html
9. Security Considerations
The focus of this document is entirely on security
10. Contact Information
Randy Butler –
John Volmer –