Higher Education PKIs (Scott Rea) Boulder CO November 15, 2007

1. Higher Education PKIs(Scott Rea) Boulder CO November 15, 2007

2. Overview • What are the drivers for PKI in Higher Education? • Stronger authentication to resources and services of an institution • Better protection of digital assets from disclosure, theft, tampering, and destruction • More efficient workflow in distributed environments • Greater ability to collaborate and reliably communicate with colleagues and peers • Greater access (and more efficient access) to external resources • Facilitation of funding opportunities • Compliance

3. Overview • Potential Killer Apps for PKI in Higher Education • S/MIME • Paperless Office workflow • EFS • Strong SSO • Shibboleth/Federations • GRID Computing Enabled for Federations • E-grants facilitation

4. LOA: Levels of Assurance • Not all CAs are created equal • Policies adhered to vary in detail and strength • Protection of private keys • Controls around private key operations • Separation of duties • Trustworthiness of Operators • Auditability • Authentication of end entities • Frequency of revocation updates

5. PKI Options • PKI Choices for Higher Education • Outsourced everything • Outsourced managed services, internal RAs • Internal operations: • Community root | Campus root • Community Policy | Campus Policy • CA software: commercial | vender | open source | RYO

6. Creating Silos of Trust Institution Dept-1 Dept-1 Dept-1 USHER CA CA CA SubCA SubCA SubCA SubCA SubCA SubCA SubCA SubCA SubCA

7. USHER : US Higher Education Root • Trusted Root for US Higher Education • Internet2 funded initiative • Only signs subordinate CA certificates • Bootstraps institutional PKIs by providing policy infrastructure and a CA • The USHER root CA and infrastructure created at Dartmouth College, now hosted with InCommon infrastructure at Internet2 • Facilitates inter-institutional trust between participating schools • Different levels of assurance supported

8. USHER Project • The USHER Project will create and maintain four new Certificate Authority (CA) systems for Internet2 • The four CA systems to be created are: • USHER Foundation CA (Now called CA1) • USHER Basic CA* • USHER Medium CA* • USHER High CA* *Not officially named yet • The USHERs will be used to provide institutions of higher education PKI trust anchors with a common policy • The USHER CAs may also be potentially cross-certified with the HEBCA to allow interoperation outside the USHER community

9. USHER Policy Authority • The USHER PA establishes policy for and oversees operation of the USHER initiatives. USHER PA activities include… • approve and certify the Certificate Policy (CP) and Certification Practices Statement (CPS) for the USHER • set policy for accepting applications for CA issuance under USHER CAs • represent the USHER in establishing cross-certification with other PKI bridges e.g. HEBCA • set policy governing operation of the USHER CAs • oversee the USHER Operational Authority • keep the USHER Membership informed of its decisions and activities.

10. USHER Project -Progress • Operational Authority (OA) contractor engaged (Dartmouth PKI Lab) • MOA with commercial vendor for infrastructure hardware (Sun) • MOA with commercial vendor for CA software and licenses (RSA) • Policy Authority formed • Prototype USHER operational on the Prototype HEBCA infrastructure • Production USHER CP produced • Production USHER CPS produced • Production USHER Foundation CA created (2/23/06) and distributed • USHER Foundation being embedded in applications (e.g. Lionshare) • USHER Foundation run from InCommon infrastructure • Community contract documentation sufficiently baked • USHER Campus root available for current InCommon Members

11. Creating Silos of Trust Institution Dept-1 Dept-1 Dept-1 USHER CA CA CA SubCA SubCA SubCA SubCA SubCA SubCA SubCA SubCA SubCA

12. HEBCA : Higher Education Bridge Certificate Authority • Bridge Certificate Authority for US Higher Education • Modeled on FBCA • Provides cross-certification between the subscribing institution and the HEBCA root CA • Flexible policy implementations through the mapping process • The HEBCA root CA and infrastructure hosted at Dartmouth College • Facilitates inter-institutional trust between participating schools • Facilitates inter-federation trust between US Higher Education community and external entities

