Content-Triggered Trust Negotiation - Semantic Scholar

Content-Triggered Trust Negotiation ADAM HESS, JASON HOLT, JARED JACOBSON, and KENT E. SEAMONS Brigham Young University

The focus of access control in client/server environments is on protecting sensitive server resources by determining whether or not a client is authorized to access those resources. The set of resources is usually static, and an access control policy associated with each resource specifies who is authorized to access the resource. In this article, we turn the traditional client/server access control model on its head and address how to protect the sensitive content that clients disclose to and receive from servers. Since client content is often dynamically generated at run-time, the usual approach of associating a policy with the resource (content) a priori does not work. We propose a general-purpose access control model designed to detect whenever sensitive information is being transmitted, and determine whether the sender or receiver is authorized. The model identifies sensitive content, maps the sensitive content to an access control policy, and establishes the trustworthiness of the sender or receiver before the sensitive content is disclosed or received. We have implemented the model within TrustBuilder, an architecture for negotiating trust between strangers based on properties other than identity. The implementation targets open systems, where clients and servers do not have preexisting trust relationships. The implementation is the first example of contenttriggered trust negotiation. It currently supports access control for sensitive content disclosed by web and email clients. Categories and Subject Descriptors: D.4.6 [Operating Systems]: Security and Protection— Access controls; K.6.5 [Management of Computing and Information Systems]: Security and Protection General Terms: Security, Design, Experimentation Additional Key Words and Phrases: Trust negotiation, access control, authentication, credentials

1. INTRODUCTION While performing Internet transactions, users often disclose sensitive information about themselves and their affiliations. The disclosure of this sensitive This research was supported by funding from Zone Labs, Inc., DARPA through AFRL contract number F33615-01-C-0336 and SSC-SD grant number N66001-01-1-8908, the National Science Foundation under grant no. CCR-0325951 and prime cooperative agreement no. IIS-0331707, and The Regents of the University of California. A preliminary version of this paper appeared in A. Hess and K. E. Seamons, “An Access Control Model for Dynamic Client Content,” Proceedings of the Eighth ACM Symposium on Access Control Models and Technologies (SACMAT ’03), Como, Italy, June 2003. Authors’ address: A. Hess, J. Holt, J. Jacobson, and K. E. Seamons, Internet Security Research Lab, Computer Science Department, Brigham Young University, 3361 TMCB, Provo, UT 84602 USA; web: http://isrl.cs.byu.edu/; email: [email protected]. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or direct commercial advantage and that copies show this notice on the first page or initial screen of a display along with the full citation. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, to redistribute to lists, or to use any component of this work in other works requires prior specific permission and/or a fee. Permissions may be requested from Publications Dept., ACM, Inc., 1515 Broadway, New York, NY 10036 USA, fax: +1 (212) 869-0481, or [email protected].
C 2004 ACM 1094-9224/04/0800-0428 $5.00 ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004, Pages 428–456.

Content-Triggered Trust Negotiation

•

429

Fig. 1. Alice sends a message to Bob. Access control monitors inspect the message to determine its sensitivity and authorize its transmission.

information can pose serious threats to individual privacy and the confidentiality of business secrets. If communication between client and server is not confidential, an eavesdropper can access the information. Moreover, the intended recipients of the information may misuse it or fail to protect it appropriately. To illustrate the problem, consider the following example. Alice is ready to make an online purchase from Bob, a stranger who operates an online store. The purchase request form requires that the purchaser include a valid credit card number and shipping address. Alice deems these pieces of information to be sensitive. If Alice were to send the information over plain HTTP, an eavesdropper could easily access the data, since the underlying communication protocol lacks confidentiality. Using HTTP over Transport Layer Security (TLS, formerly SSL) [Dierks and Allen 1999; Rescorla 2001] is one way to achieve data integrity and confidentiality. However, this only protects Alice from eavesdropping attackers and not from misuse by Bob. In order to achieve some level of assurance, Alice needs to first authenticate Bob to a role commensurate with the receipt of this information. For example, Alice may want to verify that Bob is a member of the Better Business Bureau (BBB) and is authorized to perform credit card transactions. TLS is not designed for this kind of authentication, and the web browser only provides assurance that a client is connected to the web server on the host specified in the URL. Other types of sensitive information that Alice may disclose include financial information, health records, her Social Security number, or confidential work related data. The role that Alice requires Bob to meet will vary depending on the type of information she discloses. The disclosure of this information is not limited to web forms alone. Alice can also send her sensitive information to Bob via email, chat programs, or file transfers. For example, suppose Alice emails Bob her address for shipping information and her credit card number for billing purposes. Like HTTP and TLS, these protocols lack the capability to determine the sensitivity of Alice’s outgoing network content and evaluate Bob’s trustworthiness. Without this capability, Alice must complete these tasks manually. This article addresses how to automate them. Figure 1 illustrates Alice sending a message to Bob. The diagram denotes two opportunities for an authorization decision during the transmission. First, Alice’s access control monitor can inspect the outgoing message to determine whether it is sensitive. Her monitor will disclose a sensitive message only if Bob is authorized to receive it. This would be useful when Alice sends her Social ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

430

•

A. Hess et al.

Fig. 2. Client Alice and server Bob exchange messages (request/response). Access control monitors inspect the messages to determine sensitivity and authorize message disclosure and acceptance.

Security number or credit card number to Bob in an email message. Second, Bob’s access control monitor can inspect the incoming message to determine whether it is sensitive. His monitor will accept a sensitive message only if Alice is authorized to send it. This would be useful when Bob receives a hot stock pick from Alice. Figure 1 illustrated the need for an access control monitor to inspect messages for sensitive content in a peer-to-peer messaging system. The same need exists in client/server systems, as shown in Figure 2. In this case, there are four opportunities in the request/response cycle for an access control monitor to inspect the messages being exchanged. The following real-world scenarios demonstrate the need for an access control monitor at each of the four points in the exchange. Case 1: Client outgoing message. Alice completes a web form by entering her credit card number and submits it to Bob. Her access control monitor detects sensitive information and determines whether Bob is authorized to receive it and has recently passed an audit demonstrating his web site meets the minimum security standards. Case 2: Server incoming message. Bob receives a request to update a file. His access control monitor verifies whether the file satisfies restrictions on the size and virus-free status of the content being uploaded. Case 3: Server outgoing message. Bob is a government server containing sensitive, classified, and compartmentalized content. As content leaves the server it is inspected for classification banners (e.g., confidential, secret, top secret). If any combination of banners is present in the text, then Bob must verify whether Alice is authorized to receive the content. Case 4: Client incoming message. Alice checks all incoming web traffic for urgent heath care information, emergency response alerts, hot stock picks, and so on. If present, her access control monitor checks whether Bob is authorized to disseminate information of high urgency and importance. The remainder of this article is organized as follows. In Section 2, we present a general-purpose access control model designed to detect whenever sensitive information is being transmitted and determine whether the sender or receiver is authorized. In Section 3, we discuss trust negotiation, a new authentication paradigm designed for open systems. Sections 4 and 5 ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

Content-Triggered Trust Negotiation

•

431

Fig. 3. The flow of information in the access control model.

describe the design and implementation of an instance of the access control model in TrustBuilder, a prototype trust negotiation system under development at Brigham Young University. The design targets open systems, where clients and servers are strangers. The implementation supports the access control model in TLS, web, and email client applications. Section 6 discusses related work, and Section 7 contains conclusions and future work plans. 2. ACCESS CONTROL MODEL TO DETECT SENSITIVE DATA AT RUNTIME In this section, we present an access control model for distributed systems that is designed to detect the transmission of sensitive information and determine whether the sender or receiver is authorized. The proposed access control model has provisions for determining the sensitivity of a message, mapping the types of sensitive information contained in the message to an access control policy, and determining whether the subject (i.e., sender or recipient) is authorized to perform the associated action. Figure 3 illustrates the flow of information in the model. The model specifies the behavior of the access control monitor for Alice or Bob shown in Figure 1. A candidate message is filtered to determine whether it is sensitive according to predefined rules. If the message content is sensitive, an access control policy is dynamically generated based on the types of sensitive information found in the message. Finally, the trustworthiness of the subject (sender or recipient) is established by determining whether the subject satisfies the access control policy pertaining to the sensitive content. If the sender first deems the recipient ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

