Non-profit, member-based IT support for research & educational institutions
SUMMARY OF SURVEY RESULTS
From
NSF/CREN Workshop on Directories/Repositories and Certificate Authorities
January 29-31 2001

Prepared for the
National Science Foundation and the Workshop Attendees

May 15 2001

Prepared by:
Sheri Castro, CREN
Judith Boettcher, CREN

Organizational Committee
George F. Covert, Associate Director Computer Center, Iowa State University;
Michael Gettes, Lead Application Systems Integrator, Georgetown University;
Clair W. Goldsmith, Vice President of Information Technology/Chief Information Officer, University of Alabama-Birmingham;
Francis Grewe, Assistant Director, Central Computing Operations, Office of Academic and Distributed Computing Services, University of Minnesota Twin Cities;
Ken Klingenstein, Director of Information Technology Services, University of Colorado at Boulder and Director, Middleware Initiative, UCAID;
R.L. Bob Morgan, Senior Technology Architect, Networks and Distributed Computing, University of Washington;
Jeff Schiller, Network Manager, Massachusetts Institute of Technology;
David Wasley, Assistant to the Associate Vice President for Information Resources and Communications, University of California Office of the President

Available at:
www.cren.net

Introduction (back)

The role of directories and repositories and certificate authorities in supporting the development of efficient campus IT infrastructure has been evolving rapidly.

To support technology development, technology transfer and outreach, the Advanced Networking Infrastructure and Research Program of the National Science Foundation supported two workshops on these topics to be held in the period between January and September of 2001. The first of these two workshops on Directories/Repositories and Certificate Authorities was held on January 30-31st, 2001 in Washington, DC.

Prior to participating in the workshop, 23 seminar participants completed a pre-workshop survey on the state of testing and deployment of directories/repositories and certificate authorities on their campuses. The survey was designed to assess the degree to which campuses have begun to plan, discuss, and implement these new technologies.

This is a report of the survey findings. One of the most important outcomes was the revision of the survey to be completed by the participants in the June 2001 workshop. Additionally, this summary provides a snapshot of the �state of campuses� with regard to these new technologies, and helps to project the needs of the IT community as these technologies and services continue to evolve.

Judith Boettcher
Executive Director, CREN

Workshop Survey Respondents (back)

Raul Archer, Senior Systems Programmer, Arizona State University
Christopher Larrivey, System Analyst, Bridgewater State College
Ric Miller, System Administrator, Colorado State University
Ron DiNapoli, Programmer/Analyst, Specialist, Cornell University
Charlie Reitsma, Systems Engineer, Denison University
Suzanne Maupin, Director, IT, Duke University
Peter Dragovitsch, Coordinator, Computer Applications, Florida State University
Stephen A. Felicetti, Senior Network Engineer, Fox Chase Cancer Center
John Douglass, Systems Support Specialist, Georgia Tech (Pilot)
Jeff Brailsford, Network Security and Louise Miller, Manager, Enterprise Services Group, The Johns Hopkins University
Bill Mayhew, Systems Administrator, NEOUCOM
Steven Kellogg, Pennsylvania State University (Pilot)
Dan Oberst, Director, Enterprise Services, Princeton University (Pilot)
Ben Poliakoff, System Administrator, Reed College
Mark Dumic, Manager, Networking, Systems and Telecom, Swarthmore College
Bob Goldstein, Asst Director, Computer Center, University of Illinois Chicago
Wesley Hubert, Associate Director, Academic Comp Services, University of Kansas
Christopher Misra, Network Analyst, University of Mass Amherst (Pilot)
Cory Snavely, Core Service Programmer, University of Michigan, Digital Library Initiatives
Randy Wiemer, Associate Director, Information Technology, University of Missouri
Bryan Scovill, Network Security Specialist, University of New Hampshire
Jay Leafey, Senior Systems Analyst, University of Tennessee Health Sciences
David Hicks, Computer Systems Control Specialist and Mary Ann Kingry, Coordinator, Application Development, The University of West Florida

EXECUTIVE SUMMARY (back)

The majority of the workshop survey participants maintain one or more directories on their campus, with the majority of the directories being managed by the central Information Technology office. The most common type of directory protocol being implemented is the LDAP directory protocol. Several of those who do not currently use the LDAP protocol indicated that they are planning to shift to the use of LDAP or are already in the process of doing so. Over 90% of respondents stated that there are several working applications linked to these directories. The most commonly cited applications are those for providing remote access authentication and authorization and email services.

