THE TECHNOLOGIES provided in LSAM represent one strategy toward presenting improved performance and service to the site administrator and the end user. They are varied, but they essentially make use of one key idea: the efficient and judicious use of so-called think time--the time taken by humans to process what they send or retrieve, during which no processing or machine communication takes place.
LSAM will implement several enhancements to make use of this time. Some of these improvements involve sending data before the user knows he wants it. Others involve making the data available to the user at a lower cost, however that cost is computed. However, each of these improvements introduces an additional point of vulnerability, and increases the probability of an attack on some part of the applicable transactions.
This is particularly important, given recent commercial developments on the Internet. Data of high monetary value is being transmitted daily in increasing volume. While many methods are available for securing these transactions in the well-understood single-server/single-client environment, these same tools many not apply to LSAM enhancements--or if they do apply, they do not apply efficiently or scalably.
The concerns of the security branch of LSAM fall roughly into two categories:
In the sections below, we will consider each of these in turn.
Most if not all of the LSAM mechanisms implicitly assume a transaction (or a communication, if we consider SSL) taking place between two agents, typically designated the client and the server (especially if we examine them in the context of the Web). In LSAM, however, we employ a number of tactics to improve perceived performance; these raise new security issues that we must address.
In the case of replication, documents may be stored at a variety of locations around the Internet, all of which may nonetheless go by a single name. Do we trust the replicated sites to serve untampered documents? Can we verify documents once they are returned? On the other side, who do we allow to obtain documents? And from where?
Documents may be preloaded into caches to maximize use of available bandwidth. Do the security tags specifying disposition of the documents reside with the cached copies? How are these copies protected from unauthorized eyes? What if the server requests payment for the documents?
Then again, objects may actually be streams on which communications will take place. These will need to be secured. How will information about which channels to tune in to be distributed? How will the data be readable by a large number of listeners?
In many cases, solutions to these problems already exist, but they preclude simple application of the LSAM tactics. Security mechanisms will have to underlay the most basic components of the performance-enhancing strategies employed in LSAM; otherwise, users will have to make the distasteful choice between improved security and improved performance.
We propose a strong transaction security mechanism as the basis for providing security services in LSAM. Other transaction security mechanisms, such as MOSS and SHTTP, have been proposed, but they each have some drawbacks:
Phillip Hallam-Baker had proposed a protocol, called SHEN. SHEN was lighter and also designed to secure HTTP, but most of its features were equally applicable to other protocols. SHEN has expired as an Internet-Draft. We propose a newer, stripped-down version of SHEN, that takes even greater advantage of any cooperation between components, and also removes any ties to HTTP specifically. The approach taken by MOSS, in which MIME objects in general are secured, is useful, but we allow participants to use a priori shared keys as well.
This new protocol will be called STS (Simple Transaction Security). A preliminary version of the protocol has been submitted as an Internet-Draft. This version had several problems; we plan to submit a revised draft in July.
Once this new version has been presented as an Internet-Draft, we will provide a conformant implementation in the form of an API and libraries supporting the securing of HTTP and HTTP-like transactions.
LSAM will investigate the use of several authorization mechanisms developed in other projects for use in controlling access to data and actions:
In either case, the authorization servers will issue an opaque object (possibly in conjunction with data present in order for the requester to validate with a certificate). This opaque object can then be passed using the transaction security mechanism described in the previous section.
Here are some links to information about SHTTP:
Page maintainer: Brian Tung
Last modified: Thu Feb 18 18:28:25 PST 1999
Copyright © 1996 by USC/ISI