US Higher Education PKI (Scott Rea) Net@EDU February 2007

1. US Higher Education PKI(Scott Rea)Net@EDU February 2007

2. Protecting the Institution • Identity theft if the fastest growing crime in the US, Institutions of Higher Education are a prime target - 43% of this activity results from Campus compromises • There has been an exponential increase in the number of reported cases each year • UCLA just had the worst computer breach ever at a US university (800,000 people impacted) in December 2006 • Dartmouth too has already had a security breach (back in 2004) • Protecting sensitive data with passwords is no longer sufficient – Two Factor Authentication is recommended • “While debate continues on what type of technology is best suited to prevent identity theft, many experts believe that a combination of PKI infrastructure and two-factor authentication offers the greatest promise of protection” [Financial Services Technology, Preventing Identity Theft]

3. Authentication Factors • Three Factors of Authentication: • Something you know • e.g. password, secret, URI, graphic • Something you have • e.g. key, token, smartcard, badge • Something you are • e.g. fingerprint, iris scan, face scan, signature

4. Authentication Factors • Single Factor of Authentication is most common • Passwords (something you know) are the most common single factor • At least Two Factor Authentication is recommended for securing important assets • e.g. ATM card + PIN (have + know) • 2 x Single Factor Authentication ≠ Two Factor Authentication • e.g. Password + Graphic is NOT equivalent to Smartcard + PIN (although it may be better than a single instance of One Factor Authentication) • Without Two Factor Authentication, some secure communications may be vulnerable to disclosure • Especially in wireless networks

5. Password Authentication • General issues with Authentication using Password technology • Passwords easily shared with others (in violation of access policy) • Easily captured over a network if no encrypted channel used • Vulnerable to dictionary attacks even if encrypted channels are used • Weak passwords can be guessed or brute forced offline • Vulnerable to keyboard sniffing/logging attacks on public or compromised systems • Cannot provide non-repudiation since they generally require that the user be enrolled at the service provider, and so the service provider also knows the user's password • Vulnerable to Social Engineering attacks • Single factor of Authentication only

6. A Strong Solution to Password Vulnerabilities • Public Key Infrastructure (PKI) • PKI consists of a key pair – 1 public, stored in a certificate, 1 private, stored in a protected file or smartcard • Allows exchange of session secrets in a protected (encrypted) manner without disclosing private key • PKI lets users authenticate without giving their passwords away to the service that needs to authenticate them • Dartmouth’s own password-hunting experiences, written up in EDUCAUSE Quarterly, shows that users happily type their user ID and password into any reasonable-looking web site, because so many of them require it already. • PKI is a very effective measure against phishing

7. A Strong Solution to Password Vulnerabilities • Public Key Infrastructure (PKI) • PKI lets users directly authenticate across domains • Researchers can collaborate more easily • Students can easily access materials from other institutions providing broader educational opportunities • PKI allows decentralized handling of authorization • Students on a project can get access to a web site or some other resource because Prof Smith delegated it to them • PKI simplifies this process – no need for a centralized bureaucracy, lowers overheads associated with research • Private key is never sent across the wire so cannot be compromised by sniffing • Not vulnerable to dictionary attacks • Brute force is not practical for given key lengths • Facilitates encryption of sensitive data to protect it even if a data stream or source is captured by a malicious entity

8. A Strong Solution to Password Vulnerabilities • Public Key Infrastructure (PKI) • 1024-bit keys are better than 128 character passwords (they are not subject to a limited character input set) • This is far stronger than any password based authentication • As one researcher said recently “the Sun will burn out before we break these” Quote from Prof Smith: “In the long run: user authentication and authorization in the broader information infrastructure is a widely recognized grand challenge. The best bet will likely be some combination of PKI and user tokens.” • Failing to look ahead in our IT choices means failing in our research and educational mission.

9. Advantages of PKI • 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

10. PKI Applications • Potential Killer Apps for PKI in Higher Education • Secure/Private Email (S/MIME) • Paperless Office workflow (Digital Signatures) • Protection of sensitive data (EFS) • Strong SSO – VPN (IPSec), Wireless (EAP-TLS), & SSH authentication • Shibboleth/Federations • LionShare – P2P sharing application • GRID Computing Enabled for Federations • E-grants facilitation

11. US Higher Education PKI Initiatives • USHER – US Higher Education Root • Common set of policies or expected practices for a community of CAs operating under and subordinate to a common root CA • Sponsored by Internet2 • HEBCA – Higher Education Bridge CA • Cross-certified CAs with mappings between their policies to determine equivalence • Sponsored by EDUCAUSE

12. USHER – Community Need • Much discussion about our community • A replacement for the old CREN CA • Needs for a PKi trust mechanism • Quick convergence on a set of anticipated applications • Two-factor Credentialing • Web authentication • Electronic mail (S/MIME) • VPN (IPSec), Wireless (EAP-TLS), & SSH authentication • LionShare – P2P sharing application • Grid Authentication (Globus) • Digital Signatures

13. USHER PKI Certification Authority: A hierarchical root USHER CA1 Campus A CA Campus C CA Campus B CA I Campus A subCA 1 Campus A subCA 2 User User User Device User Campus B CA II User User Device User

14. USHER Policy Authority • Jim Jokl, University of Virginia, Chair • Michael Gettes, Duke • Mark Luker, EDUCAUSE • Barry Ribbeck, Rice • Jeff Schiller, MIT • Renee Shuey, Penn State • David Wasley, independent Jan Gossaert

