Computer Networks and ISDN Systems 17 (1995) 1047-1053

-. .- ISDN SYSTEMS

Sessioneer: flexible session level authentication with off the shelf servers and clients

Scot Anderson ‘, Rick Garvin 2 BTG, Inc. 1945 Old Gallows Road, Vienna, VA 22182, USA

Abstract

Information providers have taken great advantage of the WWW to disseminate information. Many would benefit from the ability to offer additional information to authenticated users. Methods for authentication are available with some Web servers. These authentication techniques do not address the needs of the Web community because they lack flexibility and are burdensome. We offer a solution that adds session level authentication to existing Web servers that does not require server software modification and does not dictate a specific web browser. Sessioneer provides a framework for Web administrators to provide session level authentication schemes that will suit specific needs.

Keywords: Security; Authentication; Intellectual property --

1. Introductiion

BTG provides information technology services to government and commercial customers. Many of these services are provided in environments where the user authentication and session auditing require- ments are not met by current Web server implemen- tations. It was our intent to extend these capabilities in a manner that would meet the requirements of the application while not inconveniencing legitimate users. Standards that provide these capabilities are in the approval and production process, but these are not currently available and will require custom Web clients to work. Sessioneer is intended as a bridge between existing Web servers and security enhanced Web servers as well as security enhanced Web servers and non-secure clients.

’ scot@btg.com; http://www.btg.com/ - Scot ’ rgarvin@btg.com; http://www.btg.com/ m rgarvin

0169-755?/95/SO9.50 1995 Elsevier Science B.V. SSDI 0169.7552(95)00040-2

There are two authentication models available with the major available servers (CERN, NCSA and others): host filtering and user authentication. Host filtering is based on the IP address or the host name of the client system. While this is adequate when all users on a host, network number, or domain have the same access level it breaks down if multiple privi- lege levels are required. User authentication ad- dresses these problems, but current implementations are burdensome on the user. In order to access protected documents the client software must explic- itly prompt the user to provide authentication infor- mation for each request. Authenticating each access takes an appreciable time and distracts the user from the real goal of finding information. The common authentication scheme’s dependence upon user name, password and group information adds an administra- tive burden that makes operation with multiple het- erogeneous servers difficult. Having the authentica- tion secrets passed repeatedly in the clear makes this approach vulnerable to snooping attacks.

1048 S. Anderson, R. Garvin / Computer Networks and ISDN Systems 27 (1995) 1047-1053

We developed Sessioneer as a response to these issues to solve a real world problem. It is currently in operation in an application that requires authenti- cated access, multiple privilege levels and extended auditing of user actions. Our success with Sessioneer has led to its introduction into more Web applica- tions and acceptance as a valid architecture.

2. Design goals

When we started out we were trying to solve the problem of authenticated user access to Web infor- mation in an on-line ordering application. We rapidly came to the realization that existing authentication

Web Browser Vkb Server

schemes were not going to be acceptable to our clients. This problem has been solved through Ker- beros authentication in the past [l]. However, we did not wish to restrict the Web browser that could be used to those that were Kerberos aware. Another interesting approach is embedding encrypted access keys within the page’s URL [2]. However, encryp- tion may not be an option if potential users may be in countries that restrict or forbid the use of encryp- tion. We had many applications where this problem was going to occur. After working to determine the one authentication scheme that was going to solve this problem for all scenarios we realized that there was not a single best solution. Our approach was to design an architecture that would allow us to provide

Fig. 1. Sessioneer architecture.

S. Anderson, R. Garuin/Computer Networks and ISDN Systems 27 (1995) 1047-1053 1049

a framework that was easily reusable and that al- lowed us to fit the authentication scheme to the application’s requirements.

To solve this problem we came up with the following design goals:

l Limit access to Web information * Minimum burden on the user l Reusable * Use umnodified Web servers and clients l Accommodate proxies . Accommodate existing HTML and CGIs * Support UNIX and Microsoft Windows NT l Provide a framework to support the authentication

scheme * Allow the Web administrator to provide the au-

thentication scheme * Support but not require encryption * Keep It Simple * Run unprivileged * Extended auditing/logging capabilities

