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:

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:

2. MyProxy operations

MyProxy [1] is an open source software system that addresses these problems in two main ways:

  1. 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.
  2. 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:

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]:

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

  1. http://grid.ncsa.uiuc.edu/myproxy/ - MyProxy

  2. http://webauth.stanford.edu/ - WebAuth

  3. http://shibboleth.internet2.edu/ - Shibboleth

  4. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security - SAML

  5. http://en.wikipedia.org/wiki/X.509 - X.509 Wikipedia entry

  6. http://www.ietf.org/rfc/rfc3820.txt - Proxy certificate profile.

  7. http://www.oerc.ox.ac.uk/activities/projects/index.xml.ID=ShibGrid - ShibGrid project page


-- GrahamKlyne 2006-06-26 09:30:29

Creative Commons License
The content of this wiki is licensed under the Creative Commons Attribution-ShareAlike 2.0 England & Wales Licence.

OSS Watch is funded by the Joint Information Systems Committee (JISC) and is situated within the Research Technologies Service (RTS) of the University of Oxford.