GSI – Grid Security Infrastructure and the EU DataGrid Authentication Infrastructure

1. GSI – Grid Security Infrastructureand the EU DataGrid Authentication Infrastructure For the EDG CACG: David Groep <dg-eur-ca@services.cnrs.fr>

2. Outline • The Grid in one line • The Grid Security Infrastructure (from Globus) • EU DataGrid (EDG) • The EDG CA Coordination Group (CACG)

3. The Grid: coordinated resource sharing and problem solving in dynamic, multiinstitutional virtual organizations Carl Kesselman, Ian Foster, The Anatomy of the Grid • Extension of “meta-computing” to ubiquitous resources • Pioneered by the I-WAY, GUSTO and the Globus Project • Vision: getting resources like you get electricity nowadays

4. A Quick Refresher Grid Security Infrastructure (GSI) = X.509 (PKI certificate format)* + proxy certificates (single sign-on & delegation) + TLS/SSL (authentication & msg protection)* + delegation protocol (remote delegation) + GSS-API (standard API)* + GSS-API Extensions (better Grid support) * = Existing IETF standards • Others are GGF & IETF drafts

5. X.509 Proxy Certificates Work • Defines how a short term, restricted credential can be created from a normal, long-term X.509 credential • A “proxy certificate” is a special type of X.509 certificate that is signed by the normal end entity cert, or by another proxy • Supports single sign-on & delegation through “impersonation” • ANL, ISI, LBNL

6. Restricted Proxies • Q: How to restrict rights of delegated proxy to a subset of those associated with the issuer? • A: Embed restriction policy in proxy cert • Policy is evaluated by resource upon proxy use • Reduces rights available to the proxy to a subset of those held by the user • But how to avoid policy language wars? • Proxy cert just contains a container for a policy specification, without defining the language • Container = OID + blob • Can evolve policy languages over time

7. Delegation Tracing • Often want to know through what entities a proxy certificate has been delegated • Audit (retrace footsteps) • Authorization (deny from bad entities) • Solved by adding information to the signed proxy certificate about each entity to which a proxy is delegated. • Does NOT guarantee proper use of proxy • Just tells you which entities were purposely involved in a delegation

8. Proxy Certificate Standards Work • “Internet Public Key Infrastructure X.509 Proxy Certificate Profile” • draft-ietf-pkix-proxy-00.txt • Draft being considered by IETF PKIX working group, and by GGF GSI working group • Defines proxy certificate format, including restricted rights and delegation tracing • LBNL student is implementing into OpenSSL • Demonstrated a prototype of restricted proxies at HPDC as part of CAS demo

9. Delegation Protocol Work • “TLS Delegation Protocol” • draft-ietf-tls-delegation-01.txt • Draft being considered by IETF TLS working group, and by GGF GSI working group • Defines how to remotely delegate an X.509 Proxy Certificate using extensions to the TLS (SSL) protocol

10. Community Authorization Service • Question: How does a large community grant its users access to a large set of resources? • Should minimize burden on both the users and resource providers • Solution: Community Authorization Service (CAS) • Community negotiates access to resources • Resource outsources fine-grain authorization to CAS • Resource only needs to know about “CAS user” credential • CAS handles user registration, group membership… • User who wants access to resource asks CAS for a capability credential • Restricted proxy of the “CAS user” credential, checked by resource

11. CAS Operation 1. CAS request, with user/group CAS resource names membership Does the and operations collective policy resource/collective authorize this 2. CAS reply, with membership request for this capability and resource CA info user? collective policy information User Resource 3. Resource request, authenticated with Is this request capability authorized by the local policy capability? information 4. Resource reply Is this request authorized for the CAS?

12. Community Authorization Service • CAS provides user community with information needed to authenticate resources • Sent with capability credential, used on connection with resource • Resource identity (DN), CA • This allows new resources/users (and their CAs) to be made available to a community through the CAS without action on the other user’s/resource’s part

