The PKI Lab at Dartmouth Presentation for Mellon Retreat February 9, 2004

2 Dartmouth PKI Lab Project Overview and Status

3 Dartmouth PKI Lab R&D to make PKI a practical component of campus networks Multi-campus collaboration sponsored by the Mellon Foundation Dual objectives: –Deploy existing PKI technology to improve network applications (both at Dartmouth and elsewhere). –Improve the current state of the art. Identify security issues in current products. Develop solutions to the problems.

4 Production PKI Applications at Dartmouth Dartmouth certificate authority –Over 600 end user certificates issued, 435 of them to students Authentication for: –Library Electronic Journals (including OVID) –Banner Student Information System –Tuck School of Business Portal –VPN Concentrator S/MIME (few users)

5 Second Wave of PKI Deployment at Dartmouth Actively developing: Authentication for: –Blackboard Course Management System –Software downloads Hardware tokens –Required for VPN access to secured subnets Higher assurance certificates (picture ID check) We plan to reach all Dartmouth users with PKI through continued deployment of applications and increasing incentives and requirement for its use

6 Investigation and Research Wireless authentication –802.1x authentication EAP-TLS (PKI) on Win and Mac –WEP encryption on Win with proper drivers –WPA encryption with latest wireless cards and firmware –multiple SSID access point for transition Greenpass: pilot of SDSI/SPKI authorization certificates for delegation of authentication credentials for wireless guest access –Now supported by Cisco and (we hope) by Intel

7 “Open Source CA in a Box” Provide a hardened open source CA bundle suitable for trial and (initially) simple deployment. Selecting an open source CA –OpenCA –Papyrus –pyCA Enforcer TPM-hardened Linux (available now) –Turns controversial TCPA technology “to the light” to secure Linux boot process and provide much enhanced run-time protection against hackers –Useful for any Linux server application (e.g. Apache, LDAP, mail, LionShare or Westwood “ultra peer”) –slashdot.org/article.pl?sid=03/09/10/ slashdot.org/article.pl?sid=03/09/10/ Packaging for easy installation (summer) Carefully chosen enhancements to the open source CA –Added features –Enhanced private key protection We welcome feedback on requirements, contributions, testing, etc!

8 Outreach Many presentations, papers – Planning a PKI Deployment Summit Working with schools deploying PKI –PKI’s inexpensive 2-factor authentication proving an attractive proposition Deployment partners: –University of Wisconsin –University of Minnesota –University of Texas –Others getting started (USC, Yale) March/April EDUCAUSE Review “New Horizons” article Outreach web:

9 Dartmouth PKI Lab Interrelation With Other Projects: “Off the shelf” PKI for projects with Web and non- Web client/server applications Specific P2P proposal for LionShare and Westwood

10 PKI and Other Mellon Projects (Overview) The PKI Lab helps provide PKI-based security to others in higher education. We can help enable appropriate integration and use of PKI in other Mellon projects. –Vision, ideas –Consultation, deployment examples and assistance –Vulnerability analysis –Design new applications of PKI –Possibly collaborate developing infrastructure code

11 PKI and Other Mellon Projects (Authentication) Each of the other projects require user authentication (at least to some degree) PKI provides a superior method for authentication to all of them: –Avoids pitfalls of username/password –Improved security with two-factor authentication, choice of key length, strong encryption –Interoperates with a host of commercial applications –Inter-institutional authentication

12 PKI and Other Mellon Projects (Digital Signatures) Beyond authentication for access, many of the other projects may require digital signatures: –Chandler/Westwood supports with S/MIME signatures for interoperability with other systems –LionShare requires signing data before posting in order to provide trace-ability of who posted it –SAKAI user posting to a course discussion list via standard S/MIME signed instead of having to log into the application every time

13 PKI and the Rest (Encryption) P2P applications can form a “network” of peers, forwarding queries through intermediary peers in the mesh (for example, gnutella does this). In some cases, peers want to forward data through the mesh (firewalls or address translation may prohibit a direct connection). BUT do we trust the intermediary peers with the data in the clear? PKI can encrypt this data so only the intended recipient can decrypt it. Now it’s secure on the intermediaries. SSL/TLS and other transport encryption schemes can’t do this.