432

•

A. Hess et al.

as trustworthy, the message is disclosed. If the recipient then deems the sender as trustworthy, the message is accepted. The three primary components of the access control model to dynamically protect sensitive content are content classification, dynamic policy association, and authorization. The remainder of this section includes a detailed discussion of these three components, followed by a discussion of the threat model. 2.1 Content Classification The model employs content classification methods to determine whether the message content is sensitive. A variety of content classification techniques exist, each directed at a specific classification domain. The model is general purpose, supporting a wide range of techniques to recognize sensitive data in a variety of contexts. Examples of classification methods that could be incorporated into an instance of the model include pattern matching, Boolean model, extended Boolean model, fuzzy sets, neural networks, Bayesian networks, and the vector space model. The proposed model adopts a filtering approach in which the queries are static and the content is dynamic. A set of queries, Q, is created by a user or administrator to describe the types of data that are considered sensitive in the local domain. The queries are stored in a database of sensitive data type definitions. For example, a user who deems his bank account number to be sensitive may create a query that detects its disclosure. Also, a user could establish a query that recognizes whenever health information or stock quotes are downloaded from the Internet to determine if the source is trusted to provide such sensitive information. Although these examples might be accomplished using simple text pattern matching, the model can also extend to more sophisticated algorithms, such as algebraic and probabilistic models that may require training on relevant content. The database of sensitive information may require careful protection from attackers. For example, the data could be stored on disk in encrypted form and pinned in main memory when it is being accessed. Each query has a name that represents the associated relevant content type, such as bank account number query for the previous example. Associated with each sensitive content type is an access control policy created by a user or administrator that specifies the access control requirements that the other party must satisfy to send or receive the sensitive content. The content classification engine filters all dynamic content according to the following definitions:
classify(m, Q) = sim(m, q) = T ∀q∈Q

 sim(m, q) =

typeName ∅

if m is similar to q otherwise

ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

Content-Triggered Trust Negotiation

•

433

The access control monitor invokes the classify function, which takes as input the message m and a set of queries Q, and returns a set of sensitive content type names T . Each q ∈ Q is a query that looks for a specific sensitive content type. The classify function is defined as the union of the results of a similarity function sim applied to all elements of Q. The sim function filters the message m with respect to query q, according to the classification method in use. 2.2 Dynamic Policy Association The usual approach of associating an access control policy with a resource a priori is not always feasible, such as whenever sensitive content is generated dynamically and transmitted to another party. It may also be prohibitive to manually assign access control policies when the data set is large and fluid. The model supports the late binding of policies to sensitive resources. Once the content classifier determines that a message contains sensitive content, an access control policy is dynamically associated with the message to control its disclosure or authorize its receipt. The model accomplishes this using the following approach. The dynamic policy association phase utilizes a database of one-to-one mappings between each sensitive content type and its corresponding access control policy. Let us suppose that the classification engine generates a set T of sensitive content types associated with a message m. Let P be the set of all policies in the system such that for every t ∈ T , there is an associated policy p ∈ P . Given all the policies that apply to message m, a conflict resolution policy is needed to determine the final access control policy p for m. For example, given only positive authorizations, p can be constructed by conjoining each policy p associated with every t ∈ T . The general-purpose design of the model allows for a variety of access control policy languages—identity-based, role-based, capability-based, and attributebased. The model can be integrated with a wide range of authentication mechanisms. 2.3 Authorization Once an access control policy has been dynamically associated with a message, the access control monitor determines whether or not the subject (sender or recipient) is authorized. The access control decision relies on the generated policy and any credentials associated with the subject based on identities, capabilities, or attributes. Credentials may already be available to the access control monitor due to an authentication procedure conducted earlier. For instance, in a closed system, the subject may already be authenticated to a user ID or group ID through an identity-based authentication mechanism such as a password or an identity certificate. In open systems, credentials may initially be unavailable to the access control monitor because the subject is a stranger who was unaware of the access control requirements. In this situation, one approach to credential acquisition is to pull credentials from the subject on demand at the time of the access control decision to authenticate ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

434

•

A. Hess et al.

the subject according to the requirements of the access control policy. This latter approach is uncommon in existing systems and will be addressed in this article. 2.4 Threat Model The access control model is not foolproof. It is intended to prevent the inadvertent, accidental release, or acceptance of sensitive information. The classification routines will be easily circumvented by a determined sender using cryptographic, steganographic, or even simple obfuscation techniques. For example, an employee wishing to circumvent his access control monitor and send sensitive corporate data to an unqualified recipient can simply encrypt the data before sending the message. If the corporate firewall blocks encrypted content, the user can hide the data using steganography. Another concern is data encoded in various file formats. Applications such as Microsoft Word include large amounts of hidden information in their proprietary file formats, such as author information and undo data. The PDF format is an open standard, but has also caused problems for government agencies when redacted information was merely covered up by black boxes rather than being actually expunged from the file. A simple text-scanning content classifier is obviously likely to miss much of this potentially sensitive data; although a more sophisticated classifier could be built, which would properly interpret data in common file formats. Such a classifier could well prevent accidental disclosures like these. This is an excellent avenue for future work. An even more serious concern is the potential for attackers to circumvent a victim’s access control monitor that is inspecting outgoing messages without the victim’s knowledge. For instance, a malicious web page requesting sensitive information could include JavaScript code to cause the victim’s browser to obfuscate entered form data before submission. Any situation in which the attacker can cause the victim’s computer to transform sensitive data before transmission could be an avenue for attack. Another example would be an attacker who sends a document to a victim in a file format unsupported by the content classifier. The victim’s monitor would not be able to identify any data requiring sender authentication, and even more seriously, would not be able to adequately check any data added to the document by the victim before returning it to the attacker. On the other hand, if client-side encoding attacks can be prevented (e.g., by disallowing scripting and obscure file formats), attacks such as “phishing” can be effectively discouraged. “Phishing” (see www.antiphishing.org) is an attack in which attackers use spoofed email addresses and authentic-looking web sites to harvest sensitive information from unsuspecting users. In such situations, the access control monitor would attempt to authenticate the attackers and warn the user when the attacker’s credentials do not stack up. And in all of these cases, a slightly more interactive usage model could still prevent many accidental disclosures or receipts. An indicator like the “lock” icon in most browsers could unobtrusively inform users whether any sensitive information was detected in incoming messages. Observant users would notice ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

Content-Triggered Trust Negotiation

•

435

that data which should have been detected was not, and consequently that no authentication has taken place. Likewise, users could flag outgoing data containing sensitive information. If the access control monitor fails to find any, it can hold the message pending further direction from the user. Access control monitors could also warn users about using file formats or other mechanisms that have the potential of fooling the content classifier. The remainder of this article will focus on access control in open systems, where the client and server are strangers. The purpose of the more general access control model presented in this section is to demonstrate that the concepts explored in the remainder of this article are part of a more general access control problem, and elements of a solution may be applicable to the more general problem. 3. TRUST ESTABLISHMENT IN OPEN SYSTEMS The standard model for access control consists of the triple (S, O, M ), where S is the set of subjects, O is a set of objects, and M is an access control matrix. The rows and columns of the matrix correspond to distinct subjects and objects, respectively. An entry in the access control matrix, denoted M [s, o], where s ∈ S and o ∈ O, represents the privileges of subject s to access object o. The columns of M are access control lists for objects in the system. The rows of M are capability lists for the subjects in the system. This access control model works well in a closed system with a known set of subjects and static objects. The access control model based on known subjects is problematic in open systems like the Internet where a client and a server often begin a transaction as strangers, that is, they have no preexisting relationship and are not in the same security domain. Thus, identity-based authentication is not appropriate in this setting. Knowing that the server is actually bank.com is not nearly as useful as knowing that the server’s institution is a certified bank that is FDIC insured. Trust negotiation [Winslett et al. 2002; Winsborough and Li 2002; Bonatti and Samarati 2000; Winsborough et al. 2000] is an approach to establishing trust between strangers in open systems. It utilizes credentials that specify attributes of entities and/or rules for deriving an entities’ attributes. These attributes may involve sensitive information, such as financial or medical data, or sensitive corporate assets such as security policies. One approach to trust negotiation is for a resource requester and an access mediator to establish trust in one another through the cautious, iterative, bilateral disclosure of credentials. Each negotiator establishes policies to regulate not only the granting of access to system resources, but also the disclosure of credentials, policies, and related sensitive information to other parties. A negotiation consists of a sequence of exchanges that begin by disclosing credentials that are not sensitive. As credentials are disclosed, higher levels of mutual trust are established, and policies for more sensitive credentials may be satisfied, enabling these credentials also to be disclosed. In successful negotiations, credentials eventually are disclosed that satisfy the policy of the desired resource. ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

