DRAFT

DRAFT

DRAFT

A University Common Authentication Project

Information Resources & Communications

July 1, 1997

Introduction

Generalized "authentication" is one of the fundamental building blocks of modern information systems1. Strong, common authentication can enable distributed "authorization" in support of a wide variety of administrative and academic services. All UC campuses have efforts underway to develop authentication and authorization systems in support of their local information processing systems. The Office of the President, on behalf of the University, has similar requirements in support of distributed digital library systems and University administrative systems used by all campuses, including systems based on requirements arising from anticipated recommendations of the Employee Systems Task Force.

It is almost impossible to talk about authentication without getting into issues of authorization and further documentation of an individual's characteristics. While this project focuses on a methodology for affirming an individual identity, related projects must be undertaken to develop standard methodology for authorization and demographic data. Without those, this project will fail to realize it's potential value to the University.

A common University-wide authentication methodology that can support the broadest possible range of applications will enable greater and appropriate use of electronic transactions, licensed information resources and administrative systems throughout the University. Therefore, the Office of the President proposes an authentication strategy and implementation plan that builds upon existing efforts and is designed to move UC towards an integrated, reliable, flexible, and extensible authentication system.


Overview

"Authentication" in the strict sense is no more than a way of identifying an individual. It carries with it no inherent "authorization." It is critical to keep these two issues separate since to intertwine the semantics of authentication and authorization will restrict the generality of an authentication system.

Traditional information systems have used a "userid and password" to identify an individual. More correctly, the "userid" identifies the system account that the individual is trying to access and the "password" confirms that the individual knows a "secret" associated with that system account. The "userid" has associated with it privileges and authorizations and hence incorporates the semantics of both authentication and authorization. The "password" is a secret intended to be known only to the account owner and can be changed, if necessary, without changing the authorizations associated with that account. Thus a password is not authentication it is part of the system of verification that an individual is properly associated with an electronic identity.

Reliance on "userid and password" is considered a "weak" authentication strategy since they can be compromised rather easily. Some stronger authentication strategies have relied upon "one time" secrets such as a password that automatically changes each time it is used2. One implementation of this type is an electronic "secure ID card" that presents a random number to the user which must be forwarded to the target computer system within 59 seconds to be seen as valid. Such systems, as a universal solution, are generally quite expensive and require special hardware be issued to every account holder. They may be a good choice for protecting access to highly sensitive systems but do not scale well to a population the size of the entire University of California. They also do not, today, take into account the need for authentication that may depend upon non-UC registration authorities.

The two most promising generalized strong authentication strategies today are those based on Kerberos3 and those based on Public Key Certificates4. Each has strengths and weaknesses. Each was developed for authentication in a somewhat different environment. While Kerberos has been available for much longer, it still is not widely implemented and there are several incompatible versions of it in use today. Public Key Certificates (PKC) are emerging as the technology of choice for use in electronic commerce transactions, but there are not many full implementations yet and there are significant problems to be solved in the logistics of dealing with the "certificates".

We discuss these two technologies below and then propose a strategy for an initial implementation of strong UC-wide authentication.


UC Requirements

A UC-wide authentication strategy both should fulfill current needs and be adaptable, as far as can be foreseen, to the needs of future systems. To those ends, the requirements that have driven the proposed strategy include:

1. It must be possible for every person associated with the University to have a verifiable and secure electronic identity than can be adapted for use with a wide variety of UC systems that will require authentication.
   
   
2. Passwords or other "secret tokens" must never appear in the clear on a network. The authentication system must be usable from networks external to the University as well as within the University.
   
   
3. The authentication system must work from a variety of client platforms including Macintosh, Windows, and Unix. It must be adaptable to a variety of server platforms including IBM mainframes, Unix, and PC-based servers. It must be adaptable for use with new systems, such as financial and HR.
   
   
4. The system should be adequate to identify individuals for the purpose of access control to inquiry and update functions within administrative systems such as Payroll/Personnel, Benefits, and student information systems. It should be useable similarly for administering access to UC-licensed information resources and services such as printing. It should be "strong" enough that it can be used for services that may require billing.
5. 
   
   It should take advantage of commercially available technologies and recognize the direction that market forces are taking;
   
   
