User Authentication and Software Distribution on the Web

Introduction

Background

This paper discusses several authentication mechanisms, and describes why it was decided to base an authentication system around the PGP implementation of public key cryptography. It then goes on to describe how PGP authentication was integrated with the WWW, and how user keys are generated and verified using WWW and email. The uses to which strong, system wide authentication can be put are discussed, focusing on the issues associated with allowing users to purchase and download commercially licensed software packages and with allowing WWW based access to administrative systems containing sensitive personnel data.

Methods of user authentication available on the WWW

Basic Authentication

The basic authentication[HREF 5] mechanism supported by most Web servers and browsers provides a userid and password mechanism for restricting access to static pages or processing scripts. Access restrictions can be defined at the directory or document level in either a central access configuration file or within a specially named access configuration file in each directory. They can be combined with access restrictions based on the IP name or address of the requesting client.

Web site administrators create userid-password pairs and then nominate which userids can access which directories or documents. Groups of userids can be created to make management simpler.

Access restrictions are implemented by the server code, and hence no local programming is required. The server sends a special HTTP response to the client indicating that authentication is required. The client then prompts the user to supply a userid and password, which it then returns to the WWW server. Processing scripts protected by basic authentication are able to query their environment to retrieve the authenticated userid.

Although conceptually simple, the basic authentication system has many drawbacks:

• vulnerable to snooping - the userid/password are sent from the client to the server either in plaintext or uuencoded.

• administration overhead - maintaining userids and passwords requires significant effort as the number of users increases. Because the userid/password database is specific to the WWW server on one machine, this effort cannot be amortised over several applications or systems.

• user overhead - yet another userid/password combination for users to remember.

• management overheads lead to security problems - because the overhead of managing individual userids is so high, there is a temptation to implement group userids and password which provide access but do not identify an individual user. However, "leakage" of passwords from group accounts and changes to group membership make such arrangements extremely insecure.

SSL

The Secure Sockets Layer (SSL)[HREF 6] architecture was created by Netscape to overcome the security and scalability problems of the basic authentication system. Their immediate requirement was to allay the fear of users entering credit card numbers on WWW forms. Hence, the initial implementation allowed clients to authenticate servers (but not vica versa) and then establish an encrypted session with the authenticated server over which a credit card number and other information can be sent.

WWW Servers authenticate themselves to clients by sending them their public key which has been signed ("certified") by an authority trusted by the client. The client then generates a random session key which it encrypts using the public key of the WWW server and sends it to the server. The server uses its private key to decrypt this message, hence recovering the session key. From then on, the session between the client and WWW server are encrypted and information (such as credit card numbers) can be sent without risk of being snooped on the network.

The initial releases of SSL did not support authentication of users, although once a secure session is established, it is safe to use a traditional userid/password system to establish user authentication. Furthermore, the list of authorities trusted by the client to certify public keys was very small. SSL has since been expanded to support client authentication (and hence client keys) and expand the list of certifying authorities.

As its name implies, SSL is not a WWW specific protocol. It is an architecture for establishing a secure communications session over a TCP protocol, such as TCP, FTP and POP. It is not intended to provide a digital signature type feature, where a user electronically "signs" a request, although mutual authentication of client (ie, user) and server using public keys goes a long way to establishing an environment for non-repudiation of client actions.

SSL became available after we began our project to use PGP for authentication. However, there are several issues that make it a problem for its use in CSIRO:

• US export restrictions limit the strength of the SSL implementation available outside the US. Although the strength of the exported version is probably adequate for the uses to which we would be putting the technology now, this will probably not always be the case, and hence its adoption could restrict our security in the future.

• Getting keys to use with SSL involves effectively purchasing them from one of the certifying authorities which were initially hardcoded into the Netscape client. This situation has improved, but other solutions such as PGP have no such restrictions.