13. HEBCA • What is the value presented by this initiative? • HEBCA facilitates a trust fabric across all of US Higher Education so that credentials issued by participating institutions can be used (and trusted) globally e.g. signed and/or encrypted email, digitally signed documents (paperless office), etc can all be trusted inter-institutionally and not just intra-institutionally • Extensions to the Higher Education trust infrastructure into external federations is also possible and proof of concept work with the FBCA (via BCA cross-certification) has demonstrated this inter-federation trust extension • Single credential accepted globally • Potential for stronger authentication and possibly authorization of participants in grid based applications • Contributions provided to the Path Validation and Path Discovery development efforts

14. Solving Silos of Trust Institution FBCA Dept-1 Dept-1 Dept-1 HEBCA CAUDIT PKI USHER CA CA CA SubCA SubCA SubCA SubCA SubCA SubCA SubCA SubCA SubCA

15. HEBCA Project - Progress • What’s been done so far? • Operational Authority (OA) contractor engaged (Dartmouth PKI Lab) • MOA with commercial vendor for infrastructure hardware (Sun) • MOA with commercial vendor for CA software and licenses (RSA) • Policy Authority formed • Prototype HEBCA operational and cross-certified with the Prototype FBCA (new Prototype instantiated by HEBCA OA) • Prototype Registry of Directories (RoD) deployed at Dartmouth • Production HEBCA CP produced • Production HEBCA CPS produced • Preliminary Policy Mapping completed with FBCA • Test HEBCA CA deployed and cross-certified with the Prototype FBCA • Test HEBCA RoD deployed • Infrastructure has passed interoperability testing with FBCA

16. HEBCA Project - Progress • What’s been done so far? • Production HEBCA development phase complete • Issues Resolved • Discovery of a vulnerability in the protocol for indirect CRLs • Inexpensive AirGap • Citizenship requirements for Bridge-2-Bridge Interoperability • Majority of supporting documentation finalized • HEBCA Cross-Certification Criteria and Methodolgy • HEBCA Interoperability Guidelines • Draft Memorandum of Understanding • HEBCA Subscriber Agreement • HEBCA Certificate Profiles • HEBCA CRL Profiles • HEBCA Secure Personnel Selection Procedures • Business Continuity and Disaster Plans For HEBCA Operations • PKI Test Bed server instantiated • PKI Interoperability Pilot migrated • Reassessment of community needs • Audit process defined and Auditors engaged • Participation in industry working groups • Almost ready for audit and production operations

17. HEBCA Project – Next Steps • What are the next steps? • HEBCA to operate at multiple LOAs over its lifetime • Update of policy documents and procedures required to reflect the above • HEBCA to operate at Test LOA initially • Issue the limited production HEBCA Test Root • Purchase final items and bring the infrastructure online • Cross-certify limited community of interested early adopters and key federations • Validate the model and continue to develop tools for bridge aware applications

18. Challenges and Opportunities • Community applicability • If we build it they will come • Chicken & Egg profile for infrastructure and applications • An appropriate business plan • Consolidation and synergy • Are USHER & HEBCA competing initiatives? • Benefits of a common infrastructure • Alignment with policies of complimentary communities • Shibboleth / InCommon • Grids (TAGPMA)

19. Challenges and Opportunities • Open Tasks • Audit • Updated Business Plan • Mapping Grid Profiles • Classic PKI • SLCS • Promotion of PKI Test bed • Validation Authority service • Cross-certification with FBCA • Cross-certification with other HE PKI communities • CAUDIT PKI (AusCERT) • HE JP • HE BR

20. PKI - Public Key Infrastructure • Security is a chain; it's only as strong as the weakest link. The security of any system is based on many links and in a PKI they're not all cryptographic. People are involved • PKI requires co-ordination across the following 3 areas: • Technology (T) • Policy & Procedures (P) • Relationships & Liability (L)

21. LOA: Levels of Assurance • Not all IdPs are created equal • Policies adhered to vary in detail and strength (P) • Strength of private keys (T) • Protection of private keys (PL) • Controls around private key operations (TPL) • Separation of duties (PL) • Trustworthiness of Operators (L) • Auditability (TP) • Authentication of end entities (TPL) • Frequency of revocation updates (TP)