436

•

A. Hess et al.

Fig. 4. Simple trust negotiation scenario between Alice and Bob.

An example of a simple trust negotiation is shown in Figure 4. Alice requests a service from an online merchant Bob. She has no prior knowledge of Bob’s requirements to access the service because she is a first-time customer. One approach is for Bob to transmit a policy to Alice that specifies that she must submit a credit card number to make an online purchase. Alice is willing to disclose her credit card number only to a business that is a member of the BBB. In accordance with her policy, her trust negotiation agent requests that Bob disclose a BBB member credential to her. Bob then sends Alice a BBB member credential. Finally, Alice submits a valid digital credit card and receives the service. Another approach to trust negotiation is called hidden credentials [Holt et al. 2003]. Hidden credentials allow policies to be enforced noninteractively, without requiring other parties to actually disclose their credentials. Interactive protocols can also be used. Hidden credentials provide improved privacy protection compared to traditional trust negotiations that depend on direct credential and policy exchange. They can be built from Identity-Based Encryption (IBE) schemes [Boneh and Franklin 2001]. We give a simplified overview of hidden credentials in Section 5.3 and show how they can be used in the context of Simple Mail Transfer Protocol (SMTP). The remainder of this paper targets open systems where subjects are characterized by their role or other attributes, requiring authentication techniques based on attributes other than identity. In addition, the objects that require ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

Content-Triggered Trust Negotiation

•

437

protection may be generated dynamically and do not have an access control policy associated with them. Sensitive objects must be detected on-the-fly so that an appropriate access control policy can be associated with them at runtime to prevent unauthorized access. 4. CONTENT-TRIGGERED TRUST NEGOTIATION DESIGN To date, the focus of trust negotiation has been on the protection of sensitive server resources. Only a server could initiate a trust negotiation in response to a client’s request for a sensitive resource. During trust negotiation, client protection has been limited to the authorized disclosure of sensitive credentials and policies. This section presents the design of content-triggered trust negotiation by a client, allowing a client’s access control monitor to initiate a trust negotiation with a server when it detects at run-time that an outgoing or incoming message is sensitive. The design is an instance of the access control model presented in Section 2, illustrating how content-triggered trust negotiation by a client is part of a more general model of dynamic access control. The fundamental concepts also apply to content-triggered trust negotiation by a server. The focus of this article is on the client because there are design issues when the client initiates a trust negotiation that has not been addressed previously. Content-triggered trust negotiation at the client occurs under two circumstances. First, it can occur just prior to a client disclosing sensitive information as part of a service request. Second, it can occur just after a client determines it has received sensitive information from a server and the client requires that the server demonstrate that it is trustworthy. This form of protection has not been available to clients in any previous work on trust negotiation. Content-triggered trust negotiation at the client turns the traditional client/server access control model on its head, and addresses how to protect the sensitive content that clients disclose to and receive from untrusted servers. 4.1 Content Classification Design The content classification module in TrustBuilder supports a variety of classification techniques. The initial design supports three different classification models that each have a relatively high accuracy within their respective application domain: Boolean, vector space [Salton and Lesk 1968], and fuzzy set [Ogawa et al. 1991]. The Boolean method is based on set theory, and its queries are formulated using Boolean algebra. These queries are composed of keywords and determine set membership of a given message. Set membership is strict and is determined by the binary result of a query. The strengths of this method are its simplicity, speed, and guaranteed accuracy; however, its weakness lies in its inability to perform partial matches. The fuzzy set model extends the Boolean model by allowing approximate matching. Instead of enforcing strict set membership, this model returns a degree of membership bound between 0 and 1. Traditionally, this model is very accurate, with low false positive rates. The TrustBuilder implementation is based on the fuzzy set model described in Ogawa et al. [1991], which simulates ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

438

•

A. Hess et al.

a thesaurus made up of keywords from existing messages that provide partial matching for query terms. The vector space model, like the fuzzy set, also allows for partial matching. This model operates by transforming the terms in queries and messages into vectors of numeric weights. The angle between a query vector and message vector is then measured to determine the degree of similarity between the query and message, with smaller angles indicating higher relevancy. While this approach is more flexible than the Boolean method, a small percentage of misclassifications occur, resulting in false positives and negatives. There are two kinds of misclassifications—false positives and false negatives. A false positive occurs when content is classified as sensitive when it actually is not. When this overprotection happens, trust negotiation transpires even though it is not necessary. If the recipient fails to authenticate, one option is to notify the client and allow her to override TrustBuilder’s decision and send the content regardless. This is analogous to how web browser implementations respond when they receive an invalid server certificate in TLS. In such cases, the user can choose to bypass the browser’s security settings and accept the invalid certificate. A false negative occurs when sensitive content is deemed unrestricted and is inappropriately disclosed. One approach to reducing false negatives is to classify more aggressively. However, this will likely result in an increase in false positives. To minimize the overhead of content classification at runtime, the fuzzy set and vector space model support offline training on relevant sensitive messages to create the queries used to identify sensitive content. Initial experiments using all three content classification approaches demonstrate that the overhead for classification can be acceptable for interactive applications like web browsing [Hess 2003]. 4.2 Dynamic Policy Association Design To provide administrative scalability, the TrustBuilder design leverages a rolebased access control model [Sandhu et al. 1996]. Roles can be thought of as the intensional analogue to the extensional groups widely used for access control in environments such as file systems. The policy language used should allow users to define new roles and their semantics. In the design, access control policies for sensitive content types are represented as role expressions, according to the grammar in Figure 5. The policy is created by a user or administrator to specify what roles the server must satisfy to send or receive the sensitive content. The language for describing role-based access control requirements is built on propositional logic without negation. Because the design targets open systems, negation is excluded to ensure monotonicity. If it were included, then parties could establish trust by not admitting that they possessed certain credentials or attributes. By use of logic, role expression policies are capable of capturing intricate trust requirements by combining roles with Boolean operators. Role expressions are considered satisfiable if there exists some interpretation for which the logic evaluates to true. ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

Content-Triggered Trust Negotiation Expression ComplexExpression Op

→ | → | →

•

439

Role ComplexExpression (Expression) Expression Op Expression ∧|∨

Fig. 5. Role expression grammar in BNF.

The following is a simple example of the use of role expressions in the dynamic policy association process based on the purchasing scenario presented in Section 1. Suppose Alice is completing an online purchase from Bob, and he requires her to disclose her credit card number and mailing address. Once Alice’s content classification engine determines that these items are sensitive, her local policy database is consulted to obtain the access control policy associated with each type of sensitive information. The conjunction of the relevant role expressions creates the logical role expression for the final disclosure policy. These generated policies can be rewritten as more precise expressions without a loss of semantics by applying Boolean algebra rules, such as the absorption, distributive, and idempotent laws. For instance, if her credit card number has an associated access control policy of AuthorizedVisaMerchant ∧ BBBMember and her mailing address has an associated access control policy of BBBMember, the simplified conjunction of these two policies is AuthorizedVisaMerchant ∧ BBBMember. TrustBuilder utilizes the XML-based Trust Policy Language (TPL) [Herzberg et al. 2000], developed at IBM Research, to define the mapping of strangers to roles based on credentials issued by third parties. Each role contained in the final role expression generated from the policy association phase has a corresponding TPL policy that TrustBuilder uses to authenticate the opposing party. TrustBuilder uses similar policies to govern the disclosure of sensitive credentials during trust negotiation. The current TrustBuilder implementation supports X.509v3 [International Telecommunication Union 1997] certificates. 4.3 Trust Establishment Protocol Design Once a message is determined to be sensitive and an access control policy has been generated, the client’s access control monitor must determine if the server is authorized. If no server credentials are available, the client can initiate a trust negotiation to attempt to obtain the necessary credentials. In this discussion, the term agent refers to an agent that negotiates trust on behalf of a client or server. An important design decision is how the client’s agent locates the server’s agent with which to initiate a negotiation. Previous work in trust negotiation has not addressed this issue because the server simply reacts to a client request for service and initiates a trust negotiation in-band with that client. With clientside, content-triggered trust negotiation, the client and server cannot rely on an existing connection because the negotiation may take place before the client makes first contact with the service. Standard conventions need to be adopted to prescribe the relationship between a service and its associated trust negotiation agent. The solution cannot require clients to disclose, even inadvertently, sensitive information about the service request they intend to submit. ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