• A major comparative strength of SSL is its session encryption ability. However, as Netscape concede, this area is being addressed by the forthcoming IPSEC and IPV6 work within the IETF, and SSL will likely become redundant for this purpose. Public-domain alternatives such as Secure Shell (SSH) exist for session encryption.

SHTTP

SHTTP[HREF 7] is a set of protocol additions to HTTP which support strong authentication and encryption. Before the arrival of SSL, SHTTP seemed the protocol-most-likely but it has appeared to flounder as SSL grabs the market share. As a WWW specific protocol, SHTTP would form only part of the solution for an organisation such as CSIRO.

Introduction to public key cryptography

The basis of public key cryptography are mathematical transformations performed by an algorithm and 2 keys. Simply put, the algorithm and the keys have these properties:

• 2 keys are used - they comprise what is known as a key pair

• the transformation performed by one key can be reversed by the other key

• knowing one key does not allow you to derive the other key

A user wishing to use public key cryptography to receive encrypted information or digitally sign a message generates a public-private key pair. The private key is kept secure locally, typically by encrypting it with a password or pass-phrase before writing it to a local disk. The public key is published far and wide.

Someone wanting to send a message which can be understood only by this user obtains their public key and encrypts the message with this key. Given the above properties, only the user's private key can decrypt the message and assuming that the intended user is the only person in possession of that key, only they can decrypt and read the message.

Figure 1. Encryption and Decryption using a public/private key pair.

To digitally sign a message, a user encrypts it with their private key. As the message can then only be decrypted with the matching public key, anyone with that public key can decrypt the message. In doing so, the decryptors can be sure that the message was in fact encrypted using the matching private key, and hence they can assume the identity of the signer.

Messages can be both encrypted (using the public key of the intended recipient) and signed (using the private key of the sender).

Because the mathematical transformations performed by public key cryptography are computationally very intensive, practical implementations only use the public key transformations to encrypt a session key which is then used to encrypt/decrypt the message using a symmetric key algorithm such as DES or IDEA. Symmetric key algorithms are chosen for their security against attack and computational speed.

A popular implementation of public key cryptography is PGP - Pretty Good Privacy[HREF 9], which was written by Phil Zimmerman and has been since maintained and enhanced by dozens of programmers around the world. PGP is a controversial program because:

• due to the US export restrictions on strong cryptography, its initial escape from the US is considered a criminal action by the US government, which unsuccessfully pursued Phil Zimmerman for several years.

• the primary intellectual property contained in PGP, public key cryptography, is protected by patents and copyrights in the US.

• PGP makes public key cryptography available to everyone. When used properly, PGP can make message interception impractical which threatens the ability of law enforcement agencies to use this technique to conduct investigations and detect crime.

• A major issue to be addressed by all public key cryptography designs is key management:
  • how are public keys to be published?

  • how are old or compromised public keys to be recognised and ignored?

  • how are public keys to be associated with real people - that is, how do you really know which real person is associated with a particular public key?

Why CSIRO chose PGP as the basis for user authentication on the Web

It was clear that we could make use of the web to efficiently provide administrative information and functions but we needed a solution for user authentication. We had just implemented a web based software distribution system which was proving to be very popular. It helped CSIRO staff download and install software which was public domain, written internally or corporately licensed. However, there was an opportunity to save purchasing costs to extend the system to allow users to purchase and download software, such as Microsoft Office by entering an internal CSIRO account code and having the system generate the journal entries and quarterly software licensing reports to suppliers.

Several approaches were discussed:

• assign staff a personal identification number (PIN), similar to that used in EFTPOS transactions

• assign staff traditional UNIX userids and passwords and use the UNIX system security

• use a one-time password technology such as S/Key or OPIE

• use public key cryptography

Public key cryptography was seen as the Rolls-Royce solution, as although a PIN or UNIX userid method would be simple and initially cheap to implement, the cost of centrally administering these systems for over 5000 users was likely to be very high based on our experiences of maintaining such systems for other corporate applications. S/Key or OPIE would provide the advantage over PINs and passwords of not being snoopable but also require considerable central administration.