22. Assertions • Assertion based technology • Shibboleth uses SAML assertions • A range of authentication processes supported • Information about exact procedures possible but not required? • Cryptographic binding of public identity to private identity possible but not required • Generally short lived assertions issued • Revocation not well supported • PKI uses digital certificates • A range of authentication processes supported • Information about exact procedures is required • Cryptographic binding of public identity to private identity is required • Generally longer term assertions issued • Revocation required key component

23. A Simplified View of E-AuthFederation Architecture -Banks -Universities -Agency Apps -Etc. Levels 1 & 2 Online Apps & Services Levels 1 & 2 CSPs SAML Assertions Business Rules CAF SDT Levels 3 & 4 Online Apps & Services Digital Certificates Levels 3 & 4 CSPs Digital Certificates FBCA X-Certification Federal Agency PKIs Other Gov PKIs Commercial PKIs Bridges

24. LOA Mapping FPKI High (governments only) E-Auth Level 4 FPKI Medium/HW & Medium/HW-cbp E-Auth Level 3 FPKI Medium & Medium-cbp E-Auth Level 2 FPKI Basic E-Auth Level 1 FPKI Rudimentary; C4

25. PKI vs Shibboleth • Shibboleth and PKI are complimentary technologies • Shibboleth has the potential to be a PKI • Requires specific published policies & procedures (in the federation agreement? ARP?) • Must use cryptographic binding of identities • Potential to be a really good avenue for Delegated Path Discovery or Delegated Path Validation • May want to use Shibboleth as a stepping stone from current IdM to a PK underlined system • Evolutionary strengthening of IdM processes • Shibboleth growth shows better penetration into various communities than PKI

26. PKI vs Shibboleth • What are the drivers for PKI in Higher Education? • Stronger authentication to resources and services of an institution • Single Sign On within the enterprise environment • Better protection of digital assets from disclosure, theft, tampering, and destruction • More efficient workflow in distributed environments • Greater ability to collaborate and reliably communicate with colleagues and peers • Greater access (and more efficient access) to external resources • Facilitation of funding opportunities • Compliance

27. PKI vs Shibboleth • Potential Killer Apps for PKI in Higher Education • S/MIME • SSO • Paperless Office workflow • EFS • Shibboleth/Federations • GRID Computing Enabled for Federations • E-grants facilitation

28. PKI vs Shibboleth • When PKI is required • High value, high trust, high reliability transactions with end user accountability • Credentials can be leveraged for other activities besides authentication or SSO requiring end user accountability • Transactions requiring long term validity • Peer to peer transactions that want to avoid campus liabilities • Community demands it • Requirement for a particular VO • Widespread or global PKI in place

29. Bridge-Aware Applications

30. International Grid Trust Federation • IGTF founded in Oct, 2005 at GGF 15 • IGTF Purpose: • Manage authentication services for global computational grids via policy and procedures • IGTF goal: • harmonize and synchronize member PMAs policies to establish and maintain global trust relationships • IGTF members: • 3 regional Policy Management Authorities • EUgridPMA • APgridPMA • TAGPMA • 50+ CAs, 50,000+ credentials

31. IGTF

32. IGTF general Architecture • The member PMAs are responsible for accrediting authorities that issue identity assertions. • The IGTF maintains a set of authentication profiles (APs) that specify the policy and technical requirements for a class of identity assertions and assertion providers. • The management and continued evolution of an AP is assigned by the IGTF to a specific member PMA. • Proposed changes to an AP will be circulated by the chair of the PMA managing the AP to all chairs of the IGTF member PMAs. • Each of the PMAs will accredit credential-issuing authorities and document the accreditation policy and procedures. • Any changes to the policy and practices of a credential-issuing authority after accreditation will void the accreditation unless the changes have been approved by the accrediting PMA prior to their taking effect.

