Certificate Authority Design

DRAFT FOR COMMENTS

The SEEK Certificate Authority needs to provide authentication credentials for a large number of users distributed across multiple institutions, and also be trusted and manageable. The Knowledge Network for Biocomplexity project has already established an LDAP-based authentication system for a group of over 5000 scientists. The current institutions participating in this system are the National Center for Ecological Analysis and Synthesis (NCEAS), the Long Term Ecological Research Network (LTER), the Partnership for Interdisciplinary Studies of Coastal Oceans (PISCO), the University of California Natural Reserve System (UCNRS), and the Organization of Biological Field Stations (OBFS). It is a distributed system based on referrals so that each organization manages its own set of users. Referrals are set up to institution-specific LDAP servers that are run by administrators that can be trusted to maintain the security of the LDAP tree. This LDAP system is password-based, but the SEEK EcoGrid needs to utilize X.509 certificates for GSI authentication. Thus, some modifications would be needed to use this system.

For the SEEK EcoGrid, we propose to leverage this extant LDAP system, utilizing both the Distinguished Name formats and the referral system. We will store user and host certificates in the LDAP tree for easy retrieval.

Distributed CA Servers

The Root LDAP server for the SEEK EcoGrid will have a DN:

o=~EcoGrid,ou=seek.ecoinformatics.org,cn=~EcoGrid CA

This CA will in turn sign certificates for a set of subordinate CAs that will actually manage the user accounts and the LDAP tree. These will include:

NCEAS: o=~EcoGrid,ou=nceas.ucsb.edu,cn=NCEAS CA
LTER: o=~EcoGrid,ou=lternet.edu,cn=LTER CA
PISCO: o=~EcoGrid,ou=piscoweb.org,cn=PISCO CA
UCNRS: o=~EcoGrid,ou=ucnrs.org,cn=UCNRS CA
OBFS: o=~EcoGrid,ou=obfs.org,cn=OBFS CA

DN Format

Distinguished names for each of the participating organizations will follow a prescribed format, namely:

NCEAS: uid=mjones,o=NCEAS,dc=nceas,dc=ucsb,dc=edu
LTER: uid=mjones,o=LTER,dc=lternet,dc=edu
PISCO: uid=mjones,o=PISCO,dc=piscoweb,dc=org
UCNRS: uid=mjones,o=UCNRS,o=ucnrs.org
OBFS: uid=mjones,o=OBFS,dc=obfs,dc=org

Other institutional formats will be added as needed. Our goal is that all of the DN formats will contain a uid attribute and an o (organization) attribute, which allows us to easily create referrals in the tree. The suffix portion of the DN can vary by organization, although we recommend using the domain component (dc) syntax as it is consistent and known to be unique.

Adding New CA servers

New institutions that wish to participate in the EcoGrid will need to provide both a trustworthy CA and a trustworthy LDAP installation. The new institution can then contact the **note: who do they contact?** in order to register their CA and have it be listed in the root EcoGrid node. We are also considering requiring each CA node to run a grid service registry node to distribute this functionality across a wider set of servers. More details on this to follow.

End-user tools

For a certificate-based system to be effective, we need to make it simple for users to request certificates and install both the public and private keys in appropriate locations. I think we shoul dbuild a simple web-based system for a user to generate a certificate request, send it to the correct CA, and retrieve the signed certificate from the CA. This means that there needs to be a mechanism for the CA to check the validity of the request: this probably can occur through a combination of email and phone contacts to the scientist. In larger organizations such as LTER, we may want to delegate even further down the tree to individual LTER sites so that the CA managers have personal knowledge of the end users.

One immediate issue surfaces: how do we manage private keys? Private keys need to be created on the client side for privacy reasons, but installed in many possible locations. For example, we expect many people to interact with the system using Kepler. Kepler needs a mechanism to generate key requests, and store and manage private keys. Even with this, users will still encounter problems trying to run Kepler on other desktops (where the key isn't present), or run other applications that use different key storage approaches. One potential solution to this is to use a centralized key management service such as MyProxy.

The problem with MyProxy and other centralized schemes is that there needs to be a password based mechanism for obtaining the certificate, and so the whole system is still based on a centralized authentication module, which certificates are designed to bypass. However, the certificate is still used to generate proxy certificates so that services can invoke new requests on behalf of the user, so some of the advantages of the GSI proxy certificate are maintained. For example, this will be especially relevant when running analyses through an environment like Kepler and a user invokes a computation through a grid service which in turn can invoke other grid services on behalf of the user by generating and sending another proxy certificate.

EcoGridCommunity

Go to top Edit this page More info... Attach file...

This page last changed on 03-Sep-2004 12:46:16 PDT by NCEAS.jones.