440

•

A. Hess et al. Table I. Common Application-Level Protocols and Typical Sources of Potentially Sensitive Content Protocol HTTP SMTP FTP SOAP NNTP CORBA

Potential Sensitive Data in Protocol Form data, headers, cookies, URLs Email messages, attachments Transferred files Method parameters, method names Uploaded news postings Method parameters, method names

For possible solutions, consider a client’s agent that desires to contact a web server’s agent. A web server could support trust establishment in advance of a sensitive request in several ways. First, a new HTTP header could be introduced to indicate the desire to establish trust in the web server prior to making a specific request of the server. Second, the TLS protocol could be extended to support a more sophisticated version of server authentication through trust negotiation rather than the limited client/server authentication it supports today. Trust Negotiation in TLS (TNT) was an early implementation of this concept, which assumes that servers will enforce access control policies on requested resources after the secure connection has been established [Hess et al. 2002]. Extending TNT to support content-triggered trust negotiation would allow clients to initiate trust negotiation during the establishment of a TLS connection before any sensitive data is transmitted. Third, web servers could employ an external agent to handle trust negotiation by redirecting the client to the agent when trust negotiation is requested, relieving the server from making trust decisions regarding unknown clients. Other technologies besides web servers could adopt similar or alternative approaches. Consider a client using distributed object systems technologies such as Simple Object Access Protocol (SOAP) and Remote Method Invocation (RMI) to invoke a method that includes a sensitive input parameter. Some approaches to permit the client to establish trust in the service before completing the RMI could be to provide a standard method interface with each object for establishing trust or to provide a standard service for establishing trust. 5. CONTENT-TRIGGERED TRUST NEGOTIATION IMPLEMENTATION This section describes an implementation of content-triggered trust negotiation in TrustBuilder that extends three existing communication protocols. The goal was to permit the exchange of credentials and policies within the context of existing communication protocols. The implementation demonstrates that the access control model to dynamically protect sensitive content is flexible, general purpose, and suitable for integration into a wide range of applications and protocols. Application-level protocols are particularly relevant to the model because most sensitive content originates at that level and the full semantics of the data are available to the content analysis procedure for determining sensitive content. Table I lists common application-level protocols and typical sources of ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

Content-Triggered Trust Negotiation

•

441

potentially sensitive data in those protocols. Applications using these protocols could adopt the access control model to safeguard client data. The TrustBuilder implementation supports several kinds of applications to demonstrate that the model is general purpose. The prototype supports web applications that use HTTP [Fielding et al. 1999] and email applications that use SMTP [Postel 1982]. Although both protocols are common and frequently carry sensitive client data, they differ significantly. For instance, HTTP is a synchronous protocol used for direct communication between web clients and servers. In contrast, email clients use SMTP to send messages asynchronously to the email server of the recipient. The email message is indirectly relayed through Message Transfer Agents (MTAs) rather than through a direct TCP connection between the sender and the receiver. In addition to the HTTP and SMTP application-level protocols, we implemented an extension to TLS that supports content-triggered trust negotiation. TLS serves as a supporting, transparent protocol for many different connectionoriented applications. The TLS extension enables these applications to be able to leverage the access control model. Our goal in developing the prototypes was to determine whether the access control model was flexible enough to accommodate the differences in these application domains. In the remainder of this section, we discuss the major design issues faced in building a prototype for TLS, HTTP, and SMTP applications. Any access control system requires that the following criterion be met: (1) Policy enforcement: Resources may only be disclosed to recipients who satisfy the policy governing their disclosure. Additionally, the following properties may be desirable: (2) Credential ownership: The sender and receiver must prove that they know the private keys corresponding to each credential they present. (3) Signatures and receipts: The sender proves that she is the sender of the message, and the receiver proves that he received it. Note that (2) does not necessarily follow from (1). A malicious receiver could display someone else’s credentials during trust negotiation if the sender does not enforce credential ownership. The sender would verify that the credentials are not fake, and then encrypt her message against the public key listed in the credentials. Since the receiver does not know the private key corresponding to those credentials, he cannot decrypt the message. Therefore, the sender’s policies were not violated. But without enforced credential ownership and signed receipts, the sender is not guaranteed that the intended recipient actually received the message, and the receiver cannot be sure who sent a message. Enforcing credential ownership and creating signatures and receipts are well-understood techniques, and careful use of nonces and public key encryption can ensure that reflection and replay attacks are not feasible. 5.1 TLS TLS is a connection-oriented protocol that provides a secure channel between a client and a server. TLS supports confidentiality, data integrity, and ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

442

•

A. Hess et al.

client/server authentication. The TLS handshake protocol provides a means for authentication and the negotiation of security parameters, such as the encryption algorithms, encryption keys, MAC keys, and so on, that are used to transmit data securely. The TLS record protocol specifies how application data are actually transmitted between two communicating hosts so that confidentiality and data integrity are ensured. Once a TLS connection is established using the handshake protocol, it is possible to conduct a TLS rehandshake. The rehandshake is simply the TLS handshake performed over an existing TLS connection. The TNT protocol is a backward compatible extension to the TLS handshake protocol that uses trust negotiation to establish trust between strangers. TNT was originally designed to support server-initiated trust negotiation whenever an unknown client requested a protected resource. This section describes an extension to TNT to support trust negotiation initiated by a client. TNT is ideal for performing content-triggered trust negotiation because of TLS’s independence from application layer protocols. TLS sits logically between the application and transport layers of the protocol stack, providing transparent confidentiality, data integrity, identity-based authentication, and, with the advent of TNT, trust negotiation. Since TNT extends TLS, it can be applied to any TCP-based protocol, such as HTTP, Telnet, FTP, LDAP, and WAP, without modification of the application layer protocol. To take advantage of TLS and TNT, an application merely calls the TNT library and requests a trust negotiation. TNT is also a good choice because it relies on the existing, established security mechanisms of TLS for properties such as integrity, confidentiality, proof of credential ownership, and resistance to active attackers. The TNT protocol, shown in Figure 6, is designed to support trust negotiation between a TLS client and server. A full explanation of TNT is available in Jacobson [2003] and Hess et al. [2002]. Using TNT, trust negotiation can occur anytime after a client and server have already set up a TLS session. Either the client or server can initiate trust negotiation whenever they have sensitive data to send to the other communicant, because trust negotiation occurs during an abbreviated rehandshake. Each communicant may cache the roles or role expressions to which the other communicant has already authenticated. Whenever the client or server has sensitive data to send to the other communicant, it can determine whether or not the other has already authenticated to the roles in the policy that governs the data to be sent. If so, it can simply send the resource. Otherwise, it can initiate another trust negotiation rehandshake. The server begins a trust negotiation rehandshake by sending the client a HelloNegotiationRequest message. The rehandshake is encrypted using the existing TLS parameters, ensuring that sensitive policies and credentials are transmitted confidentially. The client responds with a ClientHello message, which is followed by a ServerHello message from the server. When a client initiates a trust negotiation rehandshake, the exchange begins with the ClientHello message. The sessionID included in the hello messages is the sessionID associated with the current session, to allow for streamlined session resumption following a successful trust negotiation. ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