33. EUGridPMA members and applicants Green: EMEA countries with an Accredited Authority • 23 of 25 EU member states (all except LU, MT) • + AM, CH, HR, IL, IS, NO, PK, RU, TR Other Accredited Authorities: • DoEGrids (.us), GridCanada (.ca), CERN, SEE catch-all

34. EUgridPMA Membership • Under “Classic X.509 secured infrastructure” authorities • accredited: 38 (recent additions: CERN-IT/IS, SRCE) • active applicants: 4 (Serbia, Bulgaria, Romania, Morocco) • Under “SLCS” • accredited: 0 • active applicants: 1 (SWITCH-aai) • Under MICS draft • none yet of course, but actually CERN-IS would be a good match for MICS as well • Major relying parties • EGEE, DEISA, SEE-GRID, LCG, TERENA

35. Map of the APGrid PMA • General Membership • U. Hong Kong (China) • U. Hyderabad (India) • Osaka U. (Japan) • USM (Malaysia) • Ex-officio Membership • APAC (Australia) • CNIC/SDG, IHEP (China) • AIST, KEK, NAREGI (Japan) • KISTI (Korea) • NGO (Singapore) • ASGCC, NCHC (Taiwan) • NECTEC, ThaiGrid (Thailand) • PRAGMA/UCSD (USA)

36. 9 Accredited CAs In operation AIST (Japan) APAC (Australia) ASGCC (Taiwan) CNIC (China) IHEP (China) KEK (Japan) NAREGI (Japan) Will be in operation NCHC (Taiwan) NECTEC (Thailand) 1 CA under review NGO (Singapore) Will be re-accredited KISTI (Korea) Planning PRAGMA (USA) ThaiGrid (Thailand) General membership Osaka U. (Japan) U. Hong Kong (China) U. Hyderabad (India) USM (Malaysia) APgridPMA Membership

37. TAGPMA

38. Accredited Argentina UNLP Brazilian Grid CA CANARIE (Canada)* DOEGrids* EELA LA Catch all Grid CA ESnet/DOE Office Science* REUNA Chilean CA TACC – Root In Review FNAL Mexico UNAM NCSA – Classic/SLCS Purdue University TACC – Classic/SLCS Venezuela Virginia USHER Relying Parties Dartmouth/HEBCA EELA OSG SDSC SLAC TeraGrid TheGrid LCG *Accredited by EUgridPMA TAGPMA Membership

39. TAGPMA Bridge Working Group • Recognition that there are different LOAs • in the way some credential service providers operate • Required by different applications • More efficient ways of distributing Trust Anchors • Interoperation with other trust federations • Scott Rea is Chair, representatives from each regional PMA included

40. Proposed Inter-federations CA-2 CA-1 CA-2 CA-3 HE BR CA-1 AusCert CAUDIT PKI CA-n NIH HE JP FBCA Cross-cert Cross-certs C-4 DST ACES Texas Dartmouth HEBCA Cross-certs IGTF Wisconsin UVA Univ-N USHER CertiPath SAFE CA-4 Other Bridges CA-1 CA-2 CA-3

41. E-AUTH FPKI E-Auth Level 4 High HEBCA/USHER Medium Hardware CBP High E-Auth Level 3 Medium Software CBP Medium Basic Classic Strong Basic E-Auth Level 2 Rudimentary Rudimentary C-4 IGTF Classic Ca Foundation E-Auth Level 1 SLCS MICS

42. Summary • Shibboleth and PKI are complimentary technologies • With appropriate application of policies to create the I in PKI and the requirement of cryptographic binding of identities to cover the PK in PKI, then Shibboleth can become a campus PKI (in a sense) • Shibboleth may be a good stepping stone to a global PKI community (if it ever arrives) • Shib can be used for various functions within an existing PKI • Delivery of credentials • Validation of credentials • Global acceptance of a Shibboleth federation requires PKI • Levels Of Assurance are key • It is more in the policy & liability than in the technology

43. For More Information • HEBCA Website: http://webteam.educause.edu/hebca/ Scott Rea - Scott.Rea@dartmouth.edu