scot@btg.com,
http://www.btg.com/~scot
Rick Garvin, Senior Systems Engineer, BTG, Inc. 1945 Old Gallows Road Vienna, VA 22182 USA
rgarvin@btg.com,
http://www.btg.com/~rgarvin
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 requirements are not met by current Web server implementations. 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.
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 privilege levels are required. User authentication addresses these problems, but current implementations are burdensome on the user. In order to access protected documents the client software must explicitly prompt the user to provide authentication information 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 administrative burden that makes operation with multiple heterogeneous servers difficult. Having the authentication secrets passed repeatedly in the clear makes this approach vulnerable to snooping attacks.
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 authenticated access, multiple privilege levels and extended auditing of user actions. Our success with Sessioneer has led to its introduction into more Web applications and acceptance as a valid architecture.
When we started out we were trying to solve the problem of authenticated user access to Web information in an on-line ordering application. We rapidly came to the realization that existing authentication schemes were not going to be acceptable to our clients. This problem has been solved through Kerberos authentication in the past.[1] 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, encryption may not be an option if potential users may be in countries that restrict or forbid the use of encryption. 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 a framework that was easily reusable and that allowed us to fit the authentication scheme to the application's requirements.
To solve this problem we came up with the following design goals:
We were not trying to solve the problems of secure communications. We leave this up to services like Secure Sockets Layer (SSL) and SHTTP.
The basis of the Sessioneer concept is to provide a framework upon which individuals may plug-in a specific authentication scheme. Web servers are designed to provide access to files of various types in response to specific requests from external Web clients. A Web page is a collection of graphics, text and references to other pages, and as such is a discreet event without context. Once transferred, 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 restricted files are placed outside the directory hierarchy accessible to the Web server, and can be accessed 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 authentication service, which logs the request and responds appropriately. Our solution is to produce a Certificate 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 Certificates that are unique for each page. Nothing is dictated except the use of Certificates. The Certificate is embedded in the URL in RFC 1738 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.
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 discreet areas. The first is forms capability. This 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 running on the Web host. These parameters may include such things as directives, menu options, and authentication Certificates.
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 information, placing it either outside this Web hierarchy or producing it dynamically from an executable program. 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.
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 referenced 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-authentication 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 machine. Since Certificates are one-time-use, it is not possible to take one Certificate and use it for something 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 information contained there.
No discussion of this nature would be complete without careful consideration of vulnerabilities. There are three points. Two are very specific and one is 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 reproduce 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, however, 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 transmitted information. Given that implicit to this solution 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 encrypted files, which would be essentially possible regardless.
Certificates are just part of the query string until the Sessioneer-aware CGI gets called. Certificates are passed as part of an RFC 1738 URL. The Certificate is the first argument in the query string. A URL with a Certificate would look like:
http://www.btg.com/sessioneer/validate?8e716662235e2c7fa30717072+two+three
The Certificate portion is the text between the first "?" and the first "+." In this case, "8e716662235e2c7fa30717072."
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.
This discussion will focus upon a simple implementation, 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/.
Required components for Windows NT implementation:
Steps to install sample:
We set out to add context and sessions to Web applications to support once per session user authentication 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 shortcomings of HTTP in a manner that does not inconvenience users. The competing security architectures of Netscape Communications' Secure Socket Layer (SSL), EIT's SHTTP, and CERN's Shen 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.
References:
[1] M. G. Lavenant and J. A. Kruper, "The Phoenix Project: Distributed Hypermedia Authoring", http://www1.cern.ch/PapersWWW94/j-kruper.ps
[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-paper.html,
http://www1.cern.ch/PapersWWW94/bnfb.ps