GWD-I (Informational) J. Basney, NCSA Grid Security Infrastructure (GSI) Working Group October 2001 Revised February 2002 GSI Online Credential Retrieval - Requirements Status of this Memo This memo provides information for the Grid community. It does not define any standards or technical recommendations. Distribution is unlimited. Copyright Notice Copyright (C) Global Grid Forum (2002). All Rights Reserved. 1. Abstract An online credential retrieval (OCR) service gives users secure and convenient access to the credentials they need for authentication. To make credentials available, the service either stores the credentials in a secure repository or generates new credentials on request. This memo defines requirements for online credential retrieval services that provide secure access to X.509 credentials in the Grid Security Infrastructure (GSI). Table of Contents 1. Abstract........................................................1 2. Introduction....................................................2 3. Grid Security Infrastructure and Proxy Credentials..............2 4. Usage Scenarios.................................................3 4.1. Credential Initialization.....................................3 4.2. Transparent Credential Initialization.........................3 4.3. Credential Renewal by a Trusted Service.......................3 4.4. Adding Delegation to Existing Protocols.......................3 4.5. Multiple Credentials..........................................4 5. Requirements....................................................4 5.1. Protocol Requirements.........................................4 5.1.1. Credential Retrieval Protocol Requirements..................4 5.1.2. Credential Upload Protocol Requirements.....................5 5.1.3. Administrative Protocol Requirements........................6 5.2. Credential Server Requirements................................6 5.3. Credential Repository Requirements............................6 6. Related Work....................................................6 7. Security Considerations.........................................7 8. Acknowledgements................................................8 9. References......................................................8 10. Author Contact Information.....................................8 11. Full Copyright Notice..........................................8 12. Intellectual Property Statement................................9 jbasney@ncsa.uiuc.edu 1 GWD-I (Informational) February 2002 2. Introduction Requiring users to manage their credentials has a number of drawbacks. First, users may not be able or willing to effectively protect their private keys from compromise or loss. Second, users may access secure services from many devices, and distributing their private keys to each device can be inconvenient and potentially insecure. Third, users may need multiple credentials to access different secure services because of differing trust policies, further increasing the user's key management burden. A service that securely manages user's credentials can therefore potentially improve both security and usability. This memo describes usage scenarios and defines requirements for an online credential retrieval service for the Grid Security Infrastructure (GSI). We invite comments on the scenarios and requirements in this memo and suggestions for additional scenarios and requirements that should be considered. Please send comments and suggestions to the GSI working group of the Global Grid Forum by electronic mail to security-wg@gridforum.org. 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 [3]. 3. Grid Security Infrastructure and Proxy Credentials Authentication in the Grid Security Infrastructure (GSI) is based on proxy credentials. A proxy credential consists of a proxy certificate and an associated private key. The proxy certificate is an X.509 certificate that is derived from a standard X.509 end entity certificate or another proxy certificate and signed by the private key associated with the source certificate. Proxy credentials serve to limit the vulnerability of the end entity private key while supporting GSI requirements for single sign-on and credential delegation. Rather than entering a pass phrase to decrypt the private key on every authentication operation, or stashing the pass phrase or unencrypted key on the local system for repeated use, the user can use the private key once to create a proxy credential. The proxy certificate contains restrictions, such as a short lifetime, that limits the vulnerability if the proxy key should be compromised. The proxy key can then be stashed unencrypted for the duration of the user's session. Proxy credentials can also be used to delegate credentials to processes acting on the end entity's behalf without transferring the end entity's private key to the process. Instead, the process generates its own proxy certificate and key and asks the delegating entity to sign the certificate, thereby allowing credentials to be forwarded over the network without transferring private keys. The delegating entity will typically place restrictions in the proxy certificate to limit the vulnerability of the delegated credential. jbasney@ncsa.uiuc.edu 2 GWD-I (Informational) February 2002 4. Usage Scenarios A GSI online credential retrieval (OCR) service MAY support one or more of the following usage scenarios. 4.1. Credential Initialization A user logs in to a computer where his or her credentials are not directly accessible. The user runs an OCR client program, specifying the location of an OCR service. The program connects to the OCR service, verifies the identity of the service, and establishes a secure channel to the service. The user enters a username and pass phrase, which the program sends to the OCR service to authenticate the user. If the authentication succeeds, the OCR service delegates a proxy credential to the client program, and the client program stores the proxy credential on the local system, where the user can use it for subsequent authentication operations. This description assumes the OCR client program has been previously installed on the system and the client has the ability to verify the identity of the OCR service (i.e., trusts the Certificate Authority that issued the OCR service credential). 4.2. Transparent Credential Initialization This scenario is similar to the previous one, except instead of using a pass phrase, the OCR client authenticates to the OCR service with the user's local security context, such as a Kerberos ticket. The user or administrator can modify the login script for the user's local account to run the OCR client program to transparently retrieve a proxy credential on each login. 4.3. Credential Renewal by a Trusted Service A user submits a batch job to a trusted scheduler and delegates a credential to the scheduler to be used by the job. If the credential nears expiration while the job has not yet completed, the scheduler authenticates to the OCR service with its service credential, proves possession of the user credential, and retrieves a new credential for the job with an extended lifetime. 4.4. Adding Delegation to Existing Protocols In this scenario, a user accesses a Grid service using a client program that does not support credential delegation, for example, using a web browser to access a Grid Portal. The user connects to the portal, and the portal prompts the user for his or her credential information. The user enters the username and pass phrase under which the user's credential can be retrieved from an OCR service. The portal software runs an OCR client program, using the user's username and pass phrase to obtain credentials for the user, thereby allowing the portal to access Grid resources on the user's behalf. jbasney@ncsa.uiuc.edu 3 GWD-I (Informational) February 2002 4.5. Multiple Credentials A user has different credentials for authenticating to Grid resources in different administrative domains. To access a Grid resource, the user's client program queries the resource for the types of credentials it is willing to accept. The client then queries the OCR service to find a credential for the user that meets the Grid resource's requirements and retrieves the credential if one is found. 5. Requirements This section lists requirements for protocols, servers, and credential repositories that provide credential retrieval services. 5.1. Protocol Requirements The online credential retrieval service MUST support a standard protocol for retrieving credentials. Additional protocols MAY be supported to allow users and administrators to add, remove, and modify the credentials that may be retrieved from the service. A credential upload protocol allows authorized clients to insert credentials into a repository for later retrieval or remove existing credentials from a repository. Administrative protocols allow authorized clients to modify the authorization requirements for retrieving a credential and other policy restrictions on the credentials. Each protocol SHOULD share message formats and authentication mechanisms where possible. 5.1.1. Credential Retrieval Protocol Requirements The protocol MUST support delegation of X.509 proxy credentials from the server to the client. Retrieval of other types of credentials, including X.509 end entity credentials, is not considered at this time and is not required for the usage scenarios described above. The protocol MUST authenticate the client to the server and MUST allow support of different client authentication mechanisms. Support for username/passphrase and X.509 authentication is REQUIRED. Additional authentication mechanisms, such as Kerberos, MAY be supported. The protocol MUST ensure the integrity of the client's authenticated credential retrieval request (i.e., using a message integrity check). If the retrieval protocol requires the client to transfer a secret, such as a pass phrase, to the server, the protocol MUST authenticate the server to the client before transferring the secret and the secret MUST be encrypted in transit. jbasney@ncsa.uiuc.edu 4 GWD-I (Informational) February 2002 The client MUST verify that the retrieved credentials contain the expected attributes. The protocol SHOULD support replication of the retrieval service, and the protocol definition SHOULD include a method for locating a credential retrieval server that can provide the credentials requested by the client. The credential service may be partially replicated, so a given credential may be available from some but not all servers. A credential tag and server/domain name may be required for retrieval requests. The protocol SHOULD allow the client to choose the attributes of the credential to be retrieved (according to what the server will allow). For example, the client may be authorized to obtain credentials signed by different certificate authorities, possibly with different subjects, or the client may request that the server delegate a credential with specified restrictions. Some mechanism for querying the set of available credentials would be needed to support this functionality. 5.1.2. Credential Upload Protocol Requirements Note: This protocol would apply only to credential retrieval systems that use a credential repository. The set of credentials available from online certificate authorities, which generate credentials on demand, would be controlled by an administrative protocol rather than an upload protocol. The protocol MUST support delegation of X.509 proxy credentials from the client to the server. The protocol MUST allow authenticated clients to remove previously delegated credentials from the repository. The protocol MUST allow the client to associate one or more authentication requirements with an uploaded credential. The client can choose the username/passphrase pair(s) or X.509 identities that are authorized to retrieve the credential. The protocol MUST allow the client to specify lifetime restrictions for retrieved credentials that are shorter than the lifetime of the uploaded credential. This allows the client to upload a long-lived credential to the repository while minimizing the vulnerability of credentials retrieved from the repository. The protocol MUST authenticate the server to the client to prevent uploading credentials to an untrusted server. The protocol SHOULD authenticate the client to the server and verify that the client is authorized to upload credentials. Client authentication may not be needed for "public utility" servers willing to store credentials for any Grid users. jbasney@ncsa.uiuc.edu 5 GWD-I (Informational) February 2002 The protocol MAY allow the client to associate additional restrictions with the credential to be enforced by the server beyond any policy restrictions encoded in the credential itself. 5.1.3. Administrative Protocol Requirements The protocol SHOULD allow authorized clients to associate new authentication requirements for retrieval of credentials. For example, clients can associate a new username/passphrase with a credential. 5.2. Credential Server Requirements The server MUST restrict authenticated clients to retrieve only those credentials for which they are authorized. The server SHOULD allow multiple (identity, authentication mechanism) pairs to be authorized to retrieve credentials, on a per-credential basis. The server MUST enforce limits on the maximum lifetime of delegated credentials, both on a per-credential basis and for all credentials managed by the server. The server SHOULD securely log all protocol transactions for auditing purposes. The server MAY support online notification of protocol transactions to authorized parties, including notification of requests that must be authorized before they proceed. 5.3. Credential Repository Requirements Private keys stored in the repository SHOULD be encrypted and the information required to decrypt the keys SHOULD NOT be stored in the repository. In this case, the client must include the information required to decrypt the key in the credential retrieval request, so the server can decrypt the key and use it to perform delegation. However, the server should discard the decrypted key and the information used to decrypt it immediately after performing the delegation. This may not be possible for all authentication mechanisms. For passphrase-based authentication, the private keys can be encrypted with the pass phrase. The credential repository SHOULD be replicable. 6. Related Work Protocols for secure credential retrieval are under development in the IETF Securely Available Credentials (SACRED) working group. The working group has produced a requirements document [2] and draft framework and protocol documents. Many of the SACRED requirements are equivalent to requirements listed in this memo. However, the SACRED requirements state that the credential format MUST be opaque to the protocol and the protocol MUST NOT force credentials to be present in cleartext at the server. These requirements disallow jbasney@ncsa.uiuc.edu 6 GWD-I (Informational) February 2002 X.509 proxy delegation as specified in this memo. The author(s) of this memo will work with the SACRED working group to address this issue. The development of standards for online credential retrieval in GSI SHOULD include input from the SACRED working group and SHOULD be compatible when possible with SACRED requirements and standards. The IETF Public-Key Infrastructure (X.509) (PKIX) online credential management protocols [1] define standards for interacting with online Certificate Authorities and certificate repositories. Any OCR protocols developed for GSI should be designed to be compatible with the PKIX protocols and framework. 7. Security Considerations Centralized credential management raises significant security concerns. The central server is an attractive target for attack because of the large number of credentials that may be compromised. The compromise of a certificate repository could potentially compromise all credentials stored there. Encrypting the credentials as recommended above can limit the vulnerability by requiring an additional offline attack to decrypt the credentials. However, a compromised server could instead wait for clients to retrieve their credentials to learn the encryption keys. The compromise of a server that generates credentials on demand by signing them with a certificate authority key (i.e., an online certificate authority) would allow an attacker to generate and use credentials for any principal in the security domain until the certificate authority key is revoked. It is important to place these risks in context. Kerberos Key Distribution Centers implement a form of centralized credential management, so community experience with Kerberos security can suggest best practices for securing other types of centralized credential servers. A professionally administered, dedicated credential server should provide a higher level of security than current practice, where end users store their private keys on less secure end systems, including network file systems where eavesdropping on unencrypted traffic is possible. A credential retrieval service deployed by an organization must be acceptable under the relevant certificate authority policy documents [4]. The management practices for deployed credential retrieval systems should be documented and audited. Keys used by the credential retrieval service and credentials retrieved from the service are not suitable for generating non- reputable digital signatures because the credential retrieval service has access to the keys. However, the suitability of end entity credentials for generating non-reputable signatures is not affected by delegating proxy credentials to a credential retrieval service. The credential retrieval service is not intended to manage keys for digital signatures and is not a key escrow system. jbasney@ncsa.uiuc.edu 7 GWD-I (Informational) February 2002 Credential renewal bypasses the lifetime restriction in the proxy credential and therefore must be implemented with care. An attacker could potentially use a poorly designed OCR service to renew a compromised proxy credential indefinitely. Several techniques can reduce this vulnerability. Allowing only trusted services to renew credentials requires that the attacker also compromise the trusted service's credential. The OCR service can limit the total renewable lifetime of a given credential (as is done with Kerberos renewable tickets). Finally, once a compromise is detected, the OCR service can be configured to stop renewing any compromised credentials. The OCR service's audit logs should provide information about each renewal attempt. 8. Acknowledgements Discussions with Randy Butler, Laura Pearlman, Steve Tuecke, and Von Welch led to the initial version of this memo. 9. References [1] Adams, C. and S. Ferrell, "Internet X.509 Public Key Infrastructure Certificate Management Protocols," RFC 2510, March 1999. [2] Arsenault, A. and S. Ferrell, "Securely Available Credentials - Requirements," RFC 3157 (Informational), August 2001. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. [4] Chokhani, S. and W. Ford, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework," RFC 2527 (Informational), March 1999. 10. Author Contact Information Jim Basney National Center for Supercomputing Applications University of Illinois at Urbana-Champaign 605 E. Springfield Ave. Champaign, IL 61820-5518 Phone: 217-244-1954 Email: jbasney@ncsa.uiuc.edu 11. Full Copyright Notice Copyright (C) Global Grid Forum (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph jbasney@ncsa.uiuc.edu 8 GWD-I (Informational) February 2002 are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the GGF or other organizations, except as needed for the purpose of developing Grid Recommendations in which case the procedures for copyrights defined in the GGF Document process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the GGF or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE GLOBAL GRID FORUM DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 12. Intellectual Property Statement The GGF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the GGF Secretariat. The GGF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this recommendation. Please address the information to the GGF Executive Director. jbasney@ncsa.uiuc.edu 9