Nearly all profiled institutions also maintain an existing university-wide system for granting computer or email accounts to their users. Most of these institutions use subscriber agreements of some sort that members of the campus community must agree to prior to being able to access and initiate their accounts. The process for initially registering campus community members for these services varies.

Several campuses maintain systems in which users create and set up their own accounts through an on-line process, and require users to "click through" the subscriber agreement before permitting account access. Other campuses maintain systems that create and remove email and computer accounts for faculty, staff, and students in "batch" at the beginning of the academic year. Users must "sign" an on-line or paper form that they accept the terms of the agreement before account access is permitted. Data for this account management is most commonly received from the information databases in Human Resources and the Registrar�s offices on campus.

Princeton provided a url for their Rights, Rules, and Responsibilities document (https://www.princeton.edu/pr/pub/rrr/00/index.html.) that includes a reference to computer acceptable use policies. Some policies are spelled out in that document, and others are detailed in a companion document: Princeton University IT Resources and Internet Access�Guidelines for Use. (Overall, it was clear that many of the workshop participants were in early stages of planning and were looking for information about how to proceed. According to several participants, the workshop was to be the first, important step in securing this information, as it gave time and resources to begin a detailed discussion on the pros, cons, and standards of practice in these technical areas of implementation. The participants from the pilot institutions were generally further along and more specific in their planning and their implementation plans.

The biggest short-term and long-term issues institutions face over the coming months reflected this difference in implementation between the pilot and non-pilot institutions. The majority of non-pilot institutions profiled cited short-term goals of migrating away from their old directory systems and structuring their directory information to prepare for PKI. Many institutions also cited developing a plan for PKI implementation as a high-priority short-term goal. In contrast, pilot institutions cited very specific short-term goals, such as "finishing phase II and user education" (Georgia Tech) and "customized scripting to implement a general purpose, multi-copy certificate for peripatetic users" (Princeton University).

Finally, several institutions had definite "outstanding issues" that they identified for the future of certificate authority implementation on their campus. Many of the issues centered around (1) securing campus/system-wide buy-in of digital certificates and (2) estimating/discussing the cost of maintaining, distributing, and administering certificates. Educating management about the benefits of PKI and directories over alternative solutions was also an oft-noted issue.

SECTION ONE: DIRECTORIES/REPOSITORIES (back)

Question 1.1 Do you have directories of any sort (ph, ldap, active directory, other) operational on your campus? If yes, please list. Who manages them?

All the institutions profiled (23) maintain one or more directories or repositories on their campus. Most of the institutions �about two-thirds� reported that they maintained one directory, while the remaining third reported that they maintained two or more directories.

The most common type of directory protocol maintained is the LDAP directory protocol. About two-thirds of the institutions report having an LDAP directory, while an additional three institutions are planning or have recently shifted to or integrated the use of LDAP. Six of the LDAP institutions maintain LDAP alone; the remaining institutions maintain an additional ph, Active Directory, or Novell Directory Service directory as well.

Four institutions reported having an Active Directory in operation. Other directories mentioned include 1 DND and 2 NDS directories. System administrators within the central Office of Information Technology most commonly manage these directories

  1. A ph directory that is operated by one Office of IT staff member and one LDAP directory managed by two Office of IT staff members.
  2. An LDAP directory using the Netscape/iPlanet Directory Server that is managed centrally by Computing and Information Technology. The data is supplied by Human Resources and Student Systems.
  3. We use Dartmouth's DND, although we'd like to move to LDAP soon. Our DND is managed by a single person in our Computer Users Service group.
  4. Ph and SMTP directories are managed by a UNIX system administrator. The Active Directory is managed by a Windows system administrator.
  5. We have an LDAP/X.500 gateway operated by our IT Division. Everyone is issued a "uniqname". In our library environment, our library management system (mainframe-based) receives regular feeds from the above system, which we use as a basis for granting library privileges.
  6. We have one LDAP directory managed by Directory Services, Office of IT that is used for look-up only. It is fed from employee and student data that has been prepared for our ph directory. We use the ph directory for our primary online directory. Ph is technically managed by Systems Administration, OIT, but its contents are managed by Directory Services, OIT.
  7. One NDS, managed by IT Services Department and one LDAP, managed by IT Services
  8. We are building an enterprise directory, which will run on iPlanet. It is currently providing LDAP services for three applications, but no white pages lookup as of yet. We anticipate having it communicate with Novell Directory Services that has a very large installed base and eventually with Active Directory, which is in the building stage. We retired our ph database last fall and migrated it to LDAP.
  9. We have a Directory containing all Faculty, staff and students that want a listing. We use Michigan's LDAP server that we would like to upgrade but we are trying to decide what to upgrade to. We also have a Directory containing the same information that is WAIS indexed and accessed through a web interface. Both are managed by Academic Computing and Network Services (ACNS)
  10. We have ph directory that is a read-only extract from the master data in an SQL database managed by one person in the computer center.
  11. We use Netscape LDAP 3.11 and it is managed by the network engineer group.
  12. We maintain both a ph and LDAP directories. Behind these is an Oracle database which is the primary repository for all of our services. We provide web-based facilities for querying and updating the services database and for synchronizing them in near real-time, as well as a nightly update process that links the database with the university's student and staff databases. Academic Computing Services staff manages all of these except for the last two (university-wide student and staff databases.)
  13. We have one LDAP directory using Microsoft Exchange, managed by Technical Services.
  14. One campus uses an LDAP directory which is run by the Systems group of IS. Another campus uses ph, LDAP, Active Directory and NDS run by Systems group, IS.
  15. We use NDS using Novell Manager with data feeds from SYSUAF - VMS Manager; with card access to buildings data feeds from Banner
  16. We have Active Directory that is managed by Support Systems.
  17. Ph operational; LDAP planned full for 2001.
  18. LDAP, Active Directory, Post Office, Exchange, Affiliate Database � all managed by Information Technology.

Question 1.3. Do you have any applications linked into your directory/repository?

Over 90% of respondents indicated that they have several applications linked to their campus directories. The most common applications are those that support remote access authentication and authorization for users, and email services such as email account creation, routing, and aliases. Other linked applications included phone directories and account/billing applications.

Selected Individual Responses: (back)

  1. The Blitzmail email service is directly linked to the aforementioned DND.
  2. In the library, the library management system database feeds our Oracle-based library authentication system database, which is what we use for authenticated remote access to electronic resources, including proxied services.
  3. We have three applications linked to the directory: 1) Proxies for the Libraries (RAUL - Remote Access for University Libraries). LDAP is populated with library patron information that is used to authenticate remote users before granting proxied access to the library-licensed resources that are off-campus (JSTOR, OCLC, etc.) 2) Email routing. Our Internet email relays resolve aliases using LDAP calls to the directory; 3) CABS - Computer Account and Billing System application was built to provide self-service setup for email accounts for incoming freshman and faculty. Users authenticate to the directory and are then able to select which systems they want accounts on. The account id is generated and pushed out to the host, where the account is created for the user.
  4. An application called web500gw is a web interface to the LDAP server. A perl script uses an LDAP search command and formats output for use by ph clients so they can search the LDAP directory. We advertise our LDAP server for mail reader address books.
  5. Account creation and email redirection. Other applications let us upload data in batch, or export in batch. Some applications support individuals query or update interactively.
  6. Email aliases, phone directories, remote access authentication, password synchronization, and calendar.
  7. Web authentication against IMAP server accessing internal documents and data in Package Room database; NDS controls access to departmental software and computers on campus.