13. The EU DataGrid (EDG) Project • DataGrid: generic Grid middleware and test bed for • High Energy Physics • Earth Observation and ozone modelling • Bio-informatics & bio-medicine • Middleware components (on top of Globus): • scheduling and accounting • data replication and management • monitoring • data storage • fabric and farm management

14. The EDG Test Bed • Started end 2000 – beginning 2001 with “Test Bed 0” • Globus installations in several countries • Implement core infrastructure to get this to work • Test Bed 1, deployed Nov 2001, successful demo in March 1st • Continuous upgrades till December 2003

15. The first Grid CA’s • The Globus Project has been running a “worthless” CA • authentication based on non-bouncing e-mail address only • not accepted by many of the participating sites • For EDG “production” test bed need for just a bit stronger auth • grass-roots effort by volunteers in various countries • policies and practices all different • various degrees of subject authentication • a (very) few CA’s are still in need of a written policy

16. some EDG CA stats: • 11 CAs • 1 year in operation • ~ 1000 certs issued • potential community: 10000–40000–??? Current EDG Certification Authorities • DoESG CA (ESnet, Grid-only) • Germany (FZK, Grid-only) • CERN (HEP-only, Grid-only) • Czech Republic (CESNET) • France (CNRS) • Spain (IFCA, HEP-only, Grid-only) • Netherlands (NIKHEF/DutchGrid, Grid-only) • Italy (INFN, HEP-only, Grid-only) • Portugal (LIP, HEP-only, Grid-only) • Nordic Countries (NBI, Grid-only) • Russia (Moscow State Uni, HEP-only, Grid-only) • GridPP/UKHEP (CLRC/RAL, Grid-only)

17. EDG CA “Minimum Requirements” (1) • Still largely defined by common practice … “An acceptable procedure for confirming the identity of the requestor […] e.g. by personal contact or some other rigorous method” • One CA per country → basic trust in personal authentication by CA/RA • Subject name includes full given name and affiliation • Specific nameforms per CA (but all different) • Most use personal voice recognition of known persons, or check official ID papers via an RA • RA-to-CA communications by integrity-protected e-mail • Affiliation usually checked by looking in “public” directories • “Host certificates” introduced by a pre-certified administrator

18. EDG CA “Minimum Requirements” (2) • Technical controls better specified • machine with CA private key not connected to any network • CA RSA key length 2048 bits → lifetime 5 years • Subscriber key length > 1024 bits → 1 year • All CA’s issue a CRL with a 30-day lifetime (updated ~ weekly) • Relying parties must update every 24 hrs • Audit logs must be kept • but no auditing is done! (no funding) • Strongly recommends running a directory service

19. EDG CA CP/CPS and the Matrices • Every EDG CA must provide a CP/CPS (combined) • RFC2527 preferred • a per-CA “feature matrix” is made • Cross-evaluation of CP/CPS by every CA Manager • tries to make up for lack of auditing • provide trust guidelines for “local” site administrators • Every CA Manager should inspect all other CP/CPSs • Yields the Acceptance Matrix

20. CA Feature Matrix by Brian Coghlan, TCD, Ireland

21. CA Acceptance Matrix The Acceptance Matrix Problem: This does not scale • Already 12 CA’s • Numbers growing rapidly • CrossGrid Project: + 7 countries • CERN/LHC: +120 countries • .... • Automate the evaluation • move work to proper forums

22. Grid CA Standardization Efforts • Global Grid Forum (GGF) • standardization body modeled like IETF/IRTF • 2 working groups in security area: • Grid Security Infrastructure wg • GridCP wg • http://www.globalgridforum.org/ • GridCP working group • define a reference CP (with four? levels) • every compliant CA should add own appendix with CPS (few pages) • not clear on: cross-certifying, root, or bridge CA

23. EDG and GGF CA References • The EU DataGrid http://www.eu-datagrid.org/ • The Globus Project http://www.globus.org/security/ • EDG CACG site http://marianne.in2p3.fr/datagrid/ca/ • GGF GridCP wg http://www.gridcp.es.net/ • DoESG site http://envisage.es.net/