Certificate-based Proof of Identity to Third-Party Service Providers

Last updated: 13 July 2000 (draft)

Introduction

Many Web publishers license their material or provide services to populations of other institutions. Especially popular is the model of a portal which provides personalized services based on a user's identity within a subscribing institution.

These publishers typically need to verify the user's identity in some way before allowing access to some services. This identity can in some cases be local to the portal; in other cases, it must be directly mappable to the user's identity at his or her institution.

This document describes a simple method for establishing proof of identity of a user without revealing user secrets or allowing the Web publisher access to the subscribing institution's authentication and authorization system(s).

Requirements

We expect that the Web publisher has a CGI script which can forward a user to a URL passed as an argument, if the script decides that the user is valid. How can the script make that decision? It must have some information from the subscribing institution, passed also as an argument, that it can examine and accept or reject.

Typically this comes in the form of a fixed per-institution user id and password. The institution could then pass the user's name as an additional argument. The script would check the user id and password, and if these are valid, it would accept the username and forward the user to the appropriate URL.

This method is not particularly secure and doesn't scale well. Each institution must have a fixed id and password; these are typically never changed. If the id and password are known by someone outside of the institution, that person has guaranteed access. Worse, that person has guaranteed access as any user he or she likes (provided that he or she knows the format of the user name passed as an additional argument).

Rather than a fixed id and password, we need some credential that is not forgeable, cannot be re-used, and can be verified as having come from the subscribing institution. This credential should somehow embody the user name argument as well, so that a bad guy can't substitute the user of his or her choice while leaving the institutional information intact.

These requirements lead us naturally to the notion of public key technology. In that framework, we would have the following requirements:

The credential must contain the user name.
It must have a time stamp.
It must be digitally signed by the institution.
The publisher must be able to verify the signature (it must have the public key in a trusted list).

Use of Certificates as Institutional Credentials

Rather than devise a new format for an institutional credential that meets these requirements, we propose the use of X.509 certificates. These certificates are well-defined according to an open standard, are in widespread use across the Internet today, and require tools which most buisinesses will be investigating eventually, as the adoption of public key technology becomes more and more widespread.

The certificate has a time stamp already; the specification requires it. The user name can be placed into the Subject DN or into an appropriate extension (yet to be determined). It is digitally signed, and the publisher can be given the certificate of the signer (an institutional server), for verification purposes.

These certificates will not be client certificates in the usual sense; that is, they will not be held by the user, and the corresponding private key will also not be held by the user. [Attribute certificates might well be more useful, but that requires software tools which are not currently widely available.]

Rather, these certificates will be issued upon request by the institution's authentication and authorization system. They will be passed back to a CGI script on the institution's Web server; the script will then pass it along to the script at the publisher's site. The private key generated along with the certificate will be thrown away because it is never needed in this approach. The certificates will have a short life to make validation easier; 5 minutes is probably a good length.

Subscribing Institution Implementation

We describe a typical scenario.

When the user sits down at a workstation and wants to access the publisher's service, he or she will go to a link provided on the subscribing institution's Web site. That link will invoke a CGI script on the subscribing institution's Web server, passing it the URL the user wishes to vist, and the URL of the CGI script on the publisher's host that acts as the gateway.

The CGI script will output a form which asks for a user name and password. Embedded in the form will be the destination URL and the URL of the publisher's CGI script that were passed in as arguments. This form will invoke a second CGI script that does authentication.

When the user fills in the form and submits it, the second CGI script will validate the user name and password and will request a certificate and private key from an institutional certificate server.

The script will throw away the private key, and construct a URL which points to the publisher's CGI script. As arguments to the script (buried in the URL), the certificate and the destination URL will be passed.

Publisher Implementation

When the publisher's script is invoked, it will extract the certificate and the desination URL from its arguments. It will then check the certificate for validity by doing the following:

Checking the signature using the signer's certificate (provided during pilot setup)
Checking the timestamp to be sure that the certificate is valid and has not expired
Checking a temporary cache to see that this certificate has not been used before (Note that this cache needs only to keep certificates around for 5 minutes.)

At this point the publisher knows that the certificate is valid. It must extract the user name from the certificate, and use it in whatever state-keeping mechanism the publisher has in place. (Session ID in urls, cookies, ...) It should also stuff the certificate in its temporary cache for checking against re-use.

Finally, the CGI script will refer the user to the destination URL, setting up any session management it may need.

Vulnerabilities

This is not a failsafe 100% secure system. Here are some of its vulnerabilities.

It is possible that someone could spoof the publisher's site, retrieve the arguments to the CGI script on their way to the publisher, and use them first.

Someone could conceivably hijack the subscribing institition's certificate server (very difficult).

The user's name and password could be compromised in any of the usual ways.