Scenario for Certificate Authority Infrastructure & Policy
Massachusetts Institute of Technology
April 30, 2000 (Version 3.1)
By Jeff Schiller
Institution: Massachusetts Institute of Technology
Representative:
Jeff Schiller (jis@mit.edu)
Massachusetts Institute of Technology
Cambridge, MA
(Tel) 617-253-0161
Document History
- Initial Interview of Jeff: Jan 2000
- Initial draft by Patty Gaul in Feb, 2000
- Editing by JVB during March
- Updated, Expanded, and Revised by Jeff Schiller April 30, 2000
First Uses of Digital Certificates on Campus
- Course registration
- Student elections
- Access to Web site courses
- Course feedback
- Staff & Faculty paper work (health care, tax withholding, etc.)
- External Purchasing (partners accept certificates)
Getting Started: Processes for Initially Registering Students
At MIT, students currently receive a registration package when they first arrive on campus. Included in the registration package is account information actually, an "Athena Account Coupon" that allows the student to set up a Kerberos account. This coupon contains a personalized "one time passphrase" which they use with our special Registration Applet in order to setup their Kerberos account. A Kerberos account includes an e-mail address, a home webpage and file storage space in our shared file system (AFS). Once the Kerberos account is set up, the name and password for the Kerberos account will allow for the generation of the digital certificates.
This process may change slightly in the future, as future students may receive the registration packet at his/her home, and be able to set up their Kerberos account and be issued a certificate before setting foot on campus for their first school term.
Although MIT issues certificates based on an existing Kerberos account for authentication, this isn't a necessity. However, a centralized naming scheme for staff, faculty, and students is critical on any campus before issuing digital certificates. Fortunately certificate naming structures can be quite flexible. For example the name for a person within a certificate may include their department affiliation. This is useful for situations where each department maintains its own name space.
In theory, each department or school within a university might have its own certificate authority-issuing service. In reality, however, the knowledge about how to manage and generate the issuance of certificates will not be within each department. So for now, it makes sense to have a centralized certificate authority issuing entity.
Policies and Procedures
On the issue of security, the biggest security issue is protecting the private key of an individual or institution, not the digital certificate. Because MIT's client Certificate authority is on-line, it is critically important that the server it resides on be managed responsibly with security as an important system management goal. In addition to system security, steps are taken to keep the key encrypted at all times so that even a compromise of the server may not result in the compromise of the key. MIT is looking into several hardware based solutions which would permit the key to be stored in a hardware token (like a smart card) available to the server, but not vulnerable to network based intrusions of the certificate server. One hardware solution is to use SafeKeyper box as the one being used by CREN. MIT is also investigating some more cost effective solutions as well.
The certificate that contains the public key can be stored anywhere. In fact, the certificate could be housed on various web servers. The definitive copy of CREN institutional certificates will be on the CREN/MIT repository.
Individual's private keys are stored in various ways depending on the software used to create them. In general web browser-generated keys are stored in browser dependent ways. Netscape stores private keys in its preferences directory which is on each person's machine. Internet Explorer stores them in the Windows registry. Netscape also supports smart cards for the storage of private keys, but MIT has not had any experience with this solution (yet).
Certificate Infrastructure:
MIT supports an Apache+SSL distribution for use of departments that wish to take advantage of MIT-issued certificates in departmental web-based services. We even have student-owned computers making use of MIT certificates for authentication.
MIT Registrar's office has also successfully made use of the Netscape Enterprise server and MIT certificates.
The on-line Certificate issuing server is based on the Apache+SSL+JServ webserver. The CA software itself is written in Java. It provides a web based interface that permits people, using their Kerberos credentials, to obtain a certificate.
The server for the certificate authority is stored inside a secure, locked, and alarmed space within a locked, alarmed room. Each person who has access to the room has an ID card, and there's a record of each person who enters the room, and at what time.
Problems/Outstanding Issues/Experimentation:
Anonymous certificates. The libraries in particular are interested in authentication without revealing the true identity of the person making a request. Said another way, the library is interested in authorization (i.e., is this person permitted to do what they are attempting to do) without them having to reveal their name. This is particularly of concern when people are making use of third party information services. This is an area that several organizations are looking into including MIT.
Certificates are not kiosk-friendly. When a student, for example, logs on to a terminal at a computer center, the browser wants the certificate to be launched on it, rather than being launched temporarily.
Deployment/Projects
MIT is still making use of its own root CA, but plans are being put in place to fully support the CREN Root so that servers at MIT which today accept MIT issued certificates can accept certificates from other institutions (as appropriate) as well.
|
