As once-proprietary mission-specific information systems migrate onto the Web, traditional security analysis cannot sufficiently protect each subsystem atomically. The Web encourages open, decentralized systems that span multiple administrative domains. Trust Management is an emerging framework for decentralizing security decisions that helps developers and others in asking "why" trust is granted rather than immediately focusing on "how" cryptography can enforce it.
In this paper, we recap the basic elements of Trust Management: principles, principals, and policies. We present pragmatic details of Web-based TM technology for identifying principals, labeling resources, and enforcing policies. We sketch how TM might be integrated into Web applications for document authoring and distribution, content filtering, and mobile code security. Finally, we measure today's Web protocols, servers, and clients against this model, culminating in a call for stakeholders' support in bringing automatable TM to the Web.
Keywords: Security and Authorization, Protocols, Electronic Rights Management
To date, "Web Security" has been associated with debates over cryptographic technology, protocols, and public policy, obscuring the wider challenges of building trusted Web applications. Since the Web aims to be an information space that reflects not just human knowledge but also human relationships, it will soon realize the full complexity of trust relationships among people, computers, and organizations.
Within the computer security community, Trust Management (TM) has emerged as a new philosophy for codifying, analyzing, and managing trust decisions [Blaze et al., 1996; Brickell et al., 1996]. Asking the question "Is someone trusted to take some action on some object?" entails understanding the elements of TM [Khare and Rifkin, 1997]:
In this paper, we focus on the developments bringing TM to the Web. In Section 2, we present some TM building-blocks that complement crytographic "Web Security." In Section 3, we sketch how integrating TM affects several archetypal applications, with special attention to the potential for automating trust calculations. Section 4, by contrast, discusses how current Web software technology often falls short in managing trust. We conclude Section 5 with a call for action from the Web community.
The topological shift from atomic trusted systems to an open network of separately administered systems is driving the development of innovative Web-specific TM protocols, format, and tools. In the following subsections, we consider new technologies for identifying principals, labeling Web resources, and codifying and automating policies.
The first step in constructing a secure system is usually to identify the system's users, authorized or otherwise. Passwords are a common solution for closed systems. Public-key cryptography is a far more secure way of managing such secrets, but with the attendant overhead of a public key infrastructure (PKI) [Schneier, 1996]. The Web's radically decentralized trust model is catalyzing new alternatives to hierarchical certification for identifying the people, computers, and organizations holding such keys.
A digital certificate [Kohnfelder, 1978] ensures the binding between cryptographic keys and its owner as a signed assertion. It is the missing link between the mathematics, which computers can verify, and the principals. The challenge is in deciding who should sign that assertion and why.
Traditionally, a pyramid of Certificate Authorities (CAs) vouch for the binding: "Joe Doaks' public key is 42, (signed) UC Irvine, (signed) UC Regents, (signed) State of California, (signed) USA." This approach is enshrined in ISO's X.509 certificate format, X.400 addressing, and X.500 directory service. A CA's utility is directly proportional to its reach: the size of the community willing to trust that CA. Climbing up the pyramid, CAs have ever-greater reach, but with less specificity; UC Irvine can certify the specific role "student," but the USA may be able to certify only generic "citizens."
Alternatively, every principal could just be its own CA (self-signed certificates), introducing other correspondents one-on-one. The Pretty Good Privacy (PGP) "Web of Trust" is a living example of such an anarchic certification system [Garfinkel, 1994]. Of course, its reach is more limited: without a central trusted broker, it can be very difficult to scale to large user groups such as "all UC Irvine students."
The principles of TM tend to argue against hierarchical identity certificates. First, without knowing the application at hand, a CA vouching for generic identity cannot be specific about the degree of trust involved: the capabilities verified or the priviliges granted. Second, relying on hierarchical CAs weakens the principle of trusting yourself, since it requires blanket trust in very large-scale CAs, with corresponding conflicts-of-interest. Third, the logistical challenges of centralized revocation lists make it difficult to be careful using these certificates.
Two new decentralized PKI proposals, Simple Distributed Security Infrastructure (SDSI) [Lampson and Rivest, 1996] and Simple Public Key Infrastructure (SPKI) [Ellison et al., 1997] -- currently being merged into a common SDSI 2.0 draft -- are better adapted to these principles and to the Web's decentralized growth. First, their application-specific certificates identify exactly for what each key is authorized. Second, both systems literally construct a trust chain that must loop back to the user, instead of being diverted through some omnipotent CA. Finally, both systems offer simple, real-time certificate validation.
The second step in constructing a secure system is associating access limits with each element of the system. Security metadata might encompass principals' clearance levels, the capabilities required for an action, or the key to access an object.
Traditionally, secure computing systems wire these critical bits directly into data structures and files. Since today's Web tools offer only a thin wrapper around these underlying security facilities, they usually offer the same kinds of "labels," such as filesystem permission bits and resource limits on scripts.
A more flexible solution would be to use separate security labels with general-purpose label handling. Each of those conditions could be captured as a separate statement bound by URL to a Web resource. Furthermore, the conditions themselves could be categorized into a systematic scale that is readable by machines [Khare, 1997].
There are three critical differences indicating that external metadata labels are appropriate tools for Web-based trust management systems [Khare, 1996]. First, the label can reflectively be considered a Web resource: the label has its own name, and thus can be made available in several ways. The original resource owner can embed a label within it, send it along with a resource, or publish it from an external label bureau. Second, the scales, or rating schemas, can be reflectively considered a Web resource; so, the grammar of a machine-readable label can itself be fetched from the Web. Finally, labels can be securely bound to Web resources by hash or by name (for dynamic resources such as chat rooms).
The final step in implementing a secured system is specifying the authorization decisions according to some policy. As a generic application platform, the Web should be flexible enough to accommodate a wide range of applications with varying trust policies centered on principals, objects, or actions. Several policies may also need to be composed together, enforced on behalf of several stakeholders.
Consider some alternative content-selection policies, each written in its own format: one may be a simple numerical gamut applied to Platform for Internet Content Selection (PICS) ratings [Resnick and Miller, 1996]; another may weight the opinions of several ratings in different systems; and yet a third may incorporate a Turing-complete content analyzer.
REFEREE [Chu et al., 1997] does not use a single policy language, for this reason. Instead, users load interpreters dynamically for policy languages, while maintaining a single high-level API for trust decisions. Given a pile of facts, a target, a proposed action, and its policy, REFEREE can determine if trust is always, sometimes, or never granted. PolicyMaker [Blaze et al., 1997] also provides a single trust calculation API. On the other hand, PICSRules 1.1 defines a language for writing policy rules to allow or block URL acess using PICS labels [Presler-Marshall et al., 1997].
Incorporating automated trust engines returns more control to the user as a trust-granter: depending on your policy, you can seek out, collect, and manipulate more kinds of data in pursuit of a decision. Rather than using a closed content selection system like Antarctica Online's policy ("All our content is okay, trust us"), users have the full power of PICS labels, from multiple sources, according to different systems, with personalized policies. Decentralized principal identification, the integration of security attributes with the Web metadata, and policy flexibility, all advance the goal of automatable trust management through machine-readable assertions.
The shift away from closed, known user communities to open, publicly-accessible service models complicates the security analysis for Web applications. In the following subsections, we discuss three applications that are already capturing the imagination of Web developers.
The publication of a Presidential speech could be as complicated as the story of how a bill becomes a law. First, a proposal is drafted by the Press Secretary's staffers. An ongoing editing cycle can draw, ad hoc, upon the entire White House staff. The final press release can be made available on www.whitehouse.gov only after the President has affixed his digital signature.
This is a classic secure application: a controlled set of principals with different access levels (viewing and editing), acting on a long list of protected documents. While the old process might have been implemented on a single mainframe system using operating system-level security, it is neither flexible nor scalable enough to handle today's document production cycle. Replacing it with a secured Web server is an excellent alternative, offering more accessible clients, better collaboration tools, and an expressive format for linking it all together.
Complications crop up when considering the Web as a drop-in replacement as a secure authoring environment. At the very minimum, there is an open-systems integration challenge of replacing the old monolithic username/password database with an interoperable public key certificate infrastructure. Furthermore, extending the trusted computing base to all those staffers' desktop PCs adds the potential risks of leaked documents left behind in users' caches, weak points for eavesdropping viruses, and insecure key management.
The real benefits accrue as the web of trust surrounding these documents expands outward from authoring to distribution, access, and reading. The ultimate goal for each user is to judge if the President's words have been portrayed accurately. Especially with the malleability of digital media (such as hackable video, photographs, and even whole Web sites), digitally signed assertions of provenance will become de rigeur [DesAutels et al., 1997].
Each citizen has the right to establish trust in his or her own way. Some trust their neighbors (community filtering), or the cameraman, or the camera (if it had a "tamperproof" integrity check), or the news publishers. As the Web crosses organizational boundaries -- from White House to newspaper to ISP to citizen -- a common TM infrastructure can identify speakers and make assertions about the document.
The Web's distributed control and rapid growth continuously obsolete "black-lists" of purveyors of objectionable content as well as "white-lists" of known "good" sites. Furthermore, these Manichean schemes cannot handle judgment calls: if .edu is fine, and sex is verboten, what does it imply about sex.edu?
To tackle a problem expanding as rapidly as the Web itself, we must harness the Web itself. PICS labels can scale, because labels can be associated with objects by the author or by a third-party. The key is bootstrapping the meaning of each label. Machine-readable metadata labels themselves can leverage the Web through self-description (using PICS schema description files).
Traditional end-to-end security places such filtering exclusively at the periphery, because there are only two players: publisher and reader. To represent the trust relationships in this application properly, we must account for households, schools, libraries, offices, and governments who have a say in what constitutes acceptable content. Filters need to be relocatable within the network under the control of any of these stakeholders.
Content labels can also be used in reverse: publishers of intellectual property need to select who can access their resources. Client software could block the display of a font, for example, until it finds a signed "receipt" label. Rights management labels of this sort can be crytographically bound into "pay-per-view" information goods through watermarking, steganography, or aggregation in an encrypted package. The ongoing trust relationship between reader and publisher to obey the label is enforceable in trusted software [Cox, 1996] or trusted hardware [Yee and Tygar, 1995].
A final eCommerce-related filtering application is consumer privacy. Several organizations, including the Internet Privacy Working Group (IPWG), TRUSTe, and BBBonline are trying to enumerate the uses of demographic data specifically [Hoffman et al., 1997]. W3C's Privacy Preferences Platform Project (P3P) expects commercial sites to label their policies and to notify users as they browse sites [Ackerman, 1997].
Installing new executables within secured systems calls for review and explicit authorization to prevent introducing malfunctioning or malicious code. The shift from closed to open systems does not change the threat, but it does increase the scale of the problem -- and reduces the administrative support. Mobile code on the Web leaps across organizational trust boundaries. While idly surfing the Web, a browser might take the opportunity to download, install, and execute objects and scripts automatically from unknown sources.
Once invoked, applets have wide-open access, because there are few specific limits on their trust. Worse, initial implementations did not carefully log and audit downloaded code activities, nor defend against "simple" system bugs such as self-modifying virtual machines, unprotected namespaces, and loopholes in filesystem access.
Microsoft's ActiveX architecture emphasized install-time reviews of trust relationships. To that end, Authenticode provides identity-centric policy based on VeriSign "software publisher" identity certificates. Java, on the other hand, is a bytecode-interpreted language with wider scope for "sandboxing" the interfaces an applet can execute. JavaSoft and Netscape both promote security policies which specifically grant or deny such capabilities [McGraw and Felten, 1996].
In practice, no single security policy will suffice for safely using downloaded code, any more than a single policy can capture every household's morals for content filtering. Even the earliest secure operating systems, such as Multics, combined identity and capability limits on programs. Today, users might further expect their trust manager to fetch software reviews and place quality limits as well ("At least four stars from PCPundit.com").
Managing the trust placed in downloadable components will draw on the same list of TM tools suggested throughout this paper: identity certification of authors and endorsers; machine-readable metadata about the trustworthiness of principals, objects, and actions; and flexible TM engines that can compose the policies of end-users, administrators, and publishers.
Amid the rush of new protocols, ciphers, patches, and press releases which is the Web Security industry, it is easy to lose sight of the fact that conventional security technology, even if implemented perfectly, does not add up to Trust Management. In part, this stems from incorrect or incomplete specifications of security rules. More fundamentally, it comes from the closed-system worldview that securing the Web translates to securing Web servers and Web clients alone. In fact, trust needs to be managed in several layers of the network connection, as well as in several software components.
The Web as an information system does not publish political press releases, corrupt youth, or reprogram computers. It is merely a request-response protocol for importing and exporting bags of bits across the network. If you draw a circle around Web clients and Web servers, you actually capture very little of the value gatewayed onto the Web using fill-in-form scripts, databases, and filesystems. "Securing a Web Transaction" proves only that a pile of bits has moved from one machine to another without anyone peeking or poking.
There are three levels at which we can protect Web transactions: in the transport layer underlying HTTP, within the HTTP messages themselves, or in the content exchanged atop HTTP [Khare, 1996b]. The transport layer can only provide a secure bitstream; it cannot be used to reason about the protection of individual "documents" or HTTP "actions" within that opaque stream. Those measures are properly part of the application layer, driving the development of security within HTTP messages. Finally, application developers can circumvent Web security entirely, and build their own end-to-end solutions, by using HTTP as a black-box for exchanging files.
Transport Layer Security (TLS, née SSL) can establish a private channel between two processes. A temporary session key is set up for each cryptographic handshake between any client and server. The emphasis, however, is on any: the only way to be sure that the device on the other end speaks for some person or organization is through patches that exchange X.509 identity certificates. TLS alone cannot further establish trust in those principals, an "out-of-band" certification problem. Without those checks, TLS can be spoofed in practice by man-in-the-middle attacks [Felten et al., 1997].
At the application layer, where such decisions ought to reside, security features are even weaker. With the lukewarm market acceptance of Secure HTTP (S-HTTP), today's developers have few options for securing Web semantics. Recent revisions address intermediaries in the trust topology, authenticating to proxies as well as to origin servers and to clients.
Above the application layer, security can be flexible, but its gains are minimal without its underlying layers being secure. Similar problems occur with other "generic" tools; for example, firewalls and tunnels that form Vitual Private Networks cannot overcome security loopholes in the underlying infrastructure, such as a stray machine behind the firewall with an exposed dial-in port.
A typical HTTP server might offer to "protect" some URLs by requesting a username/password challenge before granting access. This kind of access privilege is still overbroad. It requires the server administrator to be vigilant about what content is in the "protected" and open areas; it does not typically restrict the range of methods available (GET, PUT, DELETE, and so on) in the protected area; and it does not establish the identity or credentials of each individual user. Essentially, the security policy here can talk only about the "form" of a request (that is, its method and URL), but not the "substance," or contents, of that request. When every resource is just an opaque stream of bits, it is difficult to protect "all files containing next year's budget projections."
When measured against the taxonomy of issues outlined in Section 1, it is understandably difficult from a pragmatics standpoint to build trusted information systems atop common Web servers:
Principles. HTTP servers often cannot be specific, because they cannot accurately identify the particular privileges of each principal. Since Web servers often outsource work to their (buggy) operating systems, you cannot trust yourself . Furthermore, such outsourcing makes Web servers overly reliant on other subsystems' security at multiple points of entry: the corruptible file system can be clobbered on the FTP, Telnet, and Email channels; viruses can make subvert the operating system; and extensibility features such as servlets might exploit security flaws. Adding insult to injury, Web servers have trouble being careful, too. Their logging features are rudimentary (that is, they flood the client with information, without any intelligent anamoly detection). Rollback is virtually nonexistent, due to the loose coordination with the underlying information sources.
Principals. Few Web servers can reliably identify any of the three types of principals. Worse, administrators often rely on very weak security when Web servers need to make assertions today: passwords are crackable (when not sent in the clear using BASIC authentication!), IP addresses are spoofable, and DNS entries are corruptible. Sometimes, there is an appropriate tool for determining principals, but the implementation is in the wrong layer entirely: TLS client-authentication does not propagate up, so passwords must be reimplemented with HTTP Authentication above it.
Policies. Web servers offer very little flexibility when it comes to policy. Protection techniques are usually hardcoded; identities are abstracted no further than to user and group lists; and objects are grouped by URL path in lieu of any more meaningful policy binding.
Browsers are such general-purpose interfaces to the Web that they cannot afford to customize their behaviors to the context or content of a particular transaction. Usability and security suffer as users eagerly swat aside the "Show alert each time unsecured data is sent?" dialog box -- because it is raised for any private transaction, whether submitting a credit card number or a sweater color. Inattentiveness while Web surfing is rarely cured by blanket warnings such as, "Think very carefully before accepting a digitally signed program; how competent and trustworthy is the signer?" [Felten, 1997].
Principles. Web browsers have difficulty in being specific; they work in exactly the same way throughout Web space, although Microsoft Internet Explorer 4 can adapt security preferences for built-in "zones" [Microsoft, 1997]. Clients offer no means by which to trust yourself. Users cannot actively establish -- or passively monitor -- trust in organizations and individuals who publish Web resources. Finally, who can be careful implementing on top of typical client operating systems? Disk caches can leak information to other users; flaws in mobile code interpreters; overabundant or nonexistent activity logging; and so on.
Principals. End-user OSes often cannot identify principals. Regarding humans, for example, Windows 95 has a weak concept of a "uniquely-identifiable user," and user IDs were easily cracked in early Windows NT. Identifying computers or organizations is difficult too, since the user interface often hides the what little location cues there are, leading to spoofer sites [Felten et al., 1997]; or over Domain Name System trademark disputes.
Policies. Web clients can barely even claim to having security policies: often what little protection there is, is compiled in and not user-configurable. Only a few clients have incorporated rudimentary PICS filters, much less the sophisticated P3P privacy control panels or PICSRules interpreters.
We believe that as Web-based applications replace closed information systems, transactions will cross more and more organizational boundaries, often magnifying latent flaws in existing trust relationships. For example, consider the U.S. Social Security Administration's ill-fated attempt to put its records on the Web. Each American worker has a trust relationship with the SSA regarding his or her pensions, sealed by the "secrecy" of his or her Social Security Number, mother's maiden name, and birth state. For decades, those were the keys to obtaining one's Personal Earnings and Benefit Estimate Statement (PEBES). When the exact same interface was reflected on the Web, however, nationwide outrage erupted over the perceived loss of privacy, resulting in a hurried shutdown and "reevaluation" [Garfinkel, 1997].
In this case, fast and easy HTTP access has raised the potential for large-scale abuse not present in the existing postal system. The SSA is ensconced in a trust relationship that is not represented by a corresponding secret, so cryptography cannot solve their problem. Computers can alter the equation only by substituting the explicit power of cryptography for the implicit power of psychology. The irony is that they do share one secret record with each worker: that worker's earnings history -- which is why workers request a PEBES in the first place!
In the end, there will have to be a more secure way of accessing such records -- perhaps with a digital identity certificate corresponding to today's Social Security Card. Such precautions may even strengthen how the "traditional" paper system works. Cryptography can offer much stronger proofs than traditional means, so trust relationships will tend to be cemented with shared secrets that enable those protocols, such as PIN numbers, shared keys, and credentials.
Web publishers, administrators, and readers will all need infrastructure "to help users decide what to trust on the Web" [Khare, 1997]. This paper represents a call to arms to the parties who have a role in bringing this vision to fruition:
If we all work together, automatable Trust Management could indeed weave a World Wide Web of Trust, spun from the filaments of our faith in one another.
Mr. Khare's work was sponsored by the Defense Advanced Research Projects Agency and Air Force Research Laboratory, Air Force Materiel Command, USAF, under agreement number F30602-97-2-0021. He would also like to thank MCI Internet Architecture for its support in this research.
Mr. Rifkin's work was supported under the Caltech Infospheres Project, sponsored by the CISE directorate of the National Science Foundation under Problem Solving Environments grant CCR-9527130 and by the NSF Center for Research on Parallel Computation under Cooperative Agreement Number CCR-9120008.
Rohit Khare, firstname.lastname@example.org
Rohit Khare joined the
Ph.D. program in computer science at the University of California,
Irvine in Fall 1997, after serving as a member of the MCI Internet
Architecture staff. He was previously on the technical staff of the
World Wide Web Consortium at MIT, where he focused on security and
electronic commerce issues. He has been involved in the development of
cryptographic software tools and Web-related standards development.
Rohit received a B.S. in Engineering and Applied Science and in
Economics from California Institute of Technology in 1995.
Adam Rifkin, adam at xent dot com
Adam Rifkin received his B.S. and M.S. in Computer Science from the College of William and Mary. He is presently pursuing a Ph.D. in computer science at the California Institute of Technology, where he works with the Caltech Infospheres Project on the composition of active distributed objects. He has done Internet consulting and performed research with several organizations, including Canon, Hewlett-Packard, Griffiss Air Force Base, and the NASA-Langley Research Center.