Deploying PKI for Higher Education (Scott Rea) Boulder CO November 15, 2007

1. Deploying PKI for Higher Education (Scott Rea)Boulder CO November 15, 2007

2. 10 Steps to PKI Deployment • Learn about PKI • Pick your applications • Evaluate applications • Plan, get buy-in from management, determine staffing/funding etc. • Decide outsource or in-house Certificate Authority • Implement CA • Implement applications • Educate • Deploy • Measure results, refine, implement more applications, and so on

3. Learn about PKI • Google PKI • PKI is a fairly complex topic, and getting an early overview of some of the theory and technologies behind it will serve you well • PKI-Page.org • USHER.Internet2.EDU • Play with the technology • Most people learn best while doing, so don’t study PKI too long before you jump in and start using it – get or make a certificate and start using it. • Get a book • There are a number of good books on PKI theory. Be sure to sample several before you choose one. Then read the introductory section and skim other sections of interest. You can refer back to this book as needed when you really need the details. • Attend Conferences and/or Training • Look for conferences containing PKI content with relevent subject matter • Join PKI Community User or Working Groups • HEPKI-TAG • NET@EDU IDM

4. Pick your applications • To be a success, PKI must provide REAL value to REAL users • Focus on the applications that PKI can support and enable • Which applications at your campus will provide strong value and return on investment • Here’s a list as a starting point: • Secure Wireless • Strong Authentication to Web Applications • SSO or RSO • S/MIME – secure and private communications • VPN authentication • Digital Signing of documents • EFS – encrypted file systems for protection of data on mobile devices • Secure Instant Messaging • Server Identification

5. Evaluate applications • No substitute for real world experience to accurately evaluate the value, usability, cost to deploy, robustness, etc of your target application(s) • spend some time configuring and running applications with PKI, • conducting proofs of concept and pilot projects, • comparing alternatives internally and against other campus’ experiences, • exercise potential PKI applications on your campus • Acquire and install application • Acquire test certificates • Configure and test application

6. Plan, get buy-in from management, determine staffing/funding etc • PKI is best approached by an institution as a long-term investment in IT middleware • Short term ROI is not a strength of PKI • The following steps are critical: • Educate management (risks & benefits) • PKI can not be implemented in a vacuum - management support is critical • Establishing an institution-wide PKI is like making an institution-wide directory - it takes careful planning, coordination of multiple constituencies and service organizations, good design, significant resources, and persistence. • Be sure your management understands not only the costs and requirements of PKI but also the benefits in the form of extra capabilities for users, avoidance of costly security incidents, and long-term efficiency gains for both IT staff and the entire user population. • Pay attention to policies • PKI is not just technology - the policies and procedures you establish for issuing certificates are equally important • Plan and adopt or document a Certificate Policy & Certification Practices Statement • Some decisions may have legal ramifications, so consulting your legal department may be required • Before you object that one would be crazy to implement PKI if it involves lawyers, consider the fact that lawyers will definitely be involved if you have a HIPAA violation due to stray email or if you have a security incident where a password database was stolen and some unknown number of social security numbers may have been leaked. • Use good project management • As with any non-trivial IT project, planning and organization are essential • Balance is also required - be agile enough to adapt as you learn more about requirements and as new opportunities arise

7. Decide outsource or in-house Certificate Authority • PKI Choices for Higher Education • Outsourced everything • Outsourced managed services, internal RAs • Internal operations: • Community root | Campus root • Community Policy | Campus Policy • CA software: commercial | vender | open source | RYO

