1

Grids and PKI Bridges

(Globus Toolkit)

EDUCAUSE/Dartmouth PKI SummitJuly 26, 2005

Shelley Henderson - USCJim Jokl - Virginia

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

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

HEBCASAFE

Commercial

Others

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

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

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

Campus and Inter-CampusTechnical 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

Campus and Inter-CampusTechnical 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

PKI Bridge Path Validation

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

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 GridCampus A

Grid

Campus F Grid

B’s PKI C’s PKI

Cross-cert pairsUser Certs

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

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

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

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

Work Continues with SURA Grid

Typical cross-certification issues from the SURAGrid bridge web 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

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 BShim

Site C

Shim

Site A

Shim

Site D

Site Admins

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

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

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/Jul_2004/tues_bridges/tues_pm_4_spencer.pdf

Federal bridge and bridge-to-bridge context

Questions - Discussion - References