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

Dept-1

Institution

Dept-1Dept-1

SubCA

CA

SubCASubCA SubCA

CA

SubCASubCA SubCA

CA

SubCASubCA

USHER

17

Solving Silos of Trust

Dept-1

Institution

Dept-1Dept-1

SubCA

CA

SubCASubCA SubCA

CA

SubCASubCA SubCA

CA

SubCASubCA

USHER

HEBCA

FBCA

CAUDIT PKI

18

ProposedInter-federations

FBCA

CA-1CA-2

CA-n

Cross-cert

HEBCADartmouth

Wisconsin

Texas

Univ-N

UVA

USHER

DSTACES

Cross-certs

SAFECertiPath

NIH

CA-1

CA-2 CA-3

CA-4

HE JP

AusCertCAUDIT PKI

CA-1

CA-2 CA-3HE BR

Cross-certs

OtherBridges

IGTF

C-4

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