SECTION TWO: CAMPUS ENVIRONMENTS FOR COMPUTER AND EMAIL ACCOUNTS (back)

Question 2.1 Do you have an existing university-wide system for granting computer or email accounts? If yes, what process are you using for initially registering students, faculty and staff for computers and email accounts?

All the institutions that responded to the survey have a university-wide system for granting computer or email accounts, though the process for initially registering campus community members for these services varies. At least four institutions, users are responsible for creating their own email accounts via a web application. Other institutions have fully-automated systems that "require no human intervention" and rely on systems such as Directory Synchronization Service (DDS) that automatically create, maintain, and remove email accounts for all students and employees at the University upon "official" entry into or exit from the payroll/registration system. The majority of institutions generate automatic accounts for new faculty, staff and students from bulk Human Resources (HR) or Registrar data run through a series of scripts or spreadsheets at the beginning of each academic year. Two institutions profiled still perform email accounts manually via paper-and-pencil request forms.

Selected Individual Responses:

  1. Student accounts are created when they register for classes. Faculty/Staff accounts are generated from data from Human Resources. Users present valid ID and are issued accounts.
  2. Students are �bulk loaded� from student system for each new class. All new faculty and staff are assigned network and email ids and accounts when hired.
  3. Accounts are created en masse at the beginning of each academic year using a list of names generated by the registrar�s office.
  4. The current system (CARS) is an on-line process and requires a valid institutional ID card number and SSN. We are moving to a system that will also ask for a third piece of information, such as a PIN.
  5. Students are automatically assigned UNIX accounts based on matriculant data in PeopleSoft. We use nightly extracts to assign accounts to matriculants without existing accounts. As part of the process, we create full name email aliases pointing to the UNIX email address targets, and create hard copy letters that are sent by US mail to inform the students of their new logins, initial passwords, and full name aliases. For faculty and staff, requesters must fill out and sign request forms. The forms contain a reference to the institution�s acceptable use policies.
  6. We have a system that automatically creates, maintains, and removes LAN, RADIUS, and email accounts for all students and employees at the University. The system that performs these tasks for us is called "DSS" (for Directory Synchronization Service). Student accounts are created by DSS when they officially become students. Employee accounts are created by DSS when they are entered in the payroll system. There is no human intervention required for these processes.
  7. Not yet. We will use the directory for account provisioning within the next few months. The directory will generate a login id (LID) for each user, which will be their email account id and login id for any subsequent account they need while at the institution.
  8. Our main computer systems maintained by ACNS support more than 20,000 accounts. Currently a F/S/S must open an account because a service is desired. There is a web interface for the students but the Faculty/Staff process involves some paper work because of electronic identification. Our new HRS system should alleviate this problem. The university plans for 2001 include implementing an e-Identity system requiring all students to have an eID as part of registration.
  9. A web-based registration process with an initial identification check through information extracted from the general university student and staff databases.
  10. Students register for computer and email accounts via the Web. This process is fully automated. Staff and faculty must submit a written User Account Request Form for accounts and mailboxes to be created.
  11. Account requests are initiated through our help desk where initial validation is done. Requests are dispatched to individual system administrators for account creation.
  12. Staff and faculty fill out paper forms. First year students are done in batch at start of school year. Students fill out form any other time of year.
  13. Unix system, HR and banner records of students/staff names pushed through name generator. Shell/Pop accounts.
  14. We have a custom built solution that populates ph, Kerberos, and PeopleSoft in one process.
  15. Our Authentication/Authorization system is fed by SIS and HR, and it generates accounts for faculty, staff, registered and admitted students. These people can also do self-subscription through the AP system.