Content-Triggered Trust Negotiation

•

443

Fig. 6. TNT messaging. (*) Indicates a message or set of messages that may occur zero or more times in succession. (+) Indicates a set of messages that may occur one or more times in succession.

After the exchange of hello messages, the TNT protocol enters the negotiation phase, in which the server and client take turns disclosing policies and certificates until the negotiation succeeds or it is terminated. During the server’s turn, the server first discloses zero or more certificates using a combination of TLS Certificate and CertificateVerify messages. Immediately following each Certificate message, the server demonstrates ownership of a private key using the CertificateVerify message, unless the server has already demonstrated possession of the private key earlier in the negotiation. The CertificateVerify message is encrypted using the public key associated with the certificate the server just disclosed. It is sent to prove to the client that the server is the owner of the certificate in question. Next, the server discloses zero or more Policy messages. Policies are disclosed to inform the client regarding the certificates the client must disclose to advance the negotiation. Finally, the server sends a ServerTurnDone message indicating that the server has nothing further to disclose during this round of the negotiation. Next, the client takes a turn disclosing information to advance the negotiation, following the same general pattern as the server. The client concludes its turn during the current round of negotiation by sending a ClientTurnDone message. ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

444

•

A. Hess et al.

Fig. 7. Traditional HTTP client and server.

The negotiation continues for a number of rounds until the trust negotiation initiator’s policy is satisfied or the negotiation is terminated. The initiator checks to see whether the policy is satisfied after each round of the negotiation. Once the policy is satisfied, the initiator successfully concludes the negotiation by sending the NegotiationDone message. The final phase of the TNT protocol is very similar to the conclusion of the abbreviated TLS handshake. The initiator sends a ChangeCipherSpec message and a Finished message. Once the respondent replies with the same two types of messages, the rehandshake is complete. Note that the integrity and confidentiality features of TLS can provide an implicit “signature” and receipt for the transmitted message. Because only Alice and Bob know the session keys, Bob knows Alice is sending the messages he receives once rehandshaking is complete. And as long as Alice receives a valid message from Bob terminating the connection after she sends her message, Alice knows that Bob has successfully received her message. In TLS, application data may span several packets. For effective filtering, the client or server may need to inspect the entire application-layer message to have the full context of the data that will be transmitted rather than inspect the packets independently. 5.2 HTTP A web browser requests resources from a web server through HTTP, a lightweight, stateless, application-level protocol (see Figure 7). HTTP is able to transport a variety of data types. There are several instances where a web client could intentionally or inadvertently disclose sensitive data. The most prevalent case occurs when users fill out a web form and submit it to a server. The client’s data are transferred in the body of the HTTP request or appended to the URL, depending on whether the web form uses the POST method or GET method, respectively. When a user uploads a file to a web server, it is transferred in the body of the request message. A web request could inadvertently disclose sensitive information whenever the HTTP Referrer header is present. This header contains the entire URL of the referring web page. This presents a serious privacy vulnerability, since any HTML form data embedded in the previous URL is included. Even if the URL does not contain embedded client content, the web request could be sensitive. The resource requested in the URL may reveal information about a client’s interests or intentions. For example, a user requesting a web page on certain health issues invites the server to construe certain assumptions about the client. ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

Content-Triggered Trust Negotiation

•

445

Fig. 8. HTTP request with sensitive information in the referer header, cookie, and body.

HTTP cookies also present a risk for the inadvertent disclosure of sensitive information. In essence, cookies are pieces of information that a web server can store and retrieve from a client’s machine. Even if cookies contain sensitive content, it is usually not a problem to send them back to the original server that generated them. The danger comes from intradomain cookies, or cookies that are sent to all requesting servers within a given domain. This occurs when the cookie’s creator adds the domain tag to the cookie header and indicates that other machines within a given subdomain can access the cookie. For example, a cookie sent from www.example.com with its domain set to example.com would be accessible to servers such as shipping.example.com and order.store.example.com. This is a problem whenever the user trusts the cookie’s originator but does not trust the other servers within the originator’s domain. Figure 8 illustrates an HTTP request with several pieces of sensitive information included in the referrer header, cookie, and content body. To perform trust negotiation over HTTP, the protocol must be extended. The current HTTP specification provides for two forms of authentication, Basic and Digest, that occur in-band with HTTP requests and responses. For the purposes of trust negotiation, we have created a new authentication type called TrustNegotiation. Unlike Basic and Digest authentication, which support the exchange of passwords or password digests between a client and server within HTTP headers, TrustNegotiation supports the exchange of credentials and policies. Since credentials and policies may be sensitive, TLS is used to ensure confidentiality and integrity. There are several options for adding the functionality of trust negotiation to a web browser. First, a client-side proxy could intercept client requests and determine if the content is sensitive so that additional trust in the server can be established before forwarding the request. Alternatively, a proxy could be configured to sit at the edge of a corporate network inside a firewall and provide consistent, mandatory content disclosure policy association for an entire organization. This eases administrative overhead because it does not rely on clients configuring their own local environment, nor does it require the installation of ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

446

•

A. Hess et al.

Fig. 9. Traditional HTTP client and server with security agent proxy.

additional software on each client machine. It also permits transparent interception of all outgoing requests, with potential to dramatically improve the control that organizations and households have over their sensitive content. However, the overhead of examining each request could be prohibitive. A browser plug-in offers similar functionality, but at the individual browser level. This would allow individual users fine-grained control over their personal content. For our implementation, we built a client-side proxy that provides a flexible test platform for all types of browsers and scenarios (see Figure 9). The proxy indicates the desire to negotiate trust by making an HTTP request to the server including the TrustNegotiation authentication header discussed earlier. This signifies to the server that it should return a trust negotiation response. A negotiation occurs for each sensitive HTTP request during a session with the server. When a web server that supports TrustNegotiation over HTTP observes a TrustNegotiation header within an HTTP request, the requested resource portion of the URL is ignored. Hence, the client can simply indicate the server’s root as the requested URL, thereby not revealing what resource it intended to request. When sensitive content is detected and trust is established with the web server, the proxy forwards the HTTP request to the web server and relays the subsequent response to the client. In the case of a failed trust negotiation, the proxy terminates all communication with the web server and sends a web page back to the client’s browser, indicating trust negotiation failure. Using standard HTTP redirects, the server will redirect the client to the port running TLS for a secure negotiation after the client’s initial trust negotiation request. In case the web server does not recognize the trust negotiation header, it will simply reply with what it perceives as a request for the root document. This ensures backward compatibility with current HTTP applications. 5.2.1 Avoiding Man-in-the-Middle Attacks. Note that even though we conduct our authentication protocol via a TLS-protected connection, we have to consider man-in-the-middle (MITM) attacks. TLS can ensure that Alice and Bob each have a certificate issued for their own domain, but it cannot prevent Bob from making a second connection with Carol, passing Alice’s policies and credentials along to Carol (and vice versa), then stepping in once Alice and Carol have established trust. Alice and Carol each need to check that the person they are talking to (Bob) is the same person that’s proving ownership of their credentials. They can do this by asking the TLS layer to provide the public key used when establishing the connection, and making their proofs of credential ownership with respect to that key. For example, Alice might prove ownership of a particular credential by signing a message like the following using the private key associated with that ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

Content-Triggered Trust Negotiation

•

447