8. Decide outsource or in-house Certificate Authority • Commercial companies offer out-sourced CA services. • For a price, they will handle all of the logistics of issuing and managing certificates plus a portion of the Registration Authority responsibilities. • Outsourcing has the benefit that most commercial vendors have their root certificates installed in the common browser trusted root stores. This eliminates the need to distribute self-signed trusted root certificates for validation by user applications of in-house CA issued certificates. • Commercial CA services tend to have pre-established CA and RA processes and policies which can save a school from having to establish their own. On the other hand, this can be a problem and/or incur extra expense if the pre-established processes and policies don’t match the school’s needs. • Institutions wishing to operate their own CA service in-house have multiple possible paths. • One dimension of choice is where they get the CA software. Both commercial packages and open source implementations are available. Or they can start with an open source crypto library and implement their own CA (OpenSSL is usually the choice in this case). • Another dimension of choice is whether the CA root certificate is self-signed or signed by a commercial or other inter-institutional CA (such as USHER). • Running an in-house CA avoids the outsourcing charges, but incurs the overhead of setting up and operating the CA and possibly also incurs the cost of the CA software and maybe hardware to store the CAs private key securely.

9. Implement CA • This task will vary widely depending on the CA strategy – • If an outsourced CA services or license of commercial CA software is chosen, then the vendor may provide extensive assistance (for a price) • Some open source CAs come with documentation about how to set up a CA, but you’re more on your own with these unless there is a well established community. • Define your certificate policy (CP), profile(s) and certification practices statement (CPS) • See RFC 3647 for details about CP and CPS. • See RFC 3280 for details about certificate profile(s) • An excellent starting point for these documents is the PKI Lite information produced by the Higher Education PKI Technical Advisory Group (HEPKI-TAG) group • Another is the FPKI C4 documentation • CA Key Generation ceremony

10. Implement CA • 3647 – items to consider • What processes will be used in identifying users, before giving them a certificate • Allowable identifiers • In-person, trusted agent, database • LOA • Certificate Revocation • How? • Under what circumstances? • Frequency of publishing revocation data or operation of validation services • Protection of the CA's private key • Online or Offline • Strength of HSM • Multi-party control for CA operations • Physical protections • Generation and management of the subject's private key • Software or Hardware • Subscriber Agreement • Key sizes • Validity periods • Conformance with the certificate profile • Allowable uses for certificates issued under the CP • General advice about the content of the CPS, and a requirement that the certificate's CPSuri extension contain a URI pointing to the CPS.

11. Implement applications • Target select user group • Educate select user group on operation of PKI enabled application • Issue production certificates to select user group • Allow parallel running of legacy services with PKI-enabled application • Obtain feedback from select user group, update education material • A communications plan is a critical part of any roll out • Plan staged roll out to full application community

12. Educate • Education is a critical part of any PKI deployment • Create a communication plan • Groups to consider • Management • Get management on board beforehand to facilitate calming of the waters incase of backlash from users who don’t appreciate the finer points of the tradeoffs between security and convenience • The costs and prioritization issues of deploying PKI may generate pushback from system administrators and others in IT staff • System administrators and developers • These are the folks who will actually implement and maintain PKI • They need a detailed working knowledge of the technical side of PKI • They should learn about PKI in general but may not need in-depth knowledge of the cryptography behind PKI (the toolkits should obfuscate that) • Support staff • Support staff need an introduction to PKI and hands-on experience using it the way end users will use it. • They should meet the developers and administrators and know who to contact when users get stuck. • Dartmouth found that a 1 hour hands-on training session is typically enough to get the support staff up to speed • Users • Don’t try to educate users about the technical details of PKI - focus only on the essentials they need to know in order to get going and on a few safe computing practices so they will manage their credentials responsibly. • Self-help files are often sufficient • A user may not even know they are using PKI in a successful PKI deployment

13. Deploy • Phased approach is often best • Look for opportunities to run PKI based services in parallel with existing non-PKI services • But have a line in the sand • A robust PKI will scale well to meet the demands of the community • Tell the success stories

14. Measure results, refine, implement more applications • Maintaining applications is an on-going process • There is always room for refinement • Don’t try to solve all problems at once with your initial deployment. • Pick an achievable starting point and add to it incrementally, building on what works well and fixing what doesn’t