Question 2.2 Do your users sign, read or accept a policy statement on the use of their computer account or email access (i.e. a subscriber agreement)?

Almost all institutions maintain subscriber agreements that users sign, read or accept describing the use of their computer account or email access.

Institutions vary in the methods used to make sure users have read the subscriber agreement. Several institutions require users to "click through" the subscriber agreement to acknowledge their acceptance of the agreement; a few institutions merely direct users to a URL containing the subscriber agreement. One institution has users read "a very short statement of use that refers to a much more detailed policy", while another institution has an on-line statement that will soon be supplemented with an on-line "quiz" on the policy to ensure users have read and understand the agreement.

Selected Individual Responses:

  1. We have a subscriber agreement we call the �Acceptable Network Usage Policy� that users are responsible for reading. URL is printed prominently on user/pass printout.
  2. All campus community members are bound by a Rights, Rules, and Responsibilities document that includes reference to computer acceptable use policies. Some policies are spelled out in that document, and others are detailed in a companion document: Princeton University IT Resources and Internet Access�Guidelines for Use.
  3. For faculty and staff, account request forms must be signed. These forms contain a reference to the institution�s acceptable use policies. Students are required to at least indicate they have read the policies at their first login before being permitted any additional access, other than logging in.
  4. Using their student or employee ID number and PIN via a Web browser, students and employees manage their accounts. Before users can - get to their user ID and password to allow them access to campus services, they must first agree to the terms in our "Acceptable Use Policy.�
  5. The agreement is on-line. In the fall, we plan to implement an on-line quiz to signal they have read it and understand it.

