1. 1 Grids and PKI Bridges (Globus Toolkit) EDUCAUSE/Dartmouth PKI Summit July 26, 2005 Shelley Henderson - USC Jim Jokl - Virginia

2. 2 Project Background  NSF NMI Program SURA’s NMI Testbed project The Testbed focused on tools developed by both the EDIT and Grids teams  Initial phase focused on testing/evaluation of individual components  One obvious area for EDIT/Grids campus integration is PKI Globus toolkit uses PKI internally Question: can existing campus PKIs be used with Globus?  Most testbed sites were installing Globus toolkit natively and using the simple CA that is packaged with the toolkit  Using campus CA infrastructure would enable researchers to leverage existing campus services instead of running their own CAs  Using central campus authentication, what is a good approach for inter-institutional grids? How to support the Testbed Grid  Developed in the final year of the Testbed’s funding CREN CA was no longer issuing institutional certificates Work on the USHER CA in its formative stages The EDUCAUSE HEBCA-BID was working to bring HEBCA into existence Question: can we make the Globus toolkit function in a bridged PKI environment?

3. 3 Goal: Grids & PKI Bridges  Bridged PKI is a natural fit for Grids Many Grids consist of research groups from diverse organizations PKI bridge environments already working to link the various sector bridges to enable a larger trust fabric FBCA HEBCA SAFE Commercial Others

4. 4 Background: Globus Toolkit & PKI  The Globus toolkit uses PKI for authentication of users and resources  A proxy certificate is used internally grid-proxy-init uses your personal certificate to sign a short-lived proxy certificate that the toolkit generates The proxy certificate is used for authentication within the grid Server certificates are signed by the site’s main CA  Unix Identity Mapping A file maps the certificate Subject to a Unix login name Authorization is either external or happens simply via the presence of a Unix account and Grid map file entry

5. 5 NMI Testbed Globus Project Goals  Support the use of native campus CAs in Globus so that users can do all of their work using one set of credentials  Create some tools and documentation to make this easier with Globus  Scope intercampus Grid trust issues preparing to leverage other Higher Education PKI efforts Higher Education Bridge CA (HEBCA) US Higher Education Root CA (USHER)

6. 6 Campus Integration Technical Issues  The Globus/Campus CA integration piece was relatively easy to deal with End user certificate profile  Standard campus certificate profiles (e.g. PKI-Lite) work well with Globus  Normal server certificate profiles work well with Globus Proxy certificate  Globus builds its own internal proxy certificates and these do not pose any special problems Campus CA integration is complicated by the Globus interface  Campus CAs and OS-exported certificates are generally in PKCS-12 format  Globus expects raw PEM files for the certificate and the private key

7. 7 Campus and Inter-Campus Technical Issues  Some parts are harder The grid-mapfile file maps certificates to UNIX login names  Full certificate Subject DN maps to UNIX ID  Users with multiple certificates often need multiple entries  File must be maintained on each grid resource  How does this scale in a large Grid? Globus needs a signing_policy file for each certificate in a validation path  Tells what the certificate/key is allowed to do  Directory of files must be maintained on each grid resource – how does this scale in a large Grid?

8. 8 Campus and Inter-Campus Technical Issues  And some other parts are harder still Globus PKI is based on OpenSSL OpenSSL is a good PKI toolkit but it is know that its path validation logic is not bridge aware  Does not compute all possible validation paths and choose the best one  Does not include any mechanism to discover needed certificates in a directory (e.g., based on the AIA field) Our goal  Make it work anyway by preloading all of the certificates needed on each grid resource  Use this proof of concept to hopefully convince the Globus developers to switch to bridge aware path validation libraries

9. 9 PKI Bridge Path Validation

10. 10 Initial Test: Globus and Bridges  Results from initial testing using Windows XP Bridge test environment Loaded all needed cross certificates into the /etc/grid-security/certificates directory  Recall that no directory-based certificate discovery is available Also loaded certificates for all intermediate CAs in a the hierarchies Generated some simple scripts to build and install signing_policy files  Globus did appear to work via bridge-based cross-certificates

11. 11 Original Schematic of Grid Testbed PKI Integration Goal Campus E Grid A’s PKI Testbed Bridge CA Testbed CA Campus B Grid Campus C Grid Campus D Grid Campus A Grid Campus F Grid B’s PKI C’s PKI Cross-cert pairs User Certs

12. 12 Inter-campus Testbed Globus Project Activity  Built Testbed Bridge CA Off-line system Stored securely when not is use  Cross-certifications UVA UAB TACC LSU USC