14 Proposal for Other Projects (Non-P2P Projects) uPortal, ePortfolio, AAM, SAKAI, JSTOR, ARTstor –Web applications support PKI client-side authentication –It’s already built into most web servers - probably just document how to do it (refer to PKI Lab documentation) VUE, LionShare, Westwood –Non-Web applications implement PKI client authentication

15 Westwood and LionShare: P2P With PKI Specific proposal for Chandler and LionShare: PKI for P2P Authentication Without All the CA Hassles: A Proposal by the Dartmouth PKI Lab

16 LionShare and Westwood: P2P With PKI Detailed proposal at rit.mellon.org/twiki/bin/view/Main/PkiTwiki rit.mellon.org/twiki/bin/view/Main/PkiTwiki We propose that Westwood/Chandler and LionShare skip username/password authentication and implement certificates/Shibboleth based authentication right away.

17 Westwood and LionShare: P2P With PKI Both of these are P2P applications that need peer authentication. –Sharing data and services with some peers, but not all. –User wants to share calendar information with a spouse, but not the world. –Researchers share pre-publication project data with each other but not the entire school.

18 LionShare and Westwood: P2P With PKI If there is an institutional authentication service, then we can use Shibboleth to tie into whatever is available (LionShare plans to do this). Or an institutional PKI works too. How to handle the case where there is no cooperating institutional authority to manage authentication? –Collaborator at a different school. –Individual not associated with an institution. –Group of colleagues using Westwood/Chandler.

19 Westwood and LionShare: P2P With PKI Passwords don’t work well in the “no institutional infrastructure” case. –Everybody hates passwords. –This requires a potentially different username/password pair for each P2P pairing. –10 colleagues all sharing calendars with each other implies 100 username/password pairs. –Possibly automate managing all these passwords, but this is tricky and likely to be hard to use and/or easily hacked. What if each user could have at most one local and one institutional password?

20 LionShare and Westwood: P2P With PKI Certificates offer a way for each peer to have an identity that it can prove to other peers via public key encryption. Peer clients acquire these: –Certificates issued by peers –Temporary certificates via Shibboleth –Institutional or commercial Certification Authority issued certificates Certificates can carry actual identity information or can be anonymous. Same peer server code to validate and manage all types of certificates regardless of source.

21 Westwood and LionShare: P2P With PKI The Shibboleth/KCA and institutional CA certificates are standard solutions. Our proposed new concept is using self-signed certificates from client peers to authenticate to peers providing services. Challenge: How does the server peer know to trust the client peer’s certificate?

22 LionShare and Westwood: P2P With PKI Trusting self-signed client peer- issued certificates –There are reasonable ways to register these certificates for trust by another peer. –We can automate this with one easy dialog box. –PGP uses a similar model, but PKI is standards based.

23 Westwood and LionShare: P2P With PKI Advantages Mostly standard PKI – open source implementations available as starting point (NSS, OpenSSL) In P2P the “server” side only needs certificates to authenticate – no usernames and passwords Works with Shibboleth for federation and interoperability with legacy authentication servers Share implementation among multiple projects Solve all authentication scenarios without ever having to implement username/password

24 LionShare and Westwood: P2P With PKI Actions Westwood and LionShare collaborate with the PKI Lab on this Review and critique proposal (already started) Refine the proposed architecture for P2P authentication based on this concept Select open source crypto library (NSS?, OpenSSL?) Share underlying implementation Share GUI design and as much GUI implementation as possible Implement the proposed strategy as your authentication mechanism

25 For More Information Outreach web: Dartmouth PKI Lab PKI Lab information: Dartmouth user information, getting a certificate:

26 LionShare and Westwood: P2P With PKI More on trusting self-signed client peer-issued certificates –Register end user certificates for trust, not root certificates –Need to verify that it’s the right certificate before registering (thwart man in middle attack) –PKI allows for this - numerical “thumbprint” that users can manually verify via an out of band channel (phone call to compare on both sides, , IM, etc.) –Requires one manual step (verifying thumbprint) – can be as simple as a single dialog box in an otherwise automatic process