Download presentation
Presentation is loading. Please wait.
Published byRose Carter Modified over 9 years ago
1
US Higher Education PKI (Scott Rea) Net@EDU February 2007
2
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
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
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
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
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
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
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
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
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
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
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
13 USHER PKI Certification Authority: A hierarchical root USHER CA1 Campus A CA Campus C CA Campus B CA I User Campus A subCA 1 Device User Device Campus A subCA 2 User Campus B CA II User
14
14 USHER Policy Authority Jan Gossaert 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
15
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
16 Eventual Decision Dirck van Baburen, 1623 –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
17
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
18 Cosimo Rosselli, 1481 BECCAFUMI
19
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
20 USHER Expected Practices 1.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. 2.The campus may issue certificates only to entities normally affiliated with that campus. 3.The campus will not issue certificates intended or likely to confuse the Subject’s identity.
21
21 USHER Expected Practices (cont.) 4.The campus will actively maintain all services that it asserts in its certificates, e.g., –CRLs –Policy and practices, if Policy OID is present 5.The campus is strongly encouraged to develop and publish a CP and CPS. PKI Lite is available as a starting point. 6.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
22 USHER Expected Practices (cont.) 7.The campus will not issue certificates to third parties –Instead, sponsor the other entity for USHER membership 8.The campus CA infrastructure and private key will be as securely protected as other major campus authentication components. 9.In the event of key compromise, the campus CA will notify USHER as quickly as possible.
23
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
24 Georges de La Tour, 1625 –CP is final!
25
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
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
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
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
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
30 Solving Silos of Trust Dept-1 Institution Dept-1 SubCA CA SubCA CA SubCA CA SubCA USHER HEBCA FBCA CAUDIT PKI
31
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
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
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
34 eAuthentication HSPD-12 Related Initiatives Federal Initiatives
35
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
36 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) HSPD-12
37
37 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 Related Federal Initiatives
38
38 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 Real Interoperability Initiatives
39
39 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 Outstanding Issues in Inter- domain Interoperability
40
40 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 Technology Standards Implications for Academe and Medicine
41
41 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. Security and Online Services Implications for Academe and Medicine
42
42 Levels 1 & 2 CSPs Levels 3 & 4 CSPs -Banks -Universities -Agency Apps -Etc. Business Rules CAF Federal Agency PKIs Other Gov PKIs Commercial PKIs Bridges FBCA X-Certification SAML Assertions Digital Certificates Levels 1 & 2 Online Apps & Services Levels 3 & 4 Online Apps & Services SDT Digital Certificates A Simplified View of E-Auth Federation Architecture
43
43 E-Auth Level 1 E-Auth Level 2 E-Auth Level 3 E-Auth Level 4 FPKI Rudimentary; C4 FPKI Medium/HW & Medium/HW-cbp FPKI Basic FPKI Medium & Medium-cbp FPKI High (governments only)
44
44 www.cio.gov/eauthentication http://csrc.nist.gov/pki www.cio.gov/ficc www.smartcardalliance.org Fed Resources
45
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
46 IGTF
47
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
48 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 members and applicants
49
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
50 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) General Membership U. Hong Kong (China) U. Hyderabad (India) Osaka U. (Japan) USM (Malaysia) Map of the APGrid PMA
51
51 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)
52
52 TAGPMA
53
53 TAGPMA Membership 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
54
54 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
55
55 Proposed Inter-federations FBCA CA-1CA-2 CA-n Cross-cert HEBCA Dartmouth Wisconsin Texas Univ-N UVA USHER DST ACES Cross-certs SAFECertiPath NIH CA-1 CA-2CA-3 CA-4 HE JP AusCert CAUDIT PKI CA-1 CA-2 CA-3 HE BR Cross-certs Other Bridges IGTF C-4 Finance Sector
56
56 High Medium Hardware CBP Medium Software CBP Basic Rudimentary C-4 High Medium Basic Rudimentary Foundation Classic Ca SLCS MICS FPKI IGTF HEBCA/USHER Classic Strong E-Auth Level 1 E-Auth Level 2 E-Auth Level 3 E-Auth Level 4 E-AUTH
57
57 Questions Scott Rea - Scott.Rea@dartmouth.eduScott.Rea@dartmouth.edu
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.