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

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

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

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

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)

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

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)

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

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

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

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

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

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

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

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

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

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

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 CA-4 Other Bridges CA-1 CA-2 CA-3

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

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

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