Outline

1. The Profiles of the International Grid Trust Federation2nd NetherNordic SLCS meeting, 16 December 2008

2. Outline • A few words on the EUGridPMA and IGTF • A Brief History and Background • IGTF Structure • Relying Party Requirements • Authentication Profiles • Common Elements • ‘Classic’: the traditional way of doing PKI • Short Lived Credential Services (SLCS) • Member Integrated credential services (MICS)‘long-lived certs derived from a membership database’ • Accreditation Process and PMA expectations

3. Stakeholders in Grid Security Current grids are largely end-user centric • Roles of a person in a (research) collaboration or community bears no relation to her role in the home org • Grids today target researchers, not organisations • But all users are in an organisation ... ... that can - and should - be leveraged!

4. Where to Ground Trust? • There is no a priori trust relationship between grid members or member organisations • Community (VO) ‘life time’ can vary from days to decades • people and resources are members of many Vos • VOs can accept some responsibility, but are a ‘bad source’ for identity as VO loyalty may be the ‘wrong way’(as far as resource providers are concerned) • … but relationship user–VO–resource is required • for authorising access, traceability and liability, incident handling, and accounting • … so the grid needs trusted third parties

5. Authentication … academia, industry, and … Possible sources of authentication and identity • National PKI • in general uptake of 1999/93/EC and e-Identification is slow • where available, a national PKI could be leveraged • Several commercial providers • main commercial drive today: secure e-commerce based on SSL • thus primary market is server authentication, not end-user identities • are implicitly trusted by many • because web browsers pre-install the roots of trust • WebTrust “seal of approval” scope limited to a single Authority • Academic Grid PKI today • Provide end-user identities for secure mail and grid use • generally provided by the NREN or national ‘e-science’ project

6. charter guidelines acceptance process A Federation Model for Grid Authentication • A ‘policy bridge’ federation of independent CAs • Policy coordination based on common minimum requirements(not ‘policy harmonisation’) • Acceptable for major relying parties in Grid Infrastructures • No strict hierarchy with a single top nor a bridge CA as such • spread liability and enable failure containment (better resilience) • maximum leverage of national efforts and subsidiarity CA 2 CA 1 relying party n CA n CA 3 relying party 1

7. From the Beginning: the EU DataGrid CACG The EU DataGrid project in 2000 needed a PKI for AuthN • Explicitly and deliberatly split ‘complex’ AuthZ from AuthN • Estalbih both end-user and server/service PKI • CACG (David Kelsey) had the task of creating this PKI • for grid Authentication only • no support for long-term encryption or digital signatures • Single CA was not considered acceptable • Not a sustainable funding model, and single point of failure • One CA per country, large region or international organization • CA must maintain strong relationship with RAs and users • Allows incorporation of pre-existing CAs • A single hierarchy would have excluded existing CAsand was not possible to support with existing software • Coordinated group of peer CAs was most suitable choice History

8. Building the federation CA by CA • Meet or exceed common set of minimum requirements • Authorities compliant with ‘minimum requirements’ • Guidelines set jointly by relying parties (sites, projects) and authorities • De-facto a single LoA – as strongly requested by the RPs • Different technologies lead to slightly different choices • Peer-review process within the federation to evaluate members on entry • Both peer-reviewed self-audits and on-site audits • It must work! It’s not a playground for theoretical concepts, but constraint by software that is actually deployed • … ultimate decision on trust always remains with RPs

9. 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: Minimum Requirements History

10. Relying Party issues to be addressed Key characteristics of the request by our Major Relying Parties 1. standard accreditation profiles sufficient to assure approximate parity in CAs 2. monitor [] signing namespaces for name overlaps and issue unique names3. 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, backed (and to be extended) by EGEE&LCG)

11. EUGridPMA Membership EUGridPMA membership for (classic) Authorities • a single Authority per • country, large region or international treaty organization • ‘serve the largest possible community with a small number of stable CAs’ • ‘operated as a long-term commitment’ Relying Parties: major e-Infrastructures or partner organisations DEISA, EGEE, SEE-GRID, TERENA, … 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, … )

12. Foundation of the IGTFallows migration of CAs to proper Regional PMA Growth of the European Grid trust fabric History

13. International Grid Trust Federation Green: regular national CA accredited; Yellow: accreditation in progress

14. Geographical coverage of the EUGridPMA • 23 of 25 EU member states (all except LU, MT) • + AM, CH, HR, IL, IR, IS, MA, ME, MK, NO, PK, RO, RS, RU, TR, UA, SEE-GRID + CA, CERN (int), DoEGrids(US)* Pending or in progress • BY, MD, SY, LV, ZA, SN

15. IGTF Status Today • Already 77 accredited authorities • EUGridPMA: 41 countries + 1 treaty organisation • TAGPMA: 6 countries (but several authorities in US and BR) • APGridPMA: 7 countries or economic regions (several authorities in CN, TW, JP) • About 10 Major Relying Party members • 6 in Europe: DEISA, EGEE, LCG, OSG, SEE-GRID, TERENA • PRAGMA, TeraGrid, OSG , LCG in other PMAs as well

16. Different technologies, different profiles • The IGTF established a single trust fabric, incorporating authorities using different techniques • Profiles • Classic • Real-time vetting(F2F or TTP) • 13 months life time • SLCS • Existing IdM databases • 100k – 1Ms life time • MICS • IdM Federation • 13 months max • Common Elements • Unique Subject Naming • Identifier Association • Publication & IPR • Contact andincident response • Auditability

17. APGridPMA • CA A1 • … • EUGridPMA • CA E1 • CA E2 • … • TAGPMA • CA T1 • … IGTF Federation Common Policy IGTF Federation Document trustrelations SubjectNamespaceAssignment DistributionNaming Conventions Common Authentication Profiles Classic(EUGridPMA) SLCS(TAGPMA) worldwide relying parties see a uniform IGTF “mesh”