SECTION THREE: CAMPUS ENVIRONMENTS AND USES OF DIGITAL CERTIFICATES (back)

Question 3.1 What are some of your planned first uses for digital certificates on campus?

Several institutions had distinct ideas for their planned uses of digital certificates. The most frequent planned uses include the following:

  • Email encryption
  • Remote access authentication and authorization for network services
  • Server certificate signing for various IT services
  • E-commerce/on-line purchasing
  • Trusted access to medical information over the web, such as health records/clinical data

Plans for student uses for digital certificates included access to course materials, schedules, and grades. Plans for faculty and staff uses included trusted access to university records, various electronic forms, and/or the university's budget management system.

A few institutions clearly prioritized their uses for digital certificates: One institution�s first priority application for digital certificates is for student grades, while their next highest priority is using digital certificates for e-commerce purchasing. Similarly, another institution states that health records are their first priority, but encrypted email is a close second as it is a big request from their students.

Some of the schools that have been piloting the CREN certificate have very detailed plans for digital certificate use. One institution cites plans to create client certificates for a select group of users and link these certificates to an LDAP directory implementation. It is anticipated that these client certificates will include external (off campus IP addresses) access to various third party resources via a local web proxy, as well as controlled access to local campus resources.

Another pilot institution cites digital signature and encryption for official university business as a planned use of certificates. Another institution that is part of the Digital Library Initiative hopes to establish certificate-based trust relationships with other institutions that license its online content, "thereby enabling us to provide off-campus access to affiliates of those institutions in addition to our own patrons."

Selected Individual Responses:

  1. We are currently in the process of deploying our campus CA. We have the CA system installed and configured and are preparing to send the public key/CSR to CREN for our initial Institutional Certificate. Our first implementation will be to use the campus CA to sign server certs for various services provided by our IT organization (OIT). One major focus is migrating our campus-wide implementation of email services via IMAP over SSL/TLS. This is currently available also via a web mail program (IMP). All of these services use self-signed certs.
  2. Authentication/Authorization to services and session encryption.
  3. Production Quality PKI for Administrative Desktop users (dual-key):
    • Access to administrative web sites
    • Authentication for e-commerce with external vendors
    • Digital Signature and Encryption for official university business
    • Plus Key Escrow (recovery facility):
      • General purpose PKI for more mobile users (faculty, staff, students)
      • Access to university services (mail, web mail)
      • Off-campus access to restricted resources (e.g. JSTOR)
  4. We envision using digital certificates as a more robust authentication mechanism for http enabled services in general. We have considered using Digital Certificates to permit access to an http proxy server, thereby allowing securely authenticated proxied access to off campus network services that are only available to our IP addresses.
  5. Access to student information and administrative information via the web.
  6. For Faculty, email services and electronic forms. For students, email services. For Administrative personnel, electronic forms and budget management system.
  7. Our first pilot will be for VPN. After that, we foresee using digital certs for email encryption, library resources such as JSTOR (replacing the proxy service), network infrastructure device management, server certs, and purchasing
  8. To become HIPAA compliant.
  9. We are still at the stage of determining how we will use certificates. Possible early uses include access to course materials, schedules, and grades (students), or university records (faculty/staff). E-commerce is not currently an application driving us in this direction.
  10. No plans have been made yet. Our only use of Digital Certificates is on our Exchange Server for use with Outlook Web Access so that off-campus users have access to their email without the risk of sending passwords in clear text. Others include electronic purchase orders and time sheets.
  11. SSL/TLS For system/network access, securing web-available documents, secure Email, securing clinical information.
  12. Access to computers, access to Banner records, elections, and student health records, access to course materials, e-commerce, etc.
  13. Health records are our first priority. Encrypted email is a big request from students.
  14. First application will be for student grades; second application will be for e-commerce purchasing.
  15. Student registration and Access to Web CT.

Question 3.2 What process are you using, or do you plan on using for initially registering students for certificates, faculty, and staff? Which office(s) within the university will have responsibility for approving the issuing for certificates?

