* Identify issues related to Universitywide development of a common authentication architecture and work through as many of those issues as possible,
* Demonstrate a working configuration of a portion of this architecture that can be built within 3 months,
* Report on outstanding issues,
* Recommend next steps for continuing the work.
This report describes the technical architecture of the pilot projects and the results of the tests. Outstanding issues are identified for moving toward a production environment for authentication services that are working informally today and a set of short term and mid-term projects are recommended for progression towards an complete set of integrated services.
| Due Date | Description | UCB | UCD | UCLA | UCOP | UCSC | UCSD |
| August 22 | Establish campus certificate authorities -UCD, UCLA, UCSC, UCSD, UCOP. | X | X | X | X | X | X |
| September 12 | Obtain a subordinate CA signing certificate from UCOP's Certificate Authority. | X | X | X | X | X | |
| September 12 | Demonstration of MelWeb access from campuses using certificates. | X | X | X | X | X | X |
| September 26 | First draft of Kerberos and Public Key Certificates issues paper. | X | X | X | X | X | X |
| September 26 | Revision of payload definition. | X | X | X | X | X | X |
| October 15 | Demonstrate Kerberos authentication to obtain certificates. | _____ | _____ | Incom | plete | _____ | _____ |
| October 31 | Demonstration of full off-campus MelWeb access with access controls and testing the certificate authority hierarchy. Final draft of issues paper. | X | X | X | X | X | X |
The Office of the President is currently working on the construction of a demographic database, DDB, which will store information about every person who studies, works, teaches, applies to, or visits at the University of California. The demographic database is not a substitute for directory services but will eventually be an integrated component to distributed campus directory services. The workgroup is aware of the significant amount of work that will be required to construct such a database and the additional work required to establish production interfaces to campus directory services. The estimated timeframe for the construction of the DDB significantly exceeds the timeframe for the implementation of the first authentication service. The Office of the President has set a tentative date of April 1, 1998 for the rollout of applications requiring authentication. As a result, deployment of production quality authentication services will require campuses to deploy local, independent, directory services. Campus staff understand the requirements of establishing campuswide directory services. This will be a large undertaking for some of the campuses but this work can continue independent of Universitywide task force activities.
In August, the Workgroup demonstrated the feasibility of establishing a UC Certificate Authority hierarchy using Netscape's Certificate Server software. The hierarchy was used by the participating campuses to issue digital certificates on behalf of the `root' UC Authority. The Melvyl WWW gateway was used to prove the concept of application access control using authentication of client digital certificates issued by subordinate Certificate Authorities.
The Workgroup concludes that digital certificates are sufficiently robust to be used to authenticate clients at the campus level for applications having low to medium security requirements. Intercampus use of certificates will require the development of a scheme to share certificate revocation lists. High security applications, such as retirement fund management, should not use certificates for authentication until further testing of revocation mechanisms is completed.
Version: v3 (0x2)
Serial Number: 20 (0x14)
Signature Algorithm: PKCS #1 MD5 With RSA Encryption
Issuer: CN=Campus Certificate Authority, OU=Data Center, O=University
of California Campus, C=US
Validity:
Not Before: Wed Aug 27 11:21:25 1997
Not After: Mon Feb 23 10:21:25 1998
Subject: CN=J. P. Student/Email=jpstudent@uccampus.edu, OU=Student
Life Center, O=University of California Campus, C=US
Subject Public Key Info:
Algorithm: PKCS #1 RSA Encryption
Public Key:
Modulus:
00:ca:f2:54:65:fc:b9:85:57:b8:cf:b2:47:6b:5c:75:47:f0:
50:a7:6e:52:9a:a6:06:7c:c2:95:0e:e6:54:79:45:b9:d5:45:
9c:1e:84:eb:de:dc:7a:91:c8:6f:d4:7d:bf:fc:47:dd:52:a6:
99:0c:ea:94:13:5a:cc:da:b1:7b:d5
Public Exponent: 65537 (0x10001)
Extensions:
Identifier: Certificate Type
Critical: no
Certified Usage:
SSL Client
Secure E-mail
Identifier: Authority Key Identifier
Critical: no
Key Identifier:
74:ee:01:98:78:27:18:03:67:34:fd:23:a3:ef:16:60:ea:cc:
1a:ee
Identifier: UC Demographic Database Key
Critical: no
Value: 00002797357
Identifier: Campus Unique Identifier
Critical: no
Value: 000022811
Signature:
Algorithm: PKCS #1 MD5 With RSA Encryption
Signature:
30:42:94:1e:74:1b:81:e7:d0:9b:84:ed:d7:05:4f:f3:8f:2a:2e:9d:fd:
6d:19:74:c9:40:a7:53:53:96:94:bb:c2:a5:6e:ac:b2:ce:eb:07:1e:f9:
63:a9:80:cc:a4:ad:77:be:83:94:72:8c:22:65:78:45:95:38:d6:e7:0c:
0f:6f:17:9d:75:31:d8:42:eb:dd:0b:66:03:00:2f:cb:a7:f8:8b:de:d9:
ff:4b:df:1c:17:c2:94:c7:2b:54:3b:0d:b1:b6:c6:ed:d4:ab:bd:d4:24:
42:cc:c7:c1:10:4c:85:81:17:c7:f3:e8:fe:71:5e:2a:4a:35:3b:e6:15:
71:57
2.2.1 Certificate Extensions
2.2.1.1 Extensions Provided by Certificate Server Software (Netscape, Entrust)
Certificate issuing software may add extensions that are meaningful to other products designed to interact with it. For example, Netscape software adds the Certificate Type and Authority Key fields to the certificates it signs.
2.2.1.2 UC Demographic Database Key and Campus Unique Identifiers
The Office of the President is designing a Demographic Database (DDB) which will store information about every person who studies, works, teaches, applies to, or visits at the University of California. When it becomes available, the DDB will provide a unique UCOP identifier, or key, which will be included as an extension in UC certificates. Additionally, campuses will provide their own unique identifiers for inclusion in the DDB; the details of this relationship must be determined by a follow-on workgroup. DDB content will be replicated at each campus, allowing applications to use certificates to extract detailed information about each certificate holder.
2.2.1.3 Campus Defined Extensions
The Workgroup has agreed that Campus Certificate Authorities may include any locally defined extensions in certificates that they issue. Obviously, extensions should not include information that is likely to change frequently. The Workgroup has concluded that directory servers are the most practical repository for information that might otherwise be considered for inclusion as a certificate extension.
2.2.1.4 ISO-CCITT Object Identifiers (OID's)
X.509 certificate extensions are defined using a dot-separated numeric notation known as an object identifier (OID). These identifiers exist in a logical, hierarchical tree of objects registered with the ISO and CCITT organizations. It is acceptable to `invent' OIDs for the purpose of testing certificate extensions. However, the Workgroup recommends that the University register as an organization with the ISO/CCITT, thus allowing the creation of a subtree of proper OIDs. ANSI is the U.S. representative for the ISO/CCITT; the fee for registration is $1000.
Each campus CA will have the responsibility to adequately identify the individuals to whom they issue certificates. The University must create a policy that defines due diligence for the issuance of certificates at the campus level.
2.3.2 U.S. Export Law Restrictions
In June, export restrictions were eased for certain Netscape cryptographic products. Entrust software remains under these controls. The implications of distributing software to individuals who may travel outside of the U.S. is a discussion topic for a follow-on workgroup.
2.4.1 SmartCards and Certificate Portability
RSA Laboratories and other interested parties have developed a family of standards called Public-Key Cryptographic Standards, or PKCS. PKCS-11 is a standard for mechanisms to store the private-key component of a public-key/private-key pair securely on smart cards and other hardware devices. One vendor currently markets a smart card reader that fits into a 3.5" diskette drive, but it is only sold as part of a combined reader/smartcard/middleware package that is relatively expensive ($ 179 for single quantities). Smart cards provide a potential solution to the problems associated with using certificates/private keys on public facilities, such as student computer labs. The private key never leaves the card, and is thus unavailable to the next user of the workstation
PKCS#12 is a proposal for a new standard (April 30, 1997) that describes a syntax for securely transferring private keys, certificates, and other personal objects between different computers and applications. Netscape Navigator 4.0 allows certificates to be imported and exported as Personal Information Exchange (PFX) format files, but cannot accept PKCS#12 files. Microsoft Internet Explorer 4.0 will import and export PKCS#12 files, and is also able to import PFX files. A complete implementation of PKCS#12 may offer a solution to certificate and private key portability, but the safety of accessing these files over the network must be investigated.
Each Certificate Authority must provide a CRL so that applications are aware of certificates that have been revoked, for whatever reason. The Workgroup has identified CRL availability, maintenance, and scalability as issues for a follow-on workgroup.
2.5.2 CRL Access Overhead
Netscape Enterprise and Directory Servers do not currently have the ability to automatically check to see if a certificate has been revoked. Therefore, any application that uses certificates for authentication must complete a query against a CRL. Regardless of the component that performs it, the performance cost of this operation could be significant in a production environment.
In its brief lifespan, the Workgroup has worked entirely with the Netscape Certificate Server. Although any products written to use the X.509 certificate standard should be interoperable, we have not attempted any testing to confirm this.
2.6.2 Certificate Database Size Limitations
The Workgroup estimates that each campus will need to support at least 60,000 certificates. The Netscape Certificate Server is designed to issue up to 10,000 certificates for each instance of the server, but it should be possible to overcome this limitation by operating multiple certificate servers that reference a single LDAP directory server. The choice of certificate server and configuration will be at the discretion of the campus.
2.6.3 Integration with Directory Services
A certificate server can use an LDAP directory server to publish certificates, as well as the Certificate Revocation List. This configuration provides a convenient way to retrieve the valid public keys of other users on the network. Directory servers are also suitable repositories for authorization identifiers, such as userids for departmental computer systems.
A version of the Melvyl WWW gateway, known as `MelWeb', was modified to allow access only to browsers possessing client certificates signed by Authorities within the UC CA hierarchy. The campuses conducted numerous tests, including connections through non-UC Internet Service Providers, to confirm that this selective access control performed properly.
In later discussions, it became apparent that campus-level directory services could provide a means to maintain and distribute authorization data for each individual. Extracts from the DDB will eventually be used to provide University-level authorization data to directory servers on each campus.
It is likely that the University will eventually use public keys to encrypt official correspondence and affix digital signatures to official documents. A key escrow system will be needed to protect against the accidental loss of the corresponding private keys. A follow-on workgroup should investigate these issues.
1) The Office of the President must contact ANSI and register the University as an entity in the Joint-ISO-CCITT tree of numbered objects;
2) The Office of the President must obtain a Certificate Authority certificate bearing the signature of a universally recognized authority, such as Verisign;
3) The University must create a policy that defines the degree of due diligence required of each campus when verifying the identity of certificate requesters.
4) Each campus must identify a certificate server configuration that will support the existence of the expected number of locally issued certificate (at least 60,000 for the larger sites);
5) Each campus must install a directory server which is integrated with the certificate server architecture.
We recommend that a follow-on workgroup investigate these remaining issues:
* Relationship between DDB unique identifier and campus-assigned identifier
* Portability of certificates and private keys;
* Certificate revocation list implementation;
* Digital signatures and key escrow systems;
* Export law restrictions.
The workgroup identified the following information as necessary for making an informed decision on the feasibility of various Kerberos authentication services and deployment possibilities, the full cost of deployment and the timeline for the implementation of production quality Kerberos services.
* Distributed computing architecture statement for Office of the President applications
* Application development plan, including milestones for reliable authentication services, for Office of the President applications
The consensus of the workgroup is that direct use of Kerberos services in a system as large as the University of California, will require the use of multiple Kerberos servers configured in a trust relationship. The best method for establishing this relationship is through distributed Kerberos servers using inter-realm authentication. The feasibility of inter-realm authentication, one using Kerberos based DCE Security Services, was demonstrated between UC Berkeley and UC Davis. However a combined architecture of centralized and decentralized services is recommended for short term deployment in order to also support campuses that choose not to deploy Kerberos at this time. This would provide campuses the flexibility to choose local authentication architectures that are the most economical to support locally and permits incremental scalability testing and deployment of the distributed architecture as campuses transition to locally supported services.
* A fully centralized security service for UCOP administrative applications, separate from the security services available on the campuses
* A fully distributed security service which would rely on campus based security services with inter-realm authentication.
* Support of a combined architecture which would allow campuses with Kerberos Security Services to use local security services with inter-realm authentication and a central service for campuses who choose to obtain security services from the Office of the President.
8.1.1 Centralized Service at the Office of the President
Benefits
Simplicity
A centralized security service for administrative applications would simplify the creation and management of applications for Office of the President staff. It would also allow campuses without a distributed security infrastructure to rely on a centrally maintained security system.
Issues
Scalability, Reliability and Performance
A centralized service would be susceptible to network outages. Replicas of the UCOP cells could be positioned behind the UC network router/switch boundary. However the cost of this redundant configuration would need to be evaluated against the distributed model with inter-realm authentication.
Client Software
Client software licensing, distribution, installation and support would need to be addressed. UC Davis has recently experienced significant difficulty in the installation of conflicting versions of Oracle software for administrative applications which require different versions of the same software. A similar conflict with Kerberos based authentication clients is highly probable for campuses with a security infrastructure when working with a centralized DCE Security Service for UCOP administrative applications. Support of inter-realm authentication would eliminate this problem.
Middleware Integration
UC Davis has also experienced difficulty with the integration of Kerberos with Oracle middleware in the implementation of the new financial and student information systems. The choice of DCE Security Service software for UCOP administrative applications could complicate these issues or induce new desktop software integration and support issues. Support of inter-realm authentication would eliminate this problem.
Security
Efforts to move toward a single network sign-on are driven by the recognition that multiple userids and passwords are very inconvenient and they motivate users to adopt insecure methods to remember passwords which compromise security (sticky notes and shared passwords). A dual security system, in which the security services for UCOP administrative applications differs from campus security mechanisms, would establish another set of separate userids and passwords and hinder efforts towards the more secure single sign-on environment.
Administrative Overhead
Administrative procedures would need to be established to register campus staff with centralized security services. This would be redundant for campuses supporting a campus security infrastructure
8.1.2 Distributed Service with Inter-realm Authentication
Benefits
Scalability, Reliability and Performance
Distributed authentication services would improve the scalability of the authentication architecture, improve reliability through redundancy and by placing the service closer to the users and improve response time by minimizing network traffic and server load.
Simplicity
Administrative users are no longer an isolated user population and can be expected to use campus infrastructure services to connect to local administrative applications, data warehouses and Web services. A distributed security service for UCOP supported administrative applications would allow each campus to support a single security infrastructure for all campus users.
Cost
Desktop support is the largest component of personal computer ownership. Support of multiple middleware components for security services would significantly increase these costs to the campuses. The ability to maintain a single configuration on the desktop through inter-realm authentication would minimize this cost.
Reduced Administrative Overhead
Registration of principals in security services incurs one-time and recurring administrative overhead. This would be minimized in a model of distributed security services.
Issues
Policy and Procedures
A decentralized service would require each campus to agree to establish, operate and maintain DCE Security Services with a level of reliability and support that meets the production needs of the Office of the President.
Version Control
Each campus would have to agree to coordinate software choices with the Office of the President to maintain the required level of functionality for inter-realm authentication.
8.1.3 Combined Centralized and Distributed Service with Inter-realm Authentication
Benefits
Flexibility
A combined architecture would provide the flexibility for the campuses to choose between the costs and benefits of each model and to implement systems consistent with local infrastructure plans.
Cost Control
A combined architecture permits each campus to choose the most cost effective architecture.
Support Campus Migration Strategies
Campuses without local security services may have plans to implement campuswide services within the next year or two. The combined model would permit these campuses to support UCOP administrative applications through the centralized service and migrate to the distributed service within their planning timeframe.
Issues
Each campus and the Office of the President would have to work through the issues listed above which are specific to the service model deployed.
DCE Security Services were configured to permit an administrator at UC Berkeley to locally maintain the membership of a group of principals in the UC Berkeley cell and provide access rights to resources in the UC Davis cell. The trust relationship was demonstrated by configuring a DCE Distributed File System (DFS) to distribute files at UC Davis to UC Berkeley. Individuals at UC Berkeley who are appropriately authenticated, can then access the files. This required the UC Berkeley server to provide the proper credentials to read the files stored in the UC Davis DCE cell. This was accomplished by using Transarc nsapi functions for the Netscape Enterprise Server that will generate a prompt for a DCE principal name and password over an SSL encrypted connection and use this information to obtain and cache a DCE security context on the server for the authenticated principal.
On Monday, September 29 Matthew Lodata from Transarc came to UC Davis and installed a DCE cell and DFS on a development system. The set up took one hour from a clean system. On Tuesday he spent half a day at UC Berkeley, mainly installing and configuring an established Netscape server with Transarc extensions and bringing up the DFS client software. The trust relationship was established between the two cells by giving each server a principal on the server at the other campus. Browser clients could connect to the server and only access the files stored in Davis DFS space after supplying a valid DCE principal and password. The feasibility of cross cell trust and authentication was demonstrated. The remaining test items are to demonstrate access control through the use of DFS Access Control Lists.
Please describe your current Kerberos v5 services (if any):
| UCB | UCD | UCLA | UCOP | UCSC | UCSD | UCSF | |
| Number of master servers | 0 | 1 | 0 | 0
Kerberos v4 only |
1 | 0 | |
| Number of slave servers | 0 | 2 | 0 | 0 | 2 | 0 | |
| Number of principals | 13,700 | 10,000 | |||||
| Population served | Students, faculty, staff, guests, visitors | Students, faculty, staff, guests, visitors | |||||
| Brief description of applications using Kerberos v5 | +Student access to grades via the Web.
+Modem access beginning Fall quarter. |
+ central pop/imap mail service.
+ dialin network access.
+ workstation logins. |
Please describe your current DCE Security Services (if any):
| UCB | UCD | UCLA | UCOP | UCSC | UCSD | UCSF | |
| Number of master servers | 1 | 1 | 1 | 0 | 0 | 0 | |
| Number of slave servers | 1 | 0 | 0 | 0 | 0 | ||
| Number of principals | 8 | 0 | |||||
| Population served | Staff for testing purposes. | None | None | ||||
| Brief description of applications using DCE Security Services | IBM's DDCS/DRDA, underlying PeopleSoft Financial and Human
Resource
applications. DDCS/DRDA traps the PeopleSoft login dialogue and provides DCE user authentication transparently to the application. |
DFS and DFS Web |
What are the key issues for your campus in supporting administrative staff accessing UCOP applications using DCE Security Services authentication?
| UCB | UCD | UCLA | UCOP | UCSC | UCSD | UCSF | |
| Migration from Kerberos v5 to DCE Security Services? | No | Yes | No | Yes | |||
| Running parallel authentication services? | Yes. Currently investigating issues related to running Kerberos v4, Kerberos v5 and DCE Security Services in parallel. | Yes | No | Yes |
Client software? Do you currently have a site license or a recommended package?
UCB UC Berkeley has a freely available copy of KerbNet from Cygnus for testing Kerberos version 5.
UCD UC Davis has already experienced significant difficulty in the installation of conflicting versions of Oracle software for administrative applications which require different versions. We are concerned about a similar experience with Kerberos based authentication clients.
UCSD The last issue is very important to ACT; we are working to eliminate access schemes that require specialized software installations on client workstations.
What are the technical issues faced by your campus in bringing up a production level DCE Security Service by April 1, 1998?
| UCB | UCD | UCSD |
| Determine if the existing hardware/software configuration is adequate for a cell for ~50,000 users - adjust if necessary | ||
| Establish staffing and budget to support the new service. | ||
| Initialize a campus-wide directory service. | Determine how to construct a campus directory service from existing databases; | |
| Integrate the directory service into DCE services. | Identify a hardware/software configuration that provides failover capabilities in the case of machine or network outages; | |
| Put in place appropriate operational procedures to provide for a (potentially) 7x24 production environment. Requires addressing logistical, organizational and technical issues including, automatic backup procedures and system monitoring. | Establish the DCE security service as a 7X24 production service. | |
| Building or acquiring tools to make administering a DCE cell manageable. | Determine how users can use DCE without requiring client software installation (proxy? Java applets?). |
| UCB | UCD | UCSD |
| Determine the necessary hardware/software configuration to handle 50,000+ users. | Determine the necessary hardware/software configuration to support more than 10,000 certificates. | |
| Establish staffing and budget to support the new service. | Construction of a campus DDB, which will provide unique identifiers to be included as certificate extensions; | |
| Use an existing DCE cell to control issuance of initial certificates. This could be the UCOP demographic database or a UCB database from the previous step. Put in place appropriate operational procedures to provide for a (potentially) 7x24 production environment. | Establish the integrated Kerberos/Certificate service as a 7/24 production service. | Develop a system for support of portable certificates |
| Building or acquiring tools to make administering a DCE cell manageable. | Complete the integration of Kerberos authentication and the issuance of certificates. Estimated completion time, two weeks. | Develop a system for the proper management of certificate revocation lists |
* The Office of the President must obtain a Certificate Authority certificate bearing the signature of a universally recognized authority, such as Verisign
* Office of the President staff needs to produce a distributed computing architecture statement for Office of the President applications and an application development plan, including milestones for the use of reliable authentication services, which describe the functional and deployment requirements for authentication services. These documents should provide the campuses with the information they need to evaluate the feasibility of using Kerberos version 5 or DCE Security services and to detail the technical, economic and operational workload associated with the architecture.
* The Office of the President would need to establish production quality, centralized, security services for those campuses who do not intend to establish local security services or participate in inter-realm authentication. This service needs to be defined and tested including addressing issues of administrative procedures for registering principals for staff at the campuses, software distribution and responsibilities for software configuration, installation, integration with other desktop software and troubleshooting.
* Each campus must identify a certificate server configuration that will support the existence of the expected number of locally issued certificate (at least 60,000 for the larger sites) and plan for the deployment of a production quality system.
* Each campus must choose a method for supporting Kerberos based authentication services and plan for the deployment of a production quality system.
* Specify a mechanism to support the portability of certificates and private keys.
* Specify a systems to manage Certificate Revocation List.
* Specify a system to manage digital signatures and key escrow systems.
* Identify export law restrictions on encryption and forward recommendations for meeting the requirements.
* The technical feasibility of inter-realm authentication has been established. The policy and procedures for using inter-realm authentication need to be formalized. Authorization controls need to be tested using Access Control Lists.
[1] http://www.ucop.edu/irc/wp/wp_Reports/wpr009/wpr009_IRC.html