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

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]

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

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

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

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

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

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.

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

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

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

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

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 MACE & HEPKI TAG User User Device User Campus B CA II User User Device User

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

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?

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

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

BECCAFUMI Cosimo Rosselli, 1481

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.

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.

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.

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.

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…

CP is final! Georges de La Tour, 1625

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*

USHER: Some Q&A “Make-Install” CA project 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

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

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

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

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

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

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

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

Federal Initiatives eAuthentication HSPD-12 Related Initiatives

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

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)

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

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

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

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

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.

A Simplified View of E-Auth Federation 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 Levels 3 & 4 CSPs Digital Certificates Digital Certificates X-Certification FBCA Federal Agency PKIs Other Gov PKIs Commercial PKIs Bridges

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

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

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

IGTF

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.

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

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

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)

APgridPMA Membership 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)

TAGPMA

TAGPMA Membership Accredited Relying Parties In Review 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 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

Proposed Inter-federations CA-2 CA-1 HE BR 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 Finance Sector CA-4 Other Bridges CA-1 CA-2 CA-3

E-Auth Level 4 E-Auth Level 3 E-Auth Level 2 E-Auth Level 1 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

Questions Scott Rea - Scott.Rea@dartmouth.edu