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

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