Non-profit, member-based IT support for research & educational institutions

Scenario for Certificate Authority Infrastructure & Policy

Princeton University


May 24, 2000 (Version 3.1)
By Ron Hutchins

Institution: Princeton

Representative:

Daniel J. Oberst (oberst@princeton.edu)
Director, CIT/Enterprise Services
Princeton University
116 Prospect Avenue
Princeton, NJ 08540
(Tel) 609-258-6023
(Fax) 609-258-1004

Document History:

  • Initial Draft/Interview: Jan/Feb 2000
  • Update on February 08, 2000
  • Draft on 2/29/00
  • Updates by Dan Oberst on 3/13/00
  • Integrated on 3/23/00
  • Updates by Dan Oberst 3/28/00
  • Updates by Dan Oberst, Bill Sproule, & Donna Tatro 5/15/00
  • (3.1) Minor update on registration process by DanOberst/JVB on 5/24/00

First Uses of Digital Certificates on Campus

  • Student Authentication (leveraging a five year pilot program using Kerberos in place)
  • JSTOR Authentication
  • Confidential inter-office e-mail
  • Health center records for students
  • Confidential Faculty/Visa Processing correspondence
  • Financial information exchange between Library and Treasurer's Office

Getting Started: Processes for Initially Registering Students

In order to issue digital certificates, Princeton may eventually use Kerberos-based authentication, similar to that of MIT and Georgia Tech. Initially, LDAP authentication will be used. Testing has been done with the LDAP authentication (using a Princeton Net-ID/Password combination) built in with the Netscape Certificate Management System.

Students are issued a Net-ID and a password, each of which is algorithmically generated to ensure uniqueness. That Net-ID and password is mailed to the student's valid mailing address. The students are required to change that initial password the first time they sign in. If the students have difficulty with signing in that first time, or want to change their Net-ID, they are required to come to the center and validate themselves with a photo-ID.

Note: Kerberos, it was felt, was not the essential authenticating system. What is essential is to have a trusted system in place.

Policies and Procedures

Princeton's policies and procedures are still in the discussion phase. Currently certificates are in a directory, but this is not really being used.

Princeton will issue "dual key" certificates to each user (certificate pairs, a Digital Signing Certificate and a Key Encypherment Certificate), and will escrow the Encypherment Certificate to ensure that each person (or the university with due cause) has a back up in accessing information that has been encrypted.

Princeton will only support browser/mail clients that support and respect dual-key requests.

Infrastructure

Princeton is working on getting an LDAP directory in place as the first step in setting up their certificate authority.

For the Certificate Authority, they have the Netscape 4.1 Certificate Management Server up and running on a test server and have issued basic certificates which they have tested with Netscape Communicator 4.7 and 4.72 running Personal Security Manager and IE 5.00.2920. They have done the following:

  • Imported a CA chain into Netscape Communicator 4.7 and configured address books
  • Exported a certificate from IE and imported into Netscape Communicator 4.7
  • Configured and tested Messenger, Outlook 98 and Outlook 2000 for signing and encrypting messages