18. Guidelines: common elements in the IGTF • Coordinated namespace • Subject names refer to a unique entity (person, host)‘Any single subject distinguished name (DN) in a certi ficate must be linked with one and only one entity for the whole lifetime of the service.’ • Used as a basis (directly or indirectly) for authorization • Common Naming • Single distribution for all PMAs • Concerns and ‘incident’ handling • Guaranteed point of contact, to raise issues and concerns • Requirement for documentation of processes • PMA-disclosed, detailed policy and practice statement • Open to auditing by federation peers

19. Guidelines: secured X.509 CAs • Aimed at long-lived identity assertions • Identity vetting procedures • Based on (national) photo ID’s • Face-to-face verification of applicants via a network of Registration Authorities or ‘Trusted’ Registrars • Periodic renewal (once every year) • Secured operation • off-line signing key or HSM-backed on-line secured systems (140.2-3+) • Response to incidents • Timely revocation of compromised certificates • CRL issuance required (downloaded up to 400 times/minute!) • Last version: 4.2, synchronised with Federation Document • The Annotated Minimum Requirements are on the Wiki • Continues to evolve

20. Guidelines: short-lived credential service • Issue short-lived credentialsbased on another authentication system • e.g. Kerberos CA based, or existing (federated) administration • on-line issuing (with 140.2 level 2+ HSM or equivalent) • Based on crypto-data held by the applicant • Same EE cert format, but no new user-held secrets • Can act like a ‘proxy’ (RFC3820), and has similar risks • The applicant can (and will) use it like a proxy • Risk of EE key exposure is mitigated by its shorter life time • Same common guidelines apply! • reliable identity vetting to ensure uniqueness over CA life time

21. Specifics of a SLCS • Sufficient information must be recorded and archived such that the association of the entity and the subject DN can be confirmed at a later date. • Qualifying IdMs must suspend or revoke authorization to use the service if the traceability to the person is lost. • The CP/CPS must describe: • How the identity (DN) assigned in the certificate is unique within the namespace of the issuer. • How it attests to the validity of the identity. • How the identity (DN) assigned in the certificate will never be re-issued to another end-entity during the entire lifetime of the CA. • How it provides DN accountability, showing how they can verify enough identity information to trace back to the physical person for at least one year from the date of certification, and in keeping with audit retention requirements. • In the event that documented traceability is lost, the DN must never be reissued.

22. MICS vs SLCS • MICS is essentially a Classic CA, but with the identity vetting time-shifted & off-loaded to federation or IdM… which makes it look an awful lot like SLCS! But then: • The life time of the cert can be 13 months • To off-set this risk: • The requirements on IdM access and -use are stronger • Extra verification data is requested at issuance time to protect against weak or re-used IdM passwords • Active revocation support required (in SLCS: only re-active CRLs required)

23. New CAs: the Accreditation Process Accreditation Guidelines for EUGridPMA Basic elements: • Codification of procedures in a CP(S) for each CA • de facto lots of copy/paste, except for vetting and practice sections • Peer-review process for evaluation • comments welcomed from all PMA members • two assigned referees • In-person appearance during a review meeting • Accreditation after remaining issues are addressed (by e-mail) Discussions are the most important, as many details are eithernot codified, and the PMA will assess a new CA on merit, not merely a piece of canonical text • Periodic re-appearance and peer assessment of self-audits

24. Common Naming: the Distribution • Periodic, (monthly, max. biweekly) distribution of all trust anchors • Common for the entire IGTF • Includes all trust anchors for all profilesclassic, SLCS, experimental*, … but no ‘overarching’ bundle • Does not distinguished between accrediting PMAs • Wide variety of formats • RedHat Package Management (RPM) systemincluding a ‘meta’ package with dependencies per profile • ‘tar’ archives per CA, ordered per profile • Installation bundle suitable for ‘./configure && make install’ • Distributed update through chairs and registrars

25. Access to the Distribution Repository • Web site https://dist.eugridpma.info/distribution/ • Mirrored by PMAs • Web site with SCS cert • PGP singed data • Validation of contentvia TACAR • RPs (and the IGTF) willmonitor your CA/CRL!

26. The Effect of being the IGTF Distribution • Default installation by all users and relying parties in • EGEE, DEISA, SEE-GRID, TeraGrid, Open Science Grid, EELA, PRAGMA, APGrid, NAREGI, wLCG, … • All users of the VDT distribution • Virtually all European national e-Science programmes/NGIs • And likely more, but in a PKI you don’t see all relying parties (and I still get surprised at times …) • A lot of CRL downloads (indicating RPs) • From over 14000 distinct IP addresses (from which at least 300 web caches proxying for even more nodes) • 88452 downloads per day per CRL

27. Maintaining relationship with a PMA • Periodic plenary meetings (EUGridPMA: 3 per year) • Attendance expected, and required at least once per year • Expect contribution to the PMA operations, by helping out with peer reviews and assessments • Meetings rotate through Europe (giving possibility for on-site audits of the hosting CA!) • Evolution of the profiles (they are not cast in stone!) • New policy and technical development discussions(e.g. 1SCPs, Robots, CSIRT-ops, AA Operations, Cred. Repos, CRL caching or OCSP, …) • IGTF Plenary Meetings during OGF workshops (3/yr)

28. APGridPMA http://www.apgridpma.org/EUGridPMA http://www.eugridpma.org/TAGPMA http://www.tagpma.org/IGTF http://www.igtf.net/APGridPMA http://www.apgridpma.org/EUGridPMA http://www.eugridpma.org/TAGPMA http://www.tagpma.org/IGTF http://www.igtf.net/