13. 13 Testbed Grid Bridge Built a “production” test bridge for testbed Grid  Dedicated laptop running Linux  Laptop has never been on-line  Is only turned on during a cross-certification  Uses OpenSSL & simple scripts for the bridge CA “software”  Assumed that there were no Certification Policy issues  No Policy examination or mapping process  Everyone in the testbed had the same goals  Technical process only  Updated various scripts (e.g. CA, policy files, etc) Initial results  Bridge path validation in Globus works for user certificates  Server certificate validation not working via the bridge  User’s globusrun can’t validate the Globus gatekeeper’s certificate  Cross-certificates are fine  Windows XP could validate in both directions without problems

14. 14 Results from Initial Testing with Testbed Grid Bridge  Initial test environment did not test server certs from different CAs No reason to believe that the behavior would be asymmetric  OpenSSL uses some simple heuristics (e.g. backs off one level to ignore root certificates passed as part of a SSL handshake)  Digging some more made it look like cross-certifying at the lowest level in a hierarchy would solve problem  Re-cross-certified UVa at the UVASKP level as a test New cross certificates & UVASKP root This works well with OpenSSL & Globus  We need to re-run this whole test again sometime to verify the behavior I: CREN S: CREN I: CREN S: UVAPKP I: UVAPKP S: UVASKP I: UVASKP S: USER

15. 15 Conclusions at End of SURA NMI Testbed Project  Globus can be made to function via a PKI Bridge Preload cross-certificates Bridge aware path validation libraries within the Globus toolkit would be a big win  Some planned tools Credential converter web site that takes a PKCS-12 (as is available in most enterprise CAs) and returns the PEM files needed by Globus A tool to find and download cross-certificates  Based on Authority Information Access (AIA) fields in certificates like Windows XP (PKCS-7 objects) A tool to build Globus signing_policy files  Based on the certificates discovered via AIA

16. 16 Work Continues with SURA Grid  Typical cross-certification issues from the SURAGrid bridge web siteweb site Authority Key Identifier (AKI)  DirName Path and Serial Number issue Basic Constraints  Site has CA=false in cross-certificate that sites sign  An incompatible Path Length is set Missing Subject name components  Some name fields used by the Bridge CA are commented out in the default OpenSSL configuration file  Site Identification Process Relies partially on us knowing the responsible parties Technically uses SSL server certificates from commercial CAs and thus relies on their process

17. 17 SURAGrid: Original Plan  Sites provide dedicated systems Trust fabric via SURAGrid Bridge CA  Evolve to use HEBCA & USHER when ready LDAP server(s) hold  Cross-certificate pairs  Globus policy files  Unix UID information  Unix login names using a naming convention Shim Software  Builds grid_mapfile  Manages Unix accounts Site Administrators  Manage their own users enabling or disabling their access to SURAGrid Bridge CA LDAP Server Shim Site B Shim Site C Shim Site A Shim Site D Site Admins

18. 18 SURAGrid: Current Architecture  Some sites will dedicate systems, others will utilize shared resources The Bridge CA, LDAP servers, and Site Admin infrastructure remain the same Sites that dedicate resources will continue to use the Shim Sites providing pieces of shared infrastructure will leverage the data in the LDAP servers as needed  Some tools will be provided Investigating usage aggregation/management software Bridge CA LDAP Server Shim Site B Site C Shim Site A Site D Site Admins

19. 19 Current & Future Activity  Directory structure Hold cross-certificates in directory in PKCS-7 format? Would work with WinXP and AIA Hold cross-certificates as native certificate list on a per-site basis to simplify tools? Pre-built signing_policy files Designed to support Unix group and password maps  Complete the work on shim code  Anticipate that Java-based Globus Gatekeeper will use “bridge aware” path validation libraries  National infrastructure integration Work to transition to HEBCA at the appropriate time Work to leverage USHER when cross-certified with HEBCA SURAGrid could then focus on the directory service and applications over the longer run and not the trust fabric

20. 20 http://www1.sura.org/3000/SURAgrid.html  General information on the SURAGrid work https://www.pki.virginia.edu/nmi-bridge  Specific information on the Bridge CA portion of the work http://middleware.internet2.edu/hepki-tag  Links to other sites, CA software, etc http://www.opengroup.org/messaging/public/J ul_2004/tues_bridges/tues_pm_4_spencer.pdf http://www.opengroup.org/messaging/public/J ul_2004/tues_bridges/tues_pm_4_spencer.pdf  Federal bridge and bridge-to-bridge context Questions - Discussion - References