6. There should be interoperability with both clients and servers outside the UC domain in support of electronic commerce and other transactions with University academic and business partners. For example, the Pathways system for student registration should be able to interoperate with an authentication service that would register high school students generally.
   
   
7. The system should support authentication of documents as well as individuals. This would be used to support network-based transactions, to validate on-line documents, and to support "signed" electronic mail.
   
   
8. The registration of individuals in the system will be done by authorized UC personnel, under strict guidelines and policies, and only for individuals associated with the University. A policy must be developed to define the meaning of such registration and the supported scope of its use.
   
   
9. Authorization as well as demographic information about individuals will not be part of the authentication system per se. Authorization generally will be specific to each application. There may be "class authorizations" that are based on affiliation or role within the University. Demographic information such as that will be retrievable from a database keyed from the same authentication token

Kerberos

MIT developed Kerberos as part of the Athena project in the 1980's. It uses a shared key approach and never puts a secret token on the network. It was originally intended to support a relatively modest, closed community of users although it has been extended to allow so-called cross realm authentication.

All individuals are registered in a central database which may be replicated for reliability. The database contains all the secret passwords so it must be guarded very carefully.

Once authenticated to the Kerberos server, an individual requests a "ticket" from a Ticket Granting Server (TGS) for a particular service. This is presented to the applications server which attempts to decrypt it with an appropriate secret key. If this is successful, the Kerberos credential is deemed valid.

In DCE Kerberos, the credential can also contain authorization information. This does not have to be used by UC applications but may be required for some third part applications.

Kerberos sessions inherently have DES encryption keys that could be used for secure communications over any network. However, since the encryption method uses a shared key, it is not suitable for digital signatures.

Kerberos has been implemented for all the platforms of interest and is a cornerstone of the OSF DCE technology. DCE Kerberos adds the privilege and registry services to the key distribution and ticket granting services provided by standard Kerberos.


Public Key Certificates

The community interested in general electronic commerce require an authentication methodology that is not dependent on a single central registration authority. More along the lines of a passport or notary function, authentication for electronic commerce is intended to ensure that the individual is a known entity and independent transactions can be attributed without repudiation by that entity.

A comparison of Kerberos and Public Key Certificates

Issue	Kerberos	Public Key Certificate
Community	Intended for a closed community under one administrative entity.	Designed for general commerce without a central administration.
Scalability	Multiple authentication servers can interoperate but require individual trust agreements.	Can support millions of users.
Trust Model	All trust resides in the central server and in the ticket granting service.	Trust exists among cooperating certificate authorities.
Vulnerability	A single database holds all the keys.	Users may leave private keys on their workstations. Certificates are hard to "revoke".
Authorization	DCE Kerberos provides for an authorization payload which may or may not be useful.	Can be included in certificate payload but is not inherently part of the technology.
Digital Signature	Not supported.	Inherent capability. Must be supported with additional software.
Fully Encrypted Data Streams	Inherently possible, using a shared session key.	Possible using the keys but with greater computing overhead than Kerberos.
Performance	Quite good. DES is more "computationally efficient"
Client Software	Commercial software available for all platforms of interest. Also, proxy servers for web applications avoid the need for software distribution in less secure applications.	Many web clients are "certificate ready". Other client support needs to be investigated but seems likely considering the market support.
Market Support	Available in DCE and from software vendors.	Of very great interest to the electronic commerce marketplace. Basic to the VISA/MasterCard SET protocol. Supported by popular web browsers.

Public Key Certificates (PKC) provide that capability. A registration authority creates a digital certificate, using Public Key Cryptography, that represents a well defined level of assertion about the identity of an individual. A server can verify the validity of that certificate and can verify that the issuing Certificate Authority (CA) has an established trust relationship with the server's local CA.

There is no inherent authorization in a Public Key Certificate. However, the certificate can be designed to contain a variety of information about the holder, if desired. Certificates can be terminated by expiration or by revocation.

