grid authentication the eugridpma eiroforum gg meeting david groep chair 2005 09 14 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Grid Authentication & the EUGridPMA EIROforum GG Meeting David Groep, Chair, 2005.09.14 PowerPoint Presentation
Download Presentation
Grid Authentication & the EUGridPMA EIROforum GG Meeting David Groep, Chair, 2005.09.14

Grid Authentication & the EUGridPMA EIROforum GG Meeting David Groep, Chair, 2005.09.14

227 Views Download Presentation
Download Presentation

Grid Authentication & the EUGridPMA EIROforum GG Meeting David Groep, Chair, 2005.09.14

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Grid Authentication & the EUGridPMAEIROforum GG MeetingDavid Groep, Chair, 2005.09.14

  2. Outline • Grid Security Infrastructure • Virtual Organisations • Authentication vs. Authorisation • Authentication Federation: EUGridPMA • Trusting trust anchors: TACAR • International Grid Trust Federation • e-IRG Roadmap and the i2010 agenda • Discussion…

  3. A brief summary: Grid characteristics • Resource sharing across different administrative domains • … using open and generic protocols • … resulting in enhanced qualities of service

  4. Grid Security Requirements • Control access to shared services • Address autonomous managementdifferent policies in different working groups • Support multi-user collaborations • Federate through mutually trusted services • Local policy always prevails • Allow users and application communities to set up dynamic trust domains • Both personal and VO-based aggregation of resources, based on personal or VO-mediated trust • Easy to use: user single sing-on

  5. Virtual Organisations • Resource sharing and coordinated problem solving in dynamic multi-institutional virtual organisations

  6. Source of Authority The Resource Owner Always Stays In Control (and it’s worth dedicating an entire slide to this!)

  7. V i r t u a l C o m m u n i t y C P e r s o n E ( R e s e a r c h e r ) P e r s o n B F i l e s e r v e r F 1 ( A d m i n i s t r a t o r ) ( d i s k A ) C o m p u t e S e r v e r C 1 ' P e r s o n A P e r s o n D ( P r i n c i p a l I n v e s t i g a t o r ) ( R e s e a r c h e r ) P e r s o n B P e r s o n E ( S t a f f ) F i l e s e r v e r F 1 P e r s o n D ( F a c u l t y ) ( d i s k s A a n d B ) C o m p u t e S e r v e r C 2 C o m p u t e S e r v e r C 1 ( S t a f f ) P e r s o n A P e r s o n F ( F a c u l t y ) ( F a c u l t y ) P e r s o n C C o m p u t e S e r v e r C 3 ( S t u d e n t ) O r g a n i z a t i o n A O r g a n i z a t i o n B Virtual vs. Organic structure Graphic by Frank Siebenlist, ANL & Globus Alliance

  8. Stakeholders in Grid Security • Conceptually, all members of a VO are equal • Users can provide their own services • Resource provider organisations may or may not have personal members (they can just sell resources to a VO) • No a priori trust relationship between members • VO lifetime can vary from hours to decades • People (and resources) usually are members of more than one VO • … but an established relation is required • for traceability and liability • for incident handling, accounting and support

  9. VO environment • VOs today are rather long-lived • part of a Grid ‘ecosystem’: • Middleware • User support • `Infrastructure’ (a collective of Resource Centres) or • a single VO per project • Implicit sharing agreement between users and centres

  10. Many Grid Infrastructures Need Interoperation • In Europe • Enabling Grid for E-sciencE (EGEE) • Distributed European Infrastructure for Supercomputer Applications (DEISA) • South East European Grid (SEE-GRID) • many national projects (VL-e, D-Grid, UK e-Science) • In the US • Open Science Grid (OSG) • TeraGrid • also many others, like NEESGRID, NASA IPG, … • Asia-Pacific • AP Grid • Pacific Rim Applications and Grid Middleware Assembly • EGEE participation • LHC Computing Grid Project (global)

  11. Many different organisations • LCG Computing Grid ~140 sites (with LCG-2 m/w) • DEISA ~ 15 sites • OSG ~ 40 sites

  12. Separating AuthN from AuthZ • Single Authentication token (“passport”) • issued by a trustworthy third party, • recognised by many resource providers, users, and VOs • Satisfies traceability requirement • In itself does not grant any access • But only provides unique binding between a identifier and the subject* • Authorisation (“visa”) • Access is granted by the resource owner • Based directly on the AuthN identifier, or • Indirectly via VO membership • Providers define their lists of authorised users & VOs,but can still ban individual users within a VO

  13. Authentication • Based on Trusted Third Parties in an X.509 PKI • Bind identifiers to identities • Assert that via immutable tokens (“certificates”) • Using cryptographically sound methods (asymmetric cryptography using public-private key pairs) Cert Authority trust certify Relying Party(user) user Relying Party(resource centre) user service Relying Party(resource centre) Relying Party(service provider) user Relying Party(resource centre) ‘commonName=Pietje Puk’ ‘’

  14. Authorization • Variety of mechanisms • Per-resource list of authorized users (“grid-mapfile”) • Directories of authorized users (VO-LDAP) • Embedded assertions (VOMS, CAS) • Leverage AuthN identifiers provided by PKI • Identity management decoupled from access control • Renewable identity tokens • Single sign-on across multiple resources • Short-lived “proxy” credentials for users

  15. Hybrid ways to AA • Pervasive in legacy applications (like ssh) • Many times originate in organisation-focussed applications • Bridging efforts • gsissh • minimalist changes to allow remote access based on user proxy credentials • GridShib • use of a Shibboleth attribute authority as a source of authorization, based on X.509 user proxy credential • … • …

  16. Authentication Infrastructure

  17. Why PKI? • Uniformity of credentials and interoperability(X.509 and it’s use in SSL/TLS is common) • Tamper resistant credentials • One-to-many mechanism (instead of many-to-many) • Mobility (floppy disk, flash memory, smart card) • Scalability • Off-line authentication of users, • limited real-time interaction (status checks only)

  18. Well known X.509 PKIs • Secure web servers (‘https’) based on PKI • Various commercial providers • Entrust, Thawte, Verisign, SwissSign, … • Usually expensive but don’t actually subsume liability … … a rogue cracker obtained a certificate from Verisign asserting he was from Microsoft … • Are implicitly trusted by many, since web browsers pre-install the roots of trust … did you ever check the policies of all those CAs?… can you even find them?

  19. Hierarchical PKI • “hierarchies” are the traditional method of organising trust • A Relying Party that trust a top-level policy can implicitly trust all subordinates • But… • By signing a subordinate the CA assumes liability • It requires hierarchical control by the top-level CA on the subordinates(so that it en ensure policy compliance) • It implies a dependency relationship(not very well suited to a multi-national trust relationship)

  20. charter guidelines acceptance process The Federated PKI • Federation consists of many independent CAs • Common minimum requirements • Solid acceptance process • “reasonable” trust level, as required by relying parties • no ‘hierarchical top’ to make hard guarantees (more like “EU-style” cooperation) • no single point of failure CA 2 CA 1 relying party n CA n CA 3 relying party 1

  21. Building the federation • PKI providers (‘CAs’) and Relying Parties (‘sites’) together shape the minimum requirements • Authorities testify compliance with these guidelines • Peer-review process within the federation to (re) evaluate members on entry & periodically • Reduce effort on the relying parties:single document to review and assess • Reduce cost on the CAs:no audit statement needed by certified accountants ($$$) • Requires that the federation remains manageable in size

  22. Origins of the Federation: the EDG CACG The EU DataGrid needed a PKI for the test bed • CACG had the task of creating this PKI • for Grid Authentication only • no support for long-term encryption or digital signatures • Single CA not acceptable • Single point of attack or failure • One CA per country, large region or international organization • CA must have strong relationship with RAs • Some pre-existing CAs • A single hierarchy would have excluded existing CAs and was not convenient to support with existing software • Coordinated group of peer CAs was most suitable choice History

  23. Minimum requirements for RA - Testbed 1 --------------------------------------- An acceptable procedure for confirming the identity of the requestor and the right to ask for a certificate e.g. by personal contact or some other rigorous method The RA should be the appropriate person to make decisions on the right to ask for a certificate and must follow the CP. Communication between RA and CA ------------------------------- Either by signed e-mail or some other acceptable method, e.g. personal (phone) contact with known person Minimum requirements for CA - Testbed 1 --------------------------------------- The issuing machine must be: a dedicated machine located in a secure environment be managed in an appropriately secure way by a trained person the private key (and copies) should be locked in a safe or other secure place the private keu must be encrypted with a pass phrase having at least 15 characters the pass phrase must only be known by the Certificate issuer(s) not be connected to any network minimum length of user private keys must be 1024 min length of CA private key must be 2048 requests for machine certificates must be signed by personal certificates or verified by other appropriate means ... ‘Reasonable procedure … acceptable methods’ • Requirements and Best Practices for an “acceptable and trustworthy” Grid CA History

  24. Five years of growth December 2000:First CA coordination meeting for EDG March 2001:First version of the minimum requirements 5 CAs: France (CNRS), Portugal (LIP), Netherlands (NIKHEF), CERN, Italy (INFN), UK (UK eScience) December 2002:Extension to other projects: EU-CrossGrid … April 2004:Establishment of the EUGridPMAFormal charter and guidelines documents … Fall 2005:International Grid Trust Federation … History

  25. The European Policy Management Authority for Grid Authentication in e-Science (hereafter called EUGridPMA) is a body • to establish requirements and best practices for grid identity providers • to enable a common trust domain applicable to authentication of end-entities in inter-organisational access to distributed resources. • As its main activity the EUGridPMA • coordinates a Public Key Infrastructure (PKI) for use with Grid authentication middleware. • The EUGridPMA itself does not provide identity assertions, but instead asserts that - within the scope of this charter – the certificates issued by the Accredited Authorities meet or exceed the relevant guidelines. The EUGridPMA “constitution”

  26. EUGridPMA Membership EUGridPMA membership for classic CAs: • A single Certification Authority (CA) • per country, • large region (e.g. the Nordic Countries), or • international treaty organization. • The goal is to serve the largest possible community with a small number of stable CAs • operated as a long-term commitment Many CAs are operated by the (national) NREN(CESNET, ESnet, Belnet, NIIF, EEnet, SWITCH, DFN, … ) or by the e-Science programme/Science Foundation(UK eScience, VL-e, CNRS, … )

  27. Growth of the CACG & EUGridPMA History

  28. Coverage of the EUGridPMA • Green: CA Accredited • Yellow: being discussed(BalticGrid, Turkey/ULAKBIM, RedIRIS) Other Accredited CAs: • DoEGrids (US) • GridCanada • ASCCG (Taiwan) • ArmeSFO (Armenia) • CERN • Russia (“DataGrid”) • Israel (IUCC) • Pakistan • IHEP (China) and can we leverage of other (national) AuthN infrastructures?

  29. Establishing trust • Explicit requirements on identity providers • Open-ness to peer review and audits • Based on community standards (GGF) • Close involvement of major relying parties • Pan-European scope • Requirements coded in ‘guidelines’ • Specific guidelines for different technologies(“Authentication Profiles”)

  30. RPs: the issues to be addressed Relying Party requests: 1) standard accreditation profiles sufficient to assure approximate parity in CAs 2) monitor [] signing namespaces for name overlaps3) a forum [to] participate and raise issues4) [operation of] a secure collection point for information about CAs which you accredit5) common practices where possible [list courtesy of the Open Science Grid]

  31. Guidelines: common elements • Coordinated namespace • Subject names refer to a unique entity (person, host) • Basis for authorization decisions • Common Naming • One-stop shopping for all trust anchors in the federation • Trusted, redundant, download sources • Concerns and ‘incident’ handling • Guaranteed point of contact • Forum to raise issues and concerns • Requirement for documentation of processes • Detailed policy and practice statement • Open to auditing by federation peers

  32. Guidelines: secured X.509 CAs • Identity vetting procedures • Based on (national) photo ID’s • Face-to-face verification of applicants via a network of Registration Authorities • Periodic renewal (once every year) • Secure operation • off-line signing key or special (FIPS-140-3) hardware • Response to incidents • Timely revocation of compromised certificates

  33. Guidelines: short-lived credential service • Issue short-lived credentials (for grid: proxies) based on another authentication system • e.g. Kerberos CA based on existing administration • Same common guidelines apply • documented policies and processes • a reliable identity vetting mechanism • Same X.509 format, but no user-held secrets • A new profile pioneered by CAs in the Americas

  34. TACAR A trusted repository which can contain verified root-CA certificates The certificates to be collected are those directly managed by the member NRENs, or belonging either to a National Academic PKI in the TERENA member countries (NPKIs), or to non-profit research projects directly involving the academic community. • Authoritative source for validation of trust anchors • independent web administration makes for stronger trust • TACAR certificate itself published in paper/journals • over 20 CA root certificates collected(not only for grid use!)

  35. EUGridPMA and TACAR

  36. Along the e-IRG Roadmap e-IRG: e-Infrastructure Reflection Group Roadmap for i2010: • commitment to the federated approach • vision of an integrated AA infrastructure for eEurope Towards an integrated AAI for academia in Europe and beyond • The e-IRG notes the timely operation of the EUGridPMA in conjunction with the TACAR CA Repository and it expresses its satisfaction for a European initiative that serves e-Science Grid projects. […] The e-IRG strongly encourages the EUGridPMA / TACAR to continue their valuable work […] (Dublin, 2004) • The e-IRG encourages work towards a common federation for academia and research institutes that ensures mutual recognition of the strength and validity of their authorization assertions.(The Hague, 2005)

  37. APGridPMA TAGPMA Extending Trust:IGTF – the International Grid Trust Federation • common, global best practices for trust establishment • better manageability and response of the PMAs The America’s Grid PMA European Grid PMA Asia-Pacific Grid PMA

  38. APGridPMA • 13 members from the Asia-Pacific Region,chaired by Yoshio Tanaka (AIST) • Launched June 1st, 2004 • 4 ‘production-quality’ CAs • Pioneered ‘experimental’profile • AIST (.jp) • APAC (.au) • BMG (.sg) • CMSD (.in) • HKU CS SRG (.hk) • KISTI (.kr) • NCHC (.tw) • NPACI (.us) • Osaka U. (.jp) • SDG (.cn) • USM (.my) • IHEP Beijing (.cn) • ASGCC (.tw)

  39. TAGPMA • 10 members to date, chaired by Darcy Quesnel (Canarie) • Launched June 28th, 2005 • Pioneered new “SLCGS”(Kerberos CA & al.) • SDSC (.us) • FNAL (.us) • Dartmouth (.us) • Umich (.us) • Brazil (.br) • Canarie (.ca) • OSG (.us) • TERAGRID (.us) • Texas H.E. Grid (.us) • DOEGrids (.us)

  40. Relationships: IGTF, PMAs, TACAR and GGF

  41. Common Guidelines managed by the federation (collective responsibility) management assigned to the EUGridPMA management assigned to the TAGPMA management assigned to the APGridPMA

  42. Conclusions • A Common, Global, Trust Domain Exists Today • Recognised by many projects & the e-IRG • a solid basis (“classic X.509 CAs”), and • room for innovation (“SLCGS”, experimental CAs) • AuthorisationFederations are the next big challenge for Grid and an eEurope