They have also started testing the process of certificate revocation. Using Netscape Personal Security Manager (PSM), they have generated dual key request and tested key encryption certificate escrow and recovery. (The PSM/Netscape seems to generate the proper request, whereas IE/Outlook does not. They've also published public keys into a test LDAP directory and conducted (during SendmailPro beta) one test of authentication via certificate (Auth-SMTP).

More Comments from Dan:

At this stage we still have much to learn and work through. We have filed one problem report with Netscape regarding loading email addresses into the certificate. Netscape admits this is a bug and we are waiting to hear back as to whether v. 4.2 (BETA) fixes this. We have not done anything with the CREN institutional certificate, as we first want to understand the basic functionality of the Netscape server software.

Another very big challenge is the clients. Netscape and Outlook behave very differently with respect to certificates. And (this is no surprise) Netscape (with the Personal Security Manager) seems to play better with the Netscape CMS. For any pilots, we will need to instruct the participants about which client to use and how. For our Pilot users we will use Netscape Communicator with the Personal Security Manager add-in.

Security

The Princeton certificate authority server is in a locked cage. There are three levels of security for the server. It is on a rack, inside a cage, and in a room accessed by using passwords. Escrow passwords are kept in a locked room in a fireproof box in a machine room.

Princeton will soon be moving its back-up directory service to a room across campus from current facilities; this room will also have a backup of issued certificates. Any transactions between the two rooms will be made on a dedicated fiberlink which will be an extension of our mail computing center network.

Problems/Outstanding Issues/Experimentation

Princeton did not issue certificates to be used for encryption until the issue of key escrow was resolved. Princeton was concerned about not having access to critical information if a password is forgotten, or if a faculty member moves on to another institution.

Princeton would like to be able to use certificates with Boise-Cascade. Other vendors with whom Princeton would like to use certificates include SmartForce, Gartner, and Encyclopedia Britannica. It has not been decided whether anonymous certificates will be issued. Discussions are ongoing as to what specific information will be included in the cert. Some feel it is an issue to be settled by the Library faculty; and some feel that each institution will be different in the information their certs include.

More Update From Early March 2000...from Dan Oberst

We have drafted a PKI Pilot Project Initiation Plan, which is being circulating, and reviewed with the PKI "Stakeholders." We've included people from the Library, Health Services, Office of General Counsel, Administrative Computing.

As we currently envision the work we're looking at getting a test-bed CA up and running, issuing certificates for staff to test and document, and then working with a couple small pilot rollouts over the next 4-6 months. The plan is to focus on targeted populations, and point solutions, rather than broad deployment initially. We hope to work out the various client issues (and hope the vendors resolve some of them!) and develop the back-end procedures we'll need to support a broad PKI.

Certs for Access to the JSTOR server

These certificates would be for faculty who need to get JSTOR access from an ISP or from another campus location where the princeton.edu domain wouldn't otherwise be available to validate them as users. We plan on working with the library to identify the individuals, and would issue these certificates on an individual as-needed basis. We also provide a proxy server for access to some resources that require the princeton.edu (today this is how we provide off-campus/ISP access to JSTOR) with id/pw authentication. We will be investigating using certificates for this local authentication as well.

Certs for Secure (Encrypted) email for Health Services

We would like to explore with Health Services the notion of issuing certificates to staff who would receive confidential student health information via email. Students would need to retrieve the staff certs in order to use them to encrypt email to send to the Health Services professional. We envision a handful of certificates here, just for the Health Services recipients, but would be able to begin to look at the issues of escrow and recovery. We are also looking at how we might provide web-based submission using standard web or PDF forms that we can encrypt. Discussions with the Health Services staff indicated a need for information to be sent back to students securely as well. Since this would involve issuing (and possibly escrowing) encryption certificates for all the students (or worse yet attempting to coordinate deploying them on the fly for use in sending out confidential information), other methods are being considered as well (secure documents, secure web pages, etc.).

Certs for Secure (Encrypted) email between Dean of Faculty and Visa Processing Office

We have met with both offices, which routinely require sensitive information to be sent via email between them. A demonstration of how to use Netscape and Netscape email to obtain certificates and use them to sign and encrypt email has led to a small pilot project which will involve a pair of users testing signed and encrypted email between the two offices. Certificates have been issued and testing is beginning shortly.

Certs for Secured (encrypted) email between Treasurer's Office and Library Financial unit

We have met with both offices, which routinely require confidential information exchange. This pilot will be launched shortly.

Certificates for administrative access to web services

We are looking at a pilot with a couple individuals or departments who need access to restricted web pages, using Certificates for authentication. We'll also begin investigation with Treasurer's Office and Boise to see if we can use Certificates (with CREN's CA hopefully recognized by them) for authentication of Princeton staff purchases on their web site. Today they need to manage ID/PWs for all our staff who get to their page (often different from their university ID/PW). Boise supports X.509 Certificates and we will be working with them on implementation issues.

CERTS for grade submission and other confidential email (e.g. salaries, etc.)

Today we use floppy-net or email enclosures. This would be a wider rollout that would provide for signed (by the end user, hence a broad number of certificates for signing) and encrypted (a smaller set of certificates, which would need to be escrowed, for the handful of individuals who receive these).

Issues to be addressed soon...

We hope to address, in the next couple months, some of the major issues (e.g. CERT loading-what data will go into the Certificate: Number, Type of certificate-one per user; separate certs for signing and for encryption, user interface/client issues, etc.)

People involved in the various projects...

Other folks involved or closely linked to the projects are Rosemarie Walsh, a consultant from Cogence, Inc., Lee Varian, Systems Architect at Princeton, Donna Tatro, Manager of the Collaboration Services Group and Project Manager for the PKI initiative at Princeton, and Bill Sproule, Senior Systems Programmer and Technical Lead on the Project.