We were not trying to solve the problems of secure communications. We leave this up to services like Secure Sockets Layer (SSL) 3 and SH’ITP 4.

3. Architecture

The basis of the Sessioneer concept is to provide a framework upon which individuals may plug-in a specific authentication scheme, see Fig. 1. Web servers are designed to provide access to files of various types in response to specific requests from external Web1 clients. A Web page is a collection of graphics, text and references to other pages, and as such is a discrete event without context. Once trans- ferred, that page remains with the client. As a direct result, we may only impose restrictions at the time that a specific page is provided to the requester. We accomplish this through the limitation that all re- stricted files are placed outside the directory hierar- chy accessible to the Web server, and can be ac- cessed only through CGI programs once appropriate authentication processing has occurred.

Authentication is basically the identification of an individual according to some unique information. This might be a combination of name, a password and perhaps an IP address. In practice, it must be some combination of data items collected from the Web client and data entered by the user on some sort of form. We pass this information to an authentica- tion service, which logs the request and responds appropriately. Our solution is to produce a Certifi- cate used to validate subsequent requests so the client only has to authenticate once per session. The secrets requested by the authentication service, the content of the Certificate, and the validation method of the Certificate are determined by the plug-in modules provided by the application developer. The Certificate may contain any of a number of different kinds of data. This may include who made the request, their authorization level, their IP address, the length of time during which the Certificate is valid, and any others. If wished, the developer could even go so far as to use encrypted one-time Certifi- cates that are unique for each page. Nothing is dictated except the use of Certificates. The Certifi- cate is embedded in the URL in RFC 1738 5 format as the first argument in the query string. This allows for arbitrarily long Certificates. It is this Certificate that is used to maintain context and thus creates a session.

4. Implementation

4.1. Overview

The approach used for this solution is based on the well documented CGI capabilities of standard Web servers and clients. Following some relevant background discussion, this discussion will focus on the basis of the technique, on the techniques used for our solution, and will give examples of a sample implementation.

The CGI abilities relevant to this discussion are in two discrete areas. The first is forms capability. This

1050 S. Anderson, R. Gamin/Computer Networks and ISDN Systems 27 (1995) 1047-1053

is generally where much of the critical interaction with the client user begins. CGI forms are used to transfer information in an attempt to identify the client for comparison to existing data. The second involves passing parameters to a CGI program run- ning on the Web host. These parameters may include such things as directives, menu options, and authen- tication Certificates.

4.2. Background

Inherent to this entire process is the restriction of information in a system (the Web) that was designed to be open. Web servers allow the assignment of a base directory from which to operate, and an option of whether to allow “file browsing” within that directory hierarchy. The server is then expected to produce most anything from that hierarchy, within the constraints of the overall design. Sessioneer uses this to advantage by relocating all restricted informa- tion, placing it either outside this Web hierarchy or producing it dynamically from an executable pro- gram. Under both circumstances, authentication takes place before providing any information to the client.

It is important to remember that the only point of control over a Web page is at the time it is provided to the requester. Even in the case of forms, we know nothing but that the associated recipient program is invoked with data being provided on its input stream. Contextual, hierarchical access, starting with a login page, must be insured for any such authentication scheme to function.

4.3. Implementation conclusions

Each page of the authenticated hierarchy must provide a Certificate to each page it references, and must expect one from that which invoked it. The sole exception to this would be the signin page, where the requester is identified. As allowed with all Web servers, this Certificate is passed as an argument to the called page. Generalizing this into programming logic, one simply calls a Certificate-decoding routine before providing page information. When producing links within html, a Certificate-encoding routine is used to produce the unique Certificate for the refer- enced link. This is done on-the-fly when the page is requested.