Successful use of certificates requires a public key infrastructure (PKI), including a registering Certificate Authority, a directory, and a set of trust agreements in order to allow a server to fully validate a certificate. In addition, a certificate revocation and archiving mechanism must be in place.

The logistics of user support for PKC are problematical. Mobile users such as students must be able to carry their private keys and possibly their certificates with them or retrieve them from a highly secure server. They must be careful to protect their private key, e.g. never leave a private key on a public workstation.

The ISO X.509 standard seems to be the choice for most implementations currently of PKC/PKI. Many web browsers are now "certificate ready" and several commercial certificate authorities (e.g. Verisign) are in operation offering the possibility of outsourcing of the PKI.


An Integrated Strategy

The Office of the President proposes to develop an authentication capability that will exploit the best properties of both DCE Kerberos and X.509 Public Key Certificates. Servers and support infrastructure for both technologies will be developed. Applications such as the BENCOM system and the DLA licensed databases will be used as prototype systems to test the viability of these technologies.

A DCE Kerberos server suite will be implemented in support of legacy applications and those systems that are most easily adapted to this style of authentication. Kerberos might be preferable, for example, with systems that are to be used by a small, relatively closed community of users under unified administrative control.

To ease the problem of software distribution for web based applications using Kerberos, a "proxy server" using a secure socket layer (SSL) will be available. In this way, a client will need only a standard SSL-capable browser. Please note that this type of proxy system requires the user to pass their private password to the proxy computer. This runs counter to strong authentication strategies, could set a bad precedent in users' minds, and might lead to illicit collection of users' passwords.

Clients accessing highly sensitive applications, or applications that don't have a web interface, will require specific DCE Kerberos client software to avoid the vulnerability represented by the proxy server. OP intends to license a package such as Gradient for this purpose.

A public key infrastructure (PKI) will be developed, including a Certificate Authority at OP, and directory and key management systems. Certificate contents will be defined to include only data that will not change frequently over the lifetime of the certificate. Compound certificates of shorter duration can be created as needed for specific applications.

Digital signature capability will be developed using the public key infrastructure. The logistics of long term use of a certificate for this purpose need to be defined, as well as standards for how the signature is structured, etc.

The logistics of private key portability will be addressed by developing a special purpose server with Kerberos access control that will archive private keys. This will not solve the problem of leaving private keys or pass phrases on public workstations so such certificates may have to be short lived, at least for awhile. Ultimately keys should be portable via "smart cards" or other physical mechanisms.

Finally, there are some applications where Kerberos is more efficient, such as authenticated transactions, yet the user or the campus may prefer a PKC system. DCE Kerberos is moving towards an architecture that would provide the capability to initiate a Kerberos session using a PKC. After initialization, transactions might use the current Kerberos ticket mechanism.

Both Kerberos and PKC require a "registration authority" with rules and requirements for setting up individual authentication tokens. OP will work with campuses to define and refine those requirements.

The strategy outlined briefly above integrates Kerberos and PKC in a way that will allow both to be used for applications today, exploits the strengths of both, and allows for the evolution of systems towards either technology.


Implementation Plan

The OP implementation plan for the Common Authentication Project (CAP) is based on the following assumptions:

1. The University will control the administration and operation of its authentication infrastructure. However, this authentication infrastructure can not operate in isolation. It must be able to interoperate with authentication systems being deployed at other universities as well as other external organizations such as publishers, information providers, and the commercial world at large. It must interoperate with commercial web systems and secure e-mail systems.
   
   
2. A separate demographic database system will be created that will store information about members of the UC community. This information will be accessible using a UC CAP key.
   
   
3. The practical necessity of getting something built and in place in a reasonable amount of time may require that the initial implementation be centralized. However, any architecture deployed must be capable of scaling to allow distribution of administration and data repositories across the UC campuses. There are some considerations surrounding reliability in a centralized system in that it inherently has more centralized points of failure than a distributed system. Functions like replication and other forms of redundancy will need to be built in to guarantee an acceptable level of reliability required for this type of crucial infrastructure.
   
   
4. The university will not accept liability for use of its authentication process for non-University purposes. This has applicability principally in use of certificates. A Certificate Practice Statement will be developed specifying the supported scope of use of a UC issued certificate.

