The University of California, Authentication Workgroup was charged with refining the authentication architecture described in "A University Common Authentication Project" based upon input from the campuses. The first workgroup met between August 1, 1997 and October 31, 1997. A report was forwarded to the JOG Authentication Steering Group which described initial tests of authentication services and recommendations for future work. Outstanding issues were identified for further investigation.

This report summarizes the work of a second Authentication Workgroup which was charged with moving forward on the outstanding issues identified in the first report. A workplan and assignments were developed for the tasks recommended by the previous workgroup. A few additional tasks were added as a result of discussions about the relationship between authentication and authorization. This report provides a summary of the workgroup's discussions between March 12, 1998 and June 22, 1998, a description of the University-wide certificate service architecture and policy recommendations for ongoing operations.

Marina Arseniev (UCI), Peter Brantley (UCSF), Mike Friedman (UCB), Joan Gargano (UCD), Sal Gurnani (UCOP), Russ Harvey (UCR), Tom Marazita (UCSB), Pete Nielson (UCLA), Vance Vaughan (UCB), David Wasley (UCOP), Ken Weiss (UCD), Frank Whittemore (UCSD), Don Worth (UCLA).

All documents produced by the workgroup, the workplan, status reports and related references are available at: http://dcas.ucdavis.edu/authentication

Three decisions were made by the workgroup which have a significant impact on the authentication architecture and campus implementation planning.

The following definitions of databases associated with authentication and authorization services was created to clarify terminology, the sensitivity of data in each database and access issues.

A database of information about people affiliated with the University which can be used to provide valuable statistical and planning information. The schema for a demographics database is determined by the database manager. Data sources are highly variable ranging from the integration of business data, data captured from online transactions and manually entered data. The data is highly sensitive and requires a high degree of security and limited access. Data retrieval is periodic and normally through the creation of standard and ad hoc database queries.

A database of names and attributes of users, machines and other resources which may be accessed over the network. Directory services are accessed by people and applications to obtain information and manage online processes. The schema for a directory service is determined by the database manager but is driven by the requirements of standard protocols such as Domain Name Service, Cell Directory Services and X.500. The data is moderately sensitive with strong requirements for maintaining a high level of data integrity. Data retrieval is through high volume transactions between clients and servers.

A directory service offering Internet address information related to people and organizations. The schema for white pages services is determined by the database manager, common white pages protocols, i.e. Whois, CCSO ph, X.500, LDAP, Whois++, and Internet Engineering Task Force RFC 2218 which defines a common schema for Internet White Pages Service. The sensitivity of the data is moderately sensitive and is easily controlled by the database manager. Data retrieval is through a moderate level of transactions between clients and servers.

The purpose, schema, management and underlying technology for each database is very different. There are two options for relating them to one another. Each database can use the same primary key or each may use different primary keys which are related to one another in a separate database or table.

The characteristics of each service is summarized in the following table.

The NetID which will be the primary key for the UCOP demographics database and directory service, is independent of the CampusID. Any relationship between the two will be defined and maintained at the campus level. The University Directory will provide three fields which will provide a pointer to a server which can provide attribute information in support of decisions about authorization. Initially these fields could include the CampusID.

The University demographics database and directory service needs to provide location information which supports individuals with affiliations with multiple campuses.

The following is an overview of approaches to achieve portability of certificates/credentials within the proposed UC-wide Public Key Infrastructure.

• Provides one of the highest levels of security with respect to protection of an individual’s X.509 certificate and encryption and signing key pairs while maintaining a comfortable level of portability.
• Users are more comfortable with associating ownership with and protecting physical objects through experience with campus id cards, credit cards, etc.
• Prevents easy duplication of digital credentials.

• Commercial products tend to be expensive and proprietary.
• Requires additional software/hardware installed on workstations — this would likely preclude use of personal workstations.

• Inexpensive solution; No custom hardware or software requirements.
• Functionality similar to short lived Kerberos credentials without the requirement of server maintained session state.