The content of the Certificate is used to provide the restrictions needed. First up is the identification of the client user, with associated privileges. This is accomplished with the use of an independent user database, available to the CGI programs through some appropriate mechanism. Named pipes were used in the Windows NT environment, allowing independent location of the user data service. Once identified, the user is allocated a unique value which then becomes part of the Certificate to be used with subsequent references. This is not sufficient, but the rest remains under the control of the individual setting up the scheme. One can include interesting things such as the IP address from which the client logged in, the time the particular Certificate was produced, and information about the referenced CGI program itself. This results in Certificates only being useful within a limited time of when they were produced, only being good for invoking a particular CGI, and only good from that particular IP address. Before presentation in ASCII form, other obscure things, including encryption, can be done to the binary information to make them even more difficult to reproduce.

The result of this scheme is that one must start at a login screen to get started with a good Certificate on a main menu page. From there, the client may navigate through the menu. Each reference produced is unique to that user for a predetermined (and short) time frame, and they navigate like anywhere else without incident as long as they keep moving. If the client were to leave and come back later, re-authenti- cation would be necessary. If they “Add Bookmark” at some point, that bookmark would be useful only within the time-out period, and only from that ma- chine. Since Certificates are one-time-use, it is not possible to take one Certificate and use it for some- thing other than for what it was intended. Further, there is no logical information to be obtained from the Certificate, since it’s patterns can be obscured by the other processing done to hide the raw informa- tion contained there.

4.4. Vulnerabilities and the use of encryption

No discussion of this nature would be complete without careful consideration of vulnerabilities. There are three points. Two are very specific and one is

S. Anderson, R. Garvin / Computer Networks and ISDN Systems 27 (1995) 1047-1053 1051

more general. First, one may either guess or monitor your password/name combination during the initial user identification process. Even if it is encrypted, this information may be captured and used to repro- duce your login sequence. Efforts are made to avoid this, particularly by making sure that keywords such as “name” and “password” do not occur within the stream produced by the Web form. If targeted, how- ever, there is no way to protect a site from this sort of intrusion short of using one-time password schemes like s/key or password calculators. Second, one may attempt to steal a Certificate, and use it for unauthorized purposes. The utility of a Certificate is limited by the design of the encoders, so this may be limited quite nicely. The third vulnerability centers around the risk of someone reproducing Certificates in order to circumvent the entire process. This risk is also a function of how creative one gets with the Certificate and what sort of resources are applied to the encoding/decoding process. This risk can be mitigated by encrypting Certificates using a secure scheme.

Another natural question is related to the use of popular encryption algorithms to protect the trans- mitted information. Given that implicit to this solu- tion is acceptance of the inability to modify either client or server, all HTML and forms data are sent essentially in the clear. The only possible use for this within our stated limitations would be to send en- crypted files, which would be essentially possible regardless.

4.5. Certificate construction

Certificates are just part of the query string until the Sessioneer-aware CGI gets called. Certificates are passed a.s part of an RFC 1738 6 URL. The Certificate is the first argument in the query string. A URL with a Certificate would look like:

ttp://www.l~tg.com/sessioneer/validate?8e7l6462 235e2c7fa30’717072 + two + three

The Certificate portion is the text between the first . “‘?2> and the first “ + “. In this case, “8e716662235e2c7fa307’17072”.

“htrp:,//ds.irlternic.net/rfc/rfcl738.txt

This approach assumes that HTTP servers will pass URL arguments to CGIs for non-GET methods. The only other constraints are those placed on us by the clients and servers. How big can a Certificate be? The practical limit is as big as your client and server will allow a query string to be. We have not run into this boundary in any of our work.

4.6. Implementation recipe - building a system with Sessioneer authentication

This discussion will focus upon a simple imple- mentation, with a sign-on screen, a main menu and options from that menu which present previously prepared HTML documents. We will discuss the required components and the steps for installation. This implementation is for a Windows NT system, which should be equipped as a relatively strong server to support your anticipated level of Web activity.

The materials that are discussed here will be made available prior to the Third International World-Wide Web Conference April 10, 1995. These files can be found at ftp:// ftp.btg.com / pub/ info-systems/ www / sessioneer / ‘.

4.7. Implementation parts list

Required components for Windows NT imple- mentation:

