MyProxy Credential Server
This page contains notes about the open source MyProxy credential server [1].
This summary is based on discussions with Kang Tang and David Wallom of OERC, with further extensive contributions from David Spence (RAL).
Contents:
Contents
1. Certificates for grid services
The e-Science community uses X.509 certificates in the control of access to many of the grid services provided.
Using X.509 [5] certificates in a grid services environment present a couple of potential difficulties:
- Exercising services that use X.509 certificates for authentication and access control generally involves wielding the corresponding private key, which in turn is required by good practice to be kept private and password protected. But grid services depend extensively on software components that perform operations on behalf of a certified user, often when the user is not directly contactable. Using ordinary X.509 certificates in such an environment requires that the service runner be able to wield the certificates, and thus have access to the private key, contrary to all good practice concerning public/private key use.
Many users of grid services are authenticated by perfectly sound services that do not issue X.509 certificates. For example, Oxford University uses the Stanford WebAuth system [2], which is based on Kerberos. In the UK, there is a policy to roll out Shibboleth [3] as a federated authentication service for academic use, which uses SAML [4] rather than X.509 as the basis for passing authentication assertions.
2. MyProxy operations
MyProxy [1] is an open source software system that addresses these problems in two main ways:
- It allows a user to present their primiary e-Science certificate and create a new "temporary" key-pair and certificate that can handed off to the grid service infrastructure to access individual services for the duration of a task. Thus, the risk associated with handing a private key and associated certificate to the Grid infrastructure systems is minimized.
- It can act as CA certificate issuer, using non-X.509 credentials to verify a user, and issue a short-lived X.509 certificate based on those credentials. This certificate can then be used to gain access to grid services on behalf of the authenticated user.
The following broad kinds of operation are supported by MyProxy:
- proxy credential management: to create a new proxy predential, a new proxy certificate request is uploaded to the Myproxy server, together with a primary e-Science certificate, and a proxy certificate with a validation chain leading to the supplied e-Science CA is created. The default lifetime of this proxy certificate is 1 week, but this is fully configurable up the the lifetime of the supplied e-science certificate.
myproxy-logon/myproxy-get-delegation: based on recognized authentication (e.g. Shibboleth-provided), the MyProxy server issues a new proxy derived from available credentials (see below) whose default lifetime is 12 hours, but which is also configurable, which can be handed off to grid services to support requests for access to controlled resources. For download proxies the maximum lifetime is the minimum of: the uploaded proxy lifetime; the maximum downloaded proxy lifetime optionally set at upload time; and the server's maximum downloaded proxy lifetime limit.
In addition (if set up by user when uploading and allowed by the server configuration) a portal or resource broker acting on behalf of the user can renew the proxy it has downloaded repeatedly so in a sense it can use the user's credential right up to the expiry of the uploaded proxy. Thus, MyProxy issues short-lived certificates but if renewing is enabled then the uploaded proxy's lifetime (e.g. a week) is the actual limit on the length of any downloaded proxy.
3. MyProxy and ShibGrid Proxy certificates
The ShibGrid project [7] uses MyProxy to issue certificates for use ina ccessing grid resources. Despite its name, MyProxy may be used to issue real X.509 certificates.
The MyProxy web page at [1] describes MyProxy as an RFC3820 certificate issuer, and RFC3820 is specifically about proxy certificates signed by a non-CA (see sub-section below). But, as of version 3.0, MyProxy also has the ability to act as a "proper" CA. When presented with a valid Shibboleth credential, the ShibGrid project uses this functionality to issue user's proxies or auto-generated low-assurance certificates if they have no proxy. In ShibGrid deployment, the MyProxy CA is a fully qualified X.509 certification authority, and its certificates can be treated technically as any X.509 CA-issued certificate; but in a policy sense they are generally less trusted and accepted by fewer resources.
When myproxy-logon/myproxy-get-delegation is invoked, the myproxy-logon/myproxy-get-delegation client program creates a new public/private key pair and sends the public key in a certificate request to the MyProxy server. If there is a proxy credential stored on the server for the user then that proxy's private key (a different one from the user's certificate private key on the user's machine) is used to sign the resulting proxy certificate and this is returned. But if the user has no proxy credential stored on the server, the MyProxy server can be configured to instead use a CA key to sign the request, and the resulting certificate sent back is a real certificate and not a proxy.
The ShibGrid project's use of this functionality includes both uses: low-assurance certificate authority and RFC3820 proxy certificates. Supporting both types of certificate is important as not all resources will accept certificates from the low-assurance MyProxy CA. If the user has uploaded a proxy certificate to the MyProxy server then when they use ShibGrid they get a proxy certificate signed by that proxy; otherwise they get a X.509 end-entity certificate signed by MyProxy's internal low-assurance CA.
3.1. Proxy certificates
The following text is excerpted from RFC3820 [6]:
- A Proxy Certificate is an X.509 public key certificate with the following properties:
- It is signed by either an X.509 End Entity Certificate (EEC), or by another PC. This EEC or PC is referred to as the Proxy Issuer (PI).
- It can sign only another PC. It cannot sign an EEC.
- It has its own public and private key pair, distinct from any other EEC or PC.
- It has an identity derived from the identity of the EEC that signed the PC. When a PC is used for authentication, in may inherit rights of the EEC that signed the PC, subject to the restrictions that are placed on that PC by the EEC.
- Although its identity is derived from the EEC's identity, it is also unique. This allows this identity to be used for authorization as an independent identity from the identity of the issuing EEC, for example in conjunction with attribute assertions as defined in [i3].
- It contains a new X.509 extension to identify it as a PC and to place policies on the use of the PC. This new extension, along with other X.509 fields and extensions, are used to enable proper path validation and use of the PC.
If a proxy certificate is used, then the certificate path validation procedures that must be used is different from the standard X.509 path validation for normal CA certificates. It has been suggested that this introduces a new set of security concerns, if only because the overall path validation algorith, is complicated. Certificate users who understand only standard X.509 validation rules will be unable to path-validate proxy certificates.
4. References
http://grid.ncsa.uiuc.edu/myproxy/ - MyProxy
http://webauth.stanford.edu/ - WebAuth
http://shibboleth.internet2.edu/ - Shibboleth
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security - SAML
http://en.wikipedia.org/wiki/X.509 - X.509 Wikipedia entry
http://www.ietf.org/rfc/rfc3820.txt - Proxy certificate profile.
http://www.oerc.ox.ac.uk/activities/projects/index.xml.ID=ShibGrid - ShibGrid project page
-- GrahamKlyne 2006-06-26 09:30:29