Most campuses were unsure of the process they plan on using for initially registering students, faculty, and staff for digital certificates. Most respondents indicated that this was to be determined at a later date, when they were closer to providing the infrastructure for PKI. One of the two respondents whose campus had a planned process for registering digital certificates stated that the process they plan to use is their existing Registration Authority for issuing Kerberos user principals, which in turn apply toward certificate application. Another institution stated that their certificate registration will be based on LDAP authentication.

A few respondents listed the departments they thought would be involved in the certificate registration process. These included the following: Directory Services, Registrar's office, IT/Technical Services, Admissions, Student Services, and/or Human Resources. Staff at one institution noted that they are thinking of involving their "badge issuing offices", since this office sees faculty, staff, and students upon arrival and is already issuing campus badges based on photo and ID number authorizations.

Selected Individual Responses:

  1. We haven't reached that stage yet. Presumably we'd follow the same policies we do for account creation - in that the Registrar's office has the final say.
  2. Not yet determined. Certificates will require a higher level of authentication than we now impose for obtaining email access because they will permit access to more confidential information.
  3. Most likely student services and admissions.

Question 3.3 If you have an existing subscriber agreement, how will you be modifying it (if at all) for the use of Digital Certificates? Question 3.4 If you do not have a subscriber agreement, will you create one for the use of Digital Certificates?

The pilot schools were best prepared to share their plans for modifying their subscriber agreements for the use of digital certificates. One institution plans on designing a separate document as an addendum to their current acceptable use policy. A second institution notes that their subscriber agreements are updated annually, and that changes will be considered at that time. Possible planned additions include educating users about how PKI should be used, and spelling out Key Recovery policies and procedures.

The majority of respondents did not respond as to whether they would modify their existing subscriber agreements for the use of Digital Certificates. A few respondents indicated that verbiage describing added responsibilities and security issues for certificates, such as non-disclosure and non-sharing policies, would most likely be added; however, most indicated that they have not yet reached this level of planning.

Selected Individual Responses:

  1. We will be designing a separate document as an addendum.
  2. These agreements are updated annually. We will consider what changes are required. We may introduce a �click through� set of understandings and agreements as part of the PKI signup, more along the lines of education about how PKI should be used, and spelling out our Key Recovery policies and procedures
  3. Yes, not sure how we will modify it yet. It will depend on the transaction exposure that is created through their use.
  4. Not yet known. Most likely language changes would be non-disclosure and non-sharing with specific reference to certificates.
  5. Yes, we will create a new subscriber agreement for digital certificates.

Question 3.5. What are the policies and procedures that you are using to protect the private key of your institution?

Nearly all of the respondents indicated that they are not yet at the stage of planning the policies and procedures they will use to protect the private key of their institution. Many added that they hoped to learn the "standards of practice" at the upcoming workshop. One institution stated that they are currently in the process of developing this plan now, and are considering issues such as the physical security of the private key as well as a dual control method for private key usage of the institution.

Two pilot schools noted that the private keys will be kept on secured machines. For example, one institution noted that they have the CREN Institutional Root CA certificate on a standalone, secure RS/6000 machine located in a restricted-access machine room.

Selected Individual Responses:

  1. The institutional private key exists on a secured laptop. Future plans of key protection include placing the private key in a secured Repository (Library Archives) with accompanying policies preventing access.
  2. Private key will be used to sign Production and General Purpose CA certificate, and then be kept off-line and secured.
  3. We have the CREN Institutional Root CA certificate on a standalone RS/6000 located in our restricted-access machine room. Open SSL is being used. The CA use has been to sign a cert for our KX509 server that issues short-term (24 hr) certs to client systems based on a client DCE authenticaThis is merely a pilot project and is not in production.
  4. We are in the process of developing this now. We are considering the physical security, as well as dual control method for private key usage of the institution.
  5. Not yet known. We do not have a private key at this time. We hope to learn standards of practices at this conference.

SECTION FOUR: TECHNICAL IMPLEMENTATION (back)

With the exception of the pilot schools, nearly all of the institutions declined to answer the questions regarding the technical implementation of certificate authority services. Most respondents indicated that they are still searching for and gathering data on the "best practices" and best-recommended configurations for technical implementation. They are expecting to learn from the workshop content and the higher education IT community on the recommended technical infrastructure for digital certificates, registration authorities and certificate authorities.

Question 4.1 What is the infrastructure that you are setting up for your certificate authority?