15. PA Defined Community Questions • What are the obstacles to PKI deployment in higher education? • What types of CAs do campuses operate? • What LoA do their practices support? • Formal documentation and audit? • What LoA should the overall system provide? • What type of agreement can a campus sign? • What are the potential liabilities to USHER, the PA, and the community?

16. Eventual Decision • Initially offer an USHER CA that minimizes campus-level requirements and leverages current campus best practices (PKi) • Later offer an USHER CA that enforces higher levels of assurance Dirck van Baburen, 1623

17. USHER PKi Implementation & LoA • The USHER CA itself is operated at a strong level of assurance • Solid practices for protecting & operating CA • Strong process to identify designated campus officers via secure out-of-band communications • Campus LoA: as determined by the campus • PKI-Lite CP/CPS based systems expected to be common • Likely some stronger LoA PKIs too • Not imposed in USHER’s CP or Agreement • How to create a strong community? • Solution: detail expectations in a set of Expected Practices

18. Cosimo Rosselli, 1481 • BECCAFUMI

19. USHER Expected Practices • When campuses join USHER, they are expected to adhere to the set of Expected Practices. If a campus cannot, expectation is either not to join or to leave. • Policy Authority does not audit or review campuses, but will take action if ever needed.

20. USHER Expected Practices • The campus will operate its PKI using processes that are at least as strong as the management of its central accounts for email, calendaring, etc. • The campus may issue certificates only to entities normally affiliated with that campus. • The campus will not issue certificates intended or likely to confuse the Subject’s identity.

21. USHER Expected Practices (cont.) • The campus will actively maintain all services that it asserts in its certificates, e.g., • CRLs • Policy and practices, if Policy OID is present • The campus is strongly encouraged to develop and publish a CP and CPS. PKI Lite is available as a starting point. • Delegation and multiple CAs are permissible • If it matches existing campus policy and the LoA of user identification is as strong as its other practices as mentioned in E.P.1.

22. USHER Expected Practices (cont.) • The campus will not issue certificates to third parties • Instead, sponsor the other entity for USHER membership • The campus CA infrastructure and private key will be as securely protected as other major campus authentication components. • In the event of key compromise, the campus CA will notify USHER as quickly as possible.

23. USHER Certificate Policies & Profiles • For the campus • PKI-Lite, developed by HEPKI-TAG, is likely a good solution. The campus decides. • For the USHER CA • Root and Campus certificate profiles are complete • CP…

24. CP is final! Georges de La Tour, 1625

25. USHER: Current Status • Key signing ceremony completed • A couple of authority certificates have been issued • Business components are approved and will leverage InCommon’s • Legal agreement • Registration Authority • Fees: • Initial I&A of trusted officers (700) • Annual Subscription (1000) • General availability: CPS, *very soon*

26. USHER: Some Q&A • Eligibility • US Higher Education Institutions • Other entities sponsored by a US Higher Education member & approved by USHER PA • Will USHER be preloaded in browsers? • Not by default • Significant ongoing audit costs • Perhaps additional operational costs • Commercial server certificates are no longer expensive • A new root is not hard for your users to install • http://pkidev.internet2.edu/rootcerts/ • “Make-Install” CA project

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. Federal Initiatives • eAuthentication • HSPD-12 • Related Initiatives

35. Provide electronic identity authentication services for online government applications • Manage the Federal Federation (new) – extends services to private sector credential providers and online services • Set standards for assertion-based authentication tools • Federal PKI provides PKI-based services for higher assurance credentials

36. HSPD-12 • A Presidential Mandate for Federal Agencies to issue medium assurance (or better) identity credentials for access to physical and logical government resources - inside-the-firewall contractors, too • Medium Hardware or High Assurance digital certificates on SmartCards • Fast-tracked for implementation starting 10/2006 • Led to new government standards for identity proofing and vetting (FIPS 201) and for PKI hardware tokens (NIST SP 800- 7x)

37. Related Federal Initiatives • HIPAA for electronic records management in health care • Other HHS-led and VA-led electronic healthcare initiatives (HL-7, etc.), some of which will require PKI implementations • DoD CAC access for various services • Navy & Marine extranet • Procurement • Grants & Research funding applications

38. Real Interoperability Initiatives • SAFE PKI Bridge and services – supporting digitally-signed electronic forms and document management • CertiPath – Federal Bridge cross-certification under way • inCommon – EAI interoperability initiative under way (Internet2 push; assertion-based technology, LOA 1 & 2) – demonstration projects with NSF • Financial Sector Bridge underway

39. Outstanding Issues in Inter-domain Interoperability • Liability for use of electronic identity credentials • Which “standards” to follow (exception: PKI IS interoperable) • Transitive trust, e.g., “if A trusts B and B trusts A and C, is there degradation of trust if A trusts C through B?” • Lots of niggling technical and policy disconnects

40. Technology Standards Implications for Academe and Medicine • US Government LOA, standardized risk analysis, standards for PIV cards and identity proofing and vetting are here and INEVITABLY will migrate everywhere • Pickup already noted in aerospace contractor space, homeland security

41. Security and Online Services Implications for Academe and Medicine • DHS first responders, DEA PKIs and CMS moves to online services and payments management will drive medical schools, hospitals and insurance chains to adopt Federal models for electronic identity authentication • Financial services firms under SEC regulation are already falling in line, both within and outside the eAuthentication federation participation • DEA issuing digital certs to pharmaceutical supply chain entities and plans to do so to service providers (MDs, PAs, NPs, etc.

42. 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

43. 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

44. Fed Resources • www.cio.gov/eauthentication • http://csrc.nist.gov/pki • www.cio.gov/ficc • www.smartcardalliance.org

45. 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

46. IGTF

47. 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.

48. 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

49. 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

50. 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)