December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Authentication, Authorization, & Identity Issues in Grids SURA Grid Workshop Austin, TX December 8, 2005 Jim Jokl University of Virginia

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Agenda Quick Refresher on PKI Globus & GSI MyProxy & Grid portal integration Overviews –Shibboleth and GridShib –Virtual Organizations (VO), VOMS, VOX, VOMRS Example: SURAgrid approach –Cross-certification and PKI Bridges –National PKI context –Directory integration (VO approach) Campus infrastructure integration

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Two Types of Cryptography Symmetric key cryptography –A pre-shared secret is used to encrypt the data –Some examples: DES, 3-DES, RC4, etc Public key cryptography –A pair of mathematically related keys are generated One of the keys, the Public Key, is freely distributed The other key, the Private Key, is kept confidential –Given one of the keys, it is computationally very hard to compute the other

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Public Key Cryptography –Data encrypted using the public key can only be decrypted by the person with the private key 1.Bob obtains a copy of Alice’s public key 2.Bob encrypts the data using the public key and sends it to Alice Example: Bob sends secret data to Alice 1.Alice receives the data 2.Alice decrypts the data using the private key that only she possesses

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Public Key Cryptography –Likewise, data encrypted with the private key can be decrypted by anyone having a copy of the public key Assuming that the private key is protected and held by an individual, this is the basis for a digital signature If I encrypt data using my Private Key, anyone with my published Public Key can decrypt it. Since they used my Public Key to decrypt the data everyone knows that only I (with my Private Key) could have encrypted the data. Plain Text Encrypted Text one key the other key

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Certification Authorities (CA) and Registration Authorities (RA) –Accept certificate requests from users (RA) –Validate the user’s identity (RA) –Generate and sign the user’s certificate attesting to the mapping of the identity to the public key (CA) –Revoke certificates if needed (RA/CA) –Operate under a set of policies and practices at a specific Level of Assurance (RA/CA) –Operate directories and other databases –The combination of the CA, RA, and associated directories forms the Public Key Infrastructure

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide A Digital Certificate is: –An object that binds a user’s identity to their public key –An object signed by a Certification Authority (CA) –An object containing some attributes about the person who owns the certificate –An object containing some information about the CA Useful for relying party to understand campus identity policy –Often published in a campus directory if support for encryption is anticipated

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Certification Authorities and Trust You determine if you trust a certificate by validating all of the certificates starting from the user’s cert up to a root that you trust 100+ root certificates in my Microsoft store The “I” in PKI Root Certificate Intermediate Certificate User A Cert User C Cert User B Cert User D Cert User E Cert

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Digital Certificates and Security Login id and password never flow over the network Strong cryptography – what does flow over the network is very safe Enables mutual authentication Defeats a variety of man in the middle attacks No (practical) brute-force attacks Is often easier to use than login/password

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Certificate Profiles A description of the fields in a certificate –Recommended fields to use –Field values –Critical flags –Recommendations for PKI architects on the various trade-offs available as they select their certificate profile –Example ProfileExample Profile

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Trust, Private Key Protection and Non-Repudiation Digital signatures - based on the idea that only the user has access their private key A user’s private key is generally protected by the workstation’s operating system –Typical protection is no better than for any password that the user lets the operating system store Hardware tokens can be used for strong private key protection, mobility, and as a component in a non-repudiation strategy

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Grid Security Infrastructure (GSI) Basic Grid security needs –Strong authentication –Ability to encrypt data –Cross-organizational security infrastructure –Single sign-on Solution –GSI is based on PKI and certificates are used for authentication –Uses mutual authentication and encryption when needed

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide PKI Mutual Authentication Client Authentication  Client connects to server and sends user’s certificate  Server uses its root key store to validate the user’s certificate  Server sends client some random data; client uses private key to encrypt data; server decrypts data validating that client has access to the private key Server Authentication  Server replies sending its digital certificate to the client  Client validates the server’s certificate using its trusted root store  Client sends some random data to the server; server encrypts the data using its private key; client decrypts data validating that server has access to the private key Globus uses SSL/TLS to accomplish mutual authentication

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Globus Proxy Certificates Proxy certificates are signed by the user’s end entity certificate A new key pair is used Short lived proxy credential Usable as if it were a normal certificate within the globus infrastructure Not a security risk for other campus uses of PKI –Basic Constraints field grid-proxy-init GridCA Root Certificate GridCA Intermediate Certificate User Certificate Proxy1 Proxy 2 Proxy 3

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Globus Toolkit Authentication and Authorization Configuration Basic PKI authentication configuration –/etc/grid-security/certificates –Populate with trusted CA certificates and policy files –Example: 860e > UVa-root-skp.crt 860e3429.signing_policy UVa-root-skp.crt –OpenSSL can generate the certificate hashes openssl x509 -hash -in UVa-root-skp.crt –noout

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Globus Toolkit Authentication and Authorization Configuration Basic Globus authorization configuration –Simple file-based authorization is a basic GSI service –A mapping file is used to map Unix user names to certificate DNs –/etc/grid-security/grid-mapfile "/C=US/O=University of Virginia/OU=UVA Standard PKI A. Jokl 52" jaj –An LDAP call-out can be used instead of the simple Grid Mapfile –Newer versions of Globus add more authorization capability

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Testing Globus Authentication Configuration using OpenSSL Testing the gatekeeper PKI configuration Remember: Globus uses SSL with PKI authentication openssl s_client -ssl3 -no_tls1 -connect gate.target.edu:2119 \ -cert.globus/usercert.pem -key.globus/userkey.pem \ -CApath /etc/grid-security/certificates Globus Gatekeeper Computer Cluster Job Queues User’s Computer SSL with PKI Authentication

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide MyProxy Service A service for retrieving proxy credentials –Commonly used in Grid Portal environments A server service for storing and protecting user’s private keys –Keys are stored on a secure server –Keys are encrypted using the user’s password User password is not stored on the server Provides some protection against server compromise

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Some Basic MyProxy Protocol Functions PUT – place a credential on the MyProxy Server –Server generates a key pair and certificate request –Client, which has access to the user’s private key, signs the request creating a proxy certificate GET – obtain a proxy certificate from the server –Client generates a key pair and certificate request –Server signs the request using the stored credential and sends the proxy credentials to the client INFO – list the available credentials on the server DESTROY – remove credentials on the server

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide MyProxy in a Grid Portal Environment User initializes credentials in MyProxy Server User logs into portal Portal retrieves proxy credentials User interacts with portal Jobs are submitted via gatekeeper MyProxy Server Grid Portal Server User Web Login Globus Gatekeeper Cluster Job Queue Retrieve Proxy

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide MyProxy Basic Authorization Internal and configurations options for: –Who can store credentials on server –Ensures that only the owner can delete, over-write, or change credential password –Which clients are able to obtain delegated credentials from the server –Protection for access to stored credentials –Lifetime for stored credentials

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide MyProxy Commands myproxy-init: store proxy myproxy-logon: retrieve proxy myproxy-info: query stored credentials myproxy-destroy: remove credential myproxy-change-pass-phrase: change password encrypting private key myproxy-store: store credential myproxy-retrieve: retrieve credential

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Shibboleth Project of Internet2 and NSF Middeware Initiative –Focus: intercampus authentication and authorization –Federated identity Fundamental design goals –Privacy protection –Strong technology PKI cryptography Signed SAML assertions –Use local campus authentication for intercampus applications –Support directory based authorization via AA (6-8) eduPerson schema User User’s Shibboleth ORIGIN Site Shibboleth Protected Web Site (TARGET) WAYF Local AuthN Directory Schematic of Shibboleth Process Flow

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Shibboleth and GridShib Focus: leverage the attribute work done in the Shibboleth community for Grid authorization in Globus Shibboleth architecture includes the Attribute Authority (AA) and signed SAML assertions Campus directories are being upgraded to support standardized schema such as eduPerson

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Shibboleth and GridShib GridShib Globus plugin (GT4) –Makes authorization decisions based on data from a Shibboleth AA GridShib Shibboleth plugin –A name mapping plugin that maps certificate Subject DNs to local Principal Name Uses an equivalent to a grid-mapfile –With the local principal name, attributes can be obtained from the Shibboleth AA WAYF-type functionality is preconfigured Beta Gridshib software is available now

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Virtual Organizations (VO) Grids are frequently built to support inter- institutional research projects –Not all users at each institution should be able to access Grid resources –Grid security is important and inter-institutional Grids still need strong user authentication –Like the researchers, resources are likely to be placed on the Grid by multiple organizations A description of a Grid Virtual Organization –The collection of researchers and the resources that they are enabled to access can be thought of as a VO

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Virtual Organization Tasks Policies –Who can join the organization –How are resources allocated e.g., what agreements are needed between resource owners, resource consumers, and the VO Implementation –Inter-institutional authentication –Authorization: all users in a Grid may not all have the same roles. Group-based authorization may be needed

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Some Virtual Organization Tools VOMS – VO Membership Service –Holds VO authorization information such as a user’s groups and certificate information –When a user submits a job, VOMS generates an extended proxy with a short lifetime VOX – VOMS eXtended –Holds additional information on each VO member to support authorization decisions by resources VOMRS – VOMS Registration Service –A central registry of users for the VO –Holds status, roles, certificate, rights, etc –Approval process for database entries

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Some VOMRS Data Elements Roles –Visitor, Candidate, Applicant, Member Status –New, Approved, Denied, Suspended Authorization Status –New, Approved, Denied Rights –Full, none

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Example: SURAgrid Approach for Authentication and Authorization Goal –Develop a scalable inter-campus solution Preferred mechanisms –Leverage campus middleware activities Researchers should not need to operate their own authentication systems Use local campus credentials inter-institutionally –Rely on existing higher education inter- institutional authentication efforts

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Inter-campus Globus Authentication Leverage native campus PKI credentials on SURAgrid –Users do all of their work using local campus PKI credentials How do we create the inter-campus trust fabric? –Standard inter-campus PKI trust mechanisms include Operating a single Grid CA or trusting other campus CAs Cross-certification and Bridge PKIs How well does Globus operate in a bridged PKI? –OpenSSL PKI in Globus is not bridge-aware –Known to work from NMI Testbed project Decision: work with intercampus trust based on a PKI Bridge –Leverage EDUCAUSE Higher Education Bridge CA (HEBCA) when readyHEBCA

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Background: Cross-certification Top section –Traditional hierarchical validation example Bottom section –Validation using cross certification example –UVA signed a certificate request from the UAB CA –UAB signed a certificate request from the UVA CA –This pair of cross certificates enables each school to trust certs from the other using only their own root as a trust anchor –An n 2 problem I: UVA S: User-1 I: UAB S: UVA I: UAB S: UAB I: UAB S: User-2 I: UVA S: UAB I: UVA S: UVA Cross Certs I: UVA S: User-1 I: UAB S: UAB I: UVA S: UVA I: UAB S: User-2

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Background: Bridged PKI Used to enable trust between multiple hierarchical CAs Generally more infrastructure than just the cross-certificate pairs Typically involves strong policy & practices Solves the n 2 problem For SURAgrid we preload cross-certs Campus A Mid-A User A1 User A2 Campus B Campus n Mid-B User B1 Bridge CA Cross-certificate pairs

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide SURAgrid Authentication Schematic Campus E Grid A’s PKI SURAgrid Bridge 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 D’s PKI E’s PKI F’s PKI

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide SURAgrid Authentication Status SURAgrid Bridge CA –Off-line system –Used Linux and OpenSSL to build bridge Cross-certifications with the bridge complete or in progress for 8 SURAgrid sites Several more planned in near future SURAgrid Bridge Web SiteWeb Site Interesting PKI issues discussed in paperpaper

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Higher Education Bridge Certification Authority (HEBCA) A project of EDUCAUSE –Implement a bridge for higher education based on the Federal PKI bridge model –Support both campus PKIs and sector hierarchical PKIs –Cross-certify with the Federal bridge (and others as appropriate) Should form an excellent permanent trust fabric for a bridge-based Grid

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Model SURAgrid Authentication Campus E Grid A’s PKI HEBCA Campus B Grid Campus C Grid Campus D Grid Campus A Grid Campus F Grid B’s PKI C’s PKI Cross-cert pairs D’s PKI E’s PKI F’s PKI

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Bridge to Bridge Context A federal view on how the inter-bridge environment is likely to develop FBCA – Federal Bridge SAFE – Pharmaceutical HEBCA – Higher Ed Commercial - aerospace and defense Grid extensible across PKI bridges? FBCA HEBCASAFE Commercial Others

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide SURAgrid AuthN/AuthZ Status Bridge CA and cross-certification process –Forms the basic AuthN infrastructure –Builds a trust fabric that enables each site to trust the certificates issued by the other sites The grid-mapfile –Controls the basic (binary) AuthZ process –Sites add certificate Subject DNs from remote sites to their grid-mapfile based on from SURAgrid sites

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide SURAgrid AuthZ Development Grid-mapfile automation –Sites that use a recent version of Globus will use a LDAP callout that replaces the grid- mapfile –For other sites there will be some software that provides and updates a grid-mapfile for their gatekeeper

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide SURAgrid AuthZ Development LDAP AuthZ Directory –Web interface for site administrators to add and remove their SURAgrid users –Fully distributed model where each site maintains its central VO membership data –Directory holds and coordinates Certificate Subject DN Unix login name (prefixed by school initials) Allocated Unix UID (high numbers) Some Unix GIDs? (high numbers) Perhaps SSH public key, perhaps gsissh only Other (tbd) –Reliability Replication to sites that want local copies

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide SURAgrid AuthZ Development Sites contributing non-dedicated resources to SURAgrid greatly complicate the equation We will provide a code template for editing grid-mapfiles to manage SURAgrid users Publish our LDAP schema –Sites may query LDAP to implement their own SURAgrid AuthZ/AuthN interface

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Likely SURAgrid AuthZ Directions –User directory or directory access Group management Person attributes VO names Store per-person, per-group allocations Integrate with accounting Local and remote stop-lists –Resource directory Hold resource usage policies Time of day, classifications, etc –Mapping users to resources within resource policy constraints –We’ll learn a lot more about what is actually required as we work with the early user groups

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Campus Grid AuthN Decisions General Higher Education Context How a campus chooses to implement their Grid authentication may be influenced by other higher education middleware efforts Highlights from some other projects follow

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide PKI and USHER/HEBCA (How) do all of these PKI pieces fit together? –USHER – US Higher Education Root CA –HEBCA – Higher Education Bridge CA –Campus Certification Authorities –EDUCAUSE contract for outsourced certificates What should a campus be doing?

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Fundamental Campus PKI Decision: Build or Buy Building your own PKI –Certification Authority (CA) Developing or installing CA software (e.g., simpleCA, etc) Operating it in a secure environment –Implementing the Registration Authority (RA) function Identity proofing of individuals Handling requests for revocation, etc. –Some considerations Early investment in staff time, likely lower per-certificate costs for large deployments in the long run Users can have as many certificates as they need –Software examples at: tag/opensrc.html tag/opensrc.html

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Fundamental Campus PKI Decision: Build or Buy Buying PKI services –Certification Authority (CA) Provided by the outsource company Operated remotely in a secure environment –Implementing the Registration Authority (RA) function Identity proofing of individuals Handling requests for revocation, etc. –Some considerations Quick start-up Annual costs bounded by the number of certificates issued Root certificate likely already trusted by your browsers and installed in your operating systems May limit the number of certificates that each user can have –Example:

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Your Campus May Have non-Globus needs for a Central PKI The build vs. buy decision may be influenced by your PKI applications –Electronic mail (S/MIME) –VPN (IPSec), Wireless (EAP-TLS), & SSH authentication –Web authentication –LionShare –Digital signatures on documents Applications with large numbers of users may tip the balance towards the “build” option –Note that certificate management (getting the same certificate/key on multiple computers) can be hard for users

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Inter-organizational Trust USHER CA Campus CA Campus A Mid-A User Campus B Campus n Mid-B User HEBCA Bridge Cross-certificate pairs User

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide A Higher-level View of Inter-organizational Trust FBCA HEBCA SAFE Commercial Others Campus CA Educause Verisign CA USHER CA Campus CA Campus Users

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Thank You Questions, Discussion?

December 8 & 9, 2005, Austin, TX SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Some References PKI-Lite middleware.internet2.edu/hepki-tagPKI-Lite HEPKI Model Certification Policy Software CA packagespackages HEBCA – USHER – (soon) VOMS GridShib - gridshib.globus.orgGridShib MyProxy - myproxy.ncsa.uiuc.eduMyProxy