• Latency problem — no way to time out credentials when user leaves workstation before the short-lived certificate expires.
• User is required to accept and install every new certificates through a series of browser generated dialogs, a process which is notably crude. Having to repeat the process often would be an annoyance to the user, while having certificates with too long of a life span would ensure the latency problem described previously.
• Timed out certificates remain in browser’s cache and must be deleted manually.
• When user visits a site, the user must choose the current and valid certificate from a list which may contain expired certificates from other users — this is bound to cause confusion and frustration to the user.
• Introduces the use of passwords (shared secrets) which are generally considered a weaker security model than PKI and certificates.

• Provides many of the advantages of hardware tokens with less expense and no special hardware requirements.
• Can be used on any machine with the appropriate custom software or through standard web browser software via manual import/export process.

• Custom software solution consists of web browser plug-ins, which would likely be platform specific and have some associated licensing cost.
• Manual import/export process is tedious and requires user training to avoid compromise of user credentials — certificate left on browser for next user to access.
• Fairly easy to duplicate.

• Moderately inexpensive solution. Does not require custom software but some does require some development work on the session server side.
• Credentials never reside on the browser so security risk is minimal.
• Credentials can be expired based on a fixed life span or on demand.
• Login/Password authorization could be done via Kerberos.

• Latency problem — no way to time out credentials when user leaves workstation before the short-lived certificate expires.

• The NETID is not immediately apparent from the Terminal Certificate.
• Requires development of a Session component of the campus attribute server.
• Development work could surface unforseen technical issues.

• Introduces the use of passwords (shared secrets) which are generally considered a weaker security model than PKI and certificates.

A solution can not be recommended at this time. The University of California, Limited Production System should be used for testing and experimentation. In the interim, an individual may need to be issued multiple certificates.

The following is a summary of Certificate Revocation List management offerings currently available from six of the more visible commercial Public Key Infrastructure vendors.

1. Product Offerings

• Certificate Server 1.01
• Directory Server 3.X

1. Technology

• Linear storage format limited to single CRL
• CRL is posted to LDAP server
• CRL file is installable in Netscape web servers via manual process
• Pseudo OCSP support in Certificate server via CGI script which returns revocation status of a given certificate based on serial number
• Netscape plans to support OCSP in future versions of the Certificate Server

• Web CA product
• Client/Server Toolkit

1. Technology

• Distributed tree storage format which supports multiple, distributed CRL’s
• CRL is posted to one or more LDAP servers
• CRL can only be processed using Client/Server Toolkit
• "Distribution Point CRL Management" — Patented scheme to manage multiple CRL’s located on multiple LDAP servers ; Free license available vendors and implementers

• Cybertrust Enterprise Service
• Server Toolkit

1. Technology

• Linear storage format limited to single CRL
• CRL posted to LDAP server
• Toolkit supports Netscape and Microsoft Web Servers
• For large CRL management, GTE supports Valicert CRL management service

• CRL Management Service
• Server Toolkit

1. Technology

• Proprietary tree-like storage format which supports large single and combined CRL’s
• Toolkit supports Netscape and Microsoft web servers
• Protocol will converge to OCSP when standard is established

• Enterprise Certificate Authority Service

1. Technology

• Internal storage format is unknown but is externally distributed as a linear CRL
• Access to revocation information is mediated through OCSP like interface and web database search form
• Protocol will converge to OCSP when standard is established

• Sentry Certificate Authority Product
• Enterprise Certificate Authority Product
• XUDA Server Toolkit

1. Technology

• Database storage format compatible with X500,LDAP,SQL,dBase,NT admin
• Intrinsically supports multiple CRL’s
• Toolkit includes plug-in for Apache-Stronghold, Netscape, and Microsoft Web Servers
• Access to revocation information is mediated via OCSP-like protocol (XUDA)

A open standard solution can not be recommended at this time. The Online Certificate Status Protocol (OCSP) which may lead to interoperable products is still under development within the Internet Engineering Task Force. In the interim, the University of California, Limited Production System should be used for testing and experimentation with currently available products.

The research that serves as the basis for today’s public key technology dates from the mid 1970s. Indeed some researchers considered the theoretical problem of secure message exchange to be solved and directed their efforts elsewhere. It is a testament to the difficulty of the practical problems involved in implementation that twenty five years later there still exists no widely deployed public key infrastructure to enable the easy use of the technology for the secure and authenticated exchange of messages and data between arbitrary parties. These problems stem from multiple sources, both political and technical. Patent issues, export controls, and law enforcement concerns about possible criminal use of strong encryption are some of the political issues that have inhibited the widespread use of these technologies. The technical issues involved in implementing a large scale public key infrastructure revolve around directory services and models of trust. By far the largest obstacle has been the lack of standards. Proprietary solutions have been available for some time, but they lack wide scale interoperability. There are several IETF workgroups addressing some or all of the issues involved in deploying a global public key infrastructure, but as of the date of this writing, no standards exist.