Major Milestones for the Common Authentication Project

1. Establish UC as its own Certificate Authority, Define Policies for Certificates and install initial certificate infrastructure - December 1997
   
   
2. Add support for certificates to selected applications - 1st quarter 1998
   
   
3. Fully populate demographic database and start issuing certificates - 2nd quarter 1998
   
   
4. Set up systemwide Kerberos authentication server - by December 1997
   
   
5. Add support for Kerberos authentication to selected applications - by 1st quarter 1998
   
   
6. Distribute and install required Kerberos client code to designated users - 2nd quarter 1998
   
   
7. Build Kerberos/X.509 Web based gateway so users who need to can use Kerberos authentication to download certificates - 1st quarter 1998
   
   

Task List for Building a Certificate Infrastructure.

1. Determine which applications will have their access governed by certificates.
   
   
2. Have UC, through the Office of the President, establish itself as a Certificate Authority for persons affiliated with the university. This will be done by licensing the appropriate certificate issuing software and administrative authority from a vendor like Entrust. This will allow the University to define and control its own certificate infrastructures and policies. OP will also establish a trust contract with one or more national Certificate Authorities in order to build a transitive trust mechanism.
   
   
3. Define the needed classes of compound certificates in order to include the types of demographic data required for different applications. This will include things like campus affiliation, type of association with the university (student, faculty, etc.), period of validity, and similar data. A major part of this activity will be defining all of the different communities that need to be included in the UC certificate hierarchy. This issue touches on authorization as well as authentication.
   
   
4. Add support for certificates to one or more UCOP Web based applications. Likely candidates for this are the Web based version of MELVYL and the California Digital Library Initiative.
   
   
5. Set up a mechanism for users' to be able to apply for certificates and the ability to download a certificate to their workstation from a secure archive. (See below for a discussion of what to do about public and lab machines). This procedure should include the full realm of certificate management activities including issuance and revocation.

Task List for Building a DCE Kerberos Infrastructure

1. Determine which applications will have their access governed by Kerberos.
   
   
2. Install and set up a DCE Kerberos authentication environment at UCOP.
   
   
3. Set up DCE principals and passwords for users in the demographic database.
   
   
4. Add DCE Kerberos support to selected applications like payroll and student records.
   
   
5. Make arrangements to license DCE client software for end user machines like Macs, PCs and UNIX workstations on behalf of certain critical applications. This is estimated to be approximately 10,000 client DCE licenses for the whole UC system.

Dealing with Public Workstations, Lab Workstations and Users Who Use Multiple Machines

Kerberos does not present any problems in this area beyond the fact that DCE client software needs to be resident on all the machines that a user would be using, or a proxy server must be available to the user. With this done the user simply authenticates himself with the Kerberos server and normal processing occurs.

Private keys however do present a problem in that they are not easily transportable (beyond putting them on a floppy disk). In order to support use of certificate enabled applications by users at public, lab or other machines besides their normal workstation, it is proposed that such individuals would use Kerberos to authenticate themselves to an application that would download and install their private key and certificate on the public workstation for the specific user. That information must be encrypted on the workstation and protected by a suitable pass phrase.


Campus Involvement

OP encourages involvement of appropriate campus staff in the design and development of this prototype system. There are many issues to be resolved and these may have long term impact on the viability of the final prototype. Participating campuses would have early access to the prototype servers.

Campuses would be required to:

• Actively participate in design discussions, technology investigations, and preparing recommendations;
  
  
• Administer certificates for their site;
  
  
• Administer DCE security services for their site;
  
  
• Provide a secure server that would store a replica of the demographic database and possibly the authentication databases;
  
  
• Actively test prototype applications against the authentication systems and the demographic database system.

Summary

OP wishes to catalyze the development of a common UC-wide authentication system as quickly as possible. We have chosen a complex strategy but one which we feel will serve the University well in the next few years at least. We seek active involvement by the campuses in this critical project.

Comments?