|
ACS Home Related Links:
Advanced Campus Services |
NMI Integration Testbed Program
On the Call: UABJohn-Paul Robinson UAHSandi Redman UARK (U. Arkansas )Amy Apon GRIDSJohn McGee GSUVictor Bolet, Art Vandenberg, SURAMary Fran Yafchak, Kate Barzee
Purpose of meeting - Cross certification for SURA NMI Testbed Grid
Summary of Discussion
I. Expanding Cross Certified sites - We discussed the expansion of cross-certification via the BridgeCA deployed by UVa. To date TACC, UAB, USC, and LSU have cross-certified. Jim Jokl, UVa, is open to additional site cross certification and details of the cross certification process can be found at https://www.pki.virginia.edu/nmi-bridge/ .
Preceding mentioned sites all operate an "enterprise CA" which has the advantage that sites control the root certificate and hence the Bridge cross certification is totally within a site's locus of control. Essentially, encouraging enterprise CAs (using, for instance, The Globus Alliance's Simple CA http://www.globus.org/security/simple-ca.html or OpenCA http://www.openca.org/ ) is a critical factor. Also, while enterprise CAs such as Simple CA or OpenCA are solutions, we certainly can consider commercial CAs being incorporated into the BridgeCA.
It would be helpful to survey SURA NMI Testbed Grid sites as to their enterprise CA status - especially as to why they are not deploying enterprise CAs. Mary Fran suggested introducing the survey idea to the SURA HPC-Initiatives planning group as an activity of the Infrastructure Working Group (Mary Fran and Art are group leaders). Idea would be to capture state of deployment as well as the state/rationales for "non-deployment" or "not-yet-deployment."
We also discussed how a Sector CA might be enabled with Shibboleth - leveraging Shibboleth capability of various sites. A Shibbolized Sector CA would provide certificates to sites that authenticated via their Shibboleth origin. Clearly, the concept and policy of federation of trust is important: a Shibbolize Sector CA presumes the participating sites have established policy rules providing assurance as to their authentication practices. However, Sector CA doesn't need to be Shibboleth-enabled and fundamental "trust" policy issues need to be addressed in any model. Other authentication models, of course, also serve to address vetting of person authentication (e.g. KX.509 solutions or the UAB WebISO model.)
A recent NMI Award has been made for GridShib ( http://grid.ncsa.uiuc.edu/GridShib/ ) with Principle Investigators Von Welch, NCSA, Tom Barton and Kate Keahey, University of Chicago , and Frank Siebenlist, Argonne National Laboratory. GridShib information exchange with the SURA NMI Testbed Grid could be of mutual interest.
ACTION ITEMS: a) Ask Tom Barton to brief the upcoming Testbed call on GridShib. Sandi will contact. b) Update Table of Resources relative to CA information. Art to circulate, all to update. c) Explore SURA-HPC Planning Group survey of enterprise CAs - Mary Fran d) "Sign up" for BridgeCA - contact Jim Jokl, UVa UAH (local implementation of Simple CA) - Sandi UArk (local implementation of Simple CA) - Amy GSU (would like to try with GeoTrust commercial certs) - Art/Victor
Note 1 : The Supercomputing 2004 conference ( http://www.sc-conference.org/sc2004/index.html ) included a poster session " Technical & Policy Solutions for an Inter-institutional Grid" ( http://www.sc-conference.org/sc2004/schedule/index.php?module=Default&action=ShowDetail&eventid=131 ) which described the BridgeCA solution from UVa and a demonstration by LSU's Center for Computation & Technology (CCT) that submitted a task to UVa cluster using the BridgeCA.
Note 2 : See Appendix A for "SURA Certificate Authority" - an expanded discussion of CA issues as outlined by a SURA "GRID Think" working group document.
II. Application Drivers - Forgoing discussion on expanding BridgeCA cross certification highlighted importance of continuing to develop a list of applications poised to benefit from "easy" Bridge CA cross-certification:
1. Georgia State Genome Alignment application - Currently running on UAB. Previous calls have discussed plans to expand to run at USC as well as other sites (TACC? USC? UVA?.). Recently Art, John McGee, and Jim Cotillier have discussed multi-site run - with BridgeCA as a key component. 2. UAB's Blast Application - John-Paul offered this as a candidate application. 3. LSU CCT's Task Farming? As demonstrated at SC04 (see Note 1 above). 4. Sandi will check with UAH application developers. 5. Others ("Your Application Here")
It was suggested that "Application Game Plans" might include: General description, anticipated requirements for system resources, anticipated requirements for human resources, software & versions required (or dependencies).
Discussion also ranged over specific resources. Which sites are willing to host a mini-cluster dedicated to the testbed grid? (UVa will.) Definition of "dedicated" probably needs some clarification - available for use if the home institution doesn't need it first? Only available for Testbed Grid applications? Important aspect of Testbed Grid policy.
Mary Fran related Jim Jokl's interest in another aspect of interoperation: automating the grid-mapfile on any systems across which applications run. This topic continues thread from November 18 meeting (and discussed on some previous calls). For operation and scaling of a large multi-institutional grid, from both policy and technical perspectives, we should try to automate the maintenance of the grid-mapfile (mapping certificate Subject DNs to local UNIX accounts). Though sites are cross-certified, each site has to manually enable each user from a remote site within this file. UVA wants to manage this from a central LDAP server. Participating sites would manage their "permitted Testbed Grid" users and cert subject DN mapping, with automation for mapping that identity to the grid. UVA will volunteer to run the LDAP severs, provide interface for sites, etc. Shawn McKee has spoken about working on the same problem if not a similar solution. UArk, GSU, UAB, interested in grid-mapfile solution.
ACTION ITEMS: a) Circulate Application Game Plans - Art, John-Paul, Sandi, Mary Fran b) Schedule Jim Jokl for "guest lecture" on grid-mapfile topic (co-scheduled with Tom Barton?) - Mary Fran
III. Policy Matters - Policy themes abound. The SURA NMI Testbed Grid brings policy to forefront on several levels: CA policy of Bridged sites; policy related to resource sharing (hardware, software, applications, personnel); membership and participation in the Testbed Grid, "rights and obligations" topics.
Discussion began several threads: Is it c orrect to think of the Testbed Grid Bridge CA as a "stand-in" for HEBCA Bridge until it's ready? Are there "default" policies (or assumptions where no policy) inherent to the operation of the Bridge CA? Should a BridgeCA policy document define: Who can "join"? Levels of trust & security? Sharing policy?
We agreed that a starting point might be to develop a strawman policy doc based on PKI-Lite recommendations. Or indeed just review the PKI-Lite ( http://middleware.internet2.edu/hepki-tag/ ) with the intent to brief the Testbed Grid and/or provide thumbnail on how to implement/adapt to Testbed Grid.
See August 26, 2004 minutes ( http://www.nc.gsu.edu/~wwwacs/GRID_Group/min26Aug2004.htm ) for earlier discussion and Action Item about Policy: ACTION ITEM (ALL): Policy Documentation. Collect any available policy statements from NMI Testbed Sites as reference resources. (see for instance: a) Grid 2003 User Registration And VO Management Policy listed at http://www.ivdgl.org/grid3/userinfo/ under "General Grid3 user registration Current User Registrati on document"; b) HPCC Allocation Policy for USC High Performance Computing and Communications, Research Computing Facility listed at http://www.usc.edu/hpcc/ ; c) UABGrid, About at http://lab.ac.uab.edu/uabgrid/title/About .)
Finally, we considered the development of white paper specifically addressing inter-institutional authN/authZ in Testbed Grid.
ACTION ITEMS: a) Review, brief PKI-Lite - Art/Victor b) AuthN/AuthZ White Paper - Future agenda item
Note 3 : Also see, again, Appendix A for "SURA Certificate Authority" - for additional info on CA policy, HEBCA, SURA Sector CA , levels of assurance.
REMINDERs:
See NMI Middleware Site http://www.nsf-middleware.org/testbed/testbed_status.asp#grid for information on: Testbed Status & Activities NMI Testbed Grid Project * Table of Testbed Grid resources (October 2004) * Grid Applications Catalog (GSU) * UVA paper on Experiences Using Bridge CAs for Grids * UVA How-To on Cross-certification * NMI Testbed Grid Handout , January 2004 [MS-PowerPoint 61K] * About the NMI Testbed Grid Project , October 2003 [MS-Word 35K]
See: http://www.nc.gsu.edu/~wwwacs/GRID_Group/NMI.html for minutes of previous meetings as posted. Minutes available as of Dec 5, 2004: February 26 March 25 April 29 May 27 June 24 August 5 August 26
NEXT CALL : Thursday December 16 , 2004 4:00-5:00pm ET APPENDIX A SURA "thinking group" on: SURA Certificate Authority January 26, 2004 - March 29, 2004
Group members:
Executive Summary - RecommendationsA working group was charged to recommend an approach for a SURA Certificate Authority (CA) that would support certificate needs of grid infrastructure (host, LDAP and identity certificates). The working group convened and discussed issues via for two conference calls and several email exchanges. The group consensus was that:
1) A SURA Sector CA was an appropriate activity warranting further effort 2) Bridge CA functions were adequately addressed via existing HEBCA initiative 3) Funding sources could most likely be sought via SURA member collaboration on research grants 4) Best practice is that campuses establish an enterprise CA 5) There may be value in providing an Enterprise CA Primer to guide SURA members CA deployments 6) A survey of member's CA states would seem an appropriate information gathering vehicle
1) Project Description: SURA Certificate Authority (CA) The SURA CA working group charge was to articulate the issues of a SURA CA and make a recommendation for the SURA Board Spring meeting April 5-6, 2004 . The working group was originated from discussions during the January 26, 2004 SURA Grid-Think meeting held at the Atlanta Airport , during which the importance of certificates to grid infrastructure was recognized as a core issue for SURA. Working group members volunteered and met via conference call on March 5, 2004 ; minutes of the meeting were circulated and a follow up meeting was held March 29, 2004 to finalize discussion and make a recommendation. This report is provides that recommendation and details of discussions.
Clarification of Scope Mary Fran Yafchak noted that the purpose of the SURA CA Working Group was not necessarily one of specific actions per se (what to implement and how to do it), as perhaps more of advisory recommendations to the SURA CIOs on the issues that the SURA Regional Grid-Think sought to address in the "SURA CA" topic.
Jim Jokl sought some grounding on the definition of a " SURA CA ." If the issue were just of SURA institutions cross certifying their local Certificate Authority (CA) by registering with a Bridge CA (and therefore being "cross-certified" with other CAs registered at the bridge), then the Educause Higher Education Bridge Certification Authority ( http://www.educause.edu/hebca/ ) would be a recommended solution:
The goal of the Higher Education Bridge Certification Authority (HEBCA) is to facilitate trusted electronic communications within and between institutions of higher education as well as with federal and state governments.
Clearly, SURA should not duplicate a solution that is available. Further, the HEBCA group is working with the Federal Bridge Certification Authority ( http://csrc.nist.gov/pki/fbca/ ) - potentially providing a cross certification method with federal and government agencies.
Jim observed that perhaps the " SURA CA " was more of a " SURA Sector CA " model. That is, for campuses that did not have a CA (for whatever reason), SURA might support a Shibbolized CA, providing certificates for that campus. The campus would use Shibboleth to authenticate so that a certificate could be issued. So the Shibboleth Origin at each campus would effectively provide a Registration Authority (RA) function - validating a person's authentication, much like a KX.509 solution leverages a local Kerberos authentication as a way to issue certificate on behalf of authenticated persons.
Puri Bangalore asked if such a solution would work for institutions using several CAs, noting that at UAB a number of departments have each put up their own CA (using, for instance, The Globus Alliance's Simple CA http://www.globus.org/security/simple-ca.html or OpenCA http://www.openca.org/ ). As a Shibbolized CA would issue CA roots specific to an institution, Jim said there really shouldn't be a problem in issuing individual CA roots for requesting campus units. In fact, a federated solution is the overall model, whether at the level of institutions or the departments within those institutions. (A campus seeking to establish an "Enterprise PKI" solution, could establish a CampusBridgeCA to cross-certify various departmental CAs under the CampusBridgeCA, which in turn then serves as the "enterprise CA.")
Additional Discussion Points Commercial CA - it was noted that cross certification at a bridge might be an issue for a commercial CA. On the one hand, if the commercial CA vendor provides institution specific certs and the institution has policy control, then cross certifying may be easy enough. On the other hand, if the commercial CA vendor is providing a "public CA" function, with the advantages of the CA root being in already available browsers, then cross certifying at a bridge may be unlikely (and moot.)
Levels of Assurance - Clearly, a Shibbolized CA could only provide "reasonable assurance" at the level of a PKI Lite ( http://middleware.internet2.edu/hepki-tag/#PKI_Lite ). As a testbed phase this would be sufficient. A "production" phase would surely require additional review and discussion as to implementation.
Why no local CA? - Maybe the question that ought to be asked is " Why are institutions not putting up a local CA? " Maybe the recommendation of the SURA CA Working Group should be to find out what the impediments are and what can be done to facilitate implementation of a campus CA. A list of applications that PKI Lite would support might be compiled (cf. Grids, S/MIME - Secure Multipurpose Internet Mail Extension, see for example http://csrc.nist.gov/pki/smime/ , wireless authentication, SSH). Perhaps a "CA How To" compiled. Jim noted that John Douglass, Georgia Tech, has developed an open source CA "Papyrus" ( http://papyrus.gatech.edu/ and http://www.cren.net/crenca/pilotrsrcs/newgatech.html ).
Leverage Interest of Commercial CA - Dr. Carl Stucke, Georgia State , has a relationship with GeoTrust Commercial CA (from his days at Equifax and work that led to GeoTrust CA ). Carl suggested that GeoTrust might have an intellectual, philosophical interest in the SURA CA. Certainly a commercial CA such has GeoTrust has an infrastructure of trust, and experience with such infrastructure, levels of assurance and auditability issues.
Outsource, insource issues - Jim observed that outsourcing a CA, but keeping RA functions internal (such as acquiring GeoTrust identity certs, but managing their issuance at the campus level) has one set of issues. Whereas insourcing both CA and RA (such as using a Simple CA or Open CA solution) is another set of issues. Commercial vendors probably find RA functions "harder to do."
Primer of sources - Puri suggested, "What we are doing is evaluating how to proceed." With departments and applications having their own CA, with Simple CA and Open CA, the question is how to integrate. Jim maintained that having one's own CA is the way to go. Art Vandenberg noted that we're continuing to refer to a federation model. bridging departments into an enterprise, bridging enterprises. perhaps we need a SURA CA Primer .
Cost - That may be an issue, certainly at least in the sense that a local campus CA would tend to be lower cost overall to providing enterprise certificates. But there may be other cost issues, maybe other than actual dollars, such as time, policy development, and politics.
2) How it might be funded
A SURA Sector CA (using Shibboleth) could seek funding from granting agencies such as NSF, NIH, DOE opportunities. It is noted that the current NMI Integration Testbed Program has an NMI Testbed GRID project in which the University of Virginia is the lead on deploying a Bridge CA for the NMI Testbed sites. Jim Jokl indicates that development and demonstration of a Shibbolized CA will be a following activity for Testbed site. Leveraging this activity seems a logical way to pursuing additional funds. David Shealy noted that successful funding would require appropriate lead time to identify goal, articulate actions, and prepare proposal.
3) How to determine who else will be involved
Clearly, the NMI Testbed GRID sites are an initial core of institutions with specific interest in grid certificates interoperation. However, as the core sites build a demonstration grid, additional member participation would be a positive and expected result (hopefully).
Institutions that already have an enterprise CA might be a source for a SURA CA Primer, contributing their experience as a "how to" for other institutions (SURA members of course, but not limited to SURA).
Institutions that do not have an enterprise CA but do have Shibboleth Origin deployments would provide a core for a Shibbolize CA. Sites with neither an enterprise CA nor Shibboleth, would have a choice of options, though from the discussion of the SURA CA Working Group, it seems that the first choice would be deployment of an enterprise CA.
Current NMI Integration Testbed Program members who are active NMI Testbed GRID sites are: Georgia State University, Texas Advanced Computing Center , University of Alabama at Birmingham , University of Alabama at Huntsville , University of Michigan , University of Southern California , and University of Michigan . Florida State University and the University of Florida are the other two sites of the NMI Integration Testbed Program. A survey of SURA members would seem called for in order to know which members have an enterprise Certificate Authority . Again, a survey would seem logical. |
Last Updated: March 2, 2006