1 / 21

PKI in US Higher Education (Scott Rea) Fed/Ed June 2008

PKI in US Higher Education (Scott Rea) Fed/Ed June 2008. Agenda. PKI at Dartmouth New CA Platform Secure Wireless Infrastructure Digital Signatures Larger community PKI interactions USHER HEBCA TAGPMA. Dartmouth PKI - the Details.

parley
Download Presentation

PKI in US Higher Education (Scott Rea) Fed/Ed June 2008

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. PKI in US Higher Education(Scott Rea)Fed/Ed June 2008

  2. Agenda • PKI at Dartmouth • New CA Platform • Secure Wireless Infrastructure • Digital Signatures • Larger community PKI interactions • USHER • HEBCA • TAGPMA

  3. Dartmouth PKI - the Details • Dartmouth started researching PKI including pilot implementations in 2000 • CA products originally investigated • Entrust • RSA • Netscape Enterprise Service • Microsoft • OpenCA • Successfully demonstrated a range of services: • S/MIME email • Smartcard logon • Higher assurance authentication • Server/service authentication • Document digital signatures • Code signing • Data/file/drive encryption • Created an on-going outreach program that has been very successful

  4. Dartmouth PKI - the Details • Dartmouth started production PKI in 2003 • CA setup • Created CP/CPS with minimal policy • Netscape Enterprise Server (NES) Certificate Management System (became iPlanet became SunOne became Sun One, given to Red Hat) • Generated self-signed root + OCSP authorities • Keys in FIPS 140 level 3 HSM – Luna CA3 (was Chrysalis, became Rainbow, became SafeNet) • Solaris 8 – hardened OS • Open to public but firewalled for only HTTPS connections • CA transition required due to lack of platform support • Sun One CMS end-of-life 30 June 2006 • Ran at risk until future PKI directions were finalized and implemented

  5. Dartmouth PKI - the Details • CA transition • Determine PKI future directions • Evaluate possible replacement CA platforms • Build or Buy? • If build: commercial or opensource or roll-your-own • Determine evaluation framework • Cost over 3 years for 15,000 active credentials • Hardware, hosting, operations, licensing, support, local expertise • Cater for death, re-birth, or transition of existing CA • Smooth transition for 12,500 active credentials • Cater for desired future services (e.g. wireless authentication)

  6. Dartmouth PKI - the Details • CA transition • Process began in May 2006 • Decision from management to run at risk with existing platform for 12 months • Plan to be in production by 1 April 2007 to give us 3 months to transition existing users and well in time to handle freshman intake in mid-September • Run old infrastructure in parallel until end of September 2007 to mitigate any unforeseen issues • Platforms evaluated: • Outsource Managed Services (BUY) • Verisign • CyberTrust (now Verizon Business Solutions) • Identrus (previously DST, now IdenTrust) • GeoTrust • Inhouse Commercial Platform (BUILD-a) • Microsoft CA • RSA • Inhouse Opensource Platform (BUILD-b) • OpenCA • EJBCA • Inhouse Roll-your-own (BUILD-c) • CAPSO • OpenSSL

  7. Dartmouth PKI - the Details • CA transition • Outsource Managed Services (BUY) • Quickly discounted as too expensive ($135K-$490K) • Inhouse Commercial Platform (BUILD-a) • Microsoft CA – right price, but aversion to platform • RSA – too expensive • Inhouse Opensource Platform (BUILD-b) • OpenCA – too difficult to manage (Started working on OpenCA-NG) • EJBCA – not enough support • Inhouse Roll-your-own (BUILD-c) • CAPSO – negotiated free-to-higher-ed-and-research agreement • OpenSSL – too much work • CAPSO chosen as basis from which to roll-our-own CA • JCE based CA • Supports our particular HSM setup • Developed at University of Graz in Austria • Local expertise with base cryptographic modules and platform • Support available from Graz • Utilized for production in other places (e.g. Austrian Govt, UGraz) • Run on preferred enterprise OS platform – Red Hat (RHEL)

  8. Dartmouth PKI - the Details • CA transition • Decision made / management buy off by November 2006 • Resource constraints meant February 2007 was official build process start date • Additional functionality requested to support secured wireless after project started • Issues delayed production start until mid-August 2007, primarily to be ready for wireless lock down, transition of credentials from old system was done post this operation • More modification of base code than anticipated in order to integrate with Dartmouth Identity Management systems • Single resource doing development • Support from Graz was sporadic and limited • Their 1 resource was doing military service • Existing HSM not really supported on RHEL • Choice of non-current Solaris or non-preferred Microsoft • Decision to migrate to newer netHSM • Testing of new functionality with certs required CA changes to support the corresponding certificate profiles required • Vista requirements added – new API from MS not well documented • How to handle CRLs from 2 concurrent systems • Successful launch of new CA platform on August 2007 • Handled issuance of 1200 high assurance eToken based credentials for incoming freshman class • Transition of existing 12,300 active credentials successfully • New CA platform issued more credentials in first 6 months than old CA has issued in 5 years

  9. Dartmouth PKI - the Details • CA transition Report Card • 26,500+ active certificates • 3,500 certs issued on eTokens • 100 TLS certs for internal facing services • 23,000+ software certs (mostly for wireless authentication) • Outstanding issues • Certificate publishing • Expanded certificate profile support • LRA integration • Self-service Revocation

  10. Dartmouth PKI - the Details • Credential Issuance Process: • Two levels of assurance on end user credentials • Software certificate • Self-service using authentication to our central WebAuth system • Browser based issuance process • IE (W2K, XP & Vista) • FireFox, Mozilla on Win, OSX, *nix • Safari • eToken certificates • Face-2-face with local registration agent (LRA) • Requires LRA attestation of credentials checked • 2 forms of ID required (1 photo ID) • Still have to authenticate to central directory • Keys generated onboard on the token • Browser based issuance process • IE (W2K, XP & Vista) • FireFox – under supervision on Win, OSX, *nix • Single high level on the SSL/TLS servers • Manual process only after verification of admin identity and service authorization

  11. Dartmouth PKI - the Details • Current Production services: • S/MIME email • Smartcard logon • Higher assurance authentication – including 2-factor authentication using eTokens (SSH, VPN, EAP-TLS) • Server authentication (for non-public facing web services) • Limited EFS use – but no “official” escrow services currently • Limited Document digital signatures • Planned Production services: • EFS with supported escrow • Document paperless workflow

  12. Wireless Security • CALEA motivated scrutiny of existing open wireless infrastructure • Decision to move to private networks • EAP-TLS for authentication • 6 months cross-over between legacy & new infrastructure SSIDs • Open SSIDs still as gateway to commercial ISP • Some research & documentation work was required to support configuration of supplicants

  13. Wireless Security • Smooth successful roll out of new wireless infrastructure • 1000’s of certificates issued with little negative impact • Integrated with campus IdM • Required some adjustments to CA • Vista changes • Profile changes • Some adjustments for clients • Apple OSX Leopard issues • Registered SSID for devices that do not support EAP-TLS

  14. Digital Signatures • Due to wireless roll out - everyone has a credential now • How do we speed up slow paper-based workflow processes on campus? • Who is interested? • Registrar • Computer Science • Financial Services • Investigating use of Adobe as basis for facilitating electronic signatures • Least invasive to existing processes

  15. Community PKI • Dartmouth engaged in many larger PKI communities • USHER • Created USHER CA at Dartmouth • Continued policy & administrative responsibilities • HEBCA • Created & still operates HEBCA • Limited (test only use) currently • TAGPMA • Original founding member • Continued policy & accreditation participation

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

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

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

  19. 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 • 100+ CAs, 100,000+ credentials

  20. PKI Resource Query Protocol • Protocol to allow discovery of services and attributes offered by a particular CA • Where to request certificate • Where to request revocation • What validation services are available • Where to find policy • Simple client-server based protocol • Peer-to-peer or Central hub deployment options • Experimental track IETF RFC

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

More Related