Secure messaging includes the authentication and possible encryption of messages. The field of secure messaging protocols has narrowed over the last few years. The contenders, which included PEM, RIPEM, MOSS, MSP, Secure X.400 , PGP, and PGP/MIME have been reduced to two worthy of further consideration: S/MIME and OpenPGP. Of these two, the support for S/MIME by such large vendors as Microsoft, Netscape, and Lotus bodes well for its future.

S/MIME is a de-facto standard developed to use the RSA algorithm. There are browser based e-mail clients from both Netscape and Microsoft, plug-ins for Eudora and several other e-mail applications, and standalone applications from several vendors. Unfortunately, there is limited interoperability between the various implementations at this time. S/MIME uses X.509 certificates and can make use of the same public key infrastructure that will be put in place for web based transaction. It is likely that interoperability issues will be addressed by standards processes, whether IETF based, or de-facto, in the near future.

OpenPGP is another de-facto standard on its way to ratification as an IETF standard. PGP had its beginnings as a standalone program of somewhat controversial origin for encrypting binary files, but has acquired facilities for handling e-mail over the years. PGP has provided a secure messaging solution to motivated users for quite some time, but commercial support is sparse. There is a plug-in available for Eudora, and Network Associates has acquired the original freeware and is marketing it. The trust model that PGP uses is totally user-centric as opposed to the hierarchical certificate authorities used by S/MIME. This essentially requires a separate public key infrastructure, assuming that one will be in place already for web based transactions. There is a dedicated group of users and it is likely that it will be in use for some time regardless of what occurs in the near future with standardization.

If the private member of a public/private key pair is lost, any data encrypted with the corresponding public key is rendered unreadable. Key recovery refers to a method for obtaining a lost key. There are three instances where this might be necessary: Where the user has forgotten the password or pass-phrase used to access the private key, where the user is no longer available, and where a third party wants to decrypt a message without the private key holder’s knowledge. We use the term "key recovery" because key escrow has received a bad name through its mandated use as part of the U.S. Government’s "Clipper Chip" and proposed FIPS standards for public key infrastructure where the law enforcement and intelligence communities want to retain the ability to intercept otherwise private messages. In any case, the salient point is that a backup copy of a user’s private key is retained. However, within the University, there is no requirement for a backup copy of a private key used for digital signatures. If a user can no longer access a private key used for signing purposes, they can simply obtain a new key pair. Documents signed with the lost key are still verifiable using the corresponding public key. It would be advisable to have a policy in place regarding the recovery of encrypted data. A key recovery system would be one way of addressing this business need. If such a system were used, each user would have two key pairs–one used for signing and another for encryption. There are several commercial systems available that implement key recovery. There is no need for wide scale interoperability of such systems and the same function could be implemented by a policy requiring plain text archiving ofencrypted documents.

A solution can not be recommended at this time and is not required to move forward on the deployment of a Universitywide authentication system. The Authentication Workgroup should continue to monitor this technology.

Certificates are persistent. Authorization is dynamic. Any information stored within a certificate becomes as persistent as the certificate itself.

The certificate payload should not carry any attribute data for use in authorization decisions, except a pointer to a server from which attribute data can be retrieved. Special situations that are not adequately addressed by this approach will be handled by separate subordinate certificate authorities. These separate certificate authorities are responsible for managing their own certificate issuance and revocation.

Once a certificate is issued and installed into a browser, it remains there until it expires. Even if the certificate is revoked by the issuing Certificate Authority (CA), it remains installed in the browser and can still be presented in response to authentication requests. Unless the application requesting authentication verifies the certificate with the issuing CA, a revoked certificate cannot be distinguished from a valid certificate. Further, any attribute data included within the certificate remains there, and could be used to obtain access to services even after a certificate has been revoked.

Attribute data used for authorization tends to be far more dynamic and diverse than authentication. Each person associated with UC has only one identity, and needs only one set of authentication information. A single individual, however, can have a wide range of authorization privileges depending on the role they serving in at the moment. Further, authorization changes over time as people change jobs, or simply move from the classroom to the office in the case of student employees. In many cases the revocation of authorization must be immediate. Because authorization is contextual, it cannot be embedded within authentication.

Some applications handle authorization internally. Conventional web access controls, for example, rely upon a database of authorized users and associated passwords stored on the web server. An individual that authenticates successfully to that database is then authorized to retrieve information from protected directories on that server. This model does not scale well to hundreds of thousands of users. Nor does it scale well to thousands of applications or servers.

The distributed authorization model is typified by a library card. The card identifies an individual to the library. It provides authentication. The card itself provides no authorization. Before the individual presenting the card is allowed to check out any books, the librarian consults an authorization database. That database is what determines whether or not the patron can take any books home, how many books can be taken, what fines or fees must be paid to restore authorization, etc. If a library card is revoked, the authorization database is updated immediately. The patron still has the card, and is still authenticated to the library, but that authentication no longer carries any authorization to check out materials.

Each CA within UC needs to have an associated attribute server in support of authorization decisions. That way the certificates can contain a persistent pointer to a location from which attribute data can be retrieved. The attribute server can be very dynamic, with real-time updates if necessary. The specifications for the information provided by the attribute server will be defined by the UC Systemwide Authentication Task Force. John Kunze stated the basic requirements for the attribute server succinctly - the service must be distributed and secure; it must be bootstrapped from the certificate; and it may be hierarchical.

The Universitywide interface into directory services will be through secure LDAP or HTTPS. Multiple APIs must be available to authorization services.

The APIs for authorization support services will be determined by the Authentication Workgroup, in conjunction with application developers, based upon functional requirements and standard protocols.

The mechanism used to issue a certificate determines the strength of the certificate. A certificate issued by an automatic online mechanism is considered weaker than a certificate which is issued to a someone through in-person identification. The strength of the certificate is important information for applications which require a certain level of authentication based upon security requirements. The workgroup identified three classes of applications to assist in its discussions of certificate strength and criteria for issuing certificates.

• No access to confidential or sensitive information
• Can not modify files or records
• All online transactions are verified by a follow-up communication or cross check
• Does not provide access to system level services

Our expectations are that low security applications would accept certificates of strength 1 and above.

• Limited access to confidential or sensitive information
• Can modify some files or records in systems of record
• Online actions checked through automated system checks

Our expectations are that medium security applications would accept certificates of strength 3 and above.

• Full access to confidential or sensitive information
• Can modify files or records in systems of record
• Online actions unchecked
• Inability to back out a transaction

Our expectations are that high security applications would accept certificates of strength 7 and above.

All online systems require some level of event logging and auditing of transactions. The level of logging detail and the complexity of the auditing increases with security requirements.

UC certificates will have a strength field in the payload. Strength values and their meaning need to be refined by a follow-up workgroup. The following strength scale is provided as a reference.

The strength field will use a scale from 1.0 — 10.0. The meaning of the integer portion of a number will be agreed upon Universitywide. Campuses can use the decimal portion of the number to provide a campus defined level of refinement to the scale.

Strictly for the purposes of beginning work on pilot applications the following values are assigned.

7 = a generic form of PhotoID

3 = a generic, automatically generated certificate

According to X.509, a certificate policy is, "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements." A certificate policy may be used by a certificate user to help in deciding whether a certificate, and the binding therein, is sufficiently trustworthy for a particular application. A more detailed description of the practices followed by a Certificate Authority (CA) in issuing and otherwise managing certificates may be contained in a certification practice statement (CPS) published by or referenced by the CA. According to the American Bar Association Digital Signature Guidelines (ABA Guidelines), "a CPS is a statement of the practices which a certification authority employs in issuing certificates."

David Wasley and Vance Vaughan drafted an outline of the CPS. A draft CPS is available for review by members of the Authentication Workgroup and Steering Committee at http://www.ucop.edu/~authuser/cap/policy.draft.html.