Public key cryptography looked like the most expensive solution to get off the ground but the advantages of public key cryptography were:

• We could clearly see how to securely distribute control of the system to CSIRO divisions, and avoid a central log-jam

• Public key cryptography can be used to authenticate and encrypt, and can be extended to systems such as e-mail for providing digital signatures on secure mail

• We knew how to extend public key cryptography to TCP/IP systems requiring authentication such as Telnet, FTP and POP. We were excited by the opportunity to approach the holy grail of one-password authentication to computer systems across the organisation (as anyone who has to remember half a dozen or more passwords to access different computer systems would appreciate).

Due to the restrictions on strong cryptography from the US, commercial solutions were not available. Additionally, integrating public key cryptography with the Web was a new area. (The NCSA HTTP server had shipped with an experimental PGP interface, but this was later removed, apparently at the request of the US National Security Agency.) So the PGP implementation without cryptographic nobbling, without licensing costs, and with source code made it the obvious choice.

Implementing PGP with WWW

Although PGP has been ported to many environments, it is a monolithic, command line program and hence hard to integrate into a GUI environment such as Windows. Much of the programming side of the implementation effort was directed at making it easy to use under Windows and the Macintosh and it wasn't until the second iteration that this was achieved.

The first attempt at the PGP client implemented it as a helper application. Helper applications are launched by a web browser to handle a document type which the web browser can't process and display internally. Web browsers recognise document types based on their MIME header, which describes the content of the document. Users can configure their web browser to launch a helper application for any specific MIME type. Using this approach, our first attempt defined a new MIME type which would be sent by the WWW server when it required PGP authentication, and implemented a helper application which was a GUI wrapper around the PGP command line program.

Here's how it worked:

1. The NCSA HTTP server was changed so that when it received a request for a "CSIRO only" document from a non CSIRO domain, it sent a special document in place of that requested. This document contained two separate but standard HTML forms, each with some instructions and a button on the same web page.

2. The user was instructed to click the first button, which caused a document to be sent from the WWW server to the client of the special new MIME type described above, and containing just a random string for the user to digitally sign.

3. This document launched a helper application on the web client which popped up a window asking the user to enter their PGP pass phrase. Their pass phrase and the random string were passed to the PGP command line program (launched in a MS-DOS box under Windows) and the signed random string was produced.

4. The helper application, now in possession of the signed random string, opened a separate TCP/IP session with the PGP signature authenticator program on a special (non-WWW) port with the machine running the WWW server and sent the signed string.

5. The PGP signature authenticator program checked the signature to establish the identity of the user at the remote TCP/IP address. It created a file whose name is the TCP/IP address of the user and whose contents are their authenticated userid.

6. The PGP signature authenticator program confirmed to the helper application that the user has been authenticated, and the user is instructed to press the second button on the original document sent in the first step above.