credential: “I’m Alice, and this is my proof of ownership for the session I have now established with bob.example.com, whose TLS public key fingerprint is: . . . ”. If Bob was mounting a MITM attack, Carol would see that Alice was not talking directly to her, but rather to Bob. Note that this might leave open a possibility for replay attacks, should Alice’s proof of ownership to Bob be leaked to someone else—that person could then display Alice’s credential to Bob along with the replayed proof of ownership. Random session nonces, used properly, would make such replays infeasible. 5.2.2 Man-in-the-Middle Proxies. Traditional web clients make TLS connections through proxies by sending an HTTP CONNECT request to the proxy. This command indicates that the proxy should connect to a specified server and act as a tunnel between the two hosts. The proxy is required to respond and indicate success or failure, after which the client begins to negotiate a TLS session directly with the web server through the proxy. Even though the proxy can see all information relayed between the two hosts, it cannot determine the message’s content because of the cryptographic properties of TLS. This feature is detrimental to our proposed system because the proxy must be able to view the content in plaintext to determine its sensitivity. This problem is addressed by creating a MITM proxy [Rescorla 2001]. This proxy works much like the MITM attack just described, but with permission explicitly granted by the system administrator to allow the proxy to protect TLS-encrypted data. When the client requests that a tunnel be created through the proxy to the destination web server, the proxy does not make the connection, but signals to the client that it has been made. Believing that the tunnel is established, the client then begins the TLS handshake with what it believes to be the web server, but is actually the proxy server. The client starts by sending the ClientHello message and expects in return the ServerHello message from the web server. This message is expected to include the web server’s public key identity certificate; however, this is not feasible for the proxy to send, since the proxy has no access to the server’s private key to answer key challenges. Instead, the proxy replies with its own certificate with the common name indicated as ∗ instead of the web server’s domain name. This common name is used by the browser to verify that the certificate belongs to the web site that is being browsed and not some MITM attacker. These names can be wildcard matched, thus allowing the proxy to send the name of ∗ to match all web sites. Because no respected certificate authority would issue such a certificate, the proxy’s administrator must create a local certificate authority that issues the certificate. Additionally, the administrator must add the local authority to the browser’s list of trusted certificate authorities. When the client receives the proxy certificate, it accepts it as the valid certificate, since domains are wildcard matched. Once the TLS session is established between the client and the proxy, the proxy will be able to examine the client’s data in plain text and determine its sensitivity before forwarding it to the intended server. The proxy server will then make a TLS connection to the intended web server and either release the content or negotiate trust based on sensitivity. ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

448

•

A. Hess et al.

Fig. 10. Traditional SMTP/POP3 message relaying.

Fig. 11. Example of an email message containing sensitive content.

5.3 Email SMTP is the principal means by which email is transported through the Internet. Clients use this protocol to forward mail to the end recipient via Mail Transfer Agents (MTA). Email messages are forwarded by these MTAs to the recipient’s local mail server mailbox. To retrieve the messages from the mailbox, the recipient uses a protocol, such as the Post Office Protocol v3 (POP3) or the Internet Message Access Protocol. Figure 10 illustrates how SMTP and POP3 are used to relay email messages. Typical electronic mail is composed of an envelope, header, and a body. The message body may consist of a single message or a multipart collection of messages and attachments. Clients may disclose sensitive content in an email’s subject line, message body, or attachments. Figure 11 illustrates a multipart message with sensitive content included in the email body and the attachment. Much like the previous HTTP example, we have inserted a security agent proxy on the client to examine relevant portions of outgoing SMTP messages for sensitivity. When an outgoing email message is deemed sensitive, trust negotiation is initiated by withholding the sensitive message and sending a trust negotiation email message. These messages are MIME multipart email messages containing credentials and policies as attachments. The security agent ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

Content-Triggered Trust Negotiation

•

449

Fig. 12. Traditional SMTP/POP3 message relaying with security agent proxies.

proxy on the recipient side scans incoming emails when messages are retrieved from the mail server via POP3. To distinguish these trust negotiation mail messages from normal email messages, we introduced a new mail extension header, X-TrustNegotiation, which is ignored by mail agents that do not support trust negotiation. When a trust negotiation message is received, the recipient responds by sending a relevant trust negotiation response. Messages are exchanged between security agent proxies using SMTP and POP3 until the message originator deems success or failure. If successful, the original message is sent to the authenticated recipient; otherwise, an error response is sent to the sender in the form of an email. Figure 12 illustrates message relaying with our security agent proxies that support trust negotiation. The major differences between the HTTP and SMTP scenarios are the trust negotiation message formats and message transport security procedures. Trust negotiation messages in HTTP are sent inline with HTTP requests and responses. SMTP trust negotiation information, including credentials and policies, differs by being sent as multipart email messages, allowing backward compatibility with existing mail systems. Our implementation works with common email clients, such as Outlook and Mozilla, and thus far includes policy and credential exchange and credential verification, but does not yet ensure credential ownership or secure, verified delivery. Also, HTTP messages have a single sender and recipient. In contrast, SMTP allows a single sender to specify multiple recipients. This point-to-multipoint communication occurs when additional email addresses are supplied in the To:, Cc:, or Bcc: fields. In this case, the sender would negotiate trust with each receiving party before disclosing a message containing sensitive content. Sometimes, Alice may send a sensitive email message to Bob, but Bob is an alias for a list of recipients. The email server for Bob forwards the message to all the subscribers to the list. If Alice sends a trust negotiation request, then each of the subscribers will reply with a trust negotiation response. Some email servers return the subscriber’s email address in the In-Reply-To: and References: headers, which contain the message-id of Alice’s initial request. Alice could recognize this situation and negotiate trust individually with each subscriber, and disclose the sensitive message only to those that authenticate. Establishing trust via SMTP is more challenging than HTTP, where we could assume a stateful, secure connection provided by TLS for the duration of the HTTP transaction. Because SMTP is based on a store-and-forward paradigm, message occasionally take hours or days to propagate across the network. Because trust ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

450

•

A. Hess et al.

negotiation often requires multiple rounds of messages, trust negotiation agents will need to be able to maintain state information for each message for hours or days if necessary. This lack of immediacy does come with an advantage, though—the extra computational and space overhead for encryption will not be as noticeable to the end users, and more computationally intensive content classification techniques can be employed. Clearly, though, minimizing the number of round trips will be a high priority because of the high latencies involved. Hidden credentials [Holt et al. 2003], which we mentioned in Section 3, are ideal in this regard. A simplistic description of how hidden credentials might be used in the model follows. In a hidden credential scheme, IBE [Boneh and Franklin 2001] private keys specifying identities as well as attributes are used as credentials. If Alice wants to send message M to [email protected], and the content classifier constructs a policy which requires that [email protected] possess attribute ClassifiedClearance as attested by the CIA, she calls the hidden credential encryption function: HC E (M , [email protected], CIA ⇒ ClassifiedClearance) This translates roughly to an IBE encryption of M against the identity string “[email protected]: ClassifiedClearance”, using a private key generator public key belonging to the CIA. Alice can send the encryption of M to Bob knowing that her policy will be enforced. Policies with more than one term, for instance (ClassifiedClearance ∧ USCitizen) are also handled properly by HC E , by encrypting M multiple times, once for each term, according to the relevant Boolean operator. Details are in Section 5 of Holt et al. [2003]. This approach has the advantage that Alice only sends a single message to Bob, just as she would with an unprotected email message. Bob does not need to prove credential ownership in this protocol, which is a tremendous advantage if Bob’s credentials are sensitive. Obviously, a receiver receipt is not possible if Bob does not want to let Alice know what credentials he actually has. The other disadvantage is that Bob receives the encrypted resource whether he fulfills Alice’s policy or not, and such ciphertexts would be a liability if the system were later compromised. However, other protocol implementations are possible using hidden credentials that avoid these disadvantages while still greatly reducing network overhead compared to traditional trust negotiation. 6. RELATED WORK Previous work has incorporated X.509v3 certificates that store attributes or roles of subjects for use in access control decisions [e.g., Chadwick and Otenko 2002; Herzberg et al. 2000; Shin et al. 2002]. Research in trust negotiation treats certificates themselves as potentially sensitive, requiring an access control framework to regulate their disclosure. There are several recent research projects that explore trust negotiation using digital credentials. RT [Li et al. 2002; Winsborough and Li 2002] is a role-based trust management framework ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

Content-Triggered Trust Negotiation

•

451

