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

2. Agenda PKI at Dartmouth Larger community PKI interactions
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
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
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
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 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

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 -