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

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

3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 16 Creating Silos of Trust Dept-1 Institution Dept-1 SubCA CA SubCA CA SubCA CA SubCA USHER

17. 17 Solving Silos of Trust Dept-1 Institution Dept-1 SubCA CA SubCA CA SubCA CA SubCA USHER HEBCA FBCA CAUDIT PKI

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

19. 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. 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. 21 For More Information HEBCA Website: http://webteam.educause.edu/hebca/ Scott Rea - Scott.Rea@dartmouth.eduScott.Rea@dartmouth.edu