Until the end of 1996, a US Government administrative regulation, "The International Traffic in Arms Regulations" (ITAR) restricted exports of strong encryption software and hardware. Every cryptographic product with a key length exceeding 40 bit, for symmetric ciphers, and 512-bit, for public key exchange, is classified as "munitions" and prohibited from export. New export control regulations are in effect as of January 1, 1997 but is unclear if the change in rules has any implications for the users of cryptographic software.

The constitutionality of ITAR has recently been challenged in court. The Electronic Frontier Foundation (EFF) is sponsoring a lawsuit by Professor Daniel Bernstein to determine whether the Professor has the right to teach about cryptography, and collaborate with his peers around the world. A major point is whether he can publish source code that foreigners might be able to access, or speak it directly to individual who might be foreign. The case rests on established First Amendment law and relies on the fact that computer source code is human-to-human communication protected by the First Amendment (in addition to anything else it might be useful for.) In this case, U.S. District Court Judge Marilyn Patel (Northern District of California) issued a landmark ruling that computer source code is a form of speech protected under the First Amendment to the U.S. Constitution. She held that the current export controls violated the free speech rights of Daniel Bernstein, an academic cryptographer, who sought to distribute his work. The case is now on appeal to the 9th Circuit Court of Appeals, and a ruling is expected shortly. However, the ruling applies only to source code, not to the executables

On March 4, 1998 the Electronic Frontier Foundation (EFF) issued a joint statement with the American Civil Liberties Union (ACLU) and the Electronic Privacy Information Center (EPIC) at the Washington, DC, event launching the formation of a new industry-led alliance, Americans for Computer Privacy (ACP) which has been created to advocate against restrictions on the use of encryption.

In the meantime, several US-based companies offer scaled down, exportable versions of their cryptographic products to customers outside of the US. These 40-bit ciphers do not provide adequate security for most medium to high security applications.

The Authentication workgroup is not the appropriate group to interpret export restrictions on encryption software which is used with Public Key Infrastructure and certificates. The workgroup does not feel 40-bit ciphers are adequate for security in the University environment and will move forward with plans to create a PKI using certificates requiring the use of strong encryption technology which is restricted in use by export law.

Some University affiliates, especially foreign students and faculty, may be inconvenienced by export restriction laws which govern the use of the strong encryption technology.

Policies and procedures must be developed to guide the use of certificates for students, faculty and staff who travel outside of the United States. These policies must be referenced in the Certification Practice Statement. A Universitywide policy committee, with participation by legal counsel must address issues related to export laws.

Campus implementation plans which will be complete by September 30, 1998 and related tasks are listed to assist UCOP in Melvyl and BENCOM application development planning.

Melvyl will use the NetID in the certificate.

UCOP has obtained an OID which will be linked to the "University of California".

Three types of certificates, distinguished by their level of user identification, will be issued.

• NetID and/or CampusID included
• CampusID only
• No ID, i.e. anonymous, may include demographic information as defined by University contracts and is optional.

Each campus will maintain a single certificate authority for personal certificates. UCOP will maintain the anonymous certificate authority which will accept a personal certificate from a campus and issue the anonymous certificate.

The committee recommended a standard server naming convention for campus attribute servers in the format, attributes.domain, i.e. attributes.ucop.edu.

Four campuses, UCD, UCI, UCLA and UCSD, have a certificate server available and ready to work with UCOP on the MelWeb and Bencom applications.

Each campus was asked to send project planning dates which require the deployment of certificates to a population outside of the test pool to the UCOP Common Authentication Project (CAP).

Each campus was asked to identify when daily updates will be required from the University Directory and to provide the information to the University Directory development team.

Sal Gurnani will schedule a meeting of the campus directory service managers, University Directory developers and MelWeb and Bencom developers. Each Authentication Workgroup campus representative will contact their local directory services manager about representation at the meeting.

The committee discussed the importance of the Authentication Workgroup activities and agreed upon the following recommendations for ongoing work.

• Continue the workgroup with its current representation.
• The workgroup should produce a yearly report on the issues to be addressed in the upcoming year.
• The workgroup should maintain the authentication architecture statement and implementation specifications. The specifications will inform campuses on the requirements and processes required to participate in the authentication infrastructure and service.
• The workgroup should set goals three times a year for implementations which demonstrate interoperability of authentication and authorization services.
• The workgroup should establish deliverables for submission to the Steering Group three times a year.