7. The second button was now pressed to cause a script to be run on the server passing as parameters the WWW document originally requested. The script then checked that the IP address originating this request was associated with an authenticated CSIRO user, and optionally that this user had access to the requested document (most documents were available to any CSIRO user).

   Access rights were cacheable - that is, based on server configuration files, the NCSA HTTP server allowed subsequent unchallenged access to restricted documents based on an existing association of the requesting TCP/IP address to an authenticated userid. The period of this association was settable as an absolute time (eg, 20 minutes) and/or for a non-activity period (eg, 5 minutes) after which the user would need to be reauthenticated. By setting the non-activity period to 0, certain classes of documents would require user authentication on each access.

   Although user authentication was now secure, exposures still remained:

   • If pages were transmitted through insecure WWW cache servers, unauthorised accesses may occur. To counter this threat, we will not deliver "CSIRO only" pages to cache servers which we do not trust. Our HTTP server has been modified to read a list of trusted cache servers. We have also modified the standard cache/proxy server used in CSIRO (CERN 3) to pass through the address of the ultimate client, and it is this ultimate client address which is used when searching for an association between the user's TCP/IP address and their authenticated userid.

     Non-CSIRO users attempting to access CSIRO only pages must turn off proxying/caching for the CSIRO corporate web server address.

   • CSIRO only documents are not encrypted in transmission, allowing them to be snooped. Although the PGP helper application and the NCSA HTTP server were modified to encrypt the document with the user's public key, in practice this turned out to be too cumbersome.

   • CSIRO only documents may be cached on the web client, allowing another person to view the information through the client's document history.

   A Server CGI application program wanting to authenticate their user used a similar mechanism through a series of library calls:

   1. Generate a standard document with instructions and two HTML forms each with a button.

   2. On the first button press, generate the random string to be signed.

   3. On the second button press, verify that the PGP authentication server has associated a CSIRO userid with the TCP/IP address within application specified timeouts.

   This 'two button' interface worked, but confused many users. Hence, we have replaced it by running the client PGP shell as a TCP/IP server rather than as a helper application. It works like this:

   1. The NCSA server or a Server CGI application program receives a HTTP request and decides that it requires authentication of the WWW client. Synchronously with the HTTP request, it attempts to open a second TCP/IP session with the PGP shell running as a server on the WWW client's machine and sends it an access request which the user must sign.

   2. The PGP shell pops up a window displaying the access request and prompts the user to enter their pass phrase. The access request to be signed and the pass phrase are passed to the PGP command line program (running in an MS-DOS box under Windows).

   3. The PGP shell sends back the signed access request on the second open TCP/IP session and the WWW server/CGI application program verifies the signature and synchronously continues processing the HTTP request.

      This process is demonstrated in Figure 2.

      
      Figure 2. Using PGP to authenticate to a WWW server.

      As previously, associations between TCP/IP addresses and authenticated userids can be cached for application specific time intervals.

      Implementing PGP with Telnet

      The technique we now use for WWW access has proved relatively simple to use for Telnet authentication. Although no change to Telnet clients is required, the Telnet server must be modified to generate and emit the access request and check the signature on the response. It is vital that the access requests be non-repeatable to thwart a replay attack.

      Similar modifications to FTP and POP are simple and will be operational soon.

      Implementing PGP on the desktop

      By far the major part of the PGP implementation is getting the program on the desktops of users and getting their keys generated and certified.

      We produced a Windows 3.1x client (which also works on Windows 95 and NT) and a Macintosh client. A system manager familiar with the X environment has produced an interface using tcl/tk, but it is not supported centrally due to a lack of X programming skills.

      We started signing up system managers in September 1995, who used PGP for authenticating themselves to purchase licensed software. General use by all staff started in March 1996 after streamlining and distributing the PGP key generation process.

      Generating a new PGP key involves these steps[HREF 4]:

      1. The PGP client software must be downloaded and installed from the CSIRO web server.

      2. The user enters their CSIRO payid into a web form.

      3. The script behind the form uses the userid as a key to the corporate human resources system to extract their name and email address. It sends a request to generate a new PGP key to the PGP client software installed in the first step.

      4. The PGP client leads the user through the key generation processes to generate a PGP key pair.

      5. The public key of the new PGP key pair is extracted and sent using TCP/IP to a PGP request processing program running on a corporate server.

      6. This PGP request processing program examines the key and from the userid of the key extracts the user's name, email address, contact information, division and location from the corporate human resources system.

         Based on the division and location, it generates email containing the new key and user contact details to the Divisional IT Security Officer responsible for handling the request, and sends confirmatory email back to the originator.

      7. The Divisional IT Security Officer then needs to certify that the key really was generated by the user. They achieve this by contacting the user and verifying that the user's key fingerprint matches that of the key mailed to them and by using whatever techniques they can to ensure that they really are talking to the person represented by the userid on the key. By delegating this responsibility to 'locals' rather than a centralised key certification cell, it's hoped that this process is strengthened.

      8. The Divisional IT Security Officer uses a special function on their PGP client software to sign the key and forward it to the PGP request processing program running on a corporate server.

      9. This program examines the signature and the key, to verify that the key is associated with a CSIRO staff member and has been signed by a Divisional IT Security Officer authorised to certify new keys. The key is then added to the corporate public key ring and signed again by a special CSIRO key. Any previous key associated with the staff member is deleted.

      10. New keys are replicated by PGP signed e-mail to secondary key servers around the organisation. Similarly signed instructions to remove deleted keys are also e-mailed.

          Distributing software over the Web

          CSIRO has been distributing software over the web since November 1994 using an internally written system called CSI (CSIRO Software Installation)[HREF 3]. Why use the web to distribute software?
          • The web provides a way of efficiently organising software repositories which users find simple to navigate without requiring them to learn FTP commands.

          • Regional web proxy/cache servers promote efficient distribution over a wide area network.

          • By packaging software in a wrapper which triggers a web client helper application, an environment can be built which leads the user through an installation without requiring them to save-to-file, remember its name and execute it.

          Whilst an effective means for distributing public domain, internally written or corporately licensed software, CSI did not have the ability to allow users to purchase software which we license on a "per user" basis. As more and more staff install more and more software on their desktops, the administrative costs of purchasing software and getting the distribution media become very significant. By being able to make purchase and retrieval of such software an internal web function, we not only improved the efficiency of our staff but we also reduced selling costs to our suppliers who can pass on some of their savings to us.

          Hence, the use of CSI to purchase licensed software was the first use of PGP authentication to be introduced in September 1995. This function was initially restricted to system managers, but is now open to any staff member who has generated a PGP key and has the appropriate financial delegation to purchase software.

          When purchasing licensed software, the user selects the software through the web interface which lists what's available with a brief description, price and relevant version information. They nominate the purchase method (typically 'new' or 'upgrade'), the number of licenses and the account code to be debited. The CSI system then prompts them to digitally sign the purchase request containing the entered details and confirm that they have the appropriate delegation. It generates confirmatory email back to the address as registered against the user on the corporate human resources system and generates a debit from the users account and a credit to a central holding account from which the suppliers are paid on a monthly or quarterly basis. The user is then presented with a web screen containing any further installation instructions and a hyperlink to download the software package. Most of the packages are formatted using a MIME header which causes the client's browser to launch the CSI helper application. This program extracts the installation package, verifies the signature and initiates the next step of the installation. All transactions are logged and made available in a variety of report formats through the web.

          One Windows package requires elaborate license generation based on user details performed by a script running from a Windows HTTP server which first authenticates the PGP signature on the request.

          The CSI system has greatly improved the ease and confidence with which CSIRO users can license, download and install software.

          Administrative processing on the web

          One of the first scripts on the corporate web server in April 1994 allowed staff to update their own contact details, using date-of-birth as an authenticator. This system has been rewritten from C programs using direct ADABAS calls to NATURAL running from a custom WWW server which natively executes NATURAL programs within a PGP authentication framework.

          Recently added functions include:

          • pay slip details
          • pay history details
          • full leave transaction history
          • leave requests

          By providing direct access for staff to these functions we are considerably improving the efficiency of the organisation and staff satisfaction.

          Future Developments

          It has become clear that the web provides a flexible tool for implementing traditional internal administrative computing functions. Its ease of use and desktop integration mean that it is readily adopted by staff, and can be used with minimal training. Being able to authenticate staff is a vital component in the web's growth for administrative processing at CSIRO. Several new administration systems using PGP for authentication and the WWW as the GUI will be available to CSIRO staff in the second half of 1996. We have already made PGP authenticated Telnet access available and we are expanding the use of PGP authentication to FTP and POP.

          Our current use of PGP has several problems which we will need to address:

          • The CSIRO PGP client software is a GUI shell over the PGP command line program. This structure makes program development difficult and dependent on the correct operation of the command line environment (the MS-DOS box under Windows). The next version of PGP (version 3) in which PGP is implemented as a series of libraries is eagerly awaited.

          • We have not yet investigated tools to help users integrate email and PGP. As privacy of email becomes an increasingly serious issue and as email becomes used for more and more interactions, often of a commercial-in-confidence or sensitive nature, it is important that we make encryption of email as transparent as possible.

          • We have not yet investigated ways to make the PGP web-of-trust graphically visible to users when they are making decisions about trusting a key.

          • We do not yet encrypt material from the server to the client. Although this capability has been developed and demonstrated, it is cumbersome to use. Whether we should be using PGP to do this, or investigate session encryption technology such as SSL, SSH or IPSEC needs to be discussed.

          • The current CSIRO PGP client shell contains a lot of platform dependent code - it would be nice to be able to implement this in a platform independent tool such as Java.

          • PGP uses a different certificate format from the X.509 key standard format. X.509 which is becoming more widely used chiefly due to initiatives such as SSL and the endorsement of X.500 directories and LDAP by Netscape[HREF 10]. We last looked at X.500 directories in 1993 and found the capabilities of the available software to be very limited. However, we may need to consider migrating to or interoperating with X.500 directories in the future.

          • PGP was not designed with large keyrings in mind. As the number of keys on the corporate key server grew above a few hundred, key addition and deletion times increased exponentially as the key management software checked for inter-key relationships which in our environment were not required. Disabling this code dramatically reduced keyring update times, but better keyring management software is required. We are hoping that PGP V3 will address this issue as well as making it possible to implement a modular library interface to PGP rather than the command line interface currently required.

          Conclusions

          CSIRO has successfully implemented a public key infrastructure based on PGP which has been used to provide strong user authentication to web based administrative functions and software licensing. This exercise has shown that while off-the-shelf solutions may not available, the modification of available standard code is feasible. It is vital that as many aspects of key generation as possible are automated whilst maintaining high quality certification of keys.

          ---

          Hypertext References

          HREF 1

          http://www.csiro.au/itsb/staff/fit106.html - Kent Fitch's Home Page

          HREF 2

          http://www.csiro.au - The CSIRO home page

          HREF 3

          http://www.csiro.au/csi - The CSIRO software installation and distribution system (CSI)

          HREF 4

          http://www.csiro.au/pgp - The CSIRO PGP introduction page

          HREF 5

          http://hoohoo.ncsa.uiuc.edu/docs/tutorials/user.html - The Mosaic User Authentication Tutorial

          HREF 6

          http://home.netscape.com/newsref/std/SSL.html - The Netscape SSL Protocol

          HREF 7

          http://www.commerce.net/information/standards/drafts/shttp.txt - The Secure HyperText Transfer Protocol

          HREF 8

          http://www.cis.ohio-state.edu/hypertext/faq/usenet/cryptography-faq/part06/faq.html - Public Key Cryptography FAQ

          HREF 9

          http://www.ifi.uio.no/pgp/ - The International PGP Home Page

          HREF 10

          http://home.netscape.com/newsref/pr/newsrelease126.html - The Netscape X.500/LDAP press release

          ---

          Copyright

          Kent Fitch ©, 1996. The author assigns to Southern Cross University and other educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The author also grants a non-exclusive licence to Southern Cross University to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers, and for the document to be published on mirrors on the World Wide Web. Any other usage is prohibited without the express permission of the author.

          ---

          Pointers to Abstract and Conference Presentation
          Abstract	Conference Presentation	Papers & posters in this theme	All Papers & posters	AusWeb96 Home Page

          AusWeb96 The Second Australian WorldWideWeb Conference ausweb96@scu.edu.au