User Authentication service. This comes with the sample executables. This is installed as a service and should be allocated privileges to access the user database. The implementor should be cau- tious about restricting access to the data, as all information is stored there in plain ASCII format. EMWAC HTTPS Server for Windows NT. This can be obtained a number of ways, using your existing Web client or via FTP. Netscape, or some other appropriate Web Client tool. Choose the one you like best, and go with it. If you don’t have one, then you can use FTP to acquire them and begin surfing. Cover executable for presenting prepared HTML documents. This comes with the sample executa-

7 ftp://ftp.btg.com/pub/info-systems/www/sessioneer

1052 S. Anderson, R. Garvin/ Computer Networks and ISDN Systems 27 (1995) 1047-1053

bles. This file should be located in the directory assigned to the H’ITPS server.

l At least one sample HTML document. Generate this with any ASCII editor or use the sample provided. This file should be located outside the directory assigned to the HTTPS server.

l The SIGNIN executable with an appropriate menu table. This comes with the sample executables. This file should be located in the directory as- signed to the I-ITTPS server.

4.8. Implementation procedure

Steps to install sample: Install the H’ITPS server according to instruc- tions that accompanied the software. Install the chosen Web client according to in- structions that accompanied the software. Create a simple HTML document for the server to use, and verify correct operation of both the HlTPS server and the Web client. Copy the User Authentication service program to a convenient directory, for example the SYS- TEM32 subdirectory of the system root. Install the User Authentication Service by issuing the following command at a MS-DOS prompt: “webauth -install”. Invoke the “Control” applet from the “Main” window of the file manager. Invoke the “Services” option from that window, and locate the “Web Authenticator” service en- try. Use the control applet to cause it to be started automatically, and choose a user for it to run as. This user must be allowed access to the webauth data file. A sample file of this type is provided with the kit, and should be placed in a new subdirectory from the system root called “Www”. Place the cover.exe, signin.exe and signin.html files in the base directory allocated for the Web server.

shttp://home.mcom.com/info/SSL.html ’ http://www.commerce.net/information/stand/shttp.txt

lo http://info.cem.ch/hypertext/WWW/Shen/ref/shen.html

7

8

9

10

11

Create a new directory parallel to the base direc- tory allocated for the Web server called “lib”. Copy the sample HTML document and the sam- ple Signin menu into that directory. Verify that the signin.html file is the default for your H’ITPS server, or reference it from an existing HTML document in that directory. Ver- ify that the reference is correct. Make an addition to the user database for your name and password. Start the Web Authenticator with the following command: “net start webauth”. If it is already started, issue the command “net stop webauth” and then issue the start command. This operation can also be accomplished with the Services ap- plet from the Control box. Log in and try your sample menu with the sam- ple option. Verify that you must sign in to see it, and that one cannot produce the file without a valid Certificate. The Certificate will show up on the URL as the first argument in the search string.

5. Conclusions

We set out to add context and sessions to Web applications to support once per session user authen- tication that is not burdensome to users. While we achieved this goal with unmodified off the shelf servers and clients, this problem is best resolved at the HTTP level. Our approach ameliorates the short- comings of HTTP in a manner that does not inconve- nience users. The competing security architectures of Netscape Communications’ Secure Socket Layer (SSL) 8, EIT’s SHTl’P 9, and CERN’s Shen lo are just now coming to market. We hope that they help solve these problems in a coherent and open manner that obviates the need for back-end solutions. In the interim, Sessioneer solves the problem.

S. Anderson, R. Garvin/ Computer Networks and ISDN Systems 27 (1995) 1047-1053 1053

References

[I] M. G. Lakenant and J. A. Kruper, The Phoenix Project: Distributed Hypermedia Authoring. http://wwwl.cern.ch/ PapersWWW94/j-kruper.ps I1

[2] Bjorn N., Freeman-Bensen, Using the Web to Provide Private Information -or- A Short Paper About Password Protection Without Client Modifications. http:// ursaminor.scs. carleton.ca / Papers/ www94-paperhtml “, http:// wwwl.cern.ch/PapersWWW94/bnfb.ps l3

‘* http://wwwl.cem.ch/PapersW%‘W94/j-kruper.ps l2 http://ursarninor.scs.carleton.ca/Papers/www94-paper.html I3 http://wwwl.cem.ch/PapersWWW94/bnfb.ps