Identity and Authentication: Next Steps

(DRAFT – 12/17/2003)

Introduction

Since January of 1998, the University has been working on the implementation of a Public Key Infrastructure (PKI) to provide a common authentication mechanism for a wide variety of services. As part of this design, unique, system wide, UC specific identifiers would be created for every member of the University community and included in the PKI credential. The need for a common identity management and authentication mechanism has not changed; if anything, it has increased over the past five years.

1. The University's self-service employee benefits applications (and, presumably, other University applications) use Social Security Number as their primary identifier of people. This is no longer legally viable.

2. The Health Insurance Portability and Accountability Act (HIPAA) has highlighted a number of issues concerning privacy and authenticity of patient health information in electronic form requiring stronger authentication for management of access to these data.

3. The number of different applications that a given individual makes use of is constantly increasing, creating the desire for single sign-on solutions to improve the user experience.

4. The proportion of university transactions that occur electronically is increasing; we need to improve UC's ability to authenticate and audit those transactions.

5. Many University applications are vulnerable to attacks, because those applications utilize weak authentication methods. For example, transmitting identifying information and passwords "in the clear" makes them vulnerable to interception and misuse.

6. Many University applications maintain their own repositories of information that could be very useful to identity thieves. This generates greater risk to the University under the terms of California Civil Code Section 1798.29 (SB 1386) than if that information were maintained in a smaller number of repositories. Management of access to these data need to be strengthened.

As was recognized in the original proposal for a Common Authentication Project, the technologies needed to address these needs can be categorized into two general areas:

1. Authorization to use system-wide applications and resources

2. Privacy and Non-Repudiation of electronic mail and generic documents

As described later in this document, PKI technologies have not matured as quickly as anticipated five years ago. On the other hand, these needs still exist for the University.

This document is intended to start a discussion to determine a refined strategy to address these needs.

Authorization

The number of system-wide and multi-campus applications will increase, partially due to implementations at UCOP, but also due to collections of multiple campuses that will choose to share applications hosted at one their members' sites. The web services model will create a unified working environment composed of many discrete service platforms. In addition, distributed functions made possible by IT will require more complex definition of common roles and responsibilities across systems and management of access will need to be streamlined.

The industry seems to be moving toward a federated approach to access control; Shibboleth and the Liberty Alliance, both of which are based on the Security Assertion Markup Language (SAML), are prime examples of this. We believe that this model would work well within the University. Campuses would operate mutually-trusted attribute authorities that reveal commonly-defined information about people to trusted applications. Authentication itself would be invoked independently by the attribute authorities, so campuses would have the option to choose authentication technologies that best suit their needs, within the bounds of mutual trust.

Access to externally-licensed resources, such as library content, is moving in the direction of a federation of institutes of higher education and their content providers, most likely Internet2's InCommon. Shibboleth is the technology that will be used by InCommon.

The following steps are recommended to assure UC's alignment with this envisioned future:

1. Each campus should establish an authoritative enterprise directory, if it has not already done so. In order to ensure a common set of attributes, the Enterprise Directory group's work will need to be completed with respect to defining UC's common attributes. The current status of that work group can be viewed at http://www.ucop.edu/irc/edp/welcome.html.

2. Each campus should establish a Shibboleth origin for its community of users. This is probably a shorter-term strategy than the common set of attributes. Over time, other technologies may be required for future applications, but they would deployed to access the same repositories of UC's common attributes.

3. Each campus's enterprise directory will likely contain a campus-wide identifier for each member of that campus's community. UCOP should modify Payroll's IID subsystem to link to campus identity management systems, when desired, and to invoke a system-wide identity management system that will assign UCnetIDs to people; the UCnetID will stay with those people even if they transfer among the campuses. Student systems can then be modified to invoke IID to assign UCnetIDs to students, as appropriate, and an interface will be provided that will allow any campus-designated application to assign a UCnetID. Campuses should add UCnetID as an attribute in their enterprise directories. Initially, employees should be assigned UCnetIDs; other communities, such as students, alumni, etc. can be added as needed (and as appropriate information for identity matching is available).

4. A system-wide person repository should be created to support the assignment of UCnetIDs. We will need to decide what other information should be included. Most likely this will be in support of white pages services, if anything, but it may also be advantageous to use the meta-directory to cache other information that may be needed by system-wide applications. 

Privacy and Non-Repudiation

As stated above, there will be a growing need for privacy and non-repudiation of electronic mail and other documents. A particular type of document that will require privacy and non-repudiation in the future will be electronic business transactions, encoded in standard formats, such as ebXML or BPEL.

The major technologies supporting privacy and non-repudiation are based on asymmetric cryptography, but proprietary, server-based solutions are available that use other technologies. For electronic mail, S/MIME and PGP dominate, with PGP primarily addressing smaller communities of trust. For electronic business transactions, digital signature standards for XML dominate, but the schemas for the transactions themselves are not always clear. There is not a clearly dominant technology that provides privacy and non-repudiation of generic documents.

This area requires more study. While it is possible to provide privacy and non-repudiation in specific circumstances (and we will need to do so), it is not clear what long-term solutions will be adopted by the technology community. Here are some possible interim steps:

1. Participate in pilot projects, such as the federal government's electronic submission of grant requests and the implementation of secure electronic mail services if required for HIPAA compliance.

2. Consider S/MIME and PGP for small communities of trust that require secure electronic mail services until S/MIME (or some other technology) becomes practical and cost-effective for broader adoption within UC.

3. As the schemas for electronic business transactions become well-known, use XML encryption and digital signing standards to provide privacy and non-repudiation.

Recommendations for PKI at UC

We believe that asymmetric cryptography, the theoretical underpinning for PKI, and its embodiment in an infrastructure that supports important functionality such as data security and validation remains an important element for future University IT systems. No technology other than some form of PKI has emerged yet to provide those functions. Furthermore, some limited set of applications such as health care authorizations or high value University transactions could make good use of stronger authentication than currently exists. Therefore, it is important that UC continue to develop expertise in this technology and understand its practical application both within UC and in the broader marketplace.

As a result of discussions with campus IT representatives, we propose to take the following direction for the next 12-18 months:

1. Identify specific important UC business applications, such as licensed resource access or electronic grant applications, and concentrate on demonstrating use of authentication and digital credentials with those as prototypes.
2. Investigate the cost of new PKI technology, including different options and support models, with the goal of determining the most cost effective way to acquire server certificates and a PKI for at least limited use of identity/client certificates across UC. An RFP would be issued to determine if our best solution is a volume purchase, an in-house implementation based on purchased or open-source software, or some combination. This effort will also include the determination of funding and cost sharing to support the issuance of certificates.
3. Continue to investigate and develop knowledge about important elements of authentication technologies, such as “smart chip” devices. Continue to work with higher education and industry groups developing additional standards and protocols for identity and privilege management systems. Schedule presentations on authentication and authorization technologies that are important today and into the near future.

Ultimately the use of asymmetric cryptography may become almost invisible to the normal user but it will undoubtedly remain an important element of a secure distributed IT infrastructure.

Appendix: PKI at the University of California

In July 1997, a University-wide “common authentication project” was proposed to the Joint Operations Group (JOG). The goal of the UC Common Authentication Project (UCCAP) was to produce a robust and flexible common approach to authentication of on-line users which would eventually support a broad range of applications and services. Strong authentication was seen as the cornerstone for other network middleware services such as generalized authorization services and secure transaction services. Authentication credentials issued at one campus would be recognized at other campuses and could be used as a basis for access to resources and validation of transactions, as well as new requirements that might arise.

In January, 1998, the UC-wide Authentication Working Group recommended development of common format digital identity credentials that would serve all members of the UC community. These credentials would be digitally signed documents employing asymmetric cryptography to establish document integrity and authenticity. Current international standards refer to the set of servers and services that support such credentials as a “public key infrastructure” or PKI.¹ The credentials are “PKI certificates” that carry identifiers unique to the credential subject.

PKI certificates would enable reliable and flexible identification of individuals. The credential would be used in conjunction with enterprise directories to determine eligibilities, permissions and authorities of the credential holder. In turn, these data would support the use of “digital signatures” on important transactions. This system could be interoperable with parties external to the University as well to enable “business-to-business” applications.

In addition to supporting identity credentials, the PKI would support (potentially) data security through use of encrypted transmission and storage. Web-based e-commerce already makes use of this capability. Person-to-person e-mail and secure storage of sensitive data also could make use of this.

The AVP-IRC obtained a commitment of on-going permanent funding to support the basic PKI technology for all campuses and UCOP. In August 2000, a three year contract was signed with Verisign to provide this technology and support for the startup and initial implementations.