Most of the respondents did not have any clear plans at this time regarding the infrastructure for setting up for their certificate authorities. Again, the pilot schools provided more detail in this area. One of the pilot institutions is currently setting up separate hardware for their Certificate Authority, their Registration Authority, and their Key Recovery Authority. Another pilot mapped out a plan for archiving the master private key and using the CREN institutional certificate as the higher-level CA service.

Of the non-pilot schools, one of the institutions was planning on setting up a root CA and subordinate CA's, "where the root private key will be stored in hardware and only activated when required". Another institution stated that they will most likely use a Windows 2000/Active Directory on a stand-alone system in a physically secure area behind a switch limiting network traffic for their CA service.

Selected Individual Responses:

  1. Active Directory Service -based, but some of the information may also be registered in a SQL server.
  2. Kerberos, LDAP, Unix.

Question 4.1.1 Software being used, including version number

The most commonly cited software currently being used for the CA was the iPlanet Certificate Management System 4.2 Other software mentioned includes Windows 2000; Microsoft SQL server 7.0; Open SSC 0.9.6; the latest versions of Apache and ModSSL, and PERL5+; and Windows and Exchange 2000.

Question 4.1.2. Hardware being used, including current and planned, if appropriate. Similarly, only a few respondents replied to the question of the current and planned hardware for their CA implementation. Two of the pilot schools are using Netra and three SUN E-250 Servers. Another institution is piloting PKI on a Sun ES250 (SPARC) server running Solaris 7. Another respondent replied that their CA service will most likely be hosted on a Sun E250 with Solaris 8, and that they are considering using distributed firewall appliances from Watchguard. Another institution is using Dell PowerEdge 4400 and 6300 servers using both internal RAID and attaching to a Storage Area Network via Fibre Channel.

Question 4.2 How do you secure your CA server? How many levels of access do you have? Which office(s) within the university has responsibility for the secure CA environment?

Again, only a few of the respondents (6) replied to the question of how the CA server was, or would be, secured. The majority of respondents maintained two or more levels of access. Two institutions maintain the Root CA inside a locked cabinet inside a card and key access restricted room, managed by the IT department and Network Services, respectively. One institution noted that their CA Server is �hardened� Solaris 2.8, and that there are 2 levels of access required. Another institution plans on using restricted SSH access along with secure ID card, while another institution plans on using a secured (physical) computer facility managed by IT. Another institution stated that there will most likely three tiers of access, managed by the Infrastructure group that maintains responsibility for servers and networks.

SECTION FIVE: GENERAL PLANNING AND ISSUES (back)

The most important short-term and long-term issues mentioned by the survey respondents over the coming months varied considerably. Some institutions were already in the midst of technical implementation issues; others were still in the early planning stages of securing support and identifying pilot initiatives for the use of digital certificates and PKI. Many had decided that getting their directories �in order� was the first order of business. It is also possible that the directory work was more �do-able� and a known activity, and thus a more comfortable place to start the process.

5.1 Question: What are your biggest issues in the short term, in the next 4 months?

As might be expected there was more consistency in the short-term goals. Many respondents cited short-term goals of migrating away from their existing directory systems configurations to structuring their directory information to prepare for PKI by moving to the use of the LDAP protocol. Many respondents also listed �Developing a plan for PKI implementation� as a high-priority short-term goal. Additional common short-term issues that the respondents mentioned included the need to secure buy-in for the Certificate Authority service from administrators and staff. Educating users in the manner and purposes of CA services were also frequently mentioned.

Selected Individual Responses:

  1. Setting up a general purpose PKI based on Open SSL. We anticipate several months of customized scripting to implement a general purpose, multi-copy certificate for peripatetic users, an �anonymous� certificate server (verifying only institutional affiliation) and at least one resource-specific (JSTOR) certificate with accompanying LDAP database to handle queries.
  2. Migrating away from the Dartmouth�s DND as seamlessly as possible. Implementing Kerberos for services that require passwords.
  3. Implementation of the LDAP protocol and rollout of the secure web login for numerous on-campus and off-campus populations.
  4. Implementing enterprise-wide directory services with meta-directory connectors. Connectors will help to synchronize student, staff, faculty, and other "institutional person" attributes from a dozen or so directories and applications.
  5. Research and Design, Interoperability, Deployment, Maintenance.
  6. Logistics, policies, and development of a registration authority.
  7. We have a challenge in making our directory more dynamic since information comes from our legacy systems and is not updated in real time. Also, we are still deciding what benefits PKI and directories have and how they fit with e-identity, LDAP, active directory, Kerberos, portals, and middleware.
  8. Challenge of the structure of directory information over two major campuses each with a computer center and many internal databases and ways of doing things plus a multi-campus administrative computer center. We are not one big campus, but we are not completely separate either.
  9. Establishing new firewall architecture, and putting in place the resources necessary to take further steps to implement PKI.
  10. Developing an initial plan for how to transition from our current system to CA-based authentication and understanding the technical implementation of certificates and their practical uses.
  11. Windows 2000 rollout.
  12. Creating a plan for PKI.
  13. Getting paperwork for CREN CA; completing infrastructure and implementing the CREN CA.
  14. Setting up CA server, obtaining keys and deciding which applications will be certificate/LDAP enabled. Five institutions mentioned that these activities are all in the planning stage at this time.

5.2 Question: What are your outstanding issues that you see in the future?

Several institutions had definite "outstanding issues" that they foresaw in the future of CA implementation on their campus. These issues included:

  • Campus/system-wide buy-in of certificates (2 Institutions)
  • Cost of maintaining/distributing/administering certificates (3 Institutions)
  • Educating management about the benefits of PKI and directories over alternative solutions (1 institution)
  • How to make disparate systems better integrated, at the same time leaving management of local systems in the hands of people best motivated and capable of solving local problems (1 institution)

Individual Responses:

  1. Key escrow issues
  2. Resolving Netscape/IE/Outlook client certificate issues
  3. Getting vendor acceptance of certificate-based authentication
  4. Simplifying client certificate management
  5. Support issues for digital certificates, as web browsers handle certificates differently.
  6. User education will be crucial to enforce protection of private keys of certificates.
  7. Encryption of end user certs is optional and controllable by the user.
  8. Digital certificate implementations seem either embryonic or fantastically expensive. There does not seem to be any sort of "standard" implementation as yet. We worry about committing to a technology that seems to be such a moving target.
  9. Introduction of digital certificates to users
  10. Revocation seems to be the thing everybody puts off until later, and maintenance of certificates
  11. Adding certificate management system to the above directory infrastructure.
  12. Leveraging LDAP for authentication/access of LDAP-enabled applications.
  13. Interoperability as other emerging systems begin to use this technology.
  14. Security for what may become a central point of authentication and verification.
  15. Operational management
  16. Persuading management why PKI is the way to implement services at the university.
  17. Single sign-on, including existing applications as well as future ones.
  18. How to make disparate systems better integrated, at the same time leaving management of local systems in the hands of people best motivated and capable of solving local problems.
  19. Collaboration between universities, not just between our own campuses, is often mentioned. So cross-authentication and local authorization are issues.
  20. PKI and planning for HIPAA.
  21. Establishing secure access to an increasing variety of university records for students, faculty, and staff.
  22. Providing access from off-campus without compromising security.
  23. Identification and authentication of non-university persons needing use of our services (e.g. those at other schools or general public, for use of library materials, other electronic campus information sources).
  24. Campus-wide buy-in [for digital certificates].
  25. System wide buy-in [of certificates].
  26. Storage of certificates; storage of private keys; cost of distributing/administering certificates.
  27. Certificate maintenance; do we do it, or do we outsource? Open CA support. Cost of open CA versus vendor support.
  28. Determining and securing budget allocation necessary to support certificate infrastructure.
  29. Are there established authoritative sources and update policies in place? We are interested in securing these documents from other institutions

Conclusion (back)

The results of this survey are being used to continue refining the design of the workshop to be held in Minneapolis on June 6-8, 2001 and to revise the survey to be completed by the participants in the next workshop. Some of the new questions to be asked attempt to capture more detail on the specific barriers or �help� that campuses would find useful in their next steps towards building a campus with a secure and authenticated set of applications and services.
This survey and other interactions with the workshop participants suggests that campuses might find useful some set of the following:

  • A template for a campus plan to move to the use of digital certificates
  • A generic set of documents �including subscriber agreements and best practices for setting up directories, registration authorities and certificate authorities
  • A budget and personnel proposal for the implementation of digital certificates
  • A recommended set of software and hardware for setting up directories, for the registration authority and the certificate authority