2Work to Date
Section 1 of our proposal to the Mellon Foundation states four main goals. We sought to develop and deploy a PKI that:
-
"overcomes the limitations that hamper deployment of low-assurance PKI in academia",
-
"lays a foundation for developing innovative new approaches to address the security, privacy, usability, and scalability challenges that hamper the deployment of higher-assurance PKI",
-
"lays a foundation for exploring new directions in protection of intellectual property", and
-
"is easily transferable to other universities".
These goals motivated the team structure of the Lab in our first phase work. The deployment team handled goal 1, assembling a low-assurance production PKI from COTS tools and modifying legacy Dartmouth applications to interoperate with it (see section 2.1). The research/design team undertook goal 2, developing and prototyping architectures for higher-assurance PKI components, and doing vulnerability analyses of current components and tools (see section 2.2.1). Both teams shared goal 3; the development team ported legacy library applications to work with the low-assurance PKI, and the research/design teams worked on alternative authorization PKI/PMI for these applications. Both teams collaborated on goal 4 as well, producing a continuous stream of invited talks and published papers (see section 2.4.1) reporting our results.
Now as we enter into phase 2, we are ready to bring these efforts to fuller fruition. This fall, we anticipate rolling out the low-assurance PKI into a wider pilot, and integrating the more promising of the design/research tools into the production PKI. With the hire of a new staff member devoted to leading our outreach effort, we will now take these results to other universities.
2.1Deployment Team
The deployment team assembled Dartmouth’s initial campus PKI installation during the summer of 2002 and used it for application conversion and testing projects during the fall. This work focused on installing a commercial Certificate Authority product as quickly as possible, so application development could proceed. This product appeared to be both economical and usable from the major computing environments. We selected Sun’s commercial iPlanet offering rather than an Open Source alternative based on our judgment that the Open Source alternative’s high labor requirements would be more costly than the low purchase price of iPlanet. In addition, the Sun product is FIPS-validated, a requirement for cross-certification with the Federal Bridge.
The deployment team developed during the fall and winter 2002 a second iteration of the PKI services with expanded security features and performance suitable for campus-wide use. This iteration of the design added protection for the Certificate Authority server by utilizing a hardware key module and a firewall since an online design was adopted. We enhanced the server’s reliability by incorporating a disk array and automated backup procedures. The infrastructure became available for production use in February 2003.
2.1.1Production PKI Installation
We selected the Sun/iPlanet PKI product as the certificate authority component for the Dartmouth PKI project. We started with the iPlanet Certificate Management System version 4.2 as the first instance of a PKI server. It was available for testing and development in June 2002. This proved to be a full-featured PKI with a Registration Authority, Certificate Authority and key escrow and recovery among other features. Source code is available for the entire user interface allowing easy customization of what the user sees. The product also includes excellent and easy-to-use documentation which is rare. The license fee was $1.25 per user but due to discounts for students and staff (fulltime faculty is the only category of users which pays full fare) the cost for about 25,000 users was less than $15,000. This cost was not borne by the Mellon grant.
In April 2003, Sun announced that it was planning to discontinue development of the iPlanet (by then renamed SunONE) Certificate Authority product. Support will continue to be available for three years, a very long time in this field. While this was disappointing news, the Sun product is meeting our current needs and we expect that it will continue to do so within the support timeframe. AOL continues to sell a similar Enterprise Server Certificate Manager product that originated in part from the same code base. The AOL product is a possible upgrade path and provides a similar environment for other institutions interested in duplicating these results.
For our PKI development system we used two inexpensive Sun workstations each running an instance of the iPlanet server software. These served well for initial exploration of the product and then for development and testing of configurations and later for local modifications to the user interface.
For the production PKI service we upgraded the server software to SunONE Certificate Server ver. 4.7 which, despite the name change, is a minor update of our previous iPlanet software. The upgraded software was installed on a server-class computer that had recently been displaced as the campus-wide calendar server. It is a Sun E250 with hot-swappable RAID-5 disks and large memory capacity. The E250 has an attached DLT tape drive for import/export of data, and it is backed up over the network.
The production server uses a Chrysalis Luna CA3 key module to create and hold the Certificate Authority’s private signing key. The Chrysalis key module is a peripheral device attached to the Sun E250 server by a private connection to a PCI card installed in the E250’s back plane. The Certificate Authority’s private key never leaves the Chrysalis unit. Any cryptographic operations that require use of the private key are done by shipping the data to be signed to the Chrysalis unit where the crypto operations are performed, and then the encrypted data goes back to the server. There is a provision to back up the Certificate Authority’s private key on removable media so that operation of the production server could be restored if the Chrysalis unit became inoperable. Two-factor authentication is required to access the encrypted private key on the removable media, so there is reasonable protection of the private key when it is removed from the Chrysalis unit. In future work, we are considering working with the research/design team to port open source CA software onto cheaper and more secure hardware from IBM.
A Cisco PIX 506E firewall protects the production Certificate Authority server. Since users access the Certificate Authority via the web, the firewall allows all http and https traffic to reach the CA server but any other incoming traffic is limited to specific protocols originating on specific computers at Dartmouth.
The deployment team documented the architecture and parameters of this installation and will share this documentation as part of our outreach program. The installation combines the RA and CA functions on one server. It uses 2048 bit CA keys with a 10 year expiration date. The installation is purposefully easy to replicate, modify, and operate elsewhere. We also gained invaluable experience about the many problems that can arise when creating a production CA, and will share this experience with others in our outreach program.
Local enrollment extensions
After examining the needs of our initial applications, we decided to employ a self-service online registration system for end users of the PKI. This relies on the institutional processes for adding and deleting student and staff accounts in the institutional LDAP directory. Since the web authentication systems we intended to replace with a PKI-based solution rely on the same directory, this is a feasible solution. This solution also does not require additional staff to service a registration process. The SunONE product supports online registration, but we needed to extend the SunONE code to deal with different directory objects. This provisional approach leaves the PKI only as secure as the password-based system it replaced. In Phase 2 work, we plan to explore more robust enrollment schemes.
The extensions developed for the SunONE product are likely to be useful for other institutions and are now available. For example, in the Dartmouth environment, we incorporated the fuzzy name matching functionality of the Dartmouth Name Directory to simplify local use and adoption of this new infrastructure.
Enrollment System
The Dartmouth CA uses a Web-based enrollment system to issue certificates over https. The most widely used of the two options for getting a client certificate is the DND Validation enrollment. This web page asks the user for a name and password to be validated against the campus LDAP directory. (At Dartmouth, the LDAP is colloquially known to end users as the Dartmouth Name Directory, or DND) We customized the enrollment code to select the recommended options automatically, for example 1024 bit keys. If the validation succeeds, the browser generates a key pair and stores the private Key, and the CA issues a client certificate.
The second option for getting a client certificate is manual enrollment. This page provides access to a variety of parameters possibly needed for special situations. Certificate requests issued here are manually reviewed and approved by the CA administrators. This page can handle requests for things like Web server certificates, or shorter key lengths and the like at the discretion of the approving administrator. It offers a variety of enrollment options, the most notable of which are Dual Key Escrow, Security Level, and anonymous or temporary enrollment.
Key escrow has been a concern of the support staff, since users losing their keys is to be expected. The dual key option LDAP validation to issue two certificates to the client and allows recovery of the encryption key. One key-pair makes up the authentication certificate, while the second creates an encryption certificate. The CMS uses a transport certificate to securely retrieve and store a copy of the private key of the encryption certificate. This key can then be recovered to the client in the event of a loss of the private key. Key recovery is covered by an M of N security policy set by the CA administrators. This method does not work with IE, but does work with Netscape and Mozilla. A lost signing key will be replaced.
Security level enrollment makes use of the Microsoft security level options in a certificate, allowing the user to specify that a password prompt should be given every time the certificate is used. (We note that use of this feature was developed due to interaction with the research/design team.)
Anonymous enrollment uses LDAP validation of a named user to create a certificate that merely identifies the subject as a Dartmouth College certificate holder. Temporary certificates are issued with a 4-hour validity period. These temporary certificates are meant to be used in situations where the client key store is relatively un-trusted or un-securable. As an example, a user might want to log in to a Dartmouth service from an Internet café. The temporary certificate reduces the risk of the user forgetting to delete the key after finishing with it. Any browser that can generate a key pair can use these options.
Dartmouth also uses its enrollment process to publish certificates for users in its LDAP directory. This allows users a way to exchange public keys with reduced vulnerability and inconvenience. Certificates are automatically removed from the directory when they are revoked or expired. Currently, these processes require administrator intervention or the private key used to create the certificate. We are researching a method to revoke and remove a certificate using the same level of authorization that was used to create it.
Mobility
The mobility of a private key has been raised as a principle user concern. Many people use multiple computers and/or applications, and kiosk systems are popular with students. The PKILAB has documented the procedures for exporting and importing keys between different computers or web browsers, and has investigated different options for personal key storage devices. We have identified several possible solutions, but so far none of them work on all major platforms. Some physical form factors such as ID cards are appealing.
We note that supporting mobility of users is one of the driving factors behind the research/design team’s TTP project (see Section 2.2.2).
2.1.2Academic Applications
The initial applications of the Dartmouth PKI provide personal authentication for web services. The deployment team collaborated with several service providers on campus to develop a number of web authentication applications. Access to Library resources via personal PKI certificates went into production in June. Authentication to Oracle web applications has been demonstrated on the test systems and our Administrative Computing Group is pursuing making this available for production use in August. This update will enable PKI authentication for the student information system and other staff administrative services (see section 3.2.2 for more phase 2 local deployment details).
Web Authentication Replacement
Around 1996, Dartmouth adopted and deployed Kerberos has an authentication mechanism for web based applications. This became a campus standard and is currently in wide use. The changing architecture of the Internet is however preventing its continued operation for an increasing number of users. Firewalls and Network Address Translation (NAT) cause problems for Kerberos users, and client-side X.509 PKI (e.g., client-side SSL) is providing a workable alternative solution. Instead of the old Kerberos KClient and Sidecar software, appropriate Web browsers with personal certificates from the Dartmouth PKI provide similar functionality. A PKI-based solution has the additional advantages of being usable on Microsoft, Apple and UNIX machines without additional software installations.
The PKI Lab team worked with the various application groups at Dartmouth to extend their applications to also support authentication using personal PKI certificates. Applications have been converted in the Library, Research Computing, Administrative Computing and the Tuck Business School. Details of specific applications are provided in the next section.
Because PKI certificates have other uses, the mobility and time scale issues are different than the Kerberos solution. This has led to the development of alternate certificate profiles to allow the use of PKI instead of Kerberos in the special cases of working on computers the user doesn’t own, library use by guests, and protecting the identity of database users. Temporary, guest, and anonymous certificates address these needs.
In conjunction with the deployment team’s work to utilize client-side SSL, the research/design team critically examined the effectiveness of this technique (see Section 2.2.1).
Web Authentication Examples Dartmouth Web Sites
The Dartmouth College development Web server can now use client certificates. Currently, the PKI Lab web site uses client certificate authentication to control access to the download area for software that is not available to the general public. Information on how to configure similar use for other Web sites is published on the PKI Lab Web site.
Library Systems
The Library currently makes extensive use of the KClient/Sidecar infrastructure for access control to any local or vendor supplied web based data resources that could be made compatible with it. It is also used to authenticate to the Library proxy server. Off-campus library users have been significantly affected by the KClient/Sidecar network issues. In response, the Library systems staff worked with the deployment team to augment their access control procedures to allow use of personal PKI certificates for authentication to these resources.
We added logic to library applications can to check for the presence of certain environment variables set by the web server to indicate that the SSL (https) connection is certificate authenticated. These variables also identify the user (or at least indicate that the user is anonymous) to the application.
Oracle/Banner Applications
Dartmouth’s Oracle IAS web servers were can now optionally request client side SSL connections which prompt the user for a personal certificate. A CUSSP authentication bottleneck already in place for KClient/Sidecar authentication now first checks for the SSL environment variables. If they are present, then the user was already authenticated with PKI and the authentication logic skips using Kerberos. The SSL environment variables provide the user’s identity as needed for authorization. TuckStreams, the business school’s intranet system, and Banner, the student records database are both example applications making use of this type of PKI authentication. Both allow access using a certificate without any modifications to the database application.
Secure Mail
Secure mail is one of the next major application areas of the campus PKI. We tested S/MIME features of currently available e-mail clients for interoperability with the SunONE PKI and each other. We wrote and published setup and usage tips. Currently, users are generally reluctant to switch e-mail clients to gain access to S/MIME features. As another possible solution we are developing add-in code to enable levels of compatibility with other, more popular, mail clients to foster the adoption of S/MIME mail, and we are exploring the possibility of an S/MIME plug-in to add this functionality to existing clients. The deployment team developed sample code using Open SSL for the signing, verification, encryption and decryption functions. We also developed sample code making using of the NSS library in order to use keys saved in the Netscape/Mozilla key store. A Key store component is an important consideration.
An additional technique we are investigating would make use of additional servers to provide add-on S/MIME capabilities. This “mail” server would, for example, check the signatures attached to incoming mail and add MIME parts to the message that report the status of the signature to the end user via a mail client that is not S/MIME-aware. The research/design team has been exploring this idea further, including incorporation with secure hardware (see section 2.2.2).
LDAP Integration
The PKI publishes certificates into the campus wide LDAP directory. This supports integration into the address book features of some mail clients, which will retrieve certificates needed to encrypt a message when the address list is specified.
S/MIME List Servers
While researching methods to add PKI support into a mailing list manager we discovered that an existing product, Sympa <http://www.sympa.org> already has the required functionality. Sympa has the ability to understand S/MIME signed and encrypted messages, and is extremely flexible in how it deals with signed messages. It can require a person posting to a list to have a valid digital signature. This would keep unexpected or unwanted (SPAM) messages from ever reaching the list. Requiring valid signatures will also keep spoofed messages (user A pretending to be user B) from reaching the list. Administrators can use signed messages to control the list server, eliminating any possibility for a user to spoof an admin account.
Sympa has the unique ability to receive a message encrypted to the list, and re-encrypt it for each recipient. Sympa takes advantage of client certificates in the web browser. When a user visits the list administration web page, they are automatically authenticated using their Client Certificate. This prevents any sort of password sniffing or cookie stealing attack.
A Sympa list server installation is available for production applications at Dartmouth, and we are working to inform potential users of its benefits. Switching mailing list software does require some reconfiguration and training however to gain access to S/MIME features.
Digital Signature Applications
Digital Signatures on campus forms and applications for external services are another primary application area. The PKI Lab participated in the NIH-HEBCA grant application pilot project. As a result, the Dartmouth PKI is cross-certified with the prototype HEBCA, and the campus LDAP directory links into the Bridge’s directory of directories.
We installed signing software from E-Lock and integrated it with the PKI. Two different staff members representing the principal investigator and campus grant officer filled out and then signed a sample Microsoft Word formatted grant application.
On campus, most blank forms are now saved as PDF formatted documents and distributed on a public file server. The deployment team is designing an electronic signature process to make use of these. This would replace the current practice of printing forms, filling them out by hand, and signing the paper copies. We have begun investigating the PKI compatibility of Acrobat software.
Other applications for digitally signed office documents of various types are apparent. For example, Microsoft Excel formatted spreadsheets are used for travel expense reports. The XP version of Office includes digital signature capabilities. Third party add-in software is also available for previous versions.
Given the interest in and importance of this application, the research/design team critically examined the effectiveness of the current COTS tools (see section 2.2.1).
Wireless Authentication
We are starting investigations of wireless network authentication as enabled by a PKI. This application is of great interest at Dartmouth and many other academic and industrial institutions. Wireless authentication now includes a standard based on TLS---using X509 certificates and proof-of-possession. We will identify the certificate profile for TLS test it with current products. The Windows XP operating system supports this feature. Dartmouth is participating in a beta test of a similar feature with another vendor.
In conjunction with research into applications based on Dartmouth’s campus-wide wireless network being conducted at the Computer Science department, we have developed some contacts at Intel and Cisco. The lack of security solutions for wireless networks is significantly constraining wireless plans at many institutions, and so is seen as a severe market entry barrier by vendors like Cisco and Intel. In particular joint work at Dartmouth may be focused on developing a method to provide controlled guest access in a PKI authenticated network (see section 3.2.5).
2.1.3Development Expertise CA Software
The PKI Lab team has first hand experience now with Entrust, Sun, Baltimore and Windows CA software. This will be useful when assisting other institutions with their PKI designs. Experience with the Netscape and RSA products would similarly be desirable. The Lab plans to become more familiar with the current Open Source projects for this same reason. In order to use open source CAs in some applications it may be necessary to address the issue of FIPS conformance, particularly for Bridge usage. (We note that the leader of research/design team, Prof Smith, has led six successful validation efforts for the highest two levels of FIPS140 security, including the first-ever at the highest level.)
Tool Development
Developing new PKI based applications is complicated by the fact that there are many different supporting libraries available. They vary widely in terms of their functionality, the documentation available, ease of installation and use and platform support.
One tool we created is a cross platform certificate browser written in Java. It is able to retrieve certificates from an LDAP directory, which is a unique feature. This was useful while testing the PKI installation and directory integration. It is also useful for client testing on platforms that do not have a certificate viewer application built-in and for examining certificate extensions. We are using some of this code to develop a certificate editor for maintenance of LDAP directory entries.
Share with your friends: |