What we’ve learned so far

The Verisign implementation was plagued with difficulties and has not resulted in a widespread deployment of a PKI. The technology is in place at UCOP and partially in place at UCLA and UCI. UCB has expressed interest in deployment at their campus.

Other campuses have postponed or halted their deployment. Most campuses have deployed a Kerberos infrastructure which serves a variety of local needs. Some campuses are developing a “single sign-on” mechanism based on web browser “cookies,” supplanting that functionality of PKI for local services.

Meanwhile, the funding promised for this project has not been provided and is not likely to be forthcoming given the current financial crisis.

Some of the impediments to deployment have been:

• Lack of compelling applications requiring the strength of PKI credentials;

• Lack of maturity of the User interface which makes use of PKI certificates difficult in some applications;

• Lack of a reliable enterprise directory or “person registry” on some campuses from which to issue and support use of the credentials;

• Inconsistent vendor support for the technology across different platforms;

• Incomplete standards resulting in incompatible or limited functionality.

In addition, new mechanisms for privilege management have become available and may dictate a different approach to the individual identity credential. For example, the notion of “federated identity” whereby a user can authenticate to a local domain and then that domain is trusted by other domains to assert authorization information on behalf of that user alleviates the need for interoperable authentication.²

Since the current Verisign contract ends this coming August, it seems appropriate to review not only the Verisign product but also the role of a PKI within UC.

Costs

The following table shows the funds originally committed and funds allocated to IR&C in support of the PKI project:

Actual spending has tracked the funds allocated, except that spending was not cut during FY 2002/2003. The accumulated spending for PKI is projected to exceed the accumulated funds allocated by $366K at the end of FY 2002/2003.

The cost of continuing the PKI project on a small scale, as described in the "Recommendations for PKI at UC" section of this document, is expected to be approximately $120K/year for personnel and equipment, plus the cost of issuing certificates. If we were to stay with Verisign, the cost of issuing certificates would be approximately $60K/year for the first 1,000 certificates, plus $30K/year for each additional 5,000 certificates, with higher discounts at higher volumes. We expect to identify a more cost-effective solution, however, as described in the "Recommendations for PKI at UC."

Appendix: Federated Access Control

[Each campus has its own Attribute Authority, supported by that campus's Enterprise Directory and Authentication systems; only Berkeley and Irvine are shown here.]

On the left, a member of the Berkeley campus is using UC For Yourself (UCFY), which is hosted at UCOP. In order to determine who this person is, UCFY asks Berkeley's Attribute Authority for this person's UCnetID. Berkeley then authenticates this person, retrieves the UCnetID, and sends it to UCFY.

On the right, a member of the Irvine campus is using JSTOR to retrieve a library-licensed document. By policy, the University does not reveal this person's unique identity (e.g., UCnetID) to JSTOR, but is willing to reveal that this person is a member of the UCI community. Authentication and attribute retrieval occur as in the Berkeley/UCFY case, but only the "member" affiliation is sent to JSTOR.

Note that this model allows for certain aspects of Single Sign-On (SSO) services, as the Attribute Authorities can maintain a session with the user after the initial authentication step to allow attributes to be passed to other applications without additional authentication steps. As with any SSO system, though, target applications must be designed to make use of the Attribute Authorities, or gateways must be built. SAML's apparent industry acceptance may result in off-the-shelf solutions for this, but that is yet to be seen.

Appendix: Proposed Modifications to IID and uDir

1. invoke a local identity management management (if configured to do so), and

2. invoke uDir's identity management system to provide a real-time service to create UCnetIDs.

Both systems would be enhanced with a more sophisticated matching algorithm to meet current campus needs. This results in the following relationships:

The campuses that use IID to administer their student IDs would automatically have their students entered into uDir; other campuses would need to modify their student systems to accomplish this. The interfaces would be designed to allow other applications to create uDir entries and acquire UCnetIDs for other members of the University's extended community.

In order to do this, uDir would contain the UCnetID, the information required for identity matching, and the campus identifiers.

If we do need to maintain any other directory information, then the model developed by the enterprise directory group is probably still the best way to proceed. That is, campuses run their own directories and identity management, and UCOP creates a system-wide meta-directory that caches some of the campuses' information. Administration of the UCnetID's central identity repository would be distributed to the campuses.