that has been used for trust negotiation. Bonatti and Samarati [Bonatti and Samarati 2000] introduced a trust establishment framework. Their system includes a portfolio and service protection language that expresses rules for accessing services and disclosing user portfolio objects, including credentials. X-Sec [Bertino et al. 2001] is an XML-based language for specifying credentials and security policies for Web document protection. It was not originally designed for establishing trust between strangers, but it can easily be extended to do this. Examples of our earlier work in trust negotiation include support for sensitive credentials and access control policies [Seamons et al. 2001], the definition and interoperability of trust negotiation strategies [Yu et al. 2003], a trust negotiation protocol based on an extension to TLS [Hess et al. 2002], protecting privacy during trust negotiation [Seamons et al. 2002], an analysis of policy languages for trust negotiation [Seamons et al. 2002], and the development of the TrustBuilder architecture for trust negotiation [Winslett et al. 2002]. The work presented in this article compliments the previous work on trust negotiation, and is the first example of content-triggered trust negotiation to permit a client to proactively establish trust in a server prior to sending a sensitive service request. There are efforts underway in the Semantic Web community to design and develop policy languages supporting dynamic access control [Kagal et al. 2003; Tonti et al. 2003; Uszok et al. 2003], with similarities to the access control model presented in this article. In these systems, policies are dynamically assembled at run-time to enforce access control. The language described in Kagal et al. [2003] supports access control in open systems where subjects present credentials to demonstrate properties about themselves, similar to our work in trust negotiation. Our work is distinct in its support for content-triggered trust negotiation by the client, as the Semantic Web languages focus on access control at the web server. None of these languages appear to support sensitive credentials. The TrustBuilder implementation has addressed security issues that are important to integrating dynamic access control in existing security protocols. The design issues addressed in this article may be influential to the future development of Semantic Web technology. There are identity management efforts underway to better handle users’ sensitive personal information, such as the Liberty Alliance [http://www. projectliberty.org]. One focus of that project is to provide single sign-on across a federation of trusted web sites and securely manage personal information. This is an example of a closed system, whereas our focus for content-triggered trust negotiation is aimed at first-time interactions between strangers. The approach presented in this article may be suitable for the initial trust establishment process between a user and a Liberty-enabled web site or to automatically manage introductions between affinity group members under the Liberty Alliance. Trust negotiation is aimed at handling introductions between strangers and is not a replacement for authentication in closed systems. The Platform for Privacy Preferences (P3P) [W3C, http://www.w3.org/TR/ WD-P3P/Overview.html] is a project developed by the World Wide Web Consortium, which allows web sites to express their privacy policies for handling ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

452

•

A. Hess et al.

sensitive client information. Such policies inform the client regarding who is collecting the data, what is being collected, why it is being collected, and what will be shared with others. The privacy policies are created by the web site, and clients must trust that the policy reflects the web site’s practices. In our research, we focus on attributes that are asserted by trusted third parties. We support a more general notion of attributes, and view privacy practices as one of many attributes of potential interest to a client. Another self-regulatory privacy method uses privacy seals that are placed on web sites to give end users a sense of security. Some existing trust label companies are TRUSTe, Verisign, BBBOnline, and webtrust.org. While the privacy seals attempt to assure clients that the web site can be trusted, the weakness of this system lies in the fact that clients rarely verify the validity of the seal on the web site because it is typically time consuming and confusing for the average user. In addition, the assurance provided by the web seals may be inadequate for some clients. Some commercial firewalls exist that assist web clients in preserving their privacy by not allowing user-defined keywords to be transmitted in HTTP requests unless the communication channel is secure. However, this only guarantees confidentiality and integrity while the message is in transit and says nothing of the server’s trustworthiness. Another form of preventing unauthorized message delivery is SPAM filtering software for email. Like the proxies presented in this article, SPAM blocking software can perform header and text analysis; however, many messages are blocked using blacklists or collaborative signature-based spam-tracking databases instead of user-defined queries. SPAM filters differ from the proxies used in this article by operating on incoming messages instead of outbound content. 7. CONCLUSIONS AND FUTURE WORK In this article, we presented a general-purpose access control model for distributed systems that is designed to detect sensitive information about to be transmitted or received and determine whether the subject (sender or receiver) is authorized. We also provided motivating examples demonstrating how the model is relevant to peer-to-peer and client/server systems. The model supports the inspection of incoming and outgoing messages for sensitive information using content classification techniques appropriate to the particular type of content. An access control policy is generated to control access to the message according to the types of sensitive information the message contains. We presented a design for an instance of the model for clients to detect whether incoming and outgoing messages are sensitive. The design focused on open systems, where the client and server are strangers. This implies that the client’s access control monitor may lack credentials from the server at the moment when sensitive content is detected and must pull credentials from the server to make an access control decision. The client establishes trust in the server using trust negotiation, the exchange of digital credentials signed by ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

Content-Triggered Trust Negotiation

•

453

trusted third parties. This instance of the model is the first example of contenttriggered trust negotiation. To implement this model, we extended TrustBuilder to perform contenttriggered trust negotiation, expanding the use of trust negotiation beyond the protection of static server resources. Our implementation supports two rather different application-layer protocols, HTTP and SMTP. HTTP is a point-to-point synchronous communication protocol used to access resources on the World Wide Web. In contrast, SMTP is an asynchronous, message-routed protocol used in the delivery of email messages. The underlying differences between these protocols motivate disparate approaches to establishing trust when applying access control for dynamic client content. HTTP mediates trust negotiation within its synchronous request and response messages, while SMTP operates asynchronously through trust negotiation messages embedded in email. We also considered the privacy and efficiency advantages offered by hidden credentials in general and in particular with respect to email. We implemented support for content-triggered trust negotiation in TLS, by extending the TNT protocol to support client-initiated trust negotiation. By combining trust negotiation with an application-independent security layer, we made it possible for application software to make use of trust negotiation without having to modify application-layer protocols. The current implementation of the model is not intended to provide a foolproof mechanism for protecting disclosures a client might make; nevertheless, it does serve as additional assurance that the intended recipient is trustworthy via the guarantees of successful trust negotiation, and can prevent many types of accidental disclosure of sensitive data. The current implementation does not identify sensitive content that is encoded by an unrecognized file format, encrypted, hidden using steganographic techniques, or otherwise obfuscated at the application layer of the networking protocol stack. Attackers might also be able to cause victims’ computers to encode or obfuscate data without their knowledge. Additionally, while our implementation makes use of three accurate classification techniques, false positives and false negatives may occur. Our proposed model provides a new application area for content classification research. Further experimentation and research within that area may lead to greater assurance for clients who use our proposed model. The performance and accuracy of various classification methods can be explored, taking security requirements and threat models into consideration. The concepts presented in this article have the potential to appear in a variety of network-aware applications and appliances, such as cell phones, pagers, PDAs, email clients, web servers, web browsers, routers, corporate firewalls, personal firewalls, file servers, news clients, network printers, chat clients, financial software, and so on. In the future, we plan to investigate how the access control model for detecting sensitive content can be applied to protecting sensitive information on the Semantic Web. The classification engine could leverage the semantic information available in content on the Semantic Web to identify sensitive content. We plan to design and implement an extension to TrustBuilder supporting the Semantic Web. ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

454

•

A. Hess et al.

This article focused on classifying outbound client content and authenticating the recipient when the content is sensitive. In the future, we plan to apply the client’s content classifier to content received from the server. This will explore situations in which dynamic content from the server is questionable or when the client requires a high degree of trust in the content. For example, when the client content classifier detects that the inbound content refers to stock quotes or medical advice, the client may require assurance that the server provides trustworthy content. Even though the model appears to be well suited for this problem, analyzing dynamic server content will place greater demands on system scalability in cases where inbound content is proportionally greater than outbound, such as client HTTP traffic. The implementations of content-triggered trust negotiation described in this article all negotiate trust “in-band” between the client and server. An alternative approach that we are currently exploring is to negotiate trust “outof-band”. As an example, suppose Alice sends a sensitive email message to Bob and her access control monitor determines to initiate a trust negotiation. Instead of negotiating trust via email messages, Alice’s trust negotiation agent could contact Bob’s trust negotiation agent directly using a protocol such as TNT. Once trust is established, Alice’s email message is forwarded. This approach, known as surrogate trust negotiation, introduces security issues. For instance, Alice would need assurance that she is indeed talking to Bob’s agent. This approach has potential to reduce or eliminate the need for extensions to existing communication protocols to support content-triggered trust negotiation. We plan to continue exploring approaches to confidential trust negotiation using SMTP. Even if a negotiation is confidential, there are elements inherent in the communication protocol, such as email and IP addresses, which prevent total anonymity. Email addresses are especially revealing and can be used to derive much information about an individual. An area for future research is the use of anonymous remailers within the email prototype. Anonymous remailers have the capability of hiding the true identity of the sending party. In essence, they operate by removing any identifying headers and then forwarding the message to the recipient with an anonymous email address for the sender inserted by the remailer. Several remailers can be chained together to protect the anonymity of the sending party. The use of remailer technology could provide anonymity during the initial stages of a trust negotiation when Alice is attempting to send a sensitive email message to Bob and wants to verify some property about Bob before revealing any information about herself, such as her IP or email address. Remailers could also be used for a completely anonymous trust negotiation in email if anonymous credentials are used throughout the negotiation. ACKNOWLEDGMENTS

The authors thank Marianne Winslett for her helpful discussions on contenttriggered trust negotiation and her feedback on this article. The authors also thank Arnie Rosenthal for his feedback on an earlier version of this article. ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

Content-Triggered Trust Negotiation

•

455

Finally, thanks to Thomas Chan, Jim Henshaw, Michael Klingler, Travis Leithead, and Bryan Smith for their help in preparing this article. REFERENCES BERTINO, E., CASTANO, S., AND FERRARI, E. 2001. On specifying security policies for web documents with an XML-based language. In Proceedings of the Sixth ACM Symposium on Access Control Models and Technologies. ACM Press, Chantilly, VA, 57–65. BONATTI, P. AND SAMARATI, P. 2000. Regulating service access and information release on the web. In Proceedings of the 7th ACM Conference on Computer and Communications Security (CCS-7). ACM Press, 134–143. BONEH, D. AND FRANKLIN, M. 2001. Identity-based encryption from the Weil pairing. In Proceedings of Crypto 2001. Lecture Notes in Computer Science, vol. 2139. Springer, Berlin 213–229. CHADWICK, D. AND OTENKO, A. 2002. The permis X.509 role based privilege management infrastructure. In Seventh ACM Symposium on Access Control Models and Technologies, Monterey, California. DIERKS, T. AND ALLEN, C. 1999. The TLS protocol, version 1.0. Available at http://www.ietf.org/ rfc/rfc2246.txt. FIELDING, R., GETTYS, J., MOGUL, J., FRYSTYK, H., MASINTER, L., LEACH, P., AND BERNERS-LEE, T. 1999. Hypertext transfer protocol—HTTP/1.1. RFC 2616. HERZBERG, A., MASS, Y., MIHAELI, J., NAOR, D., AND RAVID, Y. 2000. Access control meets public key infrastructure, or assigning roles to strangers. In Proceedings of the 2000 IEEE Symposium on Security and Privacy. IEEE Computer Society Press, 2–14. HESS, A. 2003. Content-Triggered Trust Negotiation. M.S. thesis, Computer Science Department, Brigham Young University. HESS, A., JACOBSON, J., MILLS, H., WAMSLEY, R., SEAMONS, K. E., AND SMITH, B. 2002. Advanced client/server authentication in TLS. In Network and Distributed System Security Symposium, San Diego, CA. 203–214. HOLT, J., BRADSHAW, R., SEAMONS, K. E., AND ORMAN, H. 2003. Hidden credentials. In 2nd ACM Workshop on Privacy in the Electronic Society. ACM Press, Washington, D.C., 1–8. INTERNATIONAL TELECOMMUNICATION UNION 1997. Rec. X.509—Information Technology—Open Systems Interconnection—The Directory: Authentication Framework. International Telecommunication Union. JACOBSON, J. 2003. Trust Negotiation in Session-Layer Protocols. M.S. thesis, Computer Science Department, Brigham Young University. KAGAL, L., FININ, T., AND JOHSHI, A. 2003. A policy language for pervasive computing environment. In 4th International Workshop on Policies for Distributed Systems and Networks, Lake Como, Italy. 63–76. KAGAL, L., FININ, T., AND JOSHI, A. 2003. A policy based approach to security to the semantic web. In 2nd International Semantic Web Conference, Sanibel Island, FL. LI, N., MITCHELL, J. C., AND WINSBOROUGH, W. H. 2002. Design of a role-based trust management framework. In Proceedings of the 2002 IEEE Symposium on Security and Privacy. IEEE Computer Society Press, 114–130. Liberty Alliance Project. Available at http://www.projectliberty.org 2002. http://www.projectliberty. org. OGAWA, Y., MORITA, T., AND KOBAYASHI, K. 1991. A fuzzy document retrieval system using the keyword connection matrix and its learning method. Fuzzy Sets Syst 38, 17–41. POSTEL, J. 1982. Simple Mail Transfer Protocol. RFC 821. RESCORLA, E. 2001. SSL and TLS: Designing and Building Secure Systems. Addison-Wesley. SALTON, G. AND LESK, M. 1968. Computer evaluation of indexing and text processing. J. ACM 15, 1, 8–36. SANDHU, R. S., COYNE, E. J., FEINSTEIN, H. L., AND YOUMAN, C. E. 1996. Role-based access control models. IEEE Comput 29, 2 (Feb.), 38–47. SEAMONS, K. E., WINSLETT, M., AND YU, T. 2001. Limiting the disclosure of access control policies during automated trust negotiation. In Network and Distributed System Security Symposium, San Diego, CA. 109–124. ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.

456

•

A. Hess et al.

SEAMONS, K. E., WINSLETT, M., YU, T., SMITH, B., CHILD, E., JACOBSEN, J., MILLS, H., AND YU, L. 2002. Requirements for policy languages for trust negotiation. In Proceedings of the Third International Workshop on Policies for Distributed Systems and Networks (Policy 2002). IEEE Computer Society Press, 68–79. SEAMONS, K. E., WINSLETT, M., YU, T., YU, L., AND JARVIS, R. 2002. Protecting privacy during online trust negotiation. In 2nd Workshop on Privacy Enhancing Technologies. Springer-Verlag, San Francisco, CA, 129–143. SHIN, D., AHN, G., AND CHO, S. 2002. Role-based EAM using X509 attribute certificate. In 16th Annual IFIP WG 11.3 Working Conference on Data and Application Security, University of Cambridge, United Kingdom. TONTI, G., BRADSHAW, J. M., JEFFERS, R., MONTANARI, R., SURI, N., AND USZOK, A. 2003. Semantic web languages for policy representation and reasoning: A comparison of Kaos, Rei, and Ponder. In 2nd International Semantic Web Conference, Sanibel Island, FL. USZOK, A., BRADSHAW, J., JEFFERS, R., SURI, N., HAYES, P., BREEDY, M., BUNCH, L., JOHNSON, M., KULKARNI, S., AND LOTT, J. 2003. Kaos policy and domain services: Toward a description-logic approach to policy representation, deconfliction, and enforcement. In 4th International Workshop on Policies for Distributed Systems and Networks, Lake Como, Italy, 93–98. W3C, http://www.w3.org/TR/WD-P3P/Overview.html. Platform for Privacy Preferences (P3P) Specification. W3C, http://www.w3.org/TR/WD-P3P/Overview.html. WINSBOROUGH, W. H. AND LI, N. 2002. Towards practical automated trust negotiation. In Proceedings of the Third International Workshop on Policies for Distributed Systems and Networks (Policy 2002). IEEE Computer Society Press, Monterey, CA, 92–103. WINSBOROUGH, W. H., SEAMONS, K. E., AND JONES, V. E. 2000. Automated trust negotiation. In DARPA Information Survivability Conference and Exposition, Vol. I. IEEE Press, Hilton Head, SC, 88–102. WINSLETT, M., YU, T., SEAMONS, K. E., HESS, A., JACOBSON, J., JARVIS, R., SMITH, B., AND YU, L. 2002. Negotiating trust on the web. IEEE Internet Comput. 6, 6 (Nov./Dec.), 30–37. YU, T., WINSLETT, M., AND SEAMONS, K. E. 2003. Supporting structured credentials and sensitive policies through interoperable strategies in automated trust negotiation. ACM Trans. Inf. Syst. Secur. 6, 1 (Feb.), 1–42. Received November 2003; revised April 2004 and May 2004; accepted May 2004

ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004.