that the other needs to satisfy, trust is established gradually through bilateral ..... 3 presents PRUNES, a complete and efficient negotiation strategy, and helps the .... The following online transaction example shows what a trust negotiation ...... This is one reason why no two different strategies from the early literature on ...
AUTOMATED TRUST ESTABLISHMENT IN OPEN SYSTEMS
BY
TING YU B.S., Peking University, 1997 M.S., University of Minnesota, 1998
THESIS Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Science in the Graduate College of the University of Illinois at Urbana-Champaign, 2003
Urbana, Illinois
c Copyright by Ting Yu, 2003
AUTOMATED TRUST ESTABLISHMENT IN OPEN SYSTEMS Ting Yu, Ph.D. Department of Computer Science University of Illinois at Urbana-Champaign, 2003 Marianne Winslett, Advisor Global competitive pressures and the possibility of severe security breaches are forcing organizations and individuals to develop the ability to rapidly form relationships and cooperate to solve urgent problems. Such cooperation often involves unanticipated resource sharing across organizational boundaries. As disparate groups attempt to collaborate to conduct sensitive processes and respond to problems, their efforts to provide efficient response are hindered by traditional approaches to access control. Organizations and individuals require nimble security facilities that will enable them to rapidly and efficiently access each other’s resources, while offering specific privacy guarantees. Automated trust negotiation (ATN) is a new approach to access control in open, flexible systems. ATN enables open computing by assigning an access control policy to each resource that is to be made accessible to “outsiders”. An access control policy describes the properties of the parties allowed to access that resource, in contrast to the traditional approach of listing their identities. Party’s properties are demonstrated through the use of digital credentials, which often contain sensitive information about their owners. Thus their disclosure is also protected by access control policies. Since each negotiating party may have policies that the other needs to satisfy, trust is established gradually through bilateral disclosures of credentials. The successful deployment of ATN requires resolution of many challenging issues. This thesis focuses on two key problems of ATN: negotiation strategies and sensitive information protection. Different parties might have different requirements for how much computation they are willing to do, how freely they disclose resources, and other strategic decisions. For such decisions, each party relies on its negotiation strategies. We identify necessary and sufficient conditions to guarantee interoperability between different strategies, and present a large set of mutually interoperable strategies, which provides users with maximal flexibility in choosing strategies, while still guaranteeing that a negotiation will succeed if at all possible. Without proper protection, an access control policy itself might reveal sensitive information unintentionally. To remedy this problem, we propose a unified scheme for resource protection in ATN. This scheme treats policies as first-class resources, which can themselves be protected by policies. This provides great flexibility in expressing fine-grained access control requirements for trust negotiation. iii
To Xiaosong, and my parents.
iv
Acknowledgments First and foremost, I am deeply indebted to my faculty advisor, Marianne Winslett, for encouraging me and giving me tremendous guidance during my research. Without her mentoring, this thesis would never have been realized. Thank you for being patient in correcting my awkward writing and improving my presentation skills, thank you for giving me advice not only on research but also on how to succeed in academia, and thank you for your kind help during important decisions of my life. I greatly appreciate Prof. Kent E. Seamons for his support and collaboration during my Ph.D study. Thank you for all the interesting discussions on challenging research problems. I would like to thank my committee, Profs. Roy Campbell, Jiawei Han, José Meseguer and Dennis Mickunas for their insightful comments and suggestions on my research. I am grateful to Prof. Ding-Zhu Du, my Master’s project advisor during my studies at the University of Minnesota, for his help and encouragement. I would like to thank my former advisor Prof. H.V. Jagadish for introducing me to database research. My summer intern experience at AT&T Labs-Research was also rewarding and fruitful. I wish to express my gratitude to Dr. Divesh Srivastava, Dr. Nick Koudas and Dr. Michael Rabinovich for collaborating on interesting problems and broadening my knowledge of database technology. My research progress would not have been as smooth without valuable discussions with Jonghyun Lee, Shengke Yu and Arash Termehchy. I thank them for their feedback on my research and my presentations. I feel grateful to the faculty members in the database and information systems group, Profs. Jiawei Han, Kevin Chang, AnHai Doan and Chengxiang Zhai, for valuable suggestions for my job interview preparation. I am eternally grateful to my parents, Lihong Yu and Wenying Zhi, and my brother, Lei Yu, for their endless caring and support. Last but not the least, I thank you, my dear wife, Xiaosong Ma, for bringing so much fun to my life and for sharing my joys and sorrows. Your love and support have been and will always be my most precious possession.
v
Table of Contents List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Chapter 1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 2 Automated Trust Negotiation . . . . . . . . 2.1 An Introduction to Automated Trust Negotiation 2.2 Research Issues in Automated Trust Negotiation 2.3 Access Control Policies . . . . . . . . . . . . . 2.4 Assumptions . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
1
. 9 . 9 . 12 . 15 . 17
Chapter 3 A Complete and Efficient Trust Negotiation Strategy . . . . . . . . . . . . . . . . . . . . 20 3.1 A Brute-Force Backtracking Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2 The PRUNES Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Chapter 4 Interoperable Strategies . . . . . . . . . . . . 4.1 The TrustBuilder Protocol and Strategy Families 4.2 Characterizing Safe Disclosure Sequences . . . . 4.3 The Disclosure Tree Strategy Family . . . . . . . 4.4 Strategy Caution and Interoperability . . . . . . . 4.4.1 Disclosure Tree Coverage . . . . . . . . 4.4.2 A Non-monotonic Strategy Family . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
32 32 36 42 48 48 51
Chapter 5 Sensitive Policies and Credentials with Internal Structure . . . . . . . . . 5.1 The TrustBuilder Protocol 2 for Sensitive Policies and Structured Credentials 5.2 Binding Trees and the Binding Tree Strategy Family . . . . . . . . . . . . . 5.2.1 Binding Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.2 The Binding Tree Strategy . . . . . . . . . . . . . . . . . . . . . . . 5.3 Example Trust Negotiation with Structured Credentials and Policy Graphs . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
58 64 66 66 71 80
Chapter 6 A Unified Scheme for Resource Protection in Trust Negotiation 6.1 Sensitive Policies and Their Protection . . . . . . . . . . . . . . . 6.2 Related Work on Sensitive Policy Protection . . . . . . . . . . . . 6.2.1 Service Accessibility Rules . . . . . . . . . . . . . . . . . 6.2.2 Policy Graphs . . . . . . . . . . . . . . . . . . . . . . . . 6.3 A Unified Scheme for Resource Protection . . . . . . . . . . . . . 6.4 Strategy Interoperability under UniPro . . . . . . . . . . . . . . . 6.4.1 The UniPro Trust Negotiation Protocol . . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
85 86 88 88 90 91 97 98
vi
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . . .
. . . . . . .
. . . . . . . .
. . . . . . .
. . . . . . . .
. . . . . . .
. . . . . . . .
. . . . . . .
. . . . . . . .
. . . . . . . .
6.4.2 6.4.3 6.4.4 6.4.5 Chapter 7
Weak Strategy Interoperability . . . . . . . . . . . UniPro Trees . . . . . . . . . . . . . . . . . . . . The UniPro Tree Strategy . . . . . . . . . . . . . Cached Policies and Policy Definition Disclosures
Attacks on Trust Negotiation
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
101 105 112 118
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Chapter 8 Privacy Preservation in Trust Negotiation . . . . . . . . . . . . . . . . . . 8.1 Privacy Vulnerability in Trust Negotiation . . . . . . . . . . . . . . . . . . . 8.2 Attribute-Sensitive Credential Protection . . . . . . . . . . . . . . . . . . . . 8.3 Possession-Sensitive and Non-Possession Sensitive Credential Protection . . 8.3.1 The TrustBuilder-Relevant Strategy and the Disclosure Tree Strategy 8.3.2 Protection of Possession-Sensitive Credentials . . . . . . . . . . . . 8.3.3 Protection of Non-Possession Sensitive Credentials . . . . . . . . . . 8.3.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
128 129 132 135 137 138 144 146
Chapter 9 Related Work . . . . . . . . . . . . . . . . . . . . . . . 9.1 Access Control Basics . . . . . . . . . . . . . . . . . . . 9.1.1 Access Control Policies . . . . . . . . . . . . . . 9.1.2 Access Control Mechanisms . . . . . . . . . . . . 9.2 Public Key Infrastructure . . . . . . . . . . . . . . . . . . 9.2.1 X.509 . . . . . . . . . . . . . . . . . . . . . . . . 9.2.2 PGP . . . . . . . . . . . . . . . . . . . . . . . . . 9.2.3 Anonymous Credential Systems . . . . . . . . . . 9.3 Trust Management in Decentralized Environments . . . . . 9.3.1 The Trust Establishment Project . . . . . . . . . . 9.3.2 KeyNote . . . . . . . . . . . . . . . . . . . . . . 9.3.3 SD3 . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.4 Service Accessibility Framework . . . . . . . . . 9.3.5 RT : A Role-based Trust-management Framework 9.3.6 The TrustBuilder Project . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
150 150 150 153 154 155 156 158 160 160 162 162 163 163 164
Chapter 10 Conclusions . . . . . . . . . . . . . 10.1 Summary . . . . . . . . . . . . . . . . 10.1.1 Trust Negotiation Strategies . . 10.1.2 Sensitive Information Protection 10.2 Future Work . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
165 166 166 169 173
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Vita . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
vii
List of Figures 2.1 2.2
An architecture for automated trust negotiation . . . . . . . . . . . . . . . . . . . . . . . . 10 Two examples of access policies and a safe credential disclosure sequence . . . . . . . . . . 16
3.1 3.2 3.3
The negotiation search tree for the access control policies given in figure 2.2 . . . . . . . . 23 The pseudo code for three key functions of PRUNES . . . . . . . . . . . . . . . . . . . . . 28 The message sequence using PRUNES and the final dependency graph . . . . . . . . . . . 29
4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9
Pseudocode for TrustBuilder Protocol 1 . . . . . . . . . . . . . . . . . . . . . . . . . Example disclosure trees for a set of policies . . . . . . . . . . . . . . . . . . . . . . . Examples of operations on disclosure trees . . . . . . . . . . . . . . . . . . . . . . . . trees(S) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pseudocode for the TrustBuilder1-Simple strategy . . . . . . . . . . . . . . . . . . . . Pseudocode for the TrustBuilder1-Relevant strategy . . . . . . . . . . . . . . . . . . . Example showing the insufficiency of guaranteeing at least one evolvable tree for others Pseudocode for the NonMono strategy . . . . . . . . . . . . . . . . . . . . . . . . . . An example to show that the NonMono family is not monotonic . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
34 37 39 42 46 47 49 53 56
5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8
An example of policy graphs . . . . . . . . . . . . . . Example policy graph . . . . . . . . . . . . . . . . . . Examples of operations on binding trees . . . . . . . . The set of binding trees corresponding to S . . . . . . Pseudocode for the TrustBuilder2-Simple strategy . . . Pseudocode for the TrustBuilder2-Relevant strategy . . Policy graphs for credentials of the client and the server Binding trees for each step in the example negotiation .
. . . . . . . .
. . . . . . . .
. . . . . . . .
59 60 68 72 78 79 82 83
6.1 6.2
Example UniPro trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Example of UniPro tree expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
8.1
Policy transformation when the age attribute in Alice’s driver’s license is sensitive . . . . . . 133
9.1
An example access matrix for an operating system . . . . . . . . . . . . . . . . . . . . . . . 153
viii
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
Chapter 1
Introduction To trust an entity means to have firm confidence in the integrity and ability of that entity to perform according to one’s expectations [66]. Trust relationships between entities are particularly important when one entity’s action or service may have a great impact on the interests of others. In this thesis, we study how to establish such trust relationships between entities. In particular, we are interested in the establishment of trust relationships between service providers and service requesters in open distributed computing environments. In traditional distributed environments, service providers and requesters are usually known to each other. Often shared information in the environment tells which parties can provide what kind of services and which parties are entitled to make use of those services. Thus, trust between parties is a straightforward matter. Even if on some occasions there is a trust issue, like in traditional client-server systems, the trust establishment is usually uni-directional in the sense that the server is a well-known service provider. Before requesting any service, the client must prove it is qualified to receive that service. In this case, trust establishment is often handled by uni-directional access control methods. For example, often the client must log in as a pre-registered user. In an open computing environment, however, the goal is to allow (qualified) strangers to access the resources available in the environment. Since these outsiders are unknown to the service providers in the open environment and vice versa, there is no easy way to tell which outsiders are qualified to gain access to services or which service providers are trustworthy. Instead, a more complex approach to establishing trust is needed. As we are moving to a globally internetworked infrastructure, global competitive pressures and the possibility of severe security breaches are forcing organizations and individuals to develop the ability to
1
form relationships and cooperate to solve urgent problems. Such cooperations often involve unanticipated resource sharing across organizational boundaries. Meanwhile, people are demanding more cost effective government services, heath care services, educations, and customer service to replace traditional face-toface contact or paper-based interactions; these trends have greatly encouraged online service offerings. All these new open computing environments have imposed new requirements on trust establishment and access control. For example: Joint military activity. Dynamic information sharing is critical for accurate and timely decision making in coalitions of military and peacekeeping forces from multiple nations. Policies for such information sharing are complex and prone to change. Besides the need for coordination, each nation also requires autonomy in determining with whom and under what circumstances their information can be shared among coalition members. Access control based on individuals’ identities will result in a prohibitive management overhead. A more scalable and flexible approach is to base access control decisions on a party’s provable properties. Supply chain management. An automobile parts supplier needs to access the corporate database of an automobile maker to determine the production of widgets for the next quarter. In order to access the database, a requester has to satisfy the following two conditions. 1. The requester needs to prove that she is working for the widget supplier. This can be proved by showing her employee ID issued by the widget supplier. 2. Further, not everybody working for the widget supplier can access the database. The requester needs to show that she does have the privilege to plan the production of widgets. This can be proven by showing a valid delegation of authority from the production planning department of the widget supplier. Online services. A parent wants to register her child for the local public kindergarten. In order to be qualified for the registration, the following conditions must be satisfied. 1. The requester needs to prove that the child will be age 5 or greater on September 1, 2003. This can be done by showing the child’s birth certificate.
2
2. The requester has to be a parent or a legal guardian of the child. This can be proved by showing the child’s birth certificate or a valid court order. 3. The requester should be living in the school district of the kindergarten. This can be proven by showing the requester’s driver’s license. 4. Finally, the child should have had all the required immunizations. This can be proven by showing valid clinic records. Currently on the Internet, the prevailing authorization approach is still the traditional identity-based access control method, where clients are required to pre-register with a server, in order to obtain a local login, capability, or identity certificate before requesting that service. There are several disadvantages of this approach. 1. Such practices are usually offered in a "take-it-or-leave-it" fashion, i.e., the clients either unconditionally disclose their information to the server in the pre-registration phase, or do not get the service at all. There is little chance for the clients to apply their own access control policies for their information, and decide accordingly whether the server is trustworthy enough so that sensitive information can be disclosed. 2. When the clients fill out the online registration form, it is very hard for the server to verify whether the provided information is valid. More generally, the problem of a large amount of dirty data in commercial databases is becoming a major factor that lowers the effectiveness of commercial information analysis. 3. Often, much of the information required in online registration forms does not seem directly related to the service that clients request to access. However, since the clients have to unconditionally provide the information, there is no way that they can discuss their misgivings with the server. A particularly important example of the latter shortcoming is that the traditional access control methods usually require the customer to reveal her exact identity, which, in many cases, is irrelevant to the service the customer requests. For example, suppose an on-line digital library contains books, journals and conference proceedings that can be divided into three categories: generally accessible, accessible to ACM members only and accessible to IEEE members only. When a user wants to read a paper in ACM Transactions on 3
Information and System Security, it suffices to prove that she is actually a member of ACM. Other personal information like phone numbers and a home address do not need to be revealed. In some situations, revealing personal identification is highly undesirable. For example, a user may query an on-line medical database about a certain disease. If the identity of the user is revealed, it is very reasonable to assume that the user herself or some relative of the user may have that disease, which may be highly sensitive information. Property-based digital credentials [8] (or simply credentials) make it feasible to manage trust establishment efficiently and bi-directionally on the Internet. Digital credentials are the on-line counterparts of paper credentials that people use in their daily life, such as a driver’s license. By showing appropriate credentials to each other, a service requester and provider can both prove their qualifications. In detail, a credential is a digitally signed assertion by the credential issuer about the properties of one or more entities [ 8, 90]. Using modern encryption technology, the issuer signs a credential, which describes one or more attributes and/or relationships of the entities, using its own private key. The public key of the issuer can be used to verify that the credential was actually issued by the issuer. The signed credential can also include the public keys of the entities referred to in the credential. This allows an entity to use her private key to authenticate herself as one of the entities referred to in the credential [75]. So digitally signed credentials can be verifiable and unforgeable. In practice, digital credentials can be implemented as X.509 [47] certificates, private credentials [19], or signed XML statements. When credentials do not bear sensitive information, the trust establishment procedure is very simple. For example, in the on-line library mentioned above, the user (or a software agent acting on behalf of the user, such as a browser) first checks the library’s policy, which is always available. Then she presents her ACM membership credential along with the retrieval request. However, in many situations, especially in the context of e-business, credentials themselves carry some sensitive information. Effective crisis response Consider the scenario where Los Angeles is under a Red Alert after an earthquake. As part of disaster planning, law enforcement agencies in the LA area have reached an agreement with local telephone companies to allow access to their communication network in the event of a Red Alert. Once the alert is declared, the district attorney can use her digital employee ID and a digital authorization from the LA government to control communication traffic so that voice communication from crisis command center is guaranteed to go through. However, before the district attorney discloses the digital authorization, she requires a telephone company to prove it is a party 4
to the agreement, because the digital authorization contains confidential information regarding the compensation that the telephone company will receive when they cooperate in response to this kind of crisis. Privacy preservation in e-commerce Suppose that a landscape designer wishes to order plants from Champaign Prairie Nursery (CPN). She fills out an order form on the web, checking an order form box to indicate that she wishes to be exempt from sales tax. Upon receipt of the order, CPN will want to see a valid credit card or her account credential issued by CPN, and a current reseller’s license. The designer has no account with CPN, but she does have a digital credit card. She is willing to show her reseller’s license to anyone, but she will only show her credit card to members of the Better Business Bureau. To deal with such scenarios, a more complex procedure needs to be adopted to establish trust through negotiation. In our approach to automated trust establishment, trust is established gradually by disclosing credentials and requests for credentials, an iterative process known as trust negotiation. It differs from traditional identity-based access control systems mainly in the following aspects: 1. Trust between two strangers is established based on parties’ properties, which are proven through disclosure of digital credentials. 2. Every party can define access control policies to control outsiders’ access to their sensitive resources. These resources can include services accessible over the Internet, roles in role-based access control systems, credentials, policies, and capabilities in capability-based systems. 3. In the approaches to trust negotiation developed so far, two parties establish trust directly without involving trusted third parties, other than credential issuers. Since both parties have access control policies, trust negotiation can employ a peer-to-peer architecture, where a client and server are treated equally. Instead of a one-shot authorization and authentication, trust is established incrementally through a sequence of bilateral credential disclosures. Less sensitive credentials are disclosed first. Later on, when a certain level of trust has been established, more sensitive credentials can be disclosed.
5
The practical deployment of automated trust negotiation raises many challenging issues. This thesis is centered around two key problems of trust negotiation. Negotiation Strategies Different parties might have different requirements for how much computation they are willing to do, how freely they disclose resources, how interested they are in extracting information from the other party during negotiation, and other strategic decisions. For such decisions, each party relies on its trust negotiation strategy, an algorithm that determines what information to disclose to others and when to do so. Because the Internet is a free-wheeling place with decentralized control, all parties should be free to choose whatever strategies meet their needs. On the other hand, it is desirable for two parties always to be able to establish trust whenever it is allowed by their access control policies. These two requirements conflict with each other. How to nicely balance the requirements from the two conflicting aspects is a challenging problem. Resource Protection In contrast to traditional trust management systems, trust negotiation typically involves multiple rounds of credential and policy disclosures. Therefore, information may flow between two parties in a variety of forms. The basic model of trust negotiation uses access control policies to govern the disclosure of sensitive credentials. This model implicitly makes the assumption that sensitive information can flow to others only when credentials are disclosed. Such an assumption does not always hold in practice. Without proper protection, a policy disclosure itself might reveal sensitive information unintentionally. The major contributions of this thesis include: • We propose a model of trust negotiation that gives entities autonomy in choosing whatever strategies meet their requirements. Then we identify necessary and sufficient conditions for a successful negotiation when two parties adopt different strategies. We design a set of strategies and prove that two parties can always establish trust whenever their access control policies allow, if they are using any two strategies from the set. We also show that the set of strategies provides users maximal flexibility in choosing strategies that fit their requirements for trust negotiation. • We identify desiderata for protecting sensitive information in access control policies during trust negotiation. Then we propose a unified scheme for protecting all kinds of resources using access control 6
policies. This scheme treats policies as first-class resources so that they can receive the same level of protection as any other resource. This approach provides more expressive power and flexibility in expressing fine-grained access control requirements and policy composition for trust negotiation. We also study the impact of this scheme on strategies and show that strategy interoperability can still be guaranteed under this scheme. • Compared to traditional access control approaches, trust negotiation provides more channels for information flow. In this thesis, we investigate two types of sensitive information, namely sensitive attributes and possession-sensitive credentials, which are not effectively protected in the basic model of trust negotiation. We propose policy filtering and policy migration as two techniques to alleviate the problem of information leaks through inferences during trust negotiation. The work reported in this thesis falls within the broad scope of the TrustBuilder project, which is exploring the concept of ubiquitous trust negotiation. The TrustBuilder project includes both theoretical and practical components. On the theory side, our goal is to establish a sound theoretical underpinning for the practical side’s testbed prototypes, which test scalability and reusability of trust negotiation middleware in different contexts. In this type of work, we have found that the theory must precede and guide the implementation. Thus some of the results reported in this thesis have already been implemented in one of the TrustBuilder prototypes described in chapter 9, and some have not. The rest of the thesis is organized as follows. In chapter 2 we present in detail the key concepts and components of trust negotiation. Major assumptions of this thesis are also described in this chapter. Chapter 3 presents PRUNES, a complete and efficient negotiation strategy, and helps the reader to get familiar with the concept of strategies. In chapter 4, we give a formal definition of negotiation strategies and propose the concept of strategy families. Then we discuss how to guarantee that two parties can always establish trust whenever possible, even when they are using different strategies. Chapter 5 extends our discussion on strategies to support credentials with internal structure, which are important for real-world trust establishment. Access control policies play an important role in automated trust negotiation. In chapter 6, we discuss in detail the problem of sensitive policies and identify the desiderata for sensitive policy protection. Then we present UniPro, which is a unified scheme for protecting resources during automated trust negotiation. Chapter 8 discusses privacy preservation and attacks against trust negotiation. Related work is presented in 7
chapter 9. Chapter 10 concludes the thesis and shows directions for possible future work. Before we move to the next chapter, we would like to acknowledge the places where our publications appeared. The work on efficient and complete strategies appeared as [92]. The work on strategy interoperability in chapter 4 and 5 appeared as [95] and [96]. Part of the material in chapter 6 appeared as [93]. Part of the material in chapter 8 appeared as [94].
8
Chapter 2
Automated Trust Negotiation 2.1 An Introduction to Automated Trust Negotiation Figure 2.1 shows the general architecture for trust negotiation. Each participant in the negotiation adopts a security agent that interacts with the other party’s security agent and manages the negotiation. For simplicity, we use the term service to refer to a resource that a stranger may try to access, such as services accessed through URLs, roles in role-based access control systems, and capabilities in capability-based systems. The security agent mediates access to local protected resources, i.e., services, policies, and credentials — the three kinds of resources that may be open to access by strangers in our work. We say a credential or access control policy is disclosed if it has been sent to the other party in the negotiation, and that a service is disclosed if the other party is given access to it. Disclosure of each resource is governed by an access control policy, which specifies what properties the other party must possess if the resource is to be disclosed. Since in automated trust negotiation, one’s properties are demonstrated through the disclosure of digital credentials, an access control policy actually specifies what credentials the other party should disclose to gain access to the resource protected by the policy. This is how attribute-based access control is supported in our approach to automated trust negotiation. In the simplest case, credentials do not contain sensitive information, i.e, they can be shown to anybody whenever requested, and only the service itself needs to be protected from unauthorized access. The service requester will be willing to provide any credentials requested by the provider in order to get the service. In this case, the trust negotiation can be finished in a single round. When credentials contain sensitive information and need to be protected from unauthorized access, a
9
Alice’s Security Agent
Bob’s Security Agent
Access control policies
Access control policies
Protected Resources
Protected Resources
services credentials policies
services credentials policies
Negotiation Strategies
Negotiation Strategies
Negotiation Protocols
Negotiation Protocols
Disclosures
Figure 2.1: An architecture for automated trust negotiation single-round trust negotiation is no longer sufficient. Before a party is willing to disclose a credential, a certain level of trust must already be established. For example, a user filing an on-line application for an apartment may be asked for her digital social security card for trust establishment and a future credit check. She may reply that her digital social security card can be shown only if the other party has credentials to prove that it is authorized to accept such a card and that it adheres to guidelines for securing social security numbers. Therefore, the trust negotiation will require multiple rounds. More generally, the trust between two parties often will need to be built step by step by exchanging credentials before the client can get the service. Different parties might have different requirements for how much computation they are willing to do, how freely they disclose resources, how interested they are in extracting information from the other party in the negotiation, and other such strategic decisions. For such decisions, each party relies on its trust negotiation strategies. During a trust negotiation, once enough trust has been established that a particular credential can be disclosed to the other party, a local strategy determines whether the credential is relevant to the current stage of the negotiation and whether it should be sent to the other party. In other words, a negotiation strategy controls the exact content of the messages that a party sends to others, i.e., which 10
credentials to disclose, when to disclose them, and when to terminate a negotiation. Another important concept in the architecture of trust negotiation is trust negotiation protocols. A trust negotiation protocol defines the ordering of messages and the type of information that messages will contain. Before a trust negotiation starts, two parties should agree on the negotiation protocol that will be used. Otherwise, they will not be able to understand each other. Note the difference between a trust negotiation protocol and a communication protocol. A trust negotiation protocol is independent of the choice of communication protocol, such as HTTP, SSL/TLS [38, 33], IP, SOAP [17], etc. However, a strategy written for one negotiation protocol may not work with another negotiation protocol, as will become clear when we discuss strategies and negotiation protocols in later chapters. The architecture in figure 2.1 supports multiple protocols for establishing trust, and assumes there will be a variety of negotiation strategies that must be supported. Note that we adopt a peer-to-peer architecture for trust negotiation, i.e., we assume there is no third party which knows both parties’ access control policies. We will come back to this assumption later in this chapter. Although all our trust negotiation algorithms are peer-to-peer, for simplicity we will use the term server to refer to the owner of a service, and client to refer to a party that tries to access the service. The following online transaction example shows what a trust negotiation process may look like. Suppose Alice is a graduate student who wants to buy textbooks at the beginning of a semester. She surfs the web and finds a good deal from Bob, who is the owner of a small online book store. Bob offers a special discount to graduate students whose GPA is over 3.0. The negotiation process may look as follows. 1. Alice requests the special discount for this transaction. 2. Bob replies with the policy for the discount, requesting Alice to show 1) her student ID to prove that she is a graduate student; and 2) her official transcript to prove her that GPA is over 3.0. 3. Alice does not mind showing her student ID to others. But her official transcript contains some quite sensitive information. Besides disclosing her student ID, she also tells Bob that in order to see her official transcript, Bob must prove that his online book store belongs to the Better Business Bureau. 4. Fortunately, Bob does have a Better Business Bureau membership card. And he is willing to tell anybody about this fact. So he discloses his BBB membership card to Alice.
11
5. At this point, Alice knows that she can trust Bob and discloses her official transcript to Bob. 6. Now Bob has received both Alice’s student ID and her official transcript. After verifying she is a graduate student and her GPA is over 3.0, Bob gives Alice the special discount for this transaction. In the above example, we see that during each step each party may have multiple choices regarding what should be sent to the other party. That is where trust negotiation strategies play their role. For example, if Alice is more cautious about her information and adopts a “smart” strategy, she may figure out that if Bob does not belong to the Better Business Bureau, it will bring her no benefit to disclose her student ID. Therefore in step 3, she can better preserve her privacy by only disclosing the access control policy for her official transcript to Bob. Though such a decision in this example seems quite straightforward, in general, it requires careful analysis of an ongoing negotiation in order to identify the necessary disclosures for the next message. On the other hand, if Alice adopts a “dumb” strategy, which does not even bother to check whether a credential is relevant to the current negotiation, she may end up disclosing not only her student ID and official transcript, but also other credentials such as her AAA membership card or her public library card.
2.2 Research Issues in Automated Trust Negotiation We have made many simplifications in the example in the previous section to show the general idea of trust negotiation. In order to deploy automated trust negotiation over the Internet, many challenging issues need to be addressed. In our discussion of related work in chapter 9, we will describe how these issues have been addressed by other researchers. Access control policies Access control policies are a cornerstone of trust negotiation, and policy languages are an active area of research today. Expressive yet user-friendly policy languages are a must for the wide adoption of trust negotiation. Besides constraints on the attributes of credentials, a policy language should also be able to express the complex constraints of delegations across organizational boundaries. Since the Internet is a free-wheeling place, we do not expect there to be a policy language universally accepted by everybody [78].
Further, because of the great expressiveness of policy
languages, efficient policy compliance checking becomes a key issue for the performance of the whole 12
system [13]. Organizations and individuals must have faith in their resources’ policies, or they will be afraid to open their systems to access from outside. To instill confidence in policies, the person in charge of the security of a resource will need a policy editor, access to canned, composable, and reusable policies (e.g., the definitions of a non-profit company, a full-time student at an accredited universities, a minority-owned business); and ways to analyze, understand, and test policies before they are deployed. Security managers will want tools for regression testing (comparison of policy coverage under old and new sets of policies), consistency checking, and comparison of policies against higher-level specifications (when available). Without such tools, many organizations will be unable to change their security policies for fear that alterations will create security holes that leave them vulnerable. These concerns arise in automated trust negotiation and also in the growing number of other computational realms that rely on policies [63]. Digital credentials The deployment of automated trust negotiation depends on an underlying public key infrastructure to distribute credentials to individuals and organizations. Considering the sensitive nature of many types of credentials, a secure credential distribution mechanism is a must. During trust negotiation, because of the complex nature of many trust relationships, a party may often need to contact the issuer of a credential in order to find further supporting credentials, a problem formally known as the credential chain discovery problem. Questions arise such as where to store credentials (at the issuer side or the owner side), how to securely store them and how to efficiently find those supporting credentials. Further, to better protect users’ privacy, it is desirable to support partial disclosure of a credential’s contents. For example, in order to purchase liquor products online, ideally Alice only needs to disclose the birth_date attribute in her driver’s license. As long as she can prove that she is the owner of the credential, all the other attributes, such as her name, address and social security number, are irrelevant for this transaction, thus do not need to be disclosed at all. However, it is not obvious how to disclose part of a credential while still ensuring that the credential is verifiable and unforgeable [ 19, 22, 49]. Strong protection for sensitive information During a trust negotiation, information may flow to others in a variety of forms. Some flows are explicit and are easily controlled, while some others are more 13
subtle. For example, the constraints in an access control policy may reveal sensitive information. A party’s private information may be easily inferred by observing its response to the disclosure of a certain access control policy. It is desirable to formally model such information flows in trust negotiation so that users can have better control over their private information [ 79, 86, 85]. Negotiation strategy and interoperability A negotiation strategy determines how cautious a party is when disclosing information to others. On one hand, since there is no central control over every entity on the Internet, each party should be autonomous in choosing whatever strategies meet their requirements. On the other hand, it is desirable for two parties to always be able to establish trust whenever possible, even when they are using different strategies. Sometimes the above two goals conflict with each other. For example, if Alice is very concerned about her private information and adopts a strategy that discloses very little information to Bob, then Bob may believe there is no hope to establish trust, and thus terminate the negotiation, causing a potentially successful negotiation to fail. How to find the balance between the two goals is a challenging research problem. Attacks against trust negotiation Though in our work, we assume that secure communication channels have been provided by lower-level software, there are many potential attacks against trust negotiation at the application level. For example, Alice and Bob may collude and pool their credentials to obtain a service that neither of them could obtain alone. A service provider may be an easy target for denial-of-service attacks. An attacker may pretend to provide appealing services and sell the collected information to unauthorized parties. It is crucial to investigate how to prevent or detect such attacks during trust negotiation [22, 21]. Trust negotiation system design and implementation In order to be widely deployed, a trust negotiation system should support multiple credential distribution infrastructures, policy languages and communication protocols. This requires the design of a trust negotiation system to be highly modularized and extensible. Meanwhile, scalability and robustness are especially important for online servers, which need to be able to cope with a large volume of negotiation activities [44, 89].
14
2.3 Access Control Policies We assume that the information contained in access control policies and credentials can be expressed as finite sets of statements in a language with a formal semantics, so that two parties can agree on the interpretation of a credential or policy. XML-based or logic programming languages may be suitable languages in practice [43, 15, 4, 64, 62], subject to the limits discussed below. For convenience, we will assume that the language semantics allows us to describe the meaning of a set X of statements in the language as the set of all models that satisfy X, in the usual logic sense. We say that X satisfies a set of statements P if and only if P is true in all models of X. (This terminology allows us to talk about a set of credentials that satisfying a policy, in the usual English sense of satisfying a policy.) For purely practical reasons, we require that the language be monotonic, i.e., if a set of statements X satisfies policy P , then any superset of X will also satisfy P ; that way, once Alice has determined that the credentials disclosed by Bob satisfy the policy of a resource, Alice knows that the same policy will be satisfied for the rest of the negotiation, and does not have to be rechecked. We will first treat resources as propositional symbols — black boxes that have an externally visible key (the propositional symbol) but no other externally visible structure. This assumption will be relaxed in chapter 5, where we explore trust negotiation strategies for use with credentials that have internal structure. Each resource has exactly one access control policy, whose body is a Boolean expression involving only credentials C1 , . . . , Ck that the other party may possess, Boolean constants true and f alse, the Boolean operators ∨ and ∧, and parentheses as needed. C i is satisfied if and only if the other party has disclosed credential Ci . We assume that a security agent can distinguish between references to local and remote resources (by renaming propositional symbols as necessary). Resource C is unlocked if its access control policy is satisfied by the set of credentials disclosed by the other party. A resource is unprotected if its policy is always satisfied. An intuitive observation is that two parties cannot establish trust unless there is at least one unprotected resource at either party. The denial policy has the body f alse, which means that either the party does not possess C, or else will not disclose C under any circumstances. A party implicitly has a denial policy for each credential it does not possess. If the disclosure of a set S of credentials satisfies resource R’s policy, then we say S is a solution for R. Further, if none of S’s proper subsets is a solution for R, we say S is a minimal solution for R. The size of a policy is the number of symbol occurrences in it.
15
Landscape Designer
CPN
BBB_M ember
Landscape Designer’s Policies Credit_Card ← BBB_M ember
CPN’s Policies Credit_Card Reseller_License Order_OK ←
Reseller_License ← true
(Credit_Card ∨ CP N _Account)∧ Order_OK
Reseller_License BBB_M ember ← true
C5 Client Side Policies C 1 ← S1 ∨ S3 C3 ← true C4 ← true
R ← (C1 ∧ C6 ) ∨ (C2 ∧ C4 )
S3
C 2 ← S2 ∧ S3
Server Side Policies
C1
S1 ← (C2 ∧ C3 ) ∨ (C2 ∧ C4 ) S2 ← C 1 S3 ← C 5 ∨ C 4
S2 C2 , C4
C5 ← true R
Figure 2.2: Two examples of access policies and a safe credential disclosure sequence Given a resource R, we say a resource C is syntactically relevant to R if and only if • C appears in R’s policy, or • C appears in the policy of a resource C which is syntactically relevant to R. If C appears in one of R’s minimal solutions, then we say C is semantically relevant to R. Given sequence G = (C1 , . . . , Cn ) of disclosures of resources, if each C i is unlocked at the time it is disclosed, 1 ≤ i ≤ n, then we say G is a safe disclosure sequence. The goal of trust negotiation is to find a safe disclosure sequence G = (C 1 , . . . , Cn = R), where R is the resource to which access was originally requested. When this happens, we say that trust negotiation succeeds. If C i = Cj and 1 ≤ i < j ≤ n, then we say G is redundant. Since the language used to represent policies and credentials is monotonic, we can remove the later duplicates from a redundant safe disclosure sequence and the resulting sequence is still safe. Figure 2.2 shows a safe disclosure sequence for the landscape designer’s purchase from CPN discussed earlier, and for an abstract example. 16
2.4 Assumptions Before proceeding to the next chapter, we would like to clarify the major assumptions made in this thesis and present the rationale for these assumptions. The assumptions form our basic model for automated trust negotiation. Assumptions specific to discussions of particular topics will be presented in later chapters when appropriate. Peer-to-peer architecture As shown in figure 2.1, we assume that trust negotiation adopts a peer-to-peer architecture, where two parties interact directly and establish trust through bilateral credential disclosures. However, a peer-to-peer architecture does not mean that no trusted third parties will ever be involved in the process of trust establishment. For example, for credential verification, Alice and Bob may need to contact a public directory server to find the public keys for credential issuers. Also, the certificate authorities are another kind of third party that Alice and Bob may both trust and need to interact with. Our architecture is peer-to-peer in the sense that no trusted third party plays the role of directly determining whether two parties should trust each other or not. A peer-to-peer architecture helps to ensure the scalability of trust negotiation — whenever two parties meet, they can start building trust immediately without relying on any central servers to do the negotiating for them. An obvious alternative is to introduce a trusted third party into the architecture. For example, when Alice and Bob want to establish trust, they agree on a trusted third party Carol and ship all their credentials and policies to her. Since Carol knows both parties’ information, it is very easy for her to determine whether Alice and Bob may be able to establish trust. There are several possible ways Carol can proceed once she believes trust establishment is possible. For example, she may return a recommended credential disclosure sequence to Alice and Bob, which the two parties follow to disclose credentials to each other. This is a lightweight approach for Carol, since all the work of authentication and credential verification is still carried out by Alice and Bob. On the other hand, Carol may also interact directly with Alice and Bob to verify credential ownership, and then announce “access permitted” or “access denied” to Alice and Bob. Though this approach is heavy-weight for Carol, Alice’s and Bob’s privacy is better preserved, if they can trust Carol not to reveal what she has learned. In this thesis, we do not adopt the central-server based model, due to several reasons. First, in open systems, it is very hard for two strangers to agree on the fly on a trusted third party to which they are willing
17
to disclose all their credentials and policies. Second, if there are widely trusted authorities, like those certificate authorities proposed in X.509 [47], to negotiate trust for Alice and Bob, then considering the vast number of transactions happening over the Internet, they may easily become a bottleneck for efficient trust establishment that will make the whole system have poor scalability. Further, well-known trusted third parties will become easy targets for attacks aiming at either stealing valuable private and business information or jeopardizing normal business practices (such as through denial-of-service attacks). Third, at this point no one knows how Alice and Bob could dynamically generate their trusted authority on the fly. Another alternative is a model based on zero-knowledge proofs, where Alice can prove to Bob that she should be trusted without actually disclosing her credentials. This model is partially supported by anonymous credential systems [22, 21, 19], in the sense that simple constraints (e.g., one’s age is over 21) can shown using a zero-knowledge proof. It is not clear how efficient this technique will be when applied to prove the satisfaction of complex policies such as constraints that involve multiple interrelated credentials. On the other hand, no matter what means of proof Alice uses, the fact that she can satisfy a policy does flow to Bob. When such information is sensitive, Alice still needs to have policies to control its disclosure. Thus many of the issues related to information flow that we discuss in chapter 8 are also relevant for a zero-knowledge approach to automated trust negotiation. Public key infrastructure We assume one’s properties can be proved online through the use of digital credentials that are verifiable and unforgeable. This assumption relies on an infrastructure to support credential issuing, distribution, verification and revocation. Trust negotiation is independent of any specific choice of key infrastructure. It can work with, for example, X.509v3 [47], PGP [97], anonymous credential systems [21, 19], or any combination of the above. In particular, trust negotiation does not rely on a globally deployed credential infrastructure. Instead, trust negotiation can be applied locally inside an organization or across multiple organizations, as long as those organizations have their own credential infrastructures and credentials issued by one organization are recognized by other organizations. The ability to work with locally deployed credential infrastructures is important because it allows trust negotiation to be adopted in a grass-roots manner. Digital credentials are already being integrated into E-commerce practices [20, 24]. Further, we have seen an increasing number of initiatives and organizations that promote the use of digital credentials by individuals and corporations, such as the Government of Canada Public Key Infrastructure [45] and the 18
recent US Postal Service In-Person Proofing (IPP) program [39]. Support from lower-level software The trust negotiation architecture relies on lower levels of software to perform the functions associated with disclosure of a credential: verification of its contents, checks for revocation as desired, checks of validity dates, authentication of ownership, etc., as is normally done for X.509 certificates. Thus, the necessary calls to these functions, and the translation of credentials into the language used to represent policies, is not covered by this thesis. We also assume that secure communication channels are provided by lower-level software, such as SSL [38], TLS [33] and HTTPS [69]. Therefore, we will not discuss issues such as how to prevent message tampering and eavesdropping in the rest of this thesis. In fact, there is increasing interest in the research and business communities in supporting attribute credentials directly in secure communication channels. Interested readers are referred to [ 37, 44]. We also assume in this thesis that lower levels of software provides supports for credential management. Thus we are not going to discuss issues such as credential discovery, public key lookup, and credential revocation.
19
Chapter 3
A Complete and Efficient Trust Negotiation Strategy To help readers get familiar with the concept of a trust negotiation strategy, in this chapter we present PRUNES, a complete and efficient strategy. In this chapter we assume that the two negotiating parties both use the same strategy. Under this assumption, Alice may be able to predict what Bob might send to her in the next message. Therefore, the negotiation protocol is tightly integrated into the strategy, to the degree that we do not define them separately from one another. Further, we assume in this chapter that policies are unprotected, so we will only consider credentials and services to be resources. If P is the body of the policy for a resource C, then we write C ← P to represent C’s policy. Winsborough et al. [88] proposed some desirable properties of negotiation strategies. A negotiation strategy should be complete. By complete we mean that the security agents of the two parties can always find a successful negotiation whenever the credentials and policies of the two parties allow one. A strategy should terminate with failure when a successful negotiation does not exist. A strategy should not disclose any credentials that are not relevant to a negotiation. Finally, a strategy should be reasonably efficient. The efficiency of a strategy includes two aspects: the communication cost and the computational cost. The communication cost includes both the total size of the messages and the total number of messages sent between the two security agents. Winsborough et al. [88] proposed two different categories of negotiation strategies: eager and parsimonious. A eager negotiation strategy allows flooding-style negotiation, where each party discloses a credential to the other party as soon as the policy of that credential is satisfied, therefore ensuring that a successful negotiation can be found in the minimum possible number of rounds. The disadvantage of such a strategy 20
is that it usually results in disclosure of irrelevant credentials. For instance, Alice’s trust negotiation for a certain service with a digital library may end up disclosing credentials not requested by the service provider, such as her driver’s license and health insurance card. At the other extreme, a parsimonious strategy will not allow credential disclosures until both parties know there exists a successful negotiation. When an incoming request for a credential is received and this credential has not been unlocked, an outgoing counter request is prepared according to the credential’s access control policy and sent out in response. Based on this principle, two parsimonious negotiation strategies are proposed in [87, 88]. The strategy in [87] is not complete and has difficulties in deciding when the negotiation should fail and stop. The strategy in [88] is complete. In this strategy, when a request E comes, the security agent combines all the possible solutions into a counter request E that will be satisfied if and only if E is satisfied, and sends E back. It is also easy to decide when the strategy should halt. However, when two parties have many credentials, as well as complex policies, after several rounds of counter requests, the size of the request may become huge. In the worst case, the size of a request can grow exponentially with the number of rounds of messages, which brings exponential communication cost.
3.1 A Brute-Force Backtracking Strategy In this section, we introduce a complete brute-force backtracking negotiation strategy. Then we introduce the concept of a negotiation search tree and use it to prove some properties of the backtracking search. For the rest of this chapter, we assume every credential C’s policy is represented in the disjunctive normal form C ← D1 ∨ · · · ∨ Dl , where Di = Si1 ∧ · · · ∧ Siki , and each Sij , for 1 ≤ i ≤ l and 1 ≤ j ≤ ki , is a credential to be disclosed by the other party. We call D i a disjunct of C. The strategy starts when Alice’s (the client’s) security agent sends a request for service S to Bob, the server. When a security agent receives a request for C, it checks C’s policy. If C is an unprotected credential (or service), the request for access to it is granted immediately, which means the security agent informs the other party that credential C can be unlocked. No credentials are actually disclosed at this stage. If the party does not possess C, the request is denied. Otherwise, the security agent tries to find solutions to the first disjunct D1 of C. Suppose D1 = S1 ∧ · · · ∧ Sk . The security agent will then examine each S i , 1 ≤ i ≤ k, starting with S1 . If a request for access to Si has already been granted, the security agent moves on to S i+1 .
21
If the security agent has already issued a request for access to S i that has not been granted or denied (a pending request), the security agent does not issue another request to access S i . Instead, the security agent considers that access to Si can not be granted by the other party. Otherwise, the security agent requests S i from the other party. If access to all the credentials in D 1 is granted, then the security agent knows credential C can be unlocked and sends a grant message for C to the other party. If access to one of the credentials in D1 cannot be granted, the security agent will backtrack immediately and try D 2 . If none of the disjuncts consists of credentials that can be unlocked, a deny message for C will be sent to the other party. Finally, if the request for service S is denied, then the algorithm halts and claims that a successful negotiation is impossible between the two parties. Otherwise, there exists a successful negotiation. Both parties in the negotiation can now begin to disclose credentials, using grant and deny information accumulated during previous negotiation rounds. More details on the credential disclosure procedure will be given in section 3.2. This brute-force backtracking strategy backtracks whenever a circular dependency is detected. Given that the sets of credentials and policies are finite at both parties, the search it conducts always terminates. Also, since it searches all the possible negotiation sequences in a depth first way, we can easily prove that it is complete. Before we start discussing any strategy’s computation and communication complexity, we introduce the concept of a tree that is traversed by trust negotiation algorithms. In this chapter, we use an AND/OR tree [80] called the negotiation search tree. In a negotiation search tree, there are two kinds of nodes: credential nodes and disjunctive nodes. Credential nodes correspond to credentials and services that the parties may possess, while disjunctive nodes correspond to disjuncts of credential policies. The root of a negotiation search tree is a credential node for the service S originally requested by the client. If C ← D 1 ∨· · ·∨Dn , then every appearance of a credential node for C in the search tree will have n disjunctive nodes as its children (each of which corresponds to a disjunct of C’s policy), except when the node for C itself is a circular dependency node, which we will define soon. Similarly, for a disjunct D = C 1 ∧ · · · ∧ Ck , a disjunctive node for D will have k credential nodes as its children, each of which corresponds to a credential in D. For an unprotected credential, its credential node will have only one child, which is a special disjunctive node called a TRUE node. For a credential not possessed by a party, its credential node’s only child is a special disjunctive node called a FALSE node. Both TRUE and FALSE nodes are leaf nodes. A credential node will 22
S
C2
C6
C1
C4
F
S1
C2
C3
S3
C2
T
S2
C1
S3
S2
C5
C4
T
T
C1
T
S3
S2
C4
C5
C4
T
T
T
C1
S1
S3
C5
C4
T
T
C2
C3 T
C5
C4
T
T
S3
C2
C4
C5
C4
T
T
T
Figure 3.1: The negotiation search tree for the access control policies given in figure 2.2 be a leaf node if there is an ancestor representing the same credential in the path from S to the credential node leaf (this means a circular dependency exists and the negotiation along this path stops here). We call such a leaf node a circular dependency node. A security agent will backtrack at a circular dependency node, without sending a request message. Also, by forcing circular dependency nodes to be leaf nodes, a negotiation search tree is always finite. Figure 3.1 gives an example of a negotiation tree. S is the service the server may provide. Round nodes represent credential nodes while square nodes represent disjunctive nodes. The dotted line represents the search path taken by the security agents during negotiation using the brute-force backtracking strategy. It is easy to see now that the brute-force backtracking strategy is just a straightforward depth first search of the AND/OR tree, only the search is conducted in a distributed manner by the security agents at two sites and each security agent only has partial information about the tree. The two security agents move alternately in the tree, with each move triggered by an incoming message. There can be many nodes in 23
the negotiation search tree for the same credential, each corresponding to a request for that credential at a different time during the negotiation. The size of the negotiation search tree can be exponential in n, the number of credentials at both parties, which makes the brute-force backtracking strategy’s communication and computational complexity also exponential in n in the worst case. A key observation for the brute-force backtracking strategy is that it is not always necessary to explore a credential C’s policy whenever a request for C comes. If C has just been requested a few rounds before, and the internal state of the security agent has not changed much, it is very likely that the new request for C will be denied again. Now we will derive a sufficient condition for when a request for credential C will be denied, which we can use to get an efficient backtracking strategy. In the brute-force backtracking strategy, suppose that a request R for C is denied. We will show that with the brute-force strategy, there is no way to unlock C without first granting one or more of the ancestors of the node for C where the denial just took place. We will further show that if, when the next request for C is received, no credential has had access granted since access to R was denied, then not only will this new request for C be denied too, but no other credential will have access granted between the time the new request is received and denied. Theorem 3.1. In the brute-force backtracking strategy, when a request for C is denied, suppose that the path in the negotiation search tree from the root to the credential node for C corresponding to that request is L0 , . . . , Lk , C, where Li is a credential requested by either party, for 0 ≤ i ≤ k. Then access to C will not be granted before access to at least one L i , 0 ≤ i ≤ k, is granted. Proof. The proof proceeds by induction on d, the maximum distance from the node for credential C in the negotiation search tree corresponding to the denied request (for simplicity, we also call this node C for the rest of the proof), to a node N that is a proper descendant of C and is either a circular dependency node or a FALSE node. According to the conditions defined in section 3.1 under which a request should be denied, at least one such proper descendant must exist. So d ≥ 1. When d = 1, this proper descendant must be a FALSE node (otherwise, access to C will not be denied immediately and d is at least 2), which means that the security agent does not possess C and the theorem holds. When d = 2, since the strategy must have explored all C’s disjuncts before denying the request for C, 24
each disjunct D of C’s policy contains one or more of L 0 , . . . , Lk to constitute a circular dependency. In order to unlock C, we must satisfy one of its disjuncts D. But D can only be satisfied if all of its conjuncts can be unlocked, which means that one of L 0 , . . . , Lk must be unlocked. We conclude that when d = 2, the theorem holds. Suppose when d = j, the theorem holds. When d = j + 1, since access to C is being denied, for each disjunct D of C’s policy, there exists a credential S in D, which either has had access denied or is a circular dependency node. If S is a circular dependency node, then S is identical to one of L0 , . . . , Lk , C. Thus S cannot be unlocked without granting access to one of L0 , . . . , Lk , C. Otherwise, define d for S as we defined d for C. The node for S is two levels below the node for C in the search tree, so we have d ≤ j − 1. Since access to S has been denied, the induction hypothesis applies to the node for S , according to which S again cannot be unlocked without granting access to one of L0 , . . . , Lk , C. Because there is such an S in every disjunct of C’s policy, C cannot be unlocked without first granting access to one of L 0 , . . . , Lk , C, and the theorem holds. Theorem 3.2. In the brute-force backtracking strategy, suppose there are two requests R 1 and R2 for C, with R1 arriving before R2 . Let G be the set of granted credentials from both parties when R 1 is denied. If when R2 arrives, G is unchanged, then (1) R2 will also be denied, and (2) when R2 is denied, G is still unchanged. Proof. Suppose the paths from the root of the negotiation search tree to nodes for credential C when R 1 and R2 are issued are p1 = L10 , . . . , L1k , C and p2 = L20 , . . . , L2l , C respectively. Consider the last common node shared by p1 and p2 , tracking down from the root S. Such a node exists because at least L10 = L20 = S. More precisely, let t = max{j | ∀i, 0 ≤ i ≤ j, L1i = L2i }. Suppose for request R2 , the brute-force algorithm finds a credential disclosure sequence E to unlock C. Since L10 , . . . , L1t are ancestors of C in p2 , E does not contain any of L10 , . . . , L1t . If E does not contain any of L1t+1 , . . . , L1k , then C can be unlocked without granting access to any of L 10 , . . . , L1k and according to Theorem 1, access to R1 should not be denied in the first place, leading to a contradiction. So E must contain some credentials in L 1 t+1 , . . . , L1k . Let L1f be the first such credential to appear in E. Since L1f is in p1 , when access to R1 was denied, G does not contain any credentials in L 1 t+1 , . . . , L1k . We know that when R2 arrives, G has not changed since access to R 1 was denied. Therefore access to L 1f 25
was denied during the backtracking to L 1t , before R2 arrives. According to Theorem 1, to unlock L 1f , at least one of L10 , · · · , L1 f −1 must be unlocked. Since E does not contain any of L 10 , . . . , L1t , at least one of L1 t+1 , . . . , L1 f −1 has been unlocked before L1f is unlocked, which contradicts the fact that L 1f is the first credential in L1 t+1 , . . . , L1k to be unlocked. The proof for (2) is similar. Let period 1 cover the time from the receipt to the denial of access to R 1 , and let period 2 cover the time from the receipt to the denial of access to R 2 . Suppose when access to R2 is denied, the set of granted credentials is no longer G. Then access to some credentials has been granted during period 2. Let C be the first such credential and let p 3 be the path from C to C . If p3 does not contain anything in p1 except C, then during period 1, C must have been requested through a path from C to C that looks exactly the same as p3 , because there cannot be any circular dependencies along this path. Since access to C is granted in period 2, a request to access for C must exist and have been denied in period 1. According to Theorem 1, access to at least one credential along p 1 + p3 was granted before access to C is granted. Because C is the first credential with access granted in period 2 and the set of access-granted credentials remains unchanged between the time when R 1 is denied and R2 is received, no credentials in p1 have had access granted before access to C is granted. Therefore, at least one credential C in p3 had access granted when R2 is received, which means the search along p 3 will not reach C at all in period 2, but stop and backtrack when access to C is granted – a contradiction. If p3 contains credentials in p1 other than C, they should be in C1 t+1 , . . . , C1k because otherwise there would be a circular dependency with credentials in p 2 . Suppose L is the closest of these shared credentials to C in p3 . Note that a node for C is also a descendant of the L that appears in p 1 , and C must have been requested when that node was traversed because there is a path with no circular dependencies from the root to C via that L. Since C is the first credential with access granted in period 2, the credential disclosure sequence for C does not contain anything from p1 + p3 . Then the earlier request for C must have been granted. Again we have a contradiction.
3.2 The PRUNES Strategy In this section, we propose PRUNES, a refined backtracking strategy that prunes certain areas of the search tree, and prove it is equivalent to the brute-force strategy in finding credential disclosure sequences, therefore
26
complete too. We will show the complexity of PRUNES. Based on Theorem 2, the PRUNES strategy avoids unnecessary request resending and policy rescanning for a credential when no progress has been made in the negotiation since the last time that access to that credential was denied. At each party, each credential C is associated with a variable called current_granted which is the size of G when the last request for C was denied. There is also a global variable total_granted at each party, recording the current size of G in the negotiation. Whenever access to a new credential is granted, total_granted is increased by one. When a security agent tries to unlock a credential C that was denied before, it first checks whether C’s current_granted equals total_granted. If it does not, the security agent will send a message to the other party requesting C. Otherwise, according to Theorem 2, C cannot be unlocked in the current situation. So the security agent will backtrack without sending a request for C. Figure 3.2 gives the pseudo code of three key functions of PRUNES. The client starts the negotiation by calling PREPARE-REQUEST(S), where S is the service requested by the client. Upon receiving the request for S, the server calls TRY-UNLOCK(S). The second part of Theorem 2 ensures that by pruning the search tree this way, PRUNES will not miss any chance of granting access to other credentials, compared with the brute-force backtracking strategy. Meanwhile, the search path followed by PRUNES is a subsequence of that followed by the brute-force one. Therefore given the same policies and sets of credentials, the two strategies always find the same solution. In another word, these two strategies are equivalent. Hence PRUNES is also complete. We have not yet explained how the negotiation process leads to actual credential disclosures. In PRUNES, each security agent also maintains a dependency graph. The nodes in the graph represent credentials to which access is granted during the negotiation. Besides indicating the credential, each grant message also includes the disjunct from the access control policy of that credential whose satisfaction will cause the credential to be unlocked. Upon receiving such a grant message, a security agent will update its dependency graph by adding one edge from each credential in the received disjunct to the granted credential. There is also a special node in the dependency graph which represents the formula true. When a granted credential is unprotected, an edge from the true node to that credential is added. The party sending this grant message will update its own dependency graph in the same way, so that both parties have the same dependency graph. Then when a negotiation succeeds, both parties will agree on the credential disclosure sequence, which is defined by a topological sort of the nodes, starting from true to the target service S. Then the actual creden27
PREPARE-REQUEST(C) TRY-UNLOCK(C) if (this party does not possessC) if (access to C has been granted) return true; then if (C has a pending request) return false; SEND-MESSAGE(deny(C)); if (this is the first time access to C is requested or return; C.current_granted < total_granted) if (C is unprotected) then then SEND-MESSAGE(request(C)); SEND-MESSAGE(grant(C, true); return(HANDLE-INCOMING-MESSAGE()); total_granted ← total_granted + 1; else return false; return; done ← false; while (done = false and C has an untried disjunct) take the next disjunct D; HANDLE-INCOMING-MESSAGE() solvable ← true; while (solvalbe = true and D has an untried credential) while (true) msg = RECEIVE-MESSAGE(); take the next credential L in D; case (msg) if (PREPARE-REQUEST(L)=false) deny(C): then solvable ← false; C.current_grant ← total_granted; if (solvable = true) then done ← true; return false; if (done = true) grant(C, D): then total_granted ← total_granted + 1; SEND-MESSAGE(grant(C, D)); return true; total_grant ← total_grant + 1; request(C): TRY-UNLOCK(C); else SEND-MESSAGE(denay(C));
Figure 3.2: The pseudo code for three key functions of PRUNES tial disclosure starts and trust will be established. We call this phase the credential disclosure phase, while the first phase is the negotiation phase, when the two parties exchange request, grant and deny messages to find a credential disclosure sequence for successful trust establishment. Figure 3.3 gives an example to show how PRUNES works. It gives the message sequence in the negotiation, along with the dependency graph after access to service S is granted. At time point 5, the server denies a request for S2 because S2 needs C1 and there is already a pending request for C 1 (circular dependency). At time point 7, when the server receives a deny message for C 2 , it records the current total number of granted credentials (0 here) for C 2 and backtracks to the second disjunct in the policy for S 1 , where the first credential is again C 2 . Since the total number of granted credentials has not changed since the last time access to C2 was denied, the server will not request C 2 at this point. It denies access to S 1 instead. However, at time point 15, the total number of credentials with access granted has increased to 1. The server will request C2 then. 28
Client’s Policies C 1 ← S1 ∨ S3 C 2 ← S2 ∧ S3 C3 ← true C4 ← true C5 ← true
0 XXX XXXreq: S XXX z X 1 req: C1 9 2 XXX XXXreq: S1 XXX z X 3 req: C2 9 4 XXX XXXreq: S2 XXX z X 5 deny: S2 9 6 XXX deny: C2 XXX XXX z X 7 deny: S1 9 8 XXX XXXreq: S3 XXX z X 9 req: C5 9 10 XXX grant: C5 , true XX XXX X z X 11
11 9 XXX grant: C1 , S3 XX XXX X z X 13 req: C6 9 XXX XXX deny: C6 XXX z X 15 req: C2 9 XXX XXXreq: S2 XXX z X grant: S2 , C1 17 9 XXX grant: C2 , S2 ∧ S3 XXX XXX z X 19 req: C4 9 XXX C4 , true XXgrant: XXX X z X grant: S, C2 ∧ C4 21 9 grant: S3 , C5
12
14
16
18
20
22
S C2 I @ I @ @ @ S2 @ @ @ C4
Server’s Policies S ← (C1 ∧ C6 ) ∨ (C2 ∧ C4 ) S1 ← (C2 ∧ C3 ) ∨ (C2 ∧ C4 ) S2 ← C1 S3 ← C5 ∨ C 4
S3 I @ @ C1 C5 I @ @ T
Figure 3.3: The message sequence using PRUNES and the final dependency graph The following two theorems show the efficiency of PRUNES. Theorem 3.3.
The worst case communication complexity (total number of messages, total size
of messages, and number of rounds) of PRUNES is O(n2 ), where n is the total number of credentials requested during the negotiation. Proof. As mentioned before, the communication complexity of a negotiation strategy has two aspects: the total number of messages and the total size of messages. During the credential disclosure phase in PRUNES, there are at most n messages and the size of each message depends on the size of a credential (which we assume is bounded by a constant). We will now focus 29
our discussion on communication occurring during the negotiation phase. During that phase, there are three kinds of messages: request, deny, and grant. Since access to each credential is granted at most once, the number of grant messages is no more than the number of credentials of the two parties. Each grant message contains a disjunct from the credential’s policy. We assume that credential name lengths are bounded by a constant. So the size of a grant message is no more than O(n). Therefore the cost of grant messages is O(n 2 ) in the worst case. A credential C is requested only when (1) access to it has not been granted yet and (2) it was never requested before or its current_granted is smaller than total_granted. If the request for C is denied, its current_granted is set to be equal to total_granted, which makes current_granted monotonically increasing. Since total_granted is at most the total number of credentials possessed by the two parties, a credential C is requested at most that many times. Therefore the total number of request messages is O(n 2 ) in the worst case. Since each request message only contains a credential name, the total size of request messages is also O(n2 ) in the worst case. A deny message always responds to a request message and it also only contains a credential name. So the total number and size of deny messages are both O(n 2 ) in the worst case. In all, the worst case communication cost of PRUNES is O(n 2 ), in the sense of both the total number of messages and the total size of messages. The number of rounds is half the number of messages. Theorem 3.4.
The worst case computational complexity of PRUNES is O(nm), where n is the
total number of credentials and m is the total size of the policies of both parties. Proof. During the negotiation phase, the local computational cost for a security agent is solely the cost of scanning the access control policies. For each arriving request for credential C, in the worst case, C’s policy is completely scanned once. As shown in the proof of Theorem 3, there are at most n requests for C, so C’s policy is scanned at most n times. The computational cost in this phase is therefore at most O(nm). During the credential disclosure phase, the computational cost is dominated by the cost of performing a topological sort on the dependency graph. The dependency graph (same at both parties) has at most n vertices and n2 edges, so the computational cost in this phase is at most O(n + n 2 ) = O(n2 ). Since m ≥ n, the total computational complexity is O(nm) in the worst case. The above analysis is about worst cases and only gives a loose upper bound on the number of messages. 30
Also n and m here are only the number of credentials and the size of policies relevant to the negotiation, i.e., credentials requested and policies looked up during the negotiation. We can further reduce the number of messages by differentiating between the deny message for a credential not possessed by the party receiving the request for that credential, and the deny message for a credential that incurs a circular dependency. In the former case, no request will be sent again for that credential. Then for credentials requested by one party but not possessed by the other, there will be only one request and one deny message. In this chapter, we have assumed that the two parties adopt the same strategy. Therefore, conceptually, a negotiation strategy can be viewed as a distributed algorithm that two parties follow to find a safe disclosure sequence. Consequently, a negotiation protocol is implicitly defined by the algorithm, such as the information in messages, how to interpret the semantics of messages, and when a negotiation is considered terminated. In the next chapter, we will relax this assumption and examine how, when two parties have autonomy in choosing strategies, trust establishment can still be guaranteed whenever possible.
31
Chapter 4
Interoperable Strategies 4.1 The TrustBuilder Protocol and Strategy Families In chapter 3, we assumed that the two negotiation participants were willing to use the same strategy to establish trust. However, considering the autonomous nature of entities in open systems, such an assumption is unlikely to hold in practice. Different entities will have different requirements when choosing their trust negotiation strategies. For example, service providers (e.g., certificate authorities and e-business and e-medical servers) tend to possess many sensitive resources along with adequate computation power. Therefore, cautious strategies, which carefully analyze the ongoing negotiation and only disclose relevant information to others, may be appropriate. On the other hand, thin clients like smart cards have limited computation ability. They may choose simpler strategies which may disclose irrelevant credentials. Therefore, interoperation between different strategies with a variety of properties should be supported in automated trust negotiation. However, no two strategies that we have discussed so far can interoperate. As defined in chapter 2, a trust negotiation protocol defines the ordering of messages and the type of information messages will contain, while a trust negotiation strategy controls the exact content of the messages, i.e., which credentials to disclose, when to disclose them, and when to terminate a negotiation. In chapter 3, no trust negotiation protocol was explicitly proposed. Instead, a protocol was defined implicitly by the way PRUNES works. This is one reason why no two different strategies from the early literature on automated trust negotiation can interoperate — their underlying protocols are totally different. We remedy this problem by defining a simple protocol for TrustBuilder, shown in figure 4.1. Formally, a message in TrustBuilder Protocol 1 is a set {R 1 , . . . , Rk }, where each Ri is a disclosure of a local credential,
32
a local policy, or a local service. When a message is the empty set ∅, we also call it a failure message. Further, to guarantee the safety and timely termination of trust negotiation no matter what policies and credentials the parties possess, TrustBuilder Protocol 1 requires the negotiation strategies used with it to enforce the following three conditions throughout negotiation: 1. Every disclosure must be safe. 2. If a message contains a denial policy disclosure C ← f alse, then C must appear in a previously disclosed policy. This helps to focus the negotiation and helps prevent infinite negotiations. 3. A credential or policy can be disclosed at most once. Again, this helps focus the negotiation. As in chapter 3, we assume that policies are unprotected. Before the negotiation starts, Alice sends the original resource access request message to Bob, indicating her desire to access Bob’s service R. This request triggers the negotiation, and Bob invokes his local security agent with the call security_agent(L, R), where L is the set of Bob’s credentials and policies. Meanwhile, Alice also invokes her security agent. Then Alice and Bob exchange messages until either the service R is disclosed by Bob or one party sends a failure message. The whole negotiation process is shown in figure 4.1. In the remainder of this chapter, unless otherwise noted, we discuss only strategies that can be called from TrustBuilder Protocol 1 and satisfy the three conditions above. A formal definition of a negotiation strategy is given below. Intuitively, based on the sequence of disclosures made so far, plus the set of all local resources, a negotiation strategy will suggest the next set of disclosures to send to the other party. Definition 4.1. A strategy is a function f that takes three parameters, M, L and R, where R is a resource / mi for name, M = (m1 , . . . , mk ) is a sequence of disclosure messages such that m i = ∅ and R ∈ 1 ≤ i ≤ k, and L is a set of resources. The output of f is a set S m of disclosure messages. Further, every disclosure in a message in Sm must occur in L, as must all the disclosures in m k−2i , for 1 ≤ k − 2i < k. The remaining disclosures in M cannot occur in L. Note that a strategy returns a set of possible disclosure messages, rather than a single message. Practical negotiation strategies will suggest a single next message, but the ability to suggest several possible next
33
security_agent(L,R) Input: L is the set of local resources. R is the resource to which access was originally requested. Output: the result of the negotiation, which can either be FAIL or SUCCEED. Let M be an empty disclosure message sequence. r ← NOT_TERMINATED. If (R is a local resource) then //Negotiation is initiated by the other party. r ←send_response(M,L,R). If (r=SUCCEED or r=FAIL) //Negotiation has terminated. then return r. While (r=NOT_TERMINATED) Receive message m from the other party. Add m to the end of M. r ← check_for_termination(m,R). If (r=SUCCEED or r=FAIL) then return r. r ← send_response(M,L,R). If (r=SUCCEED or r=FAIL) then return r. End of security_agent. send_response(M,L,R) Sm ← local_strategy(M,L,R). //Sm contains the candidate messages that the local strategy suggests. Choose any single message m from Sm . Send m to the remote party. Add m to the end of M. r ← check_for_termination(m ,R). Return r. End of send_response. check_for_termination(m, R) If (m = ∅) then return FAIL. //Negotiation has failed. If (R ∈ m) then return SUCCEED. //Negotiation has succeeded. Return NOT_TERMINATED. End of check_for_termination.
Figure 4.1: Pseudocode for TrustBuilder Protocol 1 messages will be very convenient in our formal analysis of strategy properties, so we include it both in the formal definition of a negotiation strategy and also in the TrustBuilder Protocol 1 pseudocode in figure 4.1.
34
Definition 4.2. Strategies s1 and s2 are compatible if whenever there exists a safe disclosure sequence for a party Alice to obtain access to a resource owned by a party Bob, the trust negotiation will succeed when Alice uses s1 and Bob uses s2 . If s1 = s2 , then we say that fA is self-compatible. Definition 4.3. A strategy family is a set F of mutually compatible strategies, i.e., ∀s 1 ∈ F , s2 ∈ F , s1 and s2 are compatible. We say a set F of strategies is closed if given a self-compatible strategy s, if s is compatible with every strategy in F , then s ∈ F . One obvious advantage of strategy families is that a security agent (SA) can choose strategies based on its needs without worrying about interoperability, as long as it negotiates with other SAs that use strategies from the same family. As another advantage, under certain conditions, an SA does not need to stick to a fixed strategy during the entire negotiation process. It can adopt different strategies from the family in different phases of the negotiation. For example, during the early phase, since the trust between two parties is very limited, an SA may adopt a cautious strategy for disclosing credentials. When a certain level of trust has been established, in order to accelerate the negotiation, the SA may adopt a less cautious strategy. However, without the closure property, a family may not be large enough for practical use. As an extreme example, given any self-compatible strategy s, {s} is a strategy family. The closure property guarantees the maximality of a strategy family. TrustBuilder Protocol 1 is so simple and natural that it is natural to wonder whether there are any other interesting protocols. Similarly, is there more than one interesting strategy family? The answer to both questions is a resounding “yes”, especially for the structured credentials that will be discussed in chapter 5. To help us choose between potential protocols and families to present in this thesis, we have developed a set of (often conflicting) desiderata, presented below. 1. The protocol should be as simple as possible, with a minimal number of types of messages and minimal restrictions on their sequencing. 2. The family must include strategies that can be implemented using today’s typical trust negotiation environment underpinnings. For example, the reasoning powers provided by the XSB logic programming engine [74], or the IBM Trust Policy Language (TPL) engine [43], should be sufficient or nearly sufficient.
35
3. The family must include strategies that will run efficiently in today’s typical trust negotiation environments. For example, we do not like families in which the strategy must find all minimal solutions for a policy as soon as negotiation begins. 4. The family must include as many as possible of what we call “unintelligent” strategies, which tend to be extremely easy to implement but not too clever at determining which policies and credentials are relevant to the negotiation. We think such strategies will be popular, and we give them priority over cleverer strategies that will be harder to implement and often slower at run time.
4.2 Characterizing Safe Disclosure Sequences In this section, we define the concepts that we use to describe the progress of a negotiation and to characterize the behavior of different strategies. More precisely, we define the trees and tree operations that give meaning to strategies’ actions. Negotiation strategies do not need to materialize these trees; rather, the trees provide the formal basis for what a strategy does. This section is the heart of our discussion on interoperable strategies, and readers who survive its onslaught of definitions and examples will understand why some strategies interoperate and others do not. This section also shows how to generate a set of strategies based on the set’s member who is the most reluctant to disclose information. The concepts introduced in this section will be used to define a useful strategy family in section 4.3, and will resurface in revised form when we examine credentials with internal structure in chapter 5.. In the remainder of this chapter, we use R to represent the resource to which access was originally requested, unless otherwise noted. Definition 4.4. A disclosure tree for R is a finite tree satisfying the following conditions: 1. The root is labeled with R. 2. Except for the root, each node is labeled with a credential. When the context is clear, we refer to a node by its label. If two nodes are labeled with the same credential, we will explicitly distinguish them when we refer to them. 3. The labels of the children of a node C form a minimal solution for C’s policy.
36
Server Policies
Client Policies
R ← (B1 ∧ B2) ∨ B3 ∨ B4 A1 ← B1 A2 ← true A3 ← B4
B1 ← A1 ∨ (A2 ∧ A3) B2 ← A3 B3 ← A2 B4 ← true
T1 R
T2 R
B1
A2
T3 R
B2
A3
B1
T4 R
B2 B3 A2
A1 B1 A1
Figure 4.2: Example disclosure trees for a set of policies When all the leaves of a disclosure tree T are unprotected credentials, we say T is a full disclosure tree. Given a disclosure tree T , if there is a credential appearing twice in the path from a leaf node to the root, then we call T a redundant disclosure tree. Figure 4.2 shows example disclosure trees. Note that T 3 is redundant and T4 is a full disclosure tree. We use abstract examples because they are much more concise and can be easily manipulated to show all the different cases that the theory must cover. The following theorems state the relationship between disclosure trees and safe disclosure sequences that lead to the granting of access to resource R. Theorem 4.1. Given a non-redundant safe disclosure sequence Q = (C 1 , . . . , Cn = R), there is a full non-redundant disclosure tree T such that the following both hold: 1. The nodes of T are a subset of {C1 , . . . , Cn }. 2. For all credential pairs (C1 , C2 ) such that C1 is an ancestor of C2 in T , C2 is disclosed before C1 in Q. Proof. By induction on n. When n = 1, resource R is unprotected. We can have a disclosure tree with only the root node, and the theorem holds. Assume when 1 ≤ n ≤ k, the theorem holds. 37
When n = k + 1, since access to R is eventually granted, we can find a minimal solution {C j1 , . . . , Cjt } for R among the credentials in Q. Since Q is a non-redundant safe disclosure sequence, for each C ji , where 1 ≤ i ≤ t, (C1 , . . . , Cji ) is a safe disclosure sequence with length no more than k. By the induction hypothesis, there is a non-redundant disclosure tree T i whose root is Cji and all the nodes are credentials appearing in (C1 , . . . , Cji ), which is a prefix of Q. And for every credential pair (C 1 , C2 ) such that C1 is an ancestor of C2 in Ti , C2 is disclosed before C1 in (C1 , . . . , Cji ). By adding R as the root and all the roots of Ti , 1 ≤ i ≤ t, as children of R, we get a full non-redundant disclosure tree that satisfies conditions 1) and 2) in the theorem. Therefore the theorem holds. Theorem 4.2. Given a full disclosure tree for R, there is a non-redundant safe disclosure sequence ending with the disclosure of R. Proof. Let Q = (C1 , . . . , Cn = R) be the post-order traversal of T . According to the definition of full disclosure trees, when a credential is disclosed in Q, either it is unprotected or one of its minimal solutions has been disclosed. Therefore its disclosure is safe, and Q is a safe disclosure sequence. Thus, we can remove all but the first disclosure of each credential to make Q non-redundant. By theorems 4.1 and 4.2, we get the following corollary immediately. Corollary 4.1. There is a safe disclosure sequence ending with the disclosure of R if and only if there is a full non-redundant disclosure tree. Without loss of generality, from now on, we consider only non-redundant disclosure sequences. Since there is a natural mapping between safe disclosure sequences and disclosure trees, during the negotiation, theoretically one could determine whether a potential credential or policy disclosure is helpful by examining all the disclosure trees for R. At the beginning of a negotiation, before disclosures begin, the only relevant disclosure tree for the client contains a single node R. As the negotiation proceeds, other trees may become relevant. The following definitions help us describe the set of relevant trees. Definition 4.5. Given a disclosure tree T and a set C of credentials, the reduction of T by C, reduce(T, C), is the disclosure tree T which is obtained by removing all the subtrees rooted at a node labeled with resource C ∈ C. Given a set T of disclosure trees, reduce(T , C) = {reduce(T, C) | T ∈ T }.
38
R
R
R
{B4, A1, A3} reduce
B2
A1
B1
B2
B1
B1
B3
B1 R
R
B1
A2
A3
A4
B2
B5
B2
B2
B2 A1
A2
B3
A2
A3
B4
{B5 ← f alse} denial
B3
B4
R
R
(a) Example of a disclosure tree reduction.
B1
B1
R
B2
A1 B1
B1
B1 B2
A4
A4
B2
A2
B2
B1
B2
B1
A3
A1
A2
trees(S) contains the following derivation trees:
A3 R
R B4
B4
B5
B2
S = {A2, B4, R ← (B1 ∧ B2) ∨ (B3 ∧ B4) ∨ B5, B1 ← A1 ∨ (A2 ∧ A3), B3 ← A2, B5 ← A6 ∧ A7, A1 ← B1, A3 ← B4, A6 ← f alse}
R
R
B2
(c) Example of denial pruning and redundancy pruning.
{B1 ← A1 ∧ A2, A3 ← B4, A2 ← (B3 ∧ B4) ∨ B5} expand
B3
R
B2 A3
A1
redundant
B4 B1
B2
B3
(b) Example of a disclosure tree expansion. A3
(d) Example of a disclosure tree evolution.
Figure 4.3: Examples of operations on disclosure trees If C is the set of credential disclosures made so far, then reducing T by C prunes out the part of the negotiation that has already succeeded. Intuitively, if a credential C has been disclosed, then we already have a safe disclosure sequence for C. We do not need to disclose additional credentials or policies in order to get a full disclosure tree rooted at C. Tree reduction can be viewed as a reformulation of partial evaluation [15] in the context of disclosure trees. An example of a disclosure tree reduction is shown in figure 4.3(a). Definition 4.6. Given a disclosure tree T and a policy set P containing no denial policies, the expansion of T by P, expand(T, P), is the set of all disclosure trees T i such that 1. Ti can be reduced to T , i.e., there exists a set C of credentials such that reduce(T i , C) = T . 39
2. For each edge (C1 , C2 ) in Ti , if (C1 , C2 ) is not an edge of T , then C1 ’s policy is in P. 3. For each leaf node C of Ti , either P does not contain C’s policy, or T i is redundant. Given a set of disclosure trees T , expand(T , P) =
T ∈T
expand(T, P).
A disclosure tree can expand when a party receives new policy disclosures. An example of a disclosure tree expansion is shown in figure 4.3(b). Definition 4.7. Given a set T of disclosure trees and a set P of denial policies, the denial pruning of T by P, denoted deny(T , P), is the set {T | T ∈ T and T contains no resource whose policy is in P}. Since a full disclosure tree contains only credentials that the two parties possess, if a disclosure tree node is labeled with a credential with a denial policy, that tree cannot evolve into a full disclosure tree, and is no longer relevant. Definition 4.8. Given a set T of disclosure trees, the redundancy pruning of T , denoted redundant(T ), is the set {T | T ∈ T and T is not a redundant disclosure tree}. The rationale for redundancy pruning will be shown after we introduce more operations on disclosure trees. Examples of denial and redundancy pruning are shown in figure 4.3(c). Definition 4.9. Given a disclosure tree T and a set D of denial policies, a set P of non-denial policies, and a set C of credentials, let S = D ∪ P ∪ C. The evolution of T by S, denoted evolve(T, S), is redundant(denial(reduce(expand(T, P), C), D). Given a set T of disclosure trees, evolve(T , S) =
T ∈T
evolve(T, S). As a special case, when T is the
disclosure tree containing only a root node R, then we say evolve(T, S) is the trees of S, denoted trees(S). During the negotiation, let S be the set of credentials and policies disclosed so far and let L be the local policies of a negotiation party. Then trees(S ∪ L) contains all the relevant disclosure trees which can be seen by this party. An example set of trees is shown in figure 4.3(d). 40
Sometimes even though a tree may evolve into a full tree later in the negotiation, it is nonetheless redundant and can be removed by redundancy pruning, whose correctness is guaranteed by the following theorem. Theorem 4.3. Let T be a full but redundant disclosure tree. Then there is a full disclosure tree T that is not redundant. Proof. Let Q = (C1 , . . . , Cn = R) be the post-order traversal of T . Obviously Q is a safe disclosure sequence. According to corollary 4.1, there is a full non-redundant disclosure tree. Suppose S is the set of currently disclosed credentials and policies. By theorem 4.3, if a redundant tree may evolve into a full tree, then the corresponding non-redundant tree is already included in trees(S). So the redundant trees are not relevant for the remainder of the negotiation. In order to make a negotiation successful whenever the policies of the two negotiation parties allow, the negotiation strategy should make sure no possible full disclosure trees have been overlooked. A disclosure tree also tells a party what may contribute to the success of a negotiation. As an example, suppose Bob requests to access Alice’s resource R. S, the set of disclosures so far, and trees(S) are shown in figure 4.4. Suppose now it is Alice’s turn to send a message to Bob. From the disclosure tree, it is clear to an outside observer that credentials A1 and A2 must be disclosed if the negotiation is to succeed. So Alice’s negotiation strategy can now disclose A1’s and/or A2’s policy. This example shows that in order to let Alice know what might be the next appropriate message, a disclosure tree should have at least one leaf node that is a credential that Bob wants Alice to disclose. We have the following definition: Definition 4.10. Disclosure tree T ’s evolvable leaves for party A, denoted as evolvable(T, A), are the set of leaf nodes C of T such that either C = R and A is the server, or C appears in a policy that party B disclosed to A. If evolvable(T, A) = ∅, we say T is evolvable for A. The disclosure tree in figure 4.4 is evolvable for both Alice and Bob. If there is no evolvable tree, then a cautious party will choose to end the negotiation even if the policies of the two parties allow success. Therefore, to ensure that negotiations succeed whenever possible, a strategy must ensure that the other party will have an evolvable tree when the other party needs to make its next disclosure. The only exception is when the strategy knows that no disclosure tree can evolve into a full tree. If a negotiation reaches a point 41
S = {R ← B1 ∧ B2, B1 ← A1 ∧ A2} R
B2
B1
trees(S) : A1
A2
Figure 4.4: trees(S) where every leaf node of some disclosure tree is unlocked, then the tree is a full tree and corresponds to a safe disclosure sequence. If F is a strategy family, then intuitively, every strategy in F always discloses enough information to keep the negotiation moving toward success, if success is possible. If F is also closed, then F must also contain those strategies that disclose only the minimal amount of information needed to continue negotiations. Therefore it is helpful to formally define a relationship between strategies based on the information they disclose. Definition 4.11. Given two negotiation strategies s 1 and s2 , if for all possible inputs M, L, and R to s1 and s2 , we have ∀m ∈ s2 (M, L, R) ∃m ∈ s1 (M, L, R) such that m ⊆ m then we say s1 is at least as cautious as f 2 , denoted as s1 s2 or s2 s1 . Caution defines a partial order between strategies. Intuitively, if s 2 s1 then s2 always discloses at least as much information as s1 does. Definition 4.12. Given a strategy f , the set of strategies generated by f , is the set F = {s |s s}. f is called the generator of F .
4.3 The Disclosure Tree Strategy Family In this section, we present the disclosure tree strategy (DTS), and prove that DTS generates a closed family. DTS can be thought of as a strategy that is willing to reason very carefully about the trees presented in 42
the previous section, in order to avoid making any unnecessary disclosures. Though DTS is mainly of theoretical interest, the family DTS generates contains many highly practical strategies. We will give two example practical strategies belonging to the family DTS generates. Throughout this section, we assume that M = (m 1 , . . . , mk ) is a sequence of messages such that / mi for 1 ≤ i ≤ k. We assume LA and LB are the local policies of parties Alice and mi = ∅ and R ∈ Bob, respectively, and SM = 1≤i≤k mi . Without loss of generality, we assume Alice will send the next message to Bob. Definition 4.13. The Disclosure Tree Strategy (DTS for short) is a strategy DT S(M, L A , R) such that: 1. DT S(M, LA , R) = {∅} if and only if trees(SM ∪ LA ) = ∅ or trees(SM ) has no evolvable tree for Alice. 2. Otherwise, DT S(M, LA , R) contains all messages m such that one of the following conditions holds: • m = {R}, if R is unlocked by credentials in S M ; • m is a non-empty set of credentials and policies such that trees(S M ∪ m ) contains at least one evolvable tree for Bob, and no non-empty proper subset of m has this property. Condition 1 states under what circumstances the DTS strategy will terminate the negotiation with a failure message. Condition 2 guarantees that the other party will have an evolvable tree. Therefore, the other party can always send a message back that evolves a disclosure tree. Thus, no failure message will be sent unless there is no disclosure tree at all, in which case the negotiation cannot succeed anyway. Formally, we have the following theorems: Theorem 4.4. The set of strategies generated by DTS is a family. Proof. Suppose Alice and Bob adopt strategies s 1 and s2 respectively, and s1 and s2 belong to the set of strategies generated by DTS. We need to prove that if the negotiation fails, there is no safe disclosure sequence leading to the granting of access to R. When the negotiation fails, without loss of generality, we assume it is Alice who sends the failure message. Suppose that before Alice sends the failure message, M = (m 1 , . . . , mk ) is the sequence of 43
messages. When k = 0, then we must have R ← f alse and the theorem holds trivially. In the rest of the thesis, we will omit this trivial case. When k ≥ 1, since ∅ ∈ s 1 (M, LA , R) and s1 DT S, we must have DT S(M, LA , R) = {∅}. According to definition 4.13, one of the following must be true: 1. trees(SM ∪ LA ) = ∅. 2. trees(SM ) has no evolvable tree for Alice. When only 2) holds, we must have DT S((m1 , . . . , mk−1 ), LB , R) = {∅}. Otherwise, since s2 DT S and R ∈ mk , mk must be a superset of a minimal set m of credentials and policies such that trees((S M − mk ) ∪ m ) has at least one evolvable tree for Alice. Therefore, trees(S M ) also has at least one evolvable tree for Alice, which contradicts 2). Since DT S((m 1 , . . . , mk−1 ), LB , R) = {∅}, that means that before Bob sent mk , one of 1) or 2) was true. At the beginning of the negotiation, 2) is not satisfied. Therefore in some previous stage of the negotiation, 1) must have been true. When 1) holds, that means no tree will evolve to be a full disclosure tree. So there is no safe disclosure sequence leading to the granting of access to R. Theorem 4.5. If a strategy s and DT S are compatible, then s DT S. Proof. Suppose that Alice is the party who uses s. If DT S s, then there exists a choice of M, L A and R such that ∃m ∈ s(M, LA , R) such that ∀m ∈ DT S(M, LA , R), m ⊆ m . Then both of the following must be true: • trees(SM ∪ LA ) = ∅. • trees(SM ) has at least one evolvable tree for Alice. Otherwise, according to definition 4.13, DT S(M, LA , R) = {∅} and ∅ ⊆ m . Also, we have R ∈ m . Otherwise, R is unlocked by SM and {R} ∈ DT S(M, LA , R). DT S(M, LA , R) contains all the minimal sets m of local policies and credentials such that trees(S M ∪ m) has at least one evolvable tree for Bob. Since m is not a superset of any of these minimal sets, trees(SM ∪ m ) has no evolvable tree for Bob. Thus, after sending m , DTS at Bob will send a failure 44
message and end the negotiation. However, since trees(S M ∪ LA ) = ∅, there is a tree in trees(SM ∪ LA ) whose leaves are all evolvable for Bob and none of those leaves’ policies is in S M . In the case where all those credentials are unprotected, there is a full disclosure tree, which means that s and DTS are not compatible, leading to a contradiction. We call the family generated by DTS the DTS family. By theorems 4.4 and 4.5, we get the following corollary immediately. Corollary 4.2. The DTS family is closed. As we mentioned in section 4.1, one advantage of a strategy family can be the ability to adopt different strategies from a family in different phases of the negotiation. Correct interoperability is guaranteed as long as both parties’ strategies are from the same family. Definition 4.14. Let s1 and s2 be two strategies. A strategy s is a hybrid of s1 and s2 if for all choices of M, L and R, we have s (M, L, R) ⊆ s1 (M, L, R) ∪ s2 (M, L, R) and s = s1 and s = s2 . If a security agent adopts different DTS family strategies in different phases of trust negotiation, it is equivalent to adopting a hybrid of those strategies. Theorem 4.6. Let s1 and s2 be strategies in the DTS family and let s be a hybrid of s1 and s2 . Then s is also in the DTS family. Proof. ∀M, L, R, let s (M, L, R) = {m1 , . . . , mk }. Since s is a hybrid of s1 and s2 , mi ∈ s1 (M, L, R) or mi ∈ s2 (M, L, R), for all 1 ≤ i ≤ k. Because both s1 and s2 are in the DTS family, there exists m ∈ DT S(G, L, R) such that m ⊆ mi . Thus, s DT S. Therefore, as long as both parties use strategies from the DTS family, they can switch between different practical strategies as often as they like, and trust negotiation will still succeed whenever possible. Although disclosure trees are a useful tool for understanding strategy properties, it could require exponential time and space to materialize all the disclosure trees during a negotiation. Fortunately, many strategies in the DTS family are quite efficient, such as TrustBuilder1-Simple and TrustBuilder1-Relevant in figures 4.5 and 4.6.
45
The TrustBuilder1-Simple Strategy Input: M = (m1 , . . . , mk ): a sequence of safe disclosure messages. L: the local resources and policies of this party. R: the resource to which access was originally requested. Output: A set containing a single disclosure message m. Pre-condition: R has not been disclosed and mk = ∅. SM ← 1≤i≤k mi . m ← ∅. For every local credential C that is unlocked by S M m ← m ∪ {C}. For every local locked credential C if (C’s policy P is not a denial policy) then m ← m ∪ {P }. /L For every policy P ∈ SM such that P ∈ For every credential that C appears in P and has a denial policy m ← m ∪ {C ← f alse}. m ← m − SM . Return {m}. Figure 4.5: Pseudocode for the TrustBuilder1-Simple strategy
The TrustBuilder1-Simple strategy (figure 4.5) puts all undisclosed policies and unlocked credentials in the next message to the other party. If all the policies and unlocked credentials have already been disclosed, it will send a failure message. The TrustBuilder1-Relevant strategy (figure 4.6) discloses a credential C’s policy only if C is syntactically relevant to R. Similarly, TrustBuilder1-Relevant only discloses syntactically relevant unlocked credentials. In the CPN example in chapter 1, if Alice adopts the TrustBuilder1-Simple strategy, then when she receives CPN’s policy for exemption from sales tax, she will disclose all her unlocked credentials and her policies for her locked credentials, whether or not they are relevant. For example, Alice may disclose her library card, and she may tell CPN that in order to see her patient ID, CPN should present an employee certificate issued by Busey Hospital. On the other hand, suppose CPN adopts the TrustBuilder1-Relevant strategy. Then from all the disclosures Alice made, CPN will identify that only her credit card and her
46
The TrustBuilder1-Relevant Strategy Input: G = (m1 , . . . , mk ): a sequence of safe disclosure messages. L: the local resources and policies of this party. R: the resource to which access was originally requested. Output: A set containing a single disclosure message m. Pre-condition: R has not been disclosed and mk = ∅. SM ← 1≤i≤k mi . m ← ∅. For every local credential C syntactically relevant to R if (C is unlocked by SM ) then m ← m ∪ {C}. else m ← m ∪ {C’s policy}. /L For every policy P ∈ SM such that P ∈ For every credential C that appears in P and is syntactically relevant to R and has a denial policy m ← m ∪ {C ← f alse}. m ← m − SM . Return {m}.
Figure 4.6: Pseudocode for the TrustBuilder1-Relevant strategy reseller’s license are relevant. Thus, CPN will focus its efforts on satisfying Alice’s policy for access to her credit card, instead of trying to gain access to Alice’s patient ID. Lemma 4.1. If a credential C appears in a disclosure tree for R, then C is relevant to R. Theorem 4.7. TrustBuilder1-Simple and TrustBuilder1-Relevant belong to the DTS family. Proof. Because TrustBuilder1-Simple TrustBuilder1-Relevant, it suffices to show that DTS TrustBuilder1Relevant. Suppose TrustBuilder1-Relevant(M, L, R) = {m}. Let m be a message in DT S(M, LA , R). If a credential C or its policy is disclosed in m , then C must appear in a disclosure tree. According to lemma 4.1, m ⊆ m. Thus DTS TrustBuilder1-Relevant.
47
4.4 Strategy Caution and Interoperability According to our discussion so far, it looks intuitive that if two strategies s 1 and s2 are compatible with each other and s2 s3 , then s1 and s3 should also be interoperable. Similarly, if s 2 belongs to a strategy family F , it seems we should also have s3 ∈ F . The rationale behind such an intuition is that the success of a negotiation should not be jeopardized if a party is willing to disclose extra information to others. Unfortunately, the relationship between strategy caution and strategy interoperability is not that straightforward. Definition 4.15. Let F be a strategy family. If for all strategies s ∈ F and s s, we have s ∈ F , then we say F is a monotonic family. Theorem 4.8. The DTS family is monotonic. In this section we will define another strategy family, NonMono, and show that it is not monotonic. Though not as practical as DTS in terms of computation cost, NonMono does have nice features in its own right. After motivating NonMono in terms of these features, we define NonMono and investigate its properties. Later chapters do not rely on the material in this section. So readers can skip it if desired.
4.4.1 Disclosure Tree Coverage Recall that in the DTS family, Alice must guarantee that after her message, there is at least one evolvable tree for Bob. Suppose C is an evolvable leaf for Bob in that tree. Then in his next message, Bob can at least disclose C’s policy, or tell her that he does not possess C (by disclosing C ← f alse). Thus the negotiation will not terminate prematurely due to Bob’s action. Because the TrustBuilder 1 protocol allows the disclosure of denial policies, DTS family strategies can be very flexible regarding the content of messages. However, in some situations, people may be concerned about the fact that they do not possess certain credentials, making them reluctant to disclose denial policies to others 1 . If we want to accommodate such concerns during trust negotiation, then strategies should do more than simply guarantee that there is at least one evolvable tree for the other party. To see this, let us look at the example shown in figure 4.7. Suppose S contains all the disclosures made so far and it is Bob’s turn to send the next message. By examining Bob’s policies, we see clearly that T 1 1
We will discuss these non-possession sensitive credentials in detail in chapter 8.
48
Bob’s policies
Alice’s policies
R ← A1 ∨ A2 B1 ← f alse B2 ← A3 B3 ← true
A1 ← B1 ∧ B2 A2 ← B3
S = {R ← A1 ∨ A2, A1 ← B1 ∧ B2} R
R trees(S) :
A1
B1
A2 B2
T2
T1
Figure 4.7: Example showing the insufficiency of guaranteeing at least one evolvable tree for others in trees(S) will not evolve into a full tree, since Bob does not possess B1 and B2. On the other hand, T 2 is not evolvable for Bob. If Bob is not willing to disclose the denial policy of B1 or B2, there will be no relevant disclosures for Bob to make in his next message. Thus Bob may have to terminate the negotiation, though in fact the negotiation could succeed. In general, in order to avoid such a failure, Alice must disclose enough information so that every tree in the current set of trees is evolvable for Bob. In this case, if Bob still cannot find any relevant disclosures other than denial policy disclosures, then it is guaranteed that the two parties cannot establish trust. For the example shown in figure 4.7, if Alice discloses the policies for both A1 and A2, Bob will be able to move the negotiation toward success. In some situations, however, it is not necessary to make every tree evolvable for the other party. For example, suppose that the policy for A2 in figure 4.7 is changed to A2 ← B1 ∧ B2 ∧ B3. Then trees(S) will not cause a potentially successful negotiation to fail, because now the policy for A2 is stronger than that for A1. If Bob sees that there is no hope for T 1 to evolve into a full tree, then there is no hope for T 2 either. Formally, we have the following definition and lemma. Definition 4.16. Let the negotiating parties be Alice and Bob, and let T 1 and T2 be two disclosure trees. Then T1 covers T2 for Alice iff evolvable(T1 , Alice) = ∅ and evolvable(T1 , Alice) ⊆ evolvable(T2 , Alice).
49
Lemma 4.2. Let S be the set of all the credentials and policies disclosed so far, and let L be a set of local policies belonging to Alice. Suppose all the trees in trees(S) are evolvable for Alice and trees(S) contains more than one tree. Given T ∈ trees(S), the following two statements are equivalent: 1. For all possible choices of L that include all the disclosures Alice has already made, if evolve(trees(S)− {T }, S ∪ L) = ∅, then evolve(T, S ∪ L) = ∅. 2. There exists T ∈ trees(S) − {T }, such that T covers T for Alice. Intuitively, Lemma 4.2 states that for a disclosure tree T in the current set of trees, if T is covered by another tree T for Alice, and Alice finds that T and all the other trees in the current set of trees cannot evolve into full trees, then neither can T . The converse is also true. If for all possible choices of Alice’s local resources L, whenever all the other trees in the current set of trees cannot evolve into full trees, we always have that T cannot either, then T must be covered by some other evolvable tree for Alice in the current set of trees. Proof. Suppose statement 2 is false, i.e., T is not covered by any tree in trees(S) − {T } for Alice. Then every tree in trees(S) − {T } has at least one evolvable leaf C for Alice such that C ∈ evolvable(T, Alice). Let C = T ∈trees(S)−{T } (evolvable(T , Alice) − evolvable(T, Alice)). Consider the following choice of L. For every credential C ∈ C, L contains C ← f alse. For every credential C ∈ evolvable(T, Alice), L contains C ← true. Under such a choice, we have evolve(trees(S) − {T }, S ∪ L) = ∅ but evolve(T, S ∪ L) = ∅, and statement 1 is false. Further, L is consistent with the disclosures Alice already made, because L contains policies for leaf nodes only. Suppose now that statement 2 is true, i.e., that T ∈ trees(S) − {T } covers T for Alice. We will show that statement 1 is also true, by showing that when evolve(T, S ∪ L) = ∅, then evolve(trees(S) − {T }, S ∪ L) is also nonempty. For any choice of L such that evolve(T, S ∪ L) = ∅, let T ∗ ∈ evolve(T, S ∪ L). Consider any C ∈ evolvable(T, Alice). Since L only contains policies, the subtree rooted at C will not be reduced during the evolution of T . Thus C must be a node in T ∗ . Let TC be the subtree rooted at C in T ∗ . If C is also a leaf node in T , then let H = (C1 = R, C2 , . . . , Ck = C) be the path from the root to C in T . We do the following:
50
1. If TC does not contain any credentials in H except C, then we replace C by T C in T . 2. Otherwise, let Ci be the first credential in H that appears in T C . Let TC be the subtree of TC rooted at Ci . Then TC does not contain any credentials in (C 1 , . . . , Ci−1 ). We replace the subtree rooted at Ci in T by TCi . Since T covers T for Alice, we can apply the above operation on every evolvable leaf for Alice in T and will get a non-redundant disclosure tree T . For each edge in T , we can find the same edge either in T or in T ∗ . Thus we have T ∈ evolve(trees(S)−{T }, S ∪L), which means evolve(trees(S)−{T }, S ∪L) = ∅. Definition 4.17. Let T be a disclosure tree, and let S be a set of credentials. If the policy of every leaf node in T is satisfied by credentials in S, then we say T is satisfied by S. If after Alice sends a message, there is a tree T satisfied by credentials disclosed so far and that is evolvable for Bob in the current set of trees, then in his next message Bob can at least disclose those credentials that have been unlocked in T . Therefore, negotiation will not be terminated by Bob prematurely.
4.4.2 A Non-monotonic Strategy Family Based on our discussion of tree coverage and tree satisfaction, we propose a closed strategy family called NonMono for use with TrustBuilder Protocol 1. In general, every strategy in the family must send enough information so that every tree in the current set of trees is evolvable for the other party. However, there are several situations where a strategy can send less information, so that non-evolvable trees for the other party are allowed in the current set of trees. • First, if a tree T cannot evolve into a full tree according to the local policies, then the strategy does not need to make T evolvable in its next message. • Second, as suggested by lemma 4.2, T does not need to be made evolvable if it is covered by another tree. • Third, if T is evolvable for the other party and T is satisfied by the credentials disclosed so far, then the strategy does not need to make any other trees evolvable, as explained in the previous section. Formally, we have the following definition. 51
Definition 4.18. Suppose the two negotiating parties are Alice and Bob. Let S be the set of policies and credentials that have been disclosed so far, and assume R ∈ S. Let L A be the local policies of Alice, and let m be the most recent message, which is from Bob to Alice. Then NonMono is the set of all strategies s that work with TrustBuilder Protocol 1 and satisfy the following conditions: If ∅ ∈ s(S, LA , R), then 1) Either trees(S) = trees(S − m); or 2) For every evolvable tree T ∈ trees(S) for Alice, evolve(T, S ∪ L A ) = ∅. Otherwise, for each message m ∈ s(S, LA , R), 3) Either R ∈ m . Or 4) trees(S ∪ m ) = trees(S) and trees(S ∪ m ) contains a disclosure tree T such that T is satisfied by credentials disclosed in S ∪ m and T is evolvable for Bob. Or 5) trees(S ∪ m ) = trees(S) and for all T ∈ trees(S ∪ m ), • T is evolvable for Bob; or • evolve(T, S ∪ LA ) = ∅; or • There exists a set m of Alice’s local policies and unlocked credentials, such that for all T ∈ evolve(T, S ∪ m ∪ m ), there is a T ∈ trees(S ∪ m ) − {T }, such that T is covered by T for Bob. Let T be the current set of trees after Alice sends a message to Bob. Suppose T ∈ T is not evolvable for Bob. In general, leaving such a tree for Bob in T may cause a trust negotiation to fail prematurely. However, the last condition in Definition 4.18 says that there are additional disclosures that Alice could have made, such that T can be made into one or more evolvable trees T for Bob. If every such T is covered by some tree in T , then Alice can leave T unevolvable for Bob after sending her message. We will show that lemma 4.2 guarantees that, by doing so, Alice will not cause a negotiation to fail prematurely. In order to prove that the NonMono set of strategies is a closed family, it is helpful to identify the most cautious strategy in the set, which is called the NonMono strategy (NMS for short), whose pseudocode is shown in figure 4.8. 52
The NonMono strategy (NMS) Input: M = (m1 , . . . , mk ): a sequence of safe disclosure messages. L: the local resources and policies of this party. R: the resource to which access was originally requested. Output: A set of disclosure messages. Pre-condition: R has not been disclosed and mk = ∅. SM ← 1≤i≤k mi . If (trees(SM ) = trees(SM − m)) then return {∅}. If (for every T ∈ trees(SM ) that is evolvable locally, evolve(T, S M ∪ L) = ∅) then return {∅}. Let S be the set of all m such that m is a minimal set of policy and credential disclosures that satisfies one or more of the following: a) R ∈ m . Or b) trees(S ∪ m ) contains disclosure tree T such that T is satisfied by S ∪ m and is evolvable for the other party. Or c) ∀T ∈ trees(S ∪ m ), i) Either T is evolvable for the other party; or ii) evolve(T, SM ∪ L) = ∅; or iii) ∃m ⊆ L of policies and unlocked credentials, such that ∀T ∈ evolve(T, SM ∪ m ∪ m ) ∃ T ∈ trees(SM ∪ m ) − {T }, such that T covers T for the other party. Return S. Figure 4.8: Pseudocode for the NonMono strategy Theorem 4.9. The NonMono set of strategies is a family. Proof. Suppose Alice and Bob adopt strategies s 1 and s1 respectively, and s1 and s2 both belong to the NonMono set of strategies. We only need to prove that whenever the negotiation ends with a failure message, there is no safe disclosure sequence leading to the granting of access to resource R. When the negotiation ends with failure, without loss of generality, we assume it is Alice who sends the failure message. Suppose S is the set of all the credentials and policies disclosed so far and m is the last message Bob sends to Alice. Let Q = (m1 , . . . , mt = m) be the sequence of messages exchanged between the two parties. Let LA and LB be the local policies of Alice and Bob respectively. Since s 1 ∈ N onM ono, one of the following must be true: 53
1. trees(S − m) = trees(S). 2. For every tree T ∈ trees(S) that is evolvable for Alice, evolve(T, S ∪ L A ) = ∅. If condition (1) holds, since s 2 ∈ N onM ono, we must have that before Bob sends Alice message m, one of the above two conditions already holds. Otherwise, according to conditions 3), 4) and 5) in definition 4.18, since R ∈ m, we should have trees(S − m) = trees(S). Since at the beginning of the negotiation, condition (1) is not true, in some previous stage of the negotiation, condition (2) must have been true. When condition (2) holds, no evolvable tree for Alice in trees(S) has a chance to become a full disclosure tree. For those trees T ∈ trees(S) that Alice cannot evolve, the first possibility is that evolve(T, S ∪ LB ) = ∅, which means that T cannot become a full disclosure tree. The other possibility is that there is a set m of Bob’s unlocked resources and policies, such that every tree in evolve(T, S ∪ m ) is covered by a member of trees(S) − {T } for Alice. If T can evolve to become a full disclosure tree, then so can some T ∈ evolve(T, S ∪ m ). Consider any tree T ∈ trees(S) − {T } that covers T for Alice. T must not be evolvable for Alice, because we already know that none of Alice’s evolvable trees can become a full disclosure tree. If T is not evolvable for Alice, then T cannot cover any other tree for Alice (definition 4.16), a contradiction . We conclude that T cannot evolve to become a full disclosure tree. Since no member of trees(S) can evolve into a full disclosure tree, it is appropriate for Alice to send an empty message and terminate the negotiation, as there is no safe disclosure sequence culminating in the disclosure of R. The theorem holds. We call the family the NonMono family. Theorem 4.10. If a self-compatible strategy s is compatible with NMS, then s belongs to the NonMono family. Proof. By contradiction. Suppose s is compatible with NMS but does not belong to the NonMono family. Let s be adopted by Alice and NMS be adopted by Bob during the negotiation. Let m be the last message Bob sends to Alice. Since s is not in the NonMono family, we can find a choice of S, L A and R such that there exists m ∈ s(S, LA , R) satisfying all the following conditions, taken from definition 4.18. 1. trees(S) = trees(S − m), where m is the last message Bob send to Alice (if any). 54
2. There exists a tree T ∈ trees(S) that is evolvable for Alice such that evolve(T, S ∪ L A ) = ∅. 3. R ∈ m. 4. trees(S ∪ m) = trees(S) or (a) trees(S ∪ m ) contains no disclosure tree satisfied by credentials in S ∪ m that Bob can evolve. And (b) There is a tree T ∈ trees(S ∪ m ) such that i. T is not evolvable for Bob; and ii. T is non-covered, i.e., there is no set m ⊆ LA of policies and unlocked credentials such that ∀T ∈ evolve(T, S ∪ m ∪ m ), ∃T ∈ trees(S ∪ m ) − {T }, such that T covers T for Bob. Conditions 1, 2 and 3 are true because otherwise whatever Alice sends to Bob in the next message will not violate the definition of the NonMono family. Suppose trees(S ∪ m ) = trees(S). Let T be as in condition 2, let T ∈ evolve(T, S ∪ LA ) and let C be the set of leaf nodes of T . Obviously, every C ∈ C is a credential Alice wants from Bob whose policy has not been disclosed. It is possible that C ← true is the policy for every such C ∈ C. In this case, there should be a successful negotiation. However, since Bob adopts the NMS strategy and trees(S) = trees(S ∪ m ), Bob will terminate the negotiation after receiving m , causing the negotiation to fail, which contradicts the fact that s and the NMS strategy are compatible. If trees(S) = trees(S ∪ m ), let T be a non-covered tree in trees(S ∪ m ). Let m be a potential set of disclosures from Alice such that evolve(T, S ∪ m ∪ m ) contains an evolvable tree T . By condition 4(b)(ii), such a tree must exist, and T is not covered by any tree in trees(S ∪ m ) for Bob. Similarly to the proof of lemma 4.2, there exists a choice of Bob’s local policies and credentials, L B , such that evolve(trees(S ∪ m ) − {T }, S ∪ m ∪ LB ) = ∅ while evolve(T , S ∪ m ∪ m ∪ LB ) contains a full tree. Under such a choice of LB , upon receiving m , Bob will find that for every evolvable T ∈ trees(S ∪ m ), evolve(T, S ∪ mi ∪ LB ) = ∅. Since Bob adopts the NMS strategy, Bob will terminate the negotiation, though there does exist a safe disclosure sequence leading to the disclosure of R. This also contradicts the fact that s and NMS are compatible. 55
Bob’s policies
Alice’s policies
R ← A1 ∨ (A2 ∧ A3) B1 ← true B2 ← true B3 ← f alse
A1 ← B1 ∧ B2 A2 ← B1 A3 ← B3
S = {R ← A1 ∨ (A2 ∧ A3), A2 ← B1} R
R trees(S) :
A1
A2
T1
B1
A3
T2
Figure 4.9: An example to show that the NonMono family is not monotonic Corollary 4.3. The NonMono family is closed. Proof. Since s is compatible with every strategy in the NonMono strategy, it must be compatible with the NMS strategy. If s is also self-compatible, then according to theorem 4.10, s belongs to the NonMono family. Next we will show that the NonMono family is not monotonic. The key observation is that condition 5) in definition 4.18 relies on the coverage relationship between trees, and the coverage relationship does not always continue to hold if more information is disclosed. For example, in the scenario shown in figure 4.9, after receiving R’s policy, Alice checks her own policies and only discloses credential A2’s policy to Bob. This is a safe move because if Bob does not possess credential B1, then according to A1’s policy, tree T1 cannot evolve into a full tree either. In other words, there exists m = {A1 ← B1 ∧ B2} such that if m is also disclosed, then the resulting version of tree T 1 will be covered by T2 for Bob. However, if Alice chooses to disclose the policies of both A2 and A3, then the revised version of tree T 2 does not cover tree T1 any more. In this situation, after receiving {A2 ← B1, A3 ← B3}, Bob finds he does not possess B3, thus tree T2 cannot evolve into a full disclosure tree. On the other hand, T 1 does not have any evolvable leaf for Bob. According to the definition of the NonMono family, Bob may choose to terminate the negotiation, and the negotiation will fail even though success is possible (disclosure sequence (B 1 , B2 , A1 , R)). From this example, we have the following theorem. 56
Theorem 4.11. The NonMono family is not monotonic. It is easy to prove that if a family is generated by a self-compatible strategy, then that family must be monotonic. However, the result presented in this section shows that not all closed families are monotonic. In other words, unless a strategy family has been proved monotonic, it is not safe to assume that disclosing more information than necessary during a trust negotiation will not jeopardize the chance to establish trust. We expect that monotonic families will be preferred in real trust negotiation systems, because they allow users to easily customize their strategies by disclose more information when appropriate, without potentially compromising the success of a trust negotiation.
57
Chapter 5
Sensitive Policies and Credentials with Internal Structure The assumptions that policies do not contain sensitive information and that credentials can be modeled as propositional symbols make it easier to characterize the necessary properties of interoperable strategies. However, the simplifications usually do not hold in practice. In this chapter, we extend our discussion of interoperable strategies to models with more expressive power. Section 5.3 presents a detailed example that readers should refer to throughout this chapter. Realistic access control policies tend to contain sensitive information, because the details of Alice’s policy P for disclosure of credential C tend to give hints about C’s contents. For example, if there is any information in C that is so sensitive that Alice chooses to control its disclosure very tightly, then it is possible to guess at the nature of that information by looking at P : is her parole officer allowed to see C? Her welfare case worker? The local HIV, cancer, or mental health clinic? In a corporate setting, a web page accessible to all Microsoft employees plus the employees of a certain IBM department strongly suggests a secret project between the two companies. An Enron employees’ stock sale web page whose policy spelled out exactly who could sell stock and when might have raised many eyebrows. More generally, a company’s internal and external policies are part of its corporate assets, and it will not wish to indiscriminately broadcast its policies in their entirety. To protect sensitive policies, Seamons et al. [77] introduced the concept of policy graphs. The essential idea is that the policy for a resource can be disclosed gradually. Definition 5.1. A policy graph for a protected resource R is a finite directed acyclic graph with a single source node and a single sink node. The sink node represents the protected resource R. All the other nodes 58
P1 : y.type =“driver’s license”∧ y.age ≥ 25
R: Special Insurance Promotion
P0 : x.type = “student ID” ∧ x.status = “graduate student”
P2 : z.type =“transcript”∧ z.GP A ≥ 3.0
Figure 5.1: An example of policy graphs in the graph represent policies. If R is unprotected, then its policy graph has only one node representing R. Intuitively, a directed edge from node A to node B in a policy graph means that Alice must present credentials that satisfy the policy represented by node A before she can gain access to Bob’s resource represented by node B. Policy graphs are a generalization of the prerequisite/requisite rules introduced by Bonatti and Samarati [15], which can be considered as policy graphs with two levels. Policy graphs as defined here address many privacy problems associated with sensitive policies, but they are not a cure-all. Chapter 6 examines ways to more fully decouple disclosure and satisfaction of a policy. This allows, for example, Bob to gain access to a resource of Alice’s that is so sensitive that its policies are never disclosed. However, policy graphs are sufficient to address the issues raised by the examples given earlier, by, e.g., requiring Bob to present an employee ID from an unspecified company (IBM, Microsoft, the local health clinic, etc.) as an initial screening step. If Bob cannot present the “right” employee ID (as defined by a child node in the policy graph), in theory Bob never needs to see the policy node that Bob fails to satisfy (the check for a specific employer in the employee credential). For example, suppose a special insurance promotion is offered to graduate students whose age is over 25 or whose GPA is over 3.0. The access control policy graph may be as shown in figure 5.1. During a negotiation, if a requester cannot present a valid student ID proving she is a graduate student, then the insurance company can just terminate the negotiation and does not need to disclose further constraints (P1 and P2 ). If the insurance company regards the constraints on age and GPA as sensitive information, then, to some extent, policy P 0 in the source node helps to prevent the disclosure of P 1 and P2 to arbitrary strangers. As another example, suppose that Alice has had her driver’s license revoked for driving under the in59
Employee ID or Drivers License Employee ID issued by Dept. of Justice Drivers License belongs to Employee ID issued by one of my parents my insurance company Employee ID belongs to my parole officer true false my (revoked) driver’s license
Figure 5.2: Example policy graph fluence of alcohol. She may be very sensitive about the fact that she does not possess a driver’s license, which, in her home state of California, is abnormal for anyone over the age of 15 and strongly suggests that she has a seriously blemished driving record. She can define a policy subgraph G that describes who she trusts enough to disclose this fact to, then add a new sink to this subgraph, containing the policy “false” (see figure 5.2), meaning that no one will get to see her license. In the picture, the sink node represents the empty credential, a legal credential under our definition of a credential. Once enough trust has been established, Alice can disclose the policy “false”, which at that point is tantamount to admitting that she does not have a license. If G is the empty graph, Bob may interpret the policy “false” as meaning that Alice does not disclose her driver’s license to anyone. As the above example illustrates, policy graphs offer the possibility that Bob will make many disclosures and receive little or no reward from Alice, because the upper reaches of her policy graphs may contain policies he has no hope of satisfying. If we outlaw unsatisfiable policies, the same effect can be obtained by requiring obscure credentials. One way to address this issue is by allowing Bob’s policies to include a request for a credential from Alice that states that her set of policy graphs has been audited and received a seal of approval from one of a specified set of acceptable auditing firms. For example, Bob might require such credentials if he believes that he is a likely target of a denial of service attack. As another approach, Alice might also choose to disclose information about the depth or structure of her policy graphs. In the remainder of this chapter, we model a credential as a set of attribute-value pairs {C.a 1 = v1 , . . . , C.ak = vk }, where ai is an attribute name and vi is an atomic uninterpreted value for that attribute, 60
for 1 ≤ i ≤ k. C is a locally-assigned name for the credential, such as a random number. Credential names should not give away any information about credential contents, and may be changed between negotiations. As usual, we will assume that Alice can tell which credential names refer to her own credentials, and which refer to Bob’s, by renaming if necessary. Similarly, policies and other resources must have opaque local names so that Alice and Bob can discuss them. Each policy node is associated with the local name of the resource whose policy graph it belongs to. Therefore, in the rest of this chapter, when given a policy node P , we assume we can tell which resource it is related to. In this chapter we adopt a simple policy language in our examples. The semantics of the language is straightforward to readers with a basic background in mathematical logic. Essentially, the language allows conjunctions and disjunctions of restrictions on credential attribute values. Credentials are represented by variables, not by credential names. For example, Alice can require that Bob present a student ID issued by the University of Illinois showing that he is a full time student: x.issuer =“15697206” ∧ x.type =“Student ID” ∧ x.status = “Full Time” ∧ requesterAuthenticatesT o (x.owner) where 15697206 is the public key of the University of Illinois. (As mentioned in chapter 2, the handling of the requesterAuthenticatesT o predicate is assumed to be supported by lower-level software. We include it here for completeness.) Once we devise interoperable strategies for these kinds of credentials and policies, further extensions can allow, for example, credentials to have a more complex internal structure, or policies to have a different syntactic style (e.g., an XML-based language). For the examples of sensitive policies given earlier to work, we must have a means of referring to the same credential in different policy graph nodes. This allows a policy writer to gradually enforce sensitive constraints on credentials without showing all constraints to the other party at the beginning of the negotiation. Definition 5.2. Given a set C of credentials {C 1 , . . . , Cm } and a finite set P of policies with free variables x1 , . . . , xn , if there is an assignment from C to x 1 , . . . , xn that satisfies all members of P, then we say C is a solution for P and satisfies P. If no proper subset of C is a solution for P, then we say C is a minimal solution for P. As an example, consider the formula P : bef ore(x.date_of _birth,“12/31/1980”) ∧ y.state = “New 61
York” ∧ x = y. If the other negotiation participant presents two credentials C 1 = {C1 .type =“Drivers License”, C1 .date_of _birth = “10/12/1978”, C1 .number = “Y10001234”, . . . } and C2 = {C2 .type = “Student ID”, C2 .number = “z0010079”, C2 .state = “New York”, C2 .status = “Full Time”, . . . }, then C = {C1 , C2 } is a solution for P . Since no proper subset of C satisfies P , C is a minimal solution. Definition 5.3. Suppose G is the policy graph of a resource R. Let P be a node in G and P 0 → · · · → Pk = P be a path from the source node P0 to P . We call such a path a policy path to P . Let C be a set of credentials. If C satisfies P 0 ∧ · · · ∧ Pk−1 , then we say C satisfies that policy path and P is unlocked by C. As a special case, the source node in G is always unlocked. If P is a policy node and P 0 ∧ · · · ∧ Pk−1 ∧ P is satisfied by C, then we say P is context satisfied by C and C is a context solution for P . If no proper subset of C is a context solution for P , then C is a minimal context solution for P . Intuitively, a policy path to P indicates when P can be safely disclosed. If a policy is sensitive, we add more ancestors to P (thus more constraints) in G to control P ’s disclosure. The definition of context satisfaction implicitly forces the same free variable in policy nodes along a path to be bound to the same credential, enabling gradual enforcement of sensitive constraints. For example in section 5.3, one of the paths to gain access to Susan’s patientID is (policy 7) → (policy 8) → (policy 11). To context satisfy this path, x in policy 8 and policy 11 should be bound to the same credential. If Alice presents two employeeID credentials, one issued by Busey Hospital with job title “Adjunct Physician” and the other issued by Carle Clinic with job title “Staff Physician”, then she does not context satisfy the above path and should not gain access to the client’s patientID credential. Definition 5.3 extends the definition of an unlocked resource in section 2.3 so that our concept of safe disclosures still holds: during a negotiation, a resource (a credential or a policy) cannot be disclosed unless it is unlocked by credentials disclosed by the other party. Definition 5.4. Let G be the policy graph of a resource R and let C be a set of credentials. The traversal realized by C, written traversal(G, C), is a subgraph of G that satisfies the following conditions: 1. The subgraph contains all the nodes in G that are unlocked by C. 2. If P1 → P2 is an edge in G and P1 is context satisfied by C (thus P 2 is unlocked), then P1 → P2 is an edge in the subgraph. 62
We use traversals to represent the part of a policy graph that has been unlocked so far during a trust negotiation. When credentials have internal structure and no externally obvious key, when Alice receives Bob’s disclosed policy P for a credential C, she cannot tell what information P is protecting: the name “C” is now opaque. Theoretically, C can be bound to any credential-valued variable in any of Alice’s local policies. In the absence of hints from Bob about which variable C should be bound to, Alice will have to consider C to be relevant to every one of her unsatisfied local policies. She will not be able to focus her trust negotiation efforts on Bob’s truly relevant credentials and policies, and trust negotiation will become prohibitively expensive in the general case. To address this problem, we introduce the concept of a binding. When Bob discloses C’s policy P , we require him also to disclose what C is relevant to — to bind C. There are many possible forms that this binding could take. For example, if some or even all of the attribute values in the credential are not sensitive, then Bob can disclose them. The most natural attribute to disclose would usually be the credential type, e.g., C.type = “Drivers License”. With the credential type and/or additional attribute values in hand, in practice, Alice will be able to tell which policy C may satisfy. If Bob does not want to disclose any of C’s contents, he could identify a particular variable x in Alice’s policies as a binding for C. This is not tantamount to revealing that C’s contents satisfy all the constraints on x: Bob may know already that C does not satisfy the constraints on x, or that Alice cannot possibly satisfy his policy for gaining access to C (if indeed he possesses C). However, he may not yet trust Alice enough to reveal anything about C’s contents, or the fact that he does not possess C. The use of such approaches to preserve privacy is a focus of chapter 8, and we do not discuss it further in this chapter. If Bob finds it too revealing to bind C to a particular variable x, he can instead bind C to one or more of Alice’s policies — those policies that C’s disclosure may help to satisfy. If Bob divulges every such binding of C, then Alice can focus her trust negotiation on potentially relevant policies and credentials, reducing its cost. If Bob discloses some bindings that are not actually relevant, either to preserve his privacy or because he is using an unintelligent strategy, then we would like trust negotiation’s final outcome to be unaffected, although it may take Alice and Bob longer to reach that final outcome. In this chapter, when Bob discloses P , he must disclose a binding of C to one or more of Alice’s policies. Bob can disclose bindings of C to additional policies as the negotiation proceeds. 63
Unfortunately, this approach to bindings breaks many of the subtle knowledge assumptions that allowed DTS family strategies to interoperate. Alice no longer has such a clear picture of what Bob’s disclosure trees (if he cared to materialize them) would look like. Although the remainder of this chapter superficially looks like a replay of the definitions and theorems of chapter 4, in fact it reworks the entire underpinnings of strategy interoperation, because of the decrease in what Alice can deduce about what Bob knows.
5.1 The TrustBuilder Protocol 2 for Sensitive Policies and Structured Credentials The introduction of policy graphs and structured credentials adds much complexity to automated trust negotiation. In our exploration of strategy families for structured credentials, we have not found a family that satisfies all the desiderata outlined in chapter 4. In the rest of this chapter, we present a family that requires a more complex protocol than TrustBuilder Protocol 1, but does meet the other desiderata. Protocol 2 retains the structure of Protocol 1, but adds several new message types, as explained in this section. Further, the family we present requires complete disclosure of the unlocked portion of policy graphs that are considered relevant to the negotiation. This lessens the degree of protection that policy graphs provide for sensitive policies. Definition 5.5. Let G be the policy graph of a resource R and let C be the set of credentials disclosed so far. A policy graph disclosure (or traversal disclosure) takes the form (R, traversal(G, C)). At the beginning of a negotiation, since no credentials have been disclosed, the traversal only contains the source node in the resource’s policy graph. Later on, as more credentials are disclosed and more policy nodes are unlocked, traversal disclosures will cover more of a policy graph. In practice, only the new information in a traversal needs to be disclosed. However, to simplify our presentation, we assume each policy graph disclosure contains the complete current traversal of that graph. Definition 5.6. Let G be the policy graph of a resource R and let C be the set of disclosed credentials. Let C be a set of credentials such that traversal(G, C) is a proper subgraph of traversal(G, C ∪ C ). Then we say C extends traversal(G, C) (or C is an extension to traversal(G, C)). If no proper subset of C has this property, then we say C is a minimal extension to traversal(G, C). An extension disclosure for 64
traversal(G, C) takes the form extension(C , R, traversal(G, C)). Of course, extension disclosures list credential local IDs, not actual credential contents. Intuitively, if C is a minimal extension to traversal(G, C), then C is a minimal set of credentials that will reveal new structural information about R’s policy graph. Extensions formalize the concept of bindings discussed earlier. During the negotiation, Alice’s policy compliance checker may be invoked several times to get different extensions to the same traversal G. When there are no more new extensions (or there is no extension at all) to G, Alice will send a special extension disclosure in the form no_more_extensions(R, G). In summary, the following disclosures are allowed in TrustBuilder Protocol 2. 1. Policy graph disclosures, (R, traversal(G, C)). 2. Extension disclosures, extension({C1 , . . . , Ck }, R, traversal(G, C)) and no_more_extensions(R, traversal(G, C)). 3. Credential disclosures. A message in TrustBuilder Protocol 2 is a set {R 1 , . . . , Rk }, where each Ri is one of the above disclosures. As before, the empty message indicates that the negotiation has failed. The pseudocode for TrustBuilder Protocol 2 is the same as that for TrustBuilder Protocol 1 (figure 4.1). The difference between the two protocols resides in the types of information contained in messages, and in TrustBuilder Protocol 2’s requirements for the negotiation strategies used with it to enforce the following conditions throughout negotiations: 1. All credential disclosures must be safe. More precisely, a credential can be disclosed only after it is unlocked. 2. All policy graph disclosures must be safe and complete. More precisely, when (R, G) is disclosed, G must be the traversal of resource R’s policy graph realized by the set of credentials disclosed so far. 3. The same disclosure cannot be sent more than once. 4. If no_more_extensions(C, G) is disclosed in a message, then no extension disclosure extension(C, C, G) can be sent in subsequent messages, as there should be no more extensions to traversal G. This is required by the semantics of no_more_extensions disclosures. 65
5. If a traversal disclosure (R, G ) is disclosed in a message, then no traversal disclosure (R, G ) such that G is a proper subgraph of G can be disclosed in subsequent messages. Our definition of policy graph disclosures is not the only possible way to disclose edges of a policy graph G. We mentioned earlier that traversals can be disclosed incrementally, a practical twist that has no effect on the underlying theory. Disclosing entire traversals rather than allowing Alice to disclose a subgraph of a traversal does have a significant impact on the theory, because Alice knows that she knows everything that Bob knows about part of G: no detail has been omitted, even if Alice has already satisfied that detail by her previous disclosures. This completeness allows Alice to reuse her knowledge of G in different contexts that may arise later in the negotiation. Further, if she cannot find a solution for any path through Bob’s disclosed subgraph, Alice knows that she will never get access to the resource G protects, and she can focus her efforts elsewhere. As discussed earlier, this power comes at a price: Bob must disclose policy graph details that he might prefer to keep private. On the other hand, if we do not require complete traversal disclosure, we obtain some nice privacy guarantees, but the resulting family of interoperable strategies excludes many strategies that are attractive from an implementation perspective but are not intelligent enough to meet certain increased reasoning requirements that flow from this seemingly small change in the definition of a policy graph disclosure. In the remainder of the chapter, we examine interoperability among strategies that follow TrustBuilder Protocol 2 and enforce the above conditions. Similar to our discussion in section 4.2, we will introduce a new concept, called binding trees, to describe the progress of a trust negotiation, and based on it we will define a strategy family.
5.2 Binding Trees and the Binding Tree Strategy Family Binding trees are a generalization of disclosure trees to support structured credentials and policy graphs.
5.2.1 Binding Trees Definition 5.7. A binding tree is a finite tree T satisfying the following conditions: 1. Each non-root node represents a credential, a service, a traversal of a policy graph, or else is a special node called a more_extensions node. 66
2. The root represents the resource (“service”) to which access was originally requested. 3. Each credential/service node C has at most one child. The child, if present, must be a traversal node that represents a traversal of C’s policy graph. 4. If a traversal node has children, they can either be credential nodes or a single more_extensions node. 5. If a traversal node’s children are credential nodes, then they represent an extension to the traversal. 6. A more_extensions node has no children. A credential node is redundant if in the path from the root to this node, there is another credential node representing the same credential. A binding tree is redundant if it has a redundant credential node. Binding trees have several major differences from disclosure trees. Because we support policy graphs, a credential will often be associated with more than one traversal during a trust negotiation. Therefore, we need traversal nodes to distinguish different traversals. Second, we let credential nodes be children of traversal nodes, which is quite natural considering our definition of extension disclosures. Finally, a special “more_extensions” node is used because extensions to a traversal may not be disclosed all at once. We use a more_extensions node to indicate whether Alice has received all of Bob’s extensions to a traversal. Next we will show how to use binding trees to describe the progress of a trust negotiation. Definition 5.8. Given a binding tree T and a set C of credential disclosures, the reduction of T by C, written reduce(T, C), is the binding tree T obtained by removing all the subtrees rooted at nodes that represent credentials in C or traversals that C extends. Given a set T of binding trees, the reduction of T , written reduce(T , C), is the set {reduce(T, C) | T ∈ T }. An example of binding tree reduction is shown in figure 5.3(a). As we mentioned earlier, during a trust negotiation, there may be several traversals for the same credential, corresponding to different stages of the negotiation. According to the definition of a traversal, a traversal disclosed earlier is always a subgraph of the ones disclosed later. Therefore, given a set of traversals of a credential, it is easy to identify the one disclosed most recently. In the rest of the chapter, unless otherwise noted, when we refer to a credential’s traversal, we always mean its most recent one disclosed so far during a negotiation. 67
R
R
R
R GR
R GR
C2
C1 C2
C1 GC1
reduce(T, C)
GR
C2 more_extensions
C2 S1
C = {C1 , S1 , S2 , S3 }
a
binding
S2
S1 S3 S4
P = {(R, GR ), extension({C1 , C2 }, R, GR ), (C1 , GC1 ),
S1 S2 S3
of
C1
GR
GC1
GC1
GC2
(a) Example reduce(T, C)
GR
extension({S1 , S2 }, C1 , GC1 ),
tree
reduction:
extension({S1 , S3 , S4 }, C1 , GC1 ), no_more_extensions(C1 , GC1 )}
(b) Example of a binding tree expansion: expand(P)
Figure 5.3: Examples of operations on binding trees Definition 5.9. Given a set P of extension disclosures and policy graph disclosures, the expansion of P, written expand(P), is the set of all binding trees such that each binding tree T in the set satisfies the following conditions: 1. The child of a credential/service node C represents the most recent traversal of C that appears in P. 2. For every traversal node G in T whose parent is a node C, if the children of G are C 1 , . . . , Ct , then extension({C1 , . . . , Ct }, C, G) ∈ P. 3. For every traversal node G in T , if its child is a more_extensions node, then no_more_extensions(C, G) ∈ P. 4. If a leaf node is a credential/service node C, then either P does not contain any traversal disclosure for C, or C is a redundant node. 5. If a traversal node G has no child, then no_more_extensions(C, G) is the only extension disclosure for G in P. An example of binding tree expansion is shown in figure 5.3(b). Lemma 5.1. Let C contain all the credentials disclosed so far during a negotiation and let R be a sensitive local resource whose policy graph is G. Let P 0 → · · · → Pk → R be a policy path to R. If the remote 68
party possesses credentials that can satisfy the policy path, then there exists an i, 0 ≤ i ≤ k, such that P0 → · · · → Pi is a path in traversal(G, C) and Pi is a sink node in traversal(G, C). Proof. According to the definition of traversal, the source node P 0 of G belongs to traversal(G, C). Let Pi be the first node in the path such that P 0 → · · · → Pi is in traversal(G, C) but Pi → Pi+1 is not. Then Pi must be a sink node in traversal(G, C). Otherwise, Pi should be context satisfied by C, which means P i+1 is unlocked. Therefore, the edge Pi → Pi+1 is in traversal(G, C), a contradiction. Corollary 5.1. Let C contain all the credentials disclosed so far during a negotiation and let R be a local resource with policy graph G. If the remote party does not possess any extension to traversal(G, C), then there is no safe credential disclosure sequence that leads to the granting of access to R. Proof. If the remote party can gain access to R, then there is a policy path P 0 → · · · → Pk → R such that the remote party possesses a set of credentials C satisfying P0 ∧ · · · ∧ Pk . According to lemma 5.1, there is a Pi such that P0 → · · · → Pi is in traversal(G, C) and Pi is a sink node. Since C also satisfies P0 ∧ · · · ∧ Pi , C is an extension to traversal(G, C), which leads to a contradiction. Suppose M is the sequence of messages exchanged between Alice and Bob so far during a negotiation. If no_more_extensions(C, G) is the only extension disclosure for G that Alice sends to Bob, then, by corollary 5.1, Bob knows that Alice cannot gain access to his credential C. Thus, he may consider that message to be Alice’s refusal of access to C. In the remainder of the chapter, we will say a credential C is refused when no_more_extensions(C, G) is the only extension disclosure for G in M. A refusal of a credential is sent by the party who requested that credential, in contrast to a propositional denial disclosure. Definition 5.10. Given a set T of binding trees and a set R of refused credentials, the refusal pruning of T , written ref use(T , R), is the set {T | T ∈ T and T does not contain credentials in R}. Definition 5.11. Given a set T of binding trees, the redundancy pruning of T , written redundant(T ), is the set {T | T ∈ T and T is not redundant}.
69
Since the pruning operations are the same as those for disclosure trees, we do not show examples in this section. Definition 5.12. Let S be the union of a set P of policy graph disclosures and extension disclosures, a set C of credential disclosures and a set R of refused credentials. The set of binding trees corresponding to S, written trees(S), is redundant(ref use(reduce(expand(P), C), R)). Lemma 5.2. Let S contain all the disclosures made by the two negotiation participants at a certain stage of a negotiation. If there is a safe credential disclosure sequence that leads to the granting of access to resource R, then either R is disclosed in S or trees(S) = ∅. Proof. First, R is not refused in S. Otherwise, by corollary 5.1, there should be no safe disclosure sequence leading to the granting of access to R. Suppose the safe disclosure sequence is (C 1 , . . . , Ck , R). Without loss of generality, we assume (C1 , . . . , Ck , R) is non-redundant. We will prove the lemma by induction on k. When k = 0, R is unprotected. If R is not disclosed in S, then trees(S) should contain a binding tree with only the root node R. The lemma holds. Assume when k < n, 1 ≤ n, the lemma holds. When k = n, consider the non-trivial case where R is not disclosed in S and those credentials disclosed in S do not extend R’s latest traversal. Let R’s latest traversal be GR . If no_more_extensions(R, GR ) ∈ S, then trees(S) contains a tree T , where the root has a traversal node GR whose only child is a more_extensions node. If no_more_extensions(R, G R ) ∈ S, then S contains all the extensions to G R . By lemma 5.1, there exists a set C ⊆ {C1 , . . . , Ck } which is a minimal extension to GR . Since GR is not extended by credentials in S, there exist credentials in C that are not disclosed in S. Let C ⊆ C contain all such credentials. For all C ∈ C , (C1 , . . . , Ci = C) is a safe disclosure sequence and i < k. By the induction hypothesis, we can have a binding tree whose root represents C. By attaching all such trees to the traversal node G R , we get a binding tree T for R and T ∈ trees(S). If the policy graphs of Alice and Bob allow a successful negotiation, then there is always a non-redundant safe disclosure sequence leading to the granting of access to R. Therefore, by lemma 5.2, we have the following corollary immediately. 70
Corollary 5.2. If there exists a sequence of messages (m 1 , . . . , mk ) exchanged between two parties such that for all mi , 1 ≤ i ≤ k, R ∈ mi and trees( 1≤i≤k mi ) = ∅, then there is no safe disclosure sequence that leads to the granting of access to R. The set of trees of an ongoing negotiation represents all the latest disclosures as well as the connections between them. By examining the binding trees associated with a negotiation, we can determine which traversals and credentials are relevant to a negotiation. For example, let C be Alice’s credential and let G be C’s latest traversal. Suppose that G is also a traversal node of a binding tree T associated with the negotiation. If G has a more_extensions node as its child, then Alice knows she may expect Bob to disclose more extensions to G later (or else disclose no_more_extensions(C, G)). Similarly, if C is a leaf node in T , then Bob will expect Alice to disclose the latest traversal of C’s policy graph. Though we have extended the TrustBuilder protocol and introduced new concepts to accommodate structured credentials and policy graphs, our definitions for a strategy, strategy family and a generator are unchanged from those in chapter 4.
5.2.2 The Binding Tree Strategy Consider the example shown in figure 5.4. Suppose R is Bob’s only resource. Further, suppose {C 1 , C2 } is an extension to R’s traversal G R . If Alice only sends extension({C1 , C2 }, R, GR ) to Bob, then, according to TrustBuilder Protocol 2, Bob has no further disclosures to make. This example shows that whenever Alice sends a message to Bob, Alice must ensure that Bob can respond with a non-failure message, unless failure is inevitable. We call this a continuity requirement. If Alice and Bob both materialize all the binding trees, then the continuity requirement can be met easily, and we can also guarantee that every disclosure a strategy makes is relevant to the current negotiation. However, it may take exponential time and space to materialize the current set of binding trees, so materialization is impractical. Fortunately, there are other ways to meet the continuity requirement. For example, suppose Alice discloses a policy graph’s latest traversal G. Then in the next message, Bob can disclose an extension to G or refuse access to the credential that G protects. Similarly, if Alice discloses credentials that satisfy the traversal of the policy graph of one of Bob’s credentials, then the negotiation will proceed because Bob can at least disclose that credential’s policy graph’s new traversal, or the credential itself if it is now unlocked. Formally, we have the following definition. 71
R
R
trees(S) :
GR
GR
C1
C2
more_extensions
S = {(R, GR ), extension({C1 , C2 }, R, GR )}
Figure 5.4: The set of binding trees corresponding to S Definition 5.13. Given a set S of disclosures, we say Alice can expand S, if one of the following conditions holds. 1. Alice has a credential C such that • C appears in an extension disclosure in S and there is no traversal disclosure of C’s policy graph in S; or, • Credentials disclosed in S extend C’s latest traversal in S. 2. Bob has a credential C such that • A traversal disclosure of C’s policy graph is in S; and • The credentials disclosed in S do not extend the latest traversal G of C’s policy graph in S; and • no_more_extensions(C, G) is not in S. Note that Bob can easily check whether Alice can expand S without materializing binding trees. Lemma 5.3. Let S be a set of disclosures that Alice can expand, and let S be a set of disclosures that Bob could make. Then Alice can expand S ∪ S . Proof. No matter what Bob discloses in S , the two conditions in definition 5.13 will still hold for S ∪ S if they hold for S. Therefore, Alice can expand S ∪ S . Definition 5.14. Suppose Alice and Bob are the two negotiating parties. Let M = (m 1 , . . . , mk ) be a sequence of messages such that m i = ∅ and R ∈ mi for 1 ≤ i ≤ k. Let LA and LB be the local credentials, services and policy graphs of Alice and Bob respectively. Let S M = 1≤i≤k mi . Without loss of generality, 72
assume it is Alice’s turn to send the next message to Bob. The binding tree strategy (BTS) is a strategy such that BT S(M, LA , R) satisfies the following conditions: 1. BT S(M, LA , R) = {∅} if and only if one of the following conditions holds: • trees(SM ) = ∅. • There exists a set S of safe disclosures that Alice can make such that trees(S M ∪ S ) = ∅. • Alice cannot expand SM . 2. Otherwise, BT S(M, LA , R) contains all the messages m such that one of the following conditions holds: • m = {R}, if Alice possesses R and R is unlocked by credentials disclosed in S M ; • m is a minimal non-empty set of disclosures such that S M ∩ m = ∅ and Bob can expand SM ∪ m . Is it possible that Alice cannot find a non-empty set m of disclosures such that Bob can expand S ∪ m ? The following lemma answers the question. Lemma 5.4. Let S be the set of all disclosures made so far during a trust negotiation, and suppose Alice can expand S. Suppose it is Alice’s turn to send the next message. Let S be the set of all the safe disclosures Alice can make in the next message. Then if trees(S ∪ S ) = ∅, Bob can expand S ∪ S . Proof. Since Alice can expand S, S = ∅. Let T ∈ trees(S ∪ S ). According to definition 5.12, T is not redundant and T does not contain nodes representing credentials refused in S ∪ S . Consider a leaf node of T . We have: 1. The leaf node cannot represent a traversal G whose parent represents C, one of Bob’s credentials. Otherwise, since T ∈ trees(S ∪ S ), C is not refused in S ∪ S . Therefore, S ∪ S should contain all of Alice’s extensions to G, which means G cannot be a leaf node. 2. The leaf node cannot represent a credential C of Alice’s. Otherwise, since C is a leaf node of T , C is not unlocked by credentials disclosed in S. Therefore, S ∪ S should contain C’s latest traversal, which means C should not be a leaf node. 73
3. If the leaf node is a more_extensions node, then its parent cannot represent a traversal G of a credential C of Bob’s. This is because S ∪ S contains all of Alice’s extensions to G (including no_more_extensions(C, G)). Therefore G should not have a more_extensions node as its child in T . Therefore, the leaf node can only represent a credential of Bob’s, or a more_extensions node whose parent represents a traversal of one of Alice’s credentials. According to definition 5.13, in either case, Bob can expand S ∪ S . Lemma 5.4 tells us that if BT S(M, LA , R) = {∅}, then there always exists a non-empty minimal set m of disclosures of Alice such that S ∩ m = ∅ and Bob can expand S ∪ m . Theorem 5.1. The set of strategies generated by BTS is a family. Proof. Suppose Alice and Bob adopt strategies s 1 and s2 , respectively, from the set of strategies generated by BTS. We only need to prove that when the negotiation fails, there is no safe disclosure sequence leading to the granting of access to the originally requested resource R. When the negotiation fails, without loss of generality, we assume it is Alice that sends the failure message. Suppose that before Alice sends the failure message, M = (m 1 , . . . , mk ) is the sequence of exchanged messages. Therefore mk is the last message that Bob sends to Alice. Let L A and LB be the local credentials, services, and policy graphs of Alice and Bob respectively, and let S M = 1≤i≤k mi . Since ∅ ∈ s1 (M, LA , R) and s1 BT S, we must have BT S(M, LA , R) = {∅}. According to definition 5.14, one of the following conditions holds: 1. trees(SM ) = ∅. 2. There exists a set S of safe disclosures of Alice such that trees(S M ∪ S ) = ∅. 3. Alice cannot expand SM . When condition 3) holds but not 1) and 2), we must have BT S((m 1 , . . . , mk−1 ), LB , R) = {∅}. Otherwise, since s2 BT S and R ∈ mk , mk must be a superset of a minimal set m of disclosures such that Alice can expand (SM − mk ) ∪ m . According to lemma 5.3, Alice can expand S = ((SM − mk ) ∪ m ) ∪ (mk − m ), which contradicts the assumption that condition 3) holds. Since BT S((m 1 , . . . , mk−1 ), LB , R) = {∅}, 74
before Bob sent mk , one of the above conditions was true. At the beginning of the negotiation, condition 3) was not true (when a client sends a request to access resource R, the server can expand the empty disclosure sequence), we know that in some previous stage of the negotiation, condition 1) or 2) must have been true. When condition 1) or 2) holds, according to corollary 5.2, there is no safe disclosure sequence leading to the granting of access to R. Theorem 5.2. If a strategy s and BTS are compatible, then s BT S. Proof. Suppose Alice is using s and LA contains her local credentials, services and policy graphs. We will prove the theorem by contradiction. Assume s BT S. Then there exists a sequence of messages M = (m 1 , . . . , mk ) such that ∃m ∈ s(M, LA , R) such that ∀m ∈ BT S(M, LA , R), m ⊆ m . Let SM =
1≤i≤k
mi . Then all of the following must be true.
1. trees(SM ) = ∅. 2. trees(SM ∪ S ) = ∅, where S contains all the safe disclosures Alice can make in the next message. 3. Alice can expand SM . Otherwise, according to definition 5.14, ∅ ∈ BT S(M, LA , R) and ∅ ⊆ m , which leads to a contradiction. Also we have R ∈ m . Otherwise, R is unlocked by credentials disclosed in S M , which means {R} ∈ BT S(M, LA , R) and {R} ⊆ m . Since every m ∈ BT S(M, LA , R) is a non-empty minimal set of disclosures such that Bob can expand SM ∪ m, Bob cannot expand SM ∪ m . Thus, after sending m , Bob’s strategy BTS will send a failure message and end the negotiation. However, consider a binding tree T ∈ trees(SM ∪ S ). By the proof of theorem 5.1, every leaf node in T either represents one of Bob’s credentials or a more_extensions node whose parent is the latest traversal of one of Alice’s credentials. By induction on the height of T , we will prove that there is a choice of Bob’s undisclosed local credentials and policy graphs such that there is a safe disclosure sequence that leads to the granting of access to R. If we are successful in proving our claim, then that means there should be a
75
successful negotiation between the two parties. Thus if Alice terminates the negotiation as a failure, this contradicts the fact that s and BT S are compatible. We use height(T ) to denote the height of T , ignoring more_extensions nodes. When height(T ) = 1, T only contains the root node R. Thus R is owned by Bob. Let G R be R’s latest traversal disclosed in S. We can choose R’s policy graph to have an edge from every sink node in G R to R. Therefore, if the disclosures in S M ∪S are made, R can be unlocked, which means that there is a successful negotiation. When |T | = 2, besides a possible more_extensions node, T will only contain the root node R and its latest traversal GR . In this case, R is owned by Alice. Since R’s policy graph is not disclosed and R is not refused by Bob in SM , according to our assumption about a strategy’s reasoning ability (i.e., if a policy (or traversal) is not explicitly refused by Bob, Alice cannot infer whether Bob can satisfy that policy), we can choose for Bob to have a set C of unprotected credentials such that C ∩ S M = ∅ and credentials in C ∪ SM context satisfy R. Assume when |T | < n, n ≥ 2, our claim holds. When |T | = n, consider a child node C of R’s traversal node G R in T . The height of the subtree rooted at C is smaller than n. By the induction hypothesis, we can choose Bob’s local credentials and policy graphs such that C can be unlocked. If Bob possesses R, similarly to the case when height(T ) = 1, we can choose R’s policy graph such that there is an edge from every sink node in G R to R. Thus when credentials represented by the children node of GR are disclosed, R is unlocked. If Alice possesses R, let the children of G R be {C1 , . . . , Ck }. Similarly to the case when height(T ) = 2, according to our assumption about a strategy’s reasoning ability, we can choose for Bob to have a set C of unprotected credentials such that C ∩ (S M ∪ {C1 , . . . , Ck }) = ∅ and C ∪ SM ∪ {C1 , . . . , Ck } context satisfies R. We call the family generated by BTS the BTS family. Corollary 5.3. The BTS family is closed. Theorem 5.3. Let s1 and s2 be strategies in the BTS family and let s be a hybrid of s1 and s2 . Then s is also in the BTS family. 76
Proof. The proof is exactly the same as that for theorem 4.6. As mentioned earlier, when we designed TrustBuilder Protocol 2, one of the major desiderata was that some strategy family following the protocol should contain efficient strategies that are easy to implement in practice. Now we will present two such members of the BTS family. As required by the TrustBuilder protocol 2, both strategies take parameters M = (m 1 , . . . , mk ), a sequence of messages; L, the set of all local resources and policy graphs; and R, the resource to which the client originally requested access. The output is a set containing a single message. The first strategy is TrustBuilder2-Simple, which makes no effort to identify which disclosures are relevant. When it sends a message, it simply tries to make sure the other party can expand the resulting message sequence. It will terminate the negotiation only if it fails to find such a message. The pseudocode for the TrustBuilder2-Simple strategy is shown in figure 5.5. We can update the definition of syntactic relevance as follows: 1. R is syntactically relevant to R. 2. A traversal of a syntactically relevant resource is syntactically relevant to R. 3. A credential that appears in an extension to a syntactically relevant traversal is syntactically relevant to R. The second efficient strategy, the TrustBuilder2-Relevant strategy, only makes disclosures that are syntactically relevant to R whenever possible. The pseudocode for the TrustBuilder2-Relevant strategy is shown in figure 5.6. An example of the two strategies interacting is given in section 5.3. Note that in order to be compatible with unintelligent strategies in the BTS family, such as TrustBuilder2Simple, TrustBuilder2-Relevant will invoke TrustBuilder2-Simple when it cannot find any syntactically relevant disclosures. Further, in order to minimize information disclosure, TrustBuilder2-Relevant will only choose a minimal non-empty subset m of what TrustBuilder2-Simple suggests as its next message, as long as the other party can further proceed after m is disclosed. Theorem 5.4. Both TrustBuilder2-Simple and TrustBuilder2-Relevant belong to the BTS family. Proof. By theorem 5.2, we only need to prove that the two strategies are compatible with BTS. 77
The TrustBuilder2-Simple Strategy Input: M = (m1 , . . . , mk ): a sequence of safe disclosure messages. L: the local resources and policies of this party. R: the resource to which access was originally requested. Output: A set containing a single disclosure message m. Pre-condition: R has not been disclosed and mk = ∅. SM ← 1≤i≤k mi . Let C contain all the credentials disclosed in S M . m ← ∅. For every local credential C that is unlocked by S M m ← m ∪ {C}. For every local locked credential C Let C’s policy graph be GC . if ((C, traversal(GC , C)) ∈ SM ) then m ← m ∪ {(C, traversal(C, C))}. For every most recent traversal G for a credential C in SM that was disclosed by the other party and such that no_more_extensions(C , G ) ∈ SM Find an extension C to G such that for all C ⊆ C , extension(C , C , G ) ∈ SM . if (there is no such C ) then m = m ∪ {no_more_extensions(C , G )}. else m ← m ∪ {extension(C , C , G )}. m ← m − SM . if (the other party cannot expand m ∪ S M ) then return {∅}. else return {m}. Figure 5.5: Pseudocode for the TrustBuilder2-Simple strategy
Suppose Alice and Bob are using TrustBuilder2-Simple and BTS respectively. When the negotiation fails, let M = (m1 , . . . , mk ) be the message exchange sequence before the failure message is sent and let SM = 1≤i≤k mi . If Alice sends the failure message, according to the pseudocode for TrustBuilder2Simple, Alice cannot find a set m of disclosures such that m ∩ S M = ∅ and Bob can expand SM ∪ m. According to lemma 5.4, there is no safe disclosure sequence leading to the granting of access to R. On the other hand, if Bob sends the failure message, then m k is sent by Alice. Thus Bob can expand SM . According to definition 5.14, we have either trees(SM ) = ∅ or trees(SM ∪ S ) = ∅, where S contains all the disclosures that Bob can make in the next message. By corollary 5.2, there is no safe disclosure sequence
78
The TrustBuilder2-Relevant Strategy Input: M = (m1 , . . . , mk ): a sequence of safe disclosure messages. L: the local resources and policies of this party. R: the resource to which access was originally requested. Output: A set containing a single disclosure message m. Pre-condition: R has not been disclosed and mk = ∅. SM ← 1≤i≤k mi . Let C contain all the credentials disclosed in S M . m ← ∅. For every most recent traversal G for a credential C in SM that was disclosed by the other party and such that no_more_extensions(C , G ) ∈ SM if (C is relevant to R) then Find an extension binding C for G such that for all C ⊆ C , extension(C , C , G ) ∈ SM . if (there is no such C ) then m ← m ∪ {no_more_extensions(C , G )}. else m ← m ∪ {extension(C , C , G )}. For every local credential C syntactically relevant to R Let GC be C’s policy graph. if (C is unlocked by SM ) then m ← m ∪ {C}. else if ((C, traversal(GC , C)) ∈ SM ) then m ← m ∪ {(C, traversal(GC , C))}. m ← m − SM . if (m = ∅) then // the other party might be very unintelligent m ← TrustBuilder2-Simple(M ,L,R). if (m = ∅) then let m be a minimal non-empty subset of m such that the other party can expand m ∪ SM . return {m}.
Figure 5.6: Pseudocode for the TrustBuilder2-Relevant strategy leading to the granting of access to R. Since TrustBuilder2-Simple should be invoked before TrustBuilder2-Relevant sends a failure message, the argument above is also true for TrustBuilder-Relevant. In summary, both strategies are compatible with BTS.
79
5.3 Example Trust Negotiation with Structured Credentials and Policy Graphs In this section, we present an example trust negotiation that involves realistic access control policies and concerns about sensitive policies. Readers may skip this section if desired. This example involves a request to view Susan Jones’s psychiatric record at Busey Hospital. Busey Hospital’s policy graph for that record has multiple levels of nodes. The first important level says that the requester must be a physician at Busey Hospital, or else be the patient. The second important level says that the only doctor who can view the record is Jane Smith. The use of two levels ensures that only the patient and Busey physicians can find out which physicians can see Susan’s record. The hospital also has an institutional ID that it is willing to show to anyone. The requester has two credentials of interest. She is a patient at Busey Hospital, and she also works there. She will show her employee ID only to Busey Hospital. Her first important level of policies for her patient ID says that it can only be shown to people who work at Busey Hospital, Blue Cross Blue Shield of Illinois, or to Busey Hospital itself. Her second important level of policies adds the restriction that the Busey Hospital employees must be staff physicians, staff nurses, or customer service representatives in the delinquent accounts department. Figure 5.7 summarizes the structure of the relevant policy graphs, and the exact policy contents are given below. This example fits well into directed acyclic policy graphs, but is difficult to shoehorn into policy graphs that are trees: the extra structural freedom is necessary for a natural representation of the policies. Server (Busey Hospital) policies: policy 1 (institutionID): true policy 2 (psychRecord): true policy 3 (psychRecord): x.type = “patient ID” ∧ x.issuerPublicKey = publicKey(“Busey Hospital”) ∧ x.patientNumber = “12345” ∧ requesterAuthenticatesTo(x.ownerPublicKey) policy 4 (psychRecord): y.type = “employee ID” ∧ y.issuerPublicKey = publicKey(“Busey Hospital”) 80
∧ y.jobtitle = “Staff Physician” ∧ requesterAuthenticatesTo(y.ownerPublicKey) policy 5 (psychRecord): y.employeeName = “Jane Smith”
Client (patient Susan Jones and employee Dr. Sue Jones) policies: policy 6 (employeeID): x.type = “institutional ID” ∧ x.issuerPublicKey = publicKey(“Busey Hospital”) ∧ x.ownerPublicKey = publicKey(“Busey Hospital”) ∧ requesterAuthenticatesTo(“Busey Hospital”) policy 7 (patientID): true policy 8 (patientID): x.type = “employee ID” ∧ x.issuerPublicKey = publicKey(“Busey Hospital”) ∧ requesterAuthenticatesTo(x.ownerPublicKey) policy 9 (patientID): y.type = “employee ID” ∧ y.issuerPublicKey = publicKey(“Blue Cross Blue Shield of Illinois”) ∧ requesterAuthenticatesTo(y.ownerPublicKey) policy 10 (patientID): z.type = “institutional ID” ∧ z.issuerPublicKey = publicKey (“Busey Hospital”) ∧ z.ownerPublicKey = publicKey(“Busey Hospital”) ∧ requesterAuthenticatesTo(z.ownerPublicKey) policy 11 (patientID): (x.jobtitle = “Staff Physician” ∨ x.jobtitle = “Staff Nurse” ∨ (x.jobtitle = “Customer Service Representative” ∧ x.department = “Delinquent Accounts”))
We have given descriptive names to some of the credentials in this example, to help the reader. In the real world, the resource names must not reveal useful information. Also for realism, we have included the 81
Susan Jones’s Policies
Busey Hospital Policies G1 :
institutionID
G3 :
employeeID
policy 6
policy 1
G2 :
G4 :
psychRecord
patientID
policy 5 policy 11 policy 3
policy 9 policy 4
policy 10
policy 8
policy 2
policy 7
Figure 5.7: Policy graphs for credentials of the client and the server RequesterAuthenticatesTo predicate, whose interpretation is determined by whether or not the requester can demonstrate knowledge of the private key associated with the public key specified in the credential. Finally, we have included a function whose interpretation is, in practice, supplied by a call to a certification authority that publishes public keys. A trust negotiation is described below. Here we assume Busey Hospital is using the TrustBuilder2Relevant strategy while Susan Jones is using TrustBuilder2-Simple. The binding trees corresponding to the messages after each step are shown in figure 5.8. In figure 5.8, for conciseness, we use the sink nodes of a traversal to represent the whole traversal. Although the entire negotiation will be conducted by the two parties’ security agents in a transparent manner, we describe the process as though the two parties were negotiating directly, for clarity. 1. The negotiation begins when Susan Jones requests access to psychRecord. The only binding tree at this point contains a single node representing psychRecord. 2. Busey Hospital returns the current traversal (policy 3 and policy 4) of the psychRecord resource. The 82
Step 1. psychRecord
Step 2.
Step 4. psychRecord
psychRecord
policy 3, policy 4
policy 3, policy 4
employeeID
more_extensions
psychRecord policy 3, policy 4 more_extensions
Step 3.
psychRecord
psychRecord
policy 3, policy 4
policy 3, policy 4
employeeID
more_extensions
Step 5. psychRecord
policy 6 more_extensions
Figure 5.8: Binding trees for each step in the example negotiation message is {(psychRecord, (policy 3, policy 4))}. policy 3 and policy 4 include the policy ID and the content of each policy respectively. The binding tree in step 1 is expanded to have psychRecord’s current traversal (policy 3, policy 4) as the child of the root node. 3. Susan Jones determines that her employee ID satisfies policy 4 for psychRecord, and discloses the policy for employeeID. Since she is using TrustBuilder2-Simple, she also discloses the traversal of patientID, the traversal of her driversLicense and her unprotected credential libraryCard. (The policy graphs for driversLicense and libraryCard are not shown in figure 5.7.) The message Susan Jones sends to Busey Hospital will be {extension({employeeID}, psychRecord, (policy 3, policy 4)), (employeeID, policy 6), (patientID, (policy 8, policy 9, policy 10)), (driversLicense, (policy 101)), libraryCard}.
At this point, Susan Jones has no way to realize that the extension
disclosure will lead to a dead end, because her employee ID does not enable her to gain access to the medical record. As a result, the binding tree in step 2 is further expanded by attaching the subtree rooted at employeeID to psychRecord’s current traversal (policy 3, policy 4). The binding tree from 83
step 2 is also retained, to record the fact that there may be other ways of satisfying policy 3 and policy 4. 4. Busey Hospital determines that its institutional ID satisfies policy 6, and discloses institutionID. Since institutionID is syntactically relevant to psychRecord and Susan Jones can expand the resulting set of disclosures, Busey Hospital will not make any irrelevant disclosures. The message only contains the disclosure of institutionID. Since policy 6 is satisfied, the subtree rooted at policy 6 is removed though a tree reduction operation. 5. Susan Jones determines that institutionID satisfies the policy for employeeID and for patientID, and discloses both credentials, which satisfies psychRecord’s current traversal (policy 3, policy 4). Thus, the subtree rooted at traversal (policy 3, policy 4) is removed through a tree reduction operation. 6. Once Busey Hospital receives Susan Jones’s patientID, which context satisfies policy 3, psychRecord is unlocked. Thus Busey Hospital grants access to psychRecord. Suppose the message by Susan Jones in step 5 only satisfies psychRecord’s current traversal but does not unlock psychRecord. Then the hospital will disclose psychRecord’s new traversal and continue the negotiation. In that case, the binding tree in step 5 will be expanded to a single tree that has psychRecord’s new traversal as the child of the root node, similar to the one after step 2. There will no longer be any binding trees with the traversal (policy 3, policy 4).
84
Chapter 6
A Unified Scheme for Resource Protection in Trust Negotiation Access control policies play a key role in trust negotiation. Unlike traditional decentralized systems, where access control policies are either publicly visible (such as in traditional file systems) or completely hidden (such as the configuration of a firewall for a local network), one’s access control policies may need to be dynamically disclosed during the process of trust establishment. In many situations, either because the trust between two strangers is so limited, or because of the nature of the requested service, disclosing the contents of an access control policy to a stranger may leak valuable business information or jeopardize one’s privacy. For example, suppose that an online store gives a special discount to employees of its business partners. If the policy, which contains the list of its business partners, is shown to arbitrary requesters for the service, then by merely looking at the policy, an outsider will know who is partnering with the store. To give access control policies the protection they need, in this chapter we propose UniPro, a Unified Resource Protection Scheme for trust negotiation. We introduce desiderata for protection of sensitive access control policies in section 6.1, and show how previously proposed approaches measure up to the desiderata in section 6.2. In section 6.3, we present UniPro and show that unlike previous proposals, UniPro treats access control policies as first-class resources, provides fine-grained control over policy disclosures, and clearly distinguishes between policy disclosure and policy satisfaction. We also prove that UniPro generalizes two previous proposals, and explain why in spite of this, we believe that other ways of protecting policies still have an important role to play in trust negotiation. Because each party should have wide autonomy in how it conducts a trust negotiation—autonomy limited only by the need to interoperate correctly with another party during negotiation—section 6.4 discusses the impact of UniPro on the theory of strategy interoperability, 85
and the tradeoff between the greater freedom in policy protection that UniPro provides and the potential for unnecessary negotiation failure. We also explain how we expect these unnecessary failures to be avoided in practice.
6.1 Sensitive Policies and Their Protection As explained in chapter 5, realistic access control policies tend to contain sensitive information, because the details of Alice’s policy P for disclosure of credential C tend to give hints about C’s contents. Example 1. [77] Suppose a web page’s access control policy states that in order to access documents of a project in the site, a requester should present an employee ID issued either by Microsoft or by IBM. If such a policy can be shown to any requester, then one can infer with high confidence that this project is a cooperative effort of the two companies. Example 2. (Inspired by examples in [15]) Coastal Bank’s loan application policy says that a loan applicant must be a customer of the bank who is not on the bank’s bad-customer list. If this policy is fully disclosed to a requester, then an outsider can easily learn who the bank’s bad customers are, which is very sensitive business information. In the first example, the correlation between two constraints in a single policy reveals certain properties of the protected resource. The policy in the second example directly refers to sensitive local information that should be protected. One obvious way to prevent such information leakage is to selectively disclose part of a policy. For instance, in Example 1, we can first ask the requester to show an employee ID. After receiving the credential, we check whether it is issued by either Microsoft or IBM. Similarly, in Example 2, Coastal Bank may only ask for a customer ID and perform the check on the bad customer list after the credential is received. However, this approach may cause a dispute between the two negotiating parties. If we simply remove those sensitive constraints when disclosing a policy, Alice may disclose some credentials and believe that Coastal Bank’s policy has been satisfied, while Coastal Bank believes the opposite because the sensitive constraints of the bank’s policy are not satisfied. A key observation is that since policies may be sensitive and need to be protected from unauthorized disclosure, there is no essential difference between policies and other resources, from the point of view 86
of resource protection. That means that when we protect a sensitive policy, we can protect it in the same way as any other resource. Therefore a resource protection scheme that satisfies the following desiderata is desirable. 1. When Alice requests access to Bob’s resource R, Bob may disclose R’s access control policy P to Alice so that Alice can learn how to gain access to R. Once Alice has disclosed credentials that satisfy P , Bob will grant Alice access to R. One underlying assumption in this process is that the two parties have the same understanding of the semantics of policies. When one party believes that a policy has been satisfied by disclosed credentials, the other party should believe the same. Otherwise, a dispute may arise even though the two parties negotiate trust in good faith. We call this the satisfactionagreement assumption. 2. Protection of sensitive policies should be as flexible as for any other kind of resource, allowing any kind of constraint that is used for protecting other resources. Because different parts of a policy may be sensitive in different ways, the policy protection approach should allow fine-grained control of the protection applied to each part of a policy. 3. Let R be a resource with access control policy P . The resource protection scheme should decouple the protection of R and P . R’s accessibility should only depend on P ’s satisfaction. Whether P is disclosed or not should not affect R’s accessibility. In other words, the scheme should be able to model the situation where the client presents the right credentials, satisfies P and gains access to R, without becoming eligible to see the actual contents of P during a negotiation. Taken to the extreme, this will allow servers to offer private services whose existence and access control policies are never made public, but whose location and policies can be pushed privately to selected clients. 4. The design of interoperable strategies is an important issue in research on trust negotiation, and the resource protection scheme should not become an obstacle to interoperation. The resource protection scheme must allow a wide variety of practical negotiation strategies that will interoperate correctly with one another. 5. The resource protection scheme must allow a human-friendly interface for policy capture and maintenance. We believe that the challenge of policy capture and maintenance is perhaps the biggest obstacle 87
to widespread deployment of systems that are open to access by outsiders. Businesses and individuals must have confidence in their policies, but policies are hard to write and will require updates in a changing world. While these issues are the focus of work by other researchers [31, 16, 83, 84, 63] and are largely outside of the scope of this thesis, we believe that they must be kept in mind when designing a unified resource protection scheme.
6.2 Related Work on Sensitive Policy Protection 6.2.1 Service Accessibility Rules Bonatti and Samarati [15] proposed a framework for regulating service access and information release on the web. The framework is targeted at environments where no single centralized security domain exists. Their framework contains a policy language for access control specification, and a filtering mechanism to identify the relevant policies for a negotiation. A service accessibility rule in their model is composed of two parts: a prerequisite rule and a requisite rule. Service prerequisite rules state the conditions that a requester must satisfy before she can be considered for the service. Service requisite rules state sufficient conditions for obtaining access to the service, i.e., if a requester also satisfies a requisite rule, she will be entitled to access the service. To protect both the server and client’s privacy, the model enforces a specific ordering between a service’s prerequisite and requisite rules. The server will not disclose a requisite rule until after the requester satisfies a corresponding prerequisite rule. Prerequisite rules can contain constraints that are hidden from strangers. For instance, to get a special offer from an auto insurance company, suppose that a requester is first required to show a valid driver’s license which contains basic personal information such as gender, age and address. Based on such information, the insurance company will determine whether the requester is likely to be in a high risk group. How the company makes its decision should not be disclosed to the requester. If the requester does not belong to a high risk group, the insurance company will require disclosure of the title of the vehicle to verify that the requester is actually the owner of the insured vehicle. By using the model in [15], we have the following rules: 1. service_prereqs(special_of f er()) ← credential(drivers_license(gender = X, age = Y, issuer =“DMV”)) | high_risk(gender = X, age = Y ) = f alse. (The constraint 88
high_risk(gender = X, age = Y ) = f alse is hidden when the prerequisite rule is disclosed.) 2. service_reqs(special_of f er()) ← credential(vehicle_title(owner = X, issuer =“DMV”)), credential(drivers_license(name = Y )), X = Y . For simplicity, we have omitted several details in the above service rules. In particular, issuers of these credentials should be principals that the server trusts, and the requester should authenticate to the owner of each credential. We would expect the credential issuer to be identified not by a string, but by a public key lookup. Further, a party must verify that each credential it receives during trust negotiation has contents that correspond to its signature. Also, trust negotiation should be conducted over a secure channel to prevent certain attacks. We will also omit these important details in all later examples in this chapter. By explicitly indicating whether a policy is a prerequisite or requisite rule, a requester can be made to understand the consequences of disclosing particular credentials. Thus, the satisfaction-agreement assumption holds in this model. A prerequisite rule serves two functions at the same time: controlling the disclosure of the service requisite rules and controlling access to the service. The scheme does not decouple policy disclosure from policy satisfaction. Thus, desideratum 3 is not satisfied. Also, the only way to protect a sensitive policy is to keep it completely inaccessible to a requester. This makes it difficult to use service accessibility rules to express complex authorization requirements. Therefore desideratum 2 is not met. On the other hand, examples 1 and 2 can be easily expressed using service accessibility rules. Example 3. McKinley Clinic makes its patient records available for online access. Let R be Alice’s record. To gain access to R, R’s policy states that a requester must either present Alice’s patient ID for McKinley Clinic, or present a California social worker license and a release-of-information credential issued to the requester by Alice. Knowing that Alice’s record specifically allows access by social workers will help people infer that Alice may have a mental or emotional problem. Alice will probably want to keep this constraint inaccessible to strangers. However, employees of McKinley Clinic should be allowed to see the contents of this policy. Note that this does not mean that to satisfy R’s policy, a requester has to work for McKinley Clinic. Any licensed social worker can access Alice’s patient record as long as the social worker has obtained a release-of-information credential from Alice and pushes the relevant credentials to the server. 89
In example 3, if the social worker constraint is put in a prerequisite rule, then it must be made inaccessible to everybody or accessible to everybody. On the other hand, if the constraint is put in the requisite rule, then the constraint on working for McKinley Clinic has to appear in the prerequisite rule, which means that anyone other than Alice who accesses Alice’s record has to be employed by McKinley Clinic. In either case, we do not capture the original intent of the policy. If the social worker is not working for McKinley Clinic, how could she know that she should present her social worker license and the release-of-information credential from Alice? In practice, we expect that Alice will have disclosed a version of R’s policy to the social worker at the same time as Alice gave out the release-of-information credential. The social worker can cache both the credentials and the policy fragment for later use during trust negotiation. More generally, we expect advance disclosure and caching of policies to be useful whenever policies are invisible to all but a targeted audience.
6.2.2 Policy Graphs The idea proposed in chapter 5 is that by dividing access control requirements into layers and organizing them as a policy graph, one can effectively protect sensitive policies. However, from the semantics of policy graphs, we can see that each policy in a policy graph not only controls its direct successor’s accessibility, but also that of its indirect successors. In the example in figure 5.1, P0 controls when P1 and P2 can be disclosed. Further, to gain access to R also requires a requester to satisfy P 0 in the first place. Thus, the concept of policy graphs couples a policy’s satisfaction tightly with the policy’s disclosure, which makes it difficult to use policy graphs to express certain access control requirements. In example 1, if we treat the policy requiring an employee ID as the source node P 0 and regard constraints on the issuer of the employee ID as its successor P 1 , then anyone who can produce an employee ID may be able to see the contents of P 1 , which is obviously not desired. On the other hand, if we put f alse in the policy graph as P1 ’s predecessor, indicating that nobody is allowed to see the contents of P 1 , then no one will be able to gain access to the project documents, which is not consistent with the original access control requirements either. Similarly, policy graphs cannot be used to capture the intent of examples 2 and 3. In summary, policy graphs preserve the satisfaction-agreement assumption: once a policy P is satisfied, a requester knows that either she gains access to R or she will see the content of one of P ’s successors. But policy graphs couple policy disclosure with policy satisfaction, which limits their expressiveness and 90
violates desiderata 2 and 3.
6.3 A Unified Scheme for Resource Protection The lack of centralized authority on the Internet suggests that more than one general-purpose language may become popular for expressing policies. Specialized sublanguages may evolve by, for example, making it easier to capture and maintain common access control constraints for certain kinds of resources. Thus our goal is to provide a general-purpose way to protect policies without dictating the choice of policy languages, beyond certain minimal requirements described later. The examples we give in the rest of this chapter use the policy language described in chapter 5. Further, we use symbols in the calligraphic font to represent policies in the underlying policy language: P, P 1 , P2 , etc. We begin by reifying policies. Definition 6.1. A policy definition takes the form P = P, where P is a unique ID for this policy and P is a formula in the underlying policy language. We call P the content of the policy, denoted as content(P ). Definition 6.2. Given policy definition P = P and policy content P , we say a set C of credentials satisfies P ∧ P if C satisfies (P ) ∧ (P). Similarly, C satisfies (P ) ∨ P if C satisfies (P ) ∨ (P). Definition 6.2 allows policy IDs to appear in policy definitions, to give finer-grained greater control over policy protection. In the remainder of the paper, policy contents will be written in this augmented
policy language. Definition 6.2 also introduces a very simple type of policy composition. The definition can be viewed as stating what it means to satisfy two policies in the underlying language simultaneously, or to satisfy one of two policies. This kind of policy reuse and composition [16, 83, 84] is an effective way to help users design and maintain their policies. We will use it to translate policy graphs and service accessibility rules into UniPro. Although Definition 6.2 may seem trivial at first glance, it must be formulated very carefully for underlying policy languages that allow free variables to appear in policies; conjoining two policies may force two variables to refer to the same resource or attribute value. Definition 6.2 is appropriate for the policy languages used in chapter 5 and by Bonatti and Samarati, but it may need to be tailored to meet the needs of other policy languages developed in the future. 91
For example, let P1 be the ID of a seat upgrade policy that requires a requester to be a Platinum Frequent Flyer with a seat upgrade certificate. Then we have P 1 = (x.type = “Platinum Frequent Flyer” ∧ x.issuer = “CheapAir” ∧ y.type = “Seat Upgrade Certificate” ∧ y.issuer = “CheapAir”). Let P 2 be the ID of a seat upgrade policy that requires the requester to be a gate agent: P 2 = (z.type = “Employee ID” ∧ z.issuer = “CheapAir” ∧ z.jobT itle = “Gate Agent”). Now we want to have a policy ID P whose content says that a requester needs to either be a gate agent or be a Platinum Frequent Flyer with an upgrade certificate. There are several possible ways to get P through policy composition; each of these ways offers different possibilities for protecting the policies. 1. We may have P = P1 ∨ P2 . In this case, P , P1 , and P2 can have entirely different access control policies. For example, P may be made freely accessible, so that all can see P ’s internal disjunctive structure. P1 may be accessible to all Platinum Frequent Flyers and airline employees, while P 2 is only accessible to airline employees. 2. We may have P = content(P1 ) ∨ content(P2 ). In this case, anyone who can satisfy P ’s access control policy—say, all Platinum flyers—will be able to see the full policy for seat upgrades. This may be undesirable, as Platinum passengers may beg the gate agent for free upgrades, once they learn about this policy. 3. We may also have P = content(P1 ) ∧ P2 . In this case, anyone who satisfies P ’s policy can learn the standard way of obtaining an upgrade. The fact that gate agents can perform a free upgrade can be hidden from everyone but airline employees, if desired. Definition 6.3. A policy declaration takes the form R ← P , where P is the ID of the access control policy for the resource with ID R. A requester is entitled to gain access to R only if she has disclosed credentials that satisfy P . Under UniPro, each resource R is protected by exactly one policy (R ← P ), and each policy ID P has exactly one policy definition P = P. Further, the fact that R is protected by a policy with a particular ID (R ← P ) is freely disclosable to all, because P and R are both just resource IDs. In UniPro, policies can be protected by policies which can be protected by policies and so on, but the chain of protection must bottom
92
out with a policy that is either always hidden or always disclosable 1 These special policies have IDs true and false, their contents are always and never satisfied, respectively, and they are freely disclosable. In particular, assume R is not a policy. We use R ← true to denote that a resource R is not protected, and R ← f alse for a resource that a party does not possess or that will not be disclosed under any circumstances. We say R ← f alse is a denial policy declaration. Let us revisit the examples from section 6.1. Example 1. The access control policy for the project documents R is R ← P , where P = (x.type = “Employee ID”∧ P1 ) and P1 = (x.issuer = “Microsoft” ∨x.issuer = “IBM”). We also have P ← true and P1 ← f alse. Since P ’s policy is always satisfied, any requester can see P ’s content. However, P1 ’s policy is never satisfied, which means P 1 ’s content should not be shown to anybody. Assume Alice is an employee of Sun Microsystems and wants to access the project’s documents. After P ’s content has been disclosed, she may disclose her Sun employee ID. But since Alice knows that P refers to an inaccessible policy P 1 (because P1 ← f alse is freely disclosable), she knows that her employee ID may not be enough to satisfy P . Therefore, the satisfaction-agreement assumption holds in this situation. Example 2. Coastal Bank’s loan application policy definition is P = (x.type = “Customer ID” ∧x.issuer = “Coastal Bank” ∧ P1 ). We also have P1 = (x.ID ∈ BadCustomerList), P ← true, and P1 ← f alse. After a loan applicant discloses her Coastal Bank customer ID, since P 1 is a conjunct in the content of P , and the content of P 1 will never be disclosed, she should wait for Coastal Bank to decide whether P is satisfied instead of taking it for granted that she is qualified for the loan. Example 3. Let R be Alice’s patient record. We have 1. R ← P . 2. P = P1 ∨ P2 and P ← true. Everyone can see that there are two ways to get access to Alice’s record. 3. P1 = (x.type = “patient ID” ∧ x.name = “Alice” ∧ x.issuer = “McKinley Clinic”), and P1 ← true. Everyone can see that Alice can access her own records. 1
One responsibility of a policy management tool is to help users avoid non-trivial cycles when designing policies. A non-trivial cycle occurs if to veiw the content of a policy P other than true, Alice must first satisfy P .
93
4. P2 = (x.type = “Professional License” ∧ x.prof ession = “Social Worker” ∧ x.issuer = “State of California” ∧ y.type = “Medical Records Release” ∧ y.issuer = “Alice” ∧ y.institution = “McKinley Clinic”). Alice can also authorize social workers to look at her records. To prevent the inappropriate disclosure of P 2 ’s content, we also have P2 ← P3 , P3 = (z.type = “Employee ID” ∧ z.issuer = “McKinley Clinic”), and P 3 ← true. Then everyone can see that McKinley employees can see another way to gain access to Alice’s records. Next we analyze UniPro according to the first three desiderata discussed in section 6.1. 1. In UniPro, if a requester submits credentials that satisfy a resource’s policy, then she is entitled to access that resource. On the other hand, because of the explicit appearance of policy IDs in a policy, a requester will be aware of parts of a policy that have not been disclosed yet. Without seeing those parts, she will not always be able to tell whether the policy has been satisfied by the credentials she has disclosed. Therefore, there will be no disagreement between two parties over whether a policy has been satisfied, given that they both understand the semantics of the underlying policy language. 2. UniPro explicitly protects policies in the same way as other resources. Users can design policies that provide fine-grained control of sensitive policies’ disclosure. In fact, by looking at a resource’s policy, R ← P , we cannot tell whether R is a policy, a credential or a service. 3. The semantics of UniPro explicitly separates a policy’s satisfaction from its disclosure. If a resource is protected by a policy P , then as long as P is satisfied, R can be accessed. Whether P has been disclosed or not is irrelevant to R’s disclosure. Regarding desideratum 5, probably no policy language with roots in mathematical logic will ever be regarded as user-friendly by the average corporate programmer. We view the previously proposed policy languages for trust negotiation as efforts to put a firm semantic foundation under trust negotiation, and to understand the requirements for policy languages for trust negotiation. They have served admirably in this capacity, and UniPro builds directly upon them. More generally, we view UniPro not as a replacement for other policy languages, but rather as an underlying foundation that other, more programmer-friendly, policy capture tools can be hooked into. A programmer can use the friendliest capture tool with sufficient
94
modeling power for a new/updated policy, and then the captured policy can be translated into UniProstyle policy definitions in a well-known, general-purpose policy language, to provide portability and mutual comprehension of policies written by strangers. (For example, the policy languages in the RT family [62, 64] and the service accessibility language proposed in [15] have formal semantics for role/attribute definition and delegation across security domains. Thus they are ideal to serve as intermediate policy languages for security agents to understand each other’s access control requirements.) To show the promise of this approach, the following two theorems show how UniPro generalizes service accessibility rules and policy graphs. Theorem 6.1. Given a policy graph G protecting resource R, there is a set of UniPro policy definitions with the same semantics as G. More precisely, 1. If R’s UniPro policy is satisfied by a set of disclosed credentials, then there exists a path from the source node of G to an immediate predecessor of R in G, such that every policy along the path is satisfied by the set of disclosed credentials. 2. For any policy node N in the policy graph, if N ’s content is disclosed, then there exists a path from the source node of G to an immediate predecessor of N in G, such that every policy along the path is satisfied by the set of disclosed credentials. Proof. We first construct the set of policies in a bottom-up way. Then we prove that it preserves the semantics of G. Since G is an acyclic directed graph, there exists a topological order among all the nodes in G. Let N0 , . . . , Nk be an order such that for any pair of nodes (N i , Nj ), if Ni is a predecessor of Nj , Ni appears before Nj in the order. Obviously, N0 is the source node while Nk is the protected resource R. We construct a set of policies {P0 , . . . , Pk } as follows. 1. Define P0 = content(N0 ) and P0 ← true, where content(N0 ) is the policy associated with N 0 . 2. For every Ni , 0 < i < k, suppose Nt1 , . . . , Ntn are Ni ’s immediate predecessors in G. Define Pi = content(Ni ) ∧ (Pt1 ∨ · · · ∨ Ptn ) and Pi ← Pt1 ∨ · · · ∨ Ptn . 3. For Nk = R, suppose its immediate predecessors in G are N l1 , . . . , Nlm . We define R ← Pl1 ∨ · · · ∨ Plm . 95
Next we need to prove that the semantics of policy graph G is preserved by adopting the above policies. We first show that when policy Pi is satisfied, there exists a path (N 0 , . . . , Ni ) in G such that P0 ∧ · · · ∧ Pi is satisfied. This proposition can be proved by induction on i. When i = 0, since N0 is the source node, the proposition obviously holds. Assume when i ≤ n, n ≥ 0, the proposition holds. When i = n + 1, let Nt1 , . . . , Ntm be Nn+1 ’s immediate predecessors in G. If P n+1 is satisfied, then one of Ntj , 1 ≤ j ≤ m, must also be satisfied. By the induction hypothesis, there is a path (N 0 , . . . , Nn+1 ) such that P0 , . . . , Pn+1 are all satisfied. The proposition holds. If content(Ni ) is disclosed under UniPro, then since content(N i ) only appears in Pi under UniPro, the policy that protects Pi must have been satisfied. By the above proposition, we have a path from the source node to one of Ni ’s predecessors in G such that every policy in the path is satisfied. Theorem 6.1 shows that UniPro is at least as expressive as policy graphs. As shown in Examples 1 and 2 in section 6.1, there are realistic cases whose access control requirements cannot be expressed with policy graphs. Thus UniPro generalizes policy graphs. However, as mentioned earlier, policy graphs or another graphical interface to an underlying policy language can be used as a friendly interface on top of UniPro for capturing and maintaining access control requirements that do not require all of UniPro’s modeling power. Theorem 6.2. Given a service prerequisite rule service_prereqs(s) ← q 1 , . . . , qn | p1 , . . . , pm and a service requisite rule service_reqs(s) ← q 1 , . . . , qt , where qi (1 ≤ i ≤ n), pi (1 ≤ i ≤ m), and qi (1 ≤ i ≤ t) are all predicates, there is a set of UniPro policy definitions with the same semantics as the service accessibility rules. More precisely: 1. Service s’s UniPro policy is satisfied by a set of credentials disclosed by Alice if and only if those credentials satisfy q1 ∧ · · · ∧ qn , p1 ∧ · · · ∧ pm , and q1 ∧ · · · ∧ qt . 2. If the contents of any qi , 1 ≤ i ≤ t, are disclosed to Alice, then q1 ∧ · · · ∧ qn ∧ p1 ∧ · · · ∧ pm are satisfied by credentials Alice has already disclosed. 3. The contents of pi , 1 ≤ i ≤ m, are never disclosed. Proof. Let S contain the following policies, where the empty formula is written as the distinguished predicate true: 96
1. s ← Q ∧ Q. 2. Q = q1 ∧ · · · ∧ qt and Q ← Q. 3. Q = q1 ∧ · · · ∧ qn ∧ P and Q ← true. 4. P = p1 ∧ · · · ∧ pm and P ← f alse. We can see that since P ’s policy is f alse, the predicates p 1 , . . . , pm will never be disclosed. Also, in order to see q1 , . . . , qt , one has to satisfy Q, which is equivalent to satisfying the service’s prerequisite rule. In order to gain access to service s, one has to satisfy both Q and Q, as defined in the access control policy of s. Note that the framework in [15] allows a service to have multiple prerequisite rules and requisite rules. By a similar construction, we can devise a set of UniPro policies that preserves the right semantics. As shown by Example 3 in section 6.1, there are realistic access control requirements that cannot be expressed using service accessibility rules. Thus UniPro generalizes service accessibility rules.
6.4 Strategy Interoperability under UniPro Through careful control over policy disclosures, UniPro provides strong information protection during trust negotiation. However, such a flexible model has a great impact on strategy interoperability — how security agents interact with each other and find a successful negotiation whenever possible. The impact is two-fold: 1. UniPro treats access control policies as first-class resources and allows users to specify under what circumstances they can be disclosed. It is possible that a requester does not possess the right credentials to see the content of a policy. On the other hand, UniPro clearly distinguishes policy satisfaction and policy disclosure. A requester can satisfy a policy and gain access to a resource even when she cannot see the content of that policy, as shown in Example 3 of section 6.2. In this situation, it becomes a tricky matter for a requester to deal with inaccessible or invisible policies. One approach is to disclose all her credentials whose policies are satisfied, hoping some of her credentials combined together can satisfy the invisible policy. But this way, even if a requester finally satisfies the policy, a
97
lot of irrelevant information will have been disclosed. Therefore, this approach is probably appropriate only when the requester is so desperate to gain access to the resource that she does not care about unnecessary credential disclosures at all. Further, an attacker may pretend to offer a very compelling service and associate it with an invisible policy that cannot be satisfied by anybody. Such a service acts as bait for the attacker to lure eager requesters into disclosing information. 2. A party may sometimes know the content of a policy beforehand either because of a previous trust negotiation or because it is obtained through some offline channel, as shown in the third example of section 6.2. We call such policies client-cached policies, or cached policies for short. Because of cached policies, a seemingly invisible policy actually may not be an obstacle to a successful negotiation. Further, even if a policy may be visible to a party during a trust negotiation, a cached copy of the same policy will help two parties to accelerate the progress of the negotiation. Since it is quite common for a resource’s policy to change due to, for example, corporate reorganization or management changes, an interesting question is how a client can indicate that she has a cached copy of a particular policy and find out whether it is still up-to-date. Bearing the above two aspects in mind, we investigate how to design interoperable strategies under UniPro. For simplicity, in this section we use the same model for credentials and policies as in chapter 3 — credentials are treated as uninterpreted symbols and policies are modeled as propositional formulas. By using techniques similar to those introduced in chapter 5, our discussion in this section can be extended to support structured credentials and more expressive policy languages. In the following, we first design a trust negotiation protocol for UniPro (section 6.4.1). Then we propose the concepts of weak interoperability and UniPro trees to represent the status of a negotiation. Finally, we present a closed strategy family under the trust negotiation protocol for UniPro.
6.4.1 The UniPro Trust Negotiation Protocol The UniPro protocol is derived from the TrustBuilder 1 protocol with slight modifications to accommodate UniPro’s special features. The UniPro protocol allows three types of disclosures: resource disclosures, policy declaration disclosures and uncached policy notifications. Typically, if a resource belongs to Alice, then only Alice can disclose that resource. However, if the 98
resource is Alice’s policy P , then because Bob may possess a cached copy of the definition of P , it is possible for Bob to disclose P ’s content to Alice during a negotiation. Since both parties know the content of P , in this case, why would Bob need to disclose that content? The reason is to prevent Bob from probing for the content of P . Let’s look at an example. Suppose Alice has M edical_record ← P , P ← f alse, meaning that she will not disclose her medical records access control policy to anyone during negotiation. After Alice discloses M edical_record ← P and P ← f alse to Bob, Bob replies with Drivers_License ← P and P = BBB_membership. At this point, should Alice respond to P ? If Alice always responds no matter whether Bob’s driver’s license is relevant to P or not, then many rounds of messages may be wasted on irrelevant disclosures if Bob does not possess a cached copy of P . On the other hand, if Alice only responds when Bob’s driver’s license is relevant to P , then by observing Alice’s response, Bob may be able to infer the contents of P through repeated probing even though Alice has P ← f alse to prevent the disclosure of P ’s contents. Thus, in our approach, Alice does not have to respond to the disclosure of the policy for a resource C unless C is relevant to some policy whose definition has already been disclosed. This requirement makes the disclosure of cached policies necessary in the UniPro protocol. The goal of this protection is similar to that proposed by Winsborough et al. in [86, 85], which is based on the principle “discuss sensitive topics only with appropriate opponents”. In our case, Alice does not need to discuss with Bob whether a credential C is relevant to a policy P unless Bob first proves that he knows the contents of P . There are also concerns from Bob’s point of view. First, how can he know that the policy definition of P in his cache is the same as Alice’s current version? It is meaningless for Bob to disclose an out-of-date version of P and try to satisfy it. Second, even if the cached policy is exactly the same as what Alice has, Alice can still claim that they are not and consequently deny that Bob has satisfied the policy. Bob cannot prevent Alice from doing so. But we should at least provide a way for Bob to collect evidence and complain to an arbitrator later. In section 6.4.5, we show how this problem can be solved through the use of bit commitment techniques. A cached policy reflects a pre-existing relationship between Alice and Bob (e.g., they have communicated off-line previously). For privacy reasons, Bob may prefer not to reveal such a relationship unless necessary. To better preserve one’s privacy, UniPro allows Bob to continue the negotiation and try to first satisfy a policy P ’s access control policy in the normal way, through credential disclosures, even when he 99
already has a cached copy of P . That is the reason why we have the uncached policy notification in the UniPro protocol. Without such a notification, Alice cannot be sure whether a policy is really invisible to Bob. Each type of disclosure in the UniPro protocol is described as follows. Resource disclosures Given a resource R, 1. If the resource is a service, then the disclosure of R means that the other party gains access to that service. 2. If the resource is a credential C, then the disclosure means that C is disclosed to the other party. (In practice, credential contents verification, parsing of the credential into a set of statements in the policy language, and any required challenge/response for authentication will take place at this point, but we do not discuss this further in this chapter.) 3. If the resource is a policy P , then its definition P = P is sent to the other party. In other words, the content of the policy is disclosed. If P is Alice’s policy, Alice can disclose the content of P . If Bob already has a cached copy of P , he may also send a policy disclosure for P to Alice, telling Alice that P ’s content is already visible to him. Policy declaration disclosure Let R’s policy be P . Then the policy declaration disclosure of R takes the form R ← P . A policy declaration disclosure discloses the policy ID of P , not the content of policy P ’s definition. Uncached policy notification Let P be Alice’s policy. An uncached policy notification takes the form uncached(P ). When sent from Bob to Alice, uncached(P ) indicates that Bob does not possess a cached copy of P . Uncached policy notifications are needed because even if P ’s contents are invisible to Bob, Alice cannot determine whether Bob has a cached copy. Therefore, it is up to Bob to make such a notification so that Alice can know whether there is no hope for Bob to see the contents of P . The UniPro protocol is similar to the TrustBuilder 1 protocol in that every message that a party sends is a set of the disclosures defined above. An empty message still serves as a failure message, which indicates
100
that a party has decided to terminate the negotiation. The UniPro protocol requires the negotiation strategies used with it to enforce the following three conditions throughout negotiations: 1. No duplicate disclosures can be made. For example, suppose P is Alice’s policy. Then a policy definition disclosure P = P is considered the same no matter whether it is made by P ’s owner Alice or by Bob who has a cached copy of P . In other words, the contents of P should not be disclosed more than once. 2. Suppose C is Alice’s resource. Then Alice cannot disclose C to Bob unless C’s access control policy has been satisfied by credentials disclosed by Bob. 3. If a message contains a denial policy declaration C ← f alse, then C must appear in a previously disclosed policy. 4. If a message contains an uncached policy notification uncached(P ), then the policy ID P must appear either in some previously disclosed policy declaration disclosure C ← P or else on the right-hand side of a previous policy definition disclosure.
6.4.2 Weak Strategy Interoperability Under UniPro, the meaning of strategy interoperability needs to be reconsidered. Recall that our current definition of interoperability (definition 4.2) states that two strategies are interoperable if two parties who use them can always establish trust whenever there exists a safe credential disclosure sequence terminated by the disclosure of the requested resource. This definition is too strong to be used with UniPro. Since a policy may be hidden completely from a requester, under certain situations, to ensure interoperability will require a party to disclose all its credentials whose policies have been satisfied, which may severely jeopardize one’s privacy. For example, let P be one disjunct in R’s policy. If P ← f alse has been disclosed, then before Alice can give up on obtaining access to R, strong interoperability will require her to send her freely disclosable library card, AAA membership card, high school diploma, etc., to Bob in an attempt to gain access. Such strategies represent one extreme that concentrates only on establishing trust, with few considerations for privacy. Due to this reason, we will call the interoperability in definition 4.2 strong interoperability.
101
To protect privacy, a requester may not want to disclose all her credentials in an attempt to satisfy those hidden constraints. So Alice may possess the right credentials to satisfy the resource’s policy, but the negotiation may fail, because she cannot see the contents of a policy. This is an acceptable outcome of a negotiation—a reasonable tradeoff between privacy and access. Alice may reasonably believe that if she could gain access, she would already have obtained and cached the hidden portions of the access control policy, as mentioned in section 6.3. On the other hand, parties will want to adopt strategies that will guarantee a successful negotiation given “sufficient” policy visibility. Thus, when we design negotiation strategies for UniPro, there is a tradeoff between establishing trust and preserving one’s privacy. To reflect such a tradeoff, in the following we propose the concept of visible satisfaction for safe disclosure sequences. Since in UniPro access control policies are treated as first-class resources, a safe disclosure sequence may contain not only credential or service disclosures but also policy disclosures. Generally speaking, if a resource is disclosed in a safe disclosure sequence, it does not imply that the resource’s access control policy must also be disclosed in the sequence. Therefore, the concept of safe disclosure sequences alone does not capture the necessary visibility of policies. Because of the existence of cached policies, a policy disclosure P can either be made by the owner of the policy when the access control policy for P is satisfied, or by another party who has a cached copy of P . Thus, our definition of safe disclosure sequences needs to be modified accordingly. Definition 6.4. Let R be Bob’s resource that Alice requests to access. If there exists a sequence of resource disclosures (R1 , . . . , Rk = R) such that for all Ri , 1 ≤ i ≤ k, either Ri ’s access control policy is satisfied by credentials in {R1 , . . . , Ri−1 }, or Ri is a cached policy disclosure, then we say the sequence is a safe disclosure sequence culminating in R’s disclosure. If a resource is disclosed in a safe disclosure sequence, that does not imply that the resource’s access control policy is also disclosed in the sequence. Definition 6.5. Suppose P = P and let S = {d1 , . . . , dk } be a set such that each di , 1 ≤ i ≤ k, is either a credential or a policy ID appearing in P. If P is satisfied when all the credentials in S are disclosed and all the policies whose IDs are in S are satisfied, then we say S is an indirect solution for P . If no proper subset of S has this property, then we say S is a minimal indirect solution for P . Before we introduce the concept of visible satisfaction, let us revisit the concept of policy declarations. 102
Suppose we have R ← P . Both R and P can also be viewed as formulas with a single symbol in our policy language. If R is a service or a credential, then the semantics of R ← P can be interpreted as “if formula P is satisfied by a set of disclosed credentials, then the formula R can also be satisfied (since R can be disclosed)”. Since P represents a policy, satisfying P does not require seeing the contents of P . However, if we have P1 ← P , where P1 is a policy ID, then the semantics is that “if the formula P can be satisfied, then the definition of P1 becomes visible”. So from this aspect, the semantics of R ← P has a subtle difference, depending on whether R represents a policy or another kind of resource. On the other hand, for policy definition P = P, we have the semantics that “formula P is satisfied if and only if formula P is satisfied”. Thus, in some sense, the semantics of a policy definition is similar to that of a policy declaration R ← P when R represents a service or a credential. Such an observation suggests that we need to make distinctions based on this difference when we define the concept of visible satisfaction. Definition 6.6. The safe disclosure sequence (R 1 , . . . , Rn ) is visibly satisfiable for a service or a credential R if Rn = R and 1. Either n = 1, i.e., R’s access control policy is always satisfied, or 2. R ← P and the sequence (R1 , . . . , Rn−1 ) is visibly satisfiable for P . The sequence is visibly satisfiable for a policy P if the following three conditions all hold. 1. P ’s content is disclosed in the sequence, i.e., P ’s definition is the kth disclosure in the sequence, for some k, 1 ≤ k ≤ n. 2. Either the party who does not own P has a cached copy of P , or P ’s access control policy is always satisfied, or we have P ← P and (R1 , . . . , Rk−1 ) is visibly satisfiable for P . 3. Suppose P = P. There exists a minimal indirect solution {R 1 , . . . , Rt } for P, such that for each Ri , 1 ≤ i ≤ t, there exists j, 1 ≤ j ≤ n, such that (R1 , . . . , Rj ) is visibly satisfiable for R i . For a policy P , the disclosure of P ’s definition does not imply that P is visibly satisfiable. In order to make a sequence visibly satisfiable for P , we have to consider the visible satisfaction of its minimal solutions, as indicated in definition 6.6.
103
If there is a visibly satisfiable disclosure sequence for the requested resource R, then two strangers will be able to find at least one way to establish trust, without being stymied by policies that they are not entitled to access. However, even without cached policies, two strategies may manage to establish trust when there is no visibly satisfiable disclosure sequence. For example, consider the following policies: R ← PR , PR ← true, PR = P1 ∧ P2 , P1 ← f alse, P2 ← true. Clearly, there is no visibly satisfiable disclosure sequence for R. But suppose that Alice concentrates on satisfying P2 , the visible part of R’s policy. During the negotiation centering around P 2 , a number of credentials may be disclosed by both parties, and a visibly satisfiable disclosure sequence may be found for P2 . At that point, P1 may already be satisfied “accidentally” by Alice’s disclosures — perhaps even by disclosures that are not part of P 2 ’s visibly satisfiable disclosure sequence, but were part of the search for that sequence. If this happens, Alice will gain access to R without ever seeing P 1 ’s content or making an irrelevant (as defined by her strategy) disclosure. In order to protect one’s privacy, strategies are not required to try all possible disclosures to satisfy an undisclosed policy. On the other hand, if accidental satisfaction happens, negotiation strategies should be able to take advantage of it and advance the negotiation toward potential success. Definition 6.7. Let S be a set of disclosed resources. For each resource R ∈ S, we replace the policy of R with R ← true. If a disclosure sequence is safe and visibly satisfiable under these revised policies„ then the sequence is visibly satisfiable with prefix S. Intuitively, if a resource has been disclosed, then we do not need to consider whether there is a visibly satisfiable sequence for it. This reflects the possibility of accidental satisfaction during a trust negotiation. Definition 6.8. Let s1 and s2 be two strategies adopted by Alice and Bob, respectively. Let R be an arbitrary resource of Bob’s that Alice requests to access, and let S be the set of credentials and policies they have disclosed so far. If for all choices of S, Alice can always gain access to R whenever there exists a visibly satisfiable disclosure sequence for R with prefix S, then we say that s 1 and s2 are weakly interoperable. Weak interoperability represents a good balance between trust establishment and privacy protection. Clearly, if two strategies are strongly interoperable, then they are also weakly interoperable given the empty 104
prefix. Compared with the definition of strong interoperability, weak interoperability further considers the effect of accidental satisfaction on the success of trust negotiation.
6.4.3 UniPro Trees Similar to our approach in chapters 4 and 5, next we present a conceptual data structure, called UniPro trees, to represent a trust negotiation under UniPro. Then we design a closed strategy family based on UniPro trees. Definition 6.9. Let S be a set of policy definitions. If there exists a sequence of policy IDs (P 1 , . . . , Pk ), k ≥ 2, such that Pi appears in content(Pi+1 ), for 1 ≤ i < k, and Pk appears in content(P1 ), then we say S is cyclic. Otherwise we say S is acyclic. Cyclic policies represent possible circular dependencies inside a single system’s access control requirements. Though sometimes cyclic policies can be transformed into acyclic ones, in general we believe it is not a good practice for a system to have cyclic policies. Therefore, in the rest of this thesis, for simplicity, we assume both parties’ policies are acyclic. In order to formally represent a trust negotiation, UniPro trees need to reflect the new kinds of disclosures, such as policy declaration disclosures and policy definition disclosures. Further, given two credentials C1 and C2 , there are two possible ways that C 2 may contribute to C1 ’s final disclosure. C2 can be in a minimal solution for C1 ’s policy P , i.e., C2 is relevant to the satisfaction of P . Or C 2 may be in a minimal solution for P , where P ← P , i.e., C2 is relevant to the visibility of P . The conceptual data structure needs to capture such a difference. Definition 6.10. A UniPro tree for a resource R is a finite tree satisfying the following conditions: 1. Each node represents a resource (a service, credential or policy) or else is one of the following two special nodes: a cached node or an uncached node. 2. The root represents the resource R. 3. There are two types of edges in the tree, satisfaction edges and visibility edges. 4. If a node N represents a service or a credential, it can have at most one child. The child represents a policy. The edge from N to its child is a satisfaction edge. 105
5. If a node N represents a policy, its children can be divided into two types. (a) It may have at most one visibility child, connected to N by a visibility edge. The child can either be a cached node or an uncached node. (b) It may also have one or more satisfaction children, connected to N by satisfaction edges. A satisfaction child can represent a service, a credential or a policy. 6. A cached node has no children. 7. An uncached node can have at most one child, which must be a policy node. The edge from an uncached node to a policy node is a visibility edge. A node is redundant if in the path from the root to this node, there is another node representing the same resource. A UniPro tree is redundant if it has a redundant node. Intuitively, the two special nodes represent two possible ways that the content of Alice’s policy P may become visible. First, Bob may possess a cached copy of P and disclose it during a trust negotiation, as reflected by a cached node. In this case, Bob does not need to disclose any credentials to see the content of P . That is why a cached node does not have any child. Second, if Bob does not have a cached copy of P or he does not want to disclose his cached copy in the current trust negotiation, he may also gain access to P ’s content by satisfying P ’s access control policy, as reflected by an uncached node. If the child of the uncached node is policy P , then P controls when P ’s contents become visible. In other words, we have P ← P . On the other hand, satisfaction edges reflect the satisfaction relationship between resources. If R represents a service or a resource and it has a satisfaction child P , then we should have R ← P . If R represents a policy P and we have P = P, then, intuitively, the satisfaction children of P form a minimal solution for P. In other words, if all the satisfaction children of P have been satisfied, then P is also satisfied. A policy node can have satisfaction children and also a visibility child, which will be useful when we discuss when to terminate a negotiation safely, i.e., without missing any chance to establish trust. Figure 6.1 shows some example UniPro trees that may appear in certain stages of a negotiation. Dashed edges represent visibility edges, while solid edges represent satisfaction edges.
106
Alice’s policies
Bob’s policies
R ← PA1 PA1 ← PA2 , PA1 = B1 ∨ PA3 PA2 ← true, PA2 = B3 PA3 ← PA4 , PA3 = B2 PA4 ← true, PA4 = B3
B1 ← PB1 PB1 ← PB2 , PB1 = A1 PB2 ← true, PB2 = A2 B2 ← true B3 ← true
T2 R
T1 R
T4 R
T3 R
PA1 B1 uncached PA2
PA1
PA1 PA3
B1
cached
B3
PA4
B2
PB1 A1
B3 uncached PB2 A2
Figure 6.1: Example UniPro trees Definition 6.11. Given a UniPro tree T and a set C of credential disclosures, consider the set N of nodes N in T that satisfy one of the following conditions: 1. N represents a credential in C. 2. N represents a policy that is satisfied by C. 3. N is an uncached node whose children represent policies that are satisfied by C. The satisfaction reduction of T by C, written satisf action_reduce(T, C), is the UniPro tree T obtained by removing all the subtrees rooted at nodes in N . Given a set T of UniPro trees, the satisfaction reduction of T , written satisf action_reduce(T , C), is the set {satisf action_reduce(T, C) | T ∈ T }. Intuitively, if a credential has been disclosed or a policy has been satisfied, then they are not relevant to the rest of the negotiation. Another type of reduction occurs when a policy disclosure happens. Since the content of the policy is now visible, its visibility is no longer relevant either. Definition 6.12. Given a UniPro tree T and a set S of policy disclosures, the visibility reduction of T by S, written visibility_reduce(T, S), is the UniPro tree T obtained by removing all the subtrees rooted at 107
a visibility child of a policy node P whose definition disclosure is in S. Given a set T of UniPro trees, the visibility reduction of T , written visibility_reduce(T , S), is the set {visibility_reduce(T, S) | T ∈ T }. As in our discussion of disclosure trees, we need to expand UniPro trees when policy declarations and policy definitions are disclosed. Definition 6.13. Given a non-empty UniPro tree T and a set S of non-denial policy declaration disclosures and policy definition disclosures, the expansion of T by S, written expand(T, S), is the set of all UniPro trees T such that 1. T can be obtained from T by removing some subtrees rooted at nodes in T . 2. For each satisfaction edge (N1 , N2 ) in T , if (N1 , N2 ) is not a satisfaction edge in T , then either N 1 represents a service or a credential and N 1 ← N2 is a policy declaration in S, or N 1 represents a policy P , P ’s definition P = P appears in S, and the satisfaction children of P form a minimal indirect solution for P. 3. Every non-redundant policy node P has a cached node or an uncached node as its visibility child N . If N is an uncached node and P ’s policy declaration is P ← P , then either N is a leaf and P ← P is not in S or else P is N ’s child. 4. If a nonredundant leaf node N represents a service or credential, then N ’s policy declaration is not in S. Given a set of UniPro trees T , expand(T , S) =
T ∈T
expand(T, S).
Though the definition of expansion for UniPro trees seems complex, there should be no difficulty for readers who survived chapters 4 and 5 to understand it. An example of UniPro tree expansion is shown in figure 6.2. Definition 6.14. Given a set T of UniPro trees and a set D of denial policy declaration disclosures and policy definitions of the form P = f alse, the denial pruning of T , written deny(T , D), is the set containing all the trees T in T that satisfy all the following conditions: 1. T does not contain any credential C where C ← f alse ∈ D. 108
T : R PA1
S includes the following disclosures: B1 ← PB1 , PB1 ← PB2 PB2 = A2
cached
B1 expand(T, S)
T1 :
T1 :
R
T1 :
R
PA1
PA1
PA1 B1
cached
R
B1
B1 cached
cached PB1
PB1
PB1 uncached
uncached cached
PB2
PB2
cached
A2
uncached
A2
Figure 6.2: Example of UniPro tree expansion 2. T does not contain any policy node P where P = f alse ∈ D. 3. For any P ← f alse ∈ D, if P appears in T , then P has a cached node as its only child. Intuitively, if Alice does not possess or will not disclose a credential C or a policy P , then C and P will not appear in any minimal visibly satisfiable sequence culminating in R’s disclosure. Since the UniPro trees in an expansion reflect all the possible ways to satisfy a resource’s policy, removing those trees involving inaccessible resources will not jeopardize our chance to establish trust successfully under weak interoperability. Even given P ← f alse, we do not discard any tree with node P whose child is a cached node. This represents our hope that the content of P may still be disclosed later through a cached policy disclosure. Due to a similar reason, we can also remove redundant trees without jeopardizing the success of a trust negotiation under weak interoperability. It is possible that Alice may accidentally satisfy a policy in the future without seeing the content of that policy, as in the example in section 6.4.2. However, if a negotiation must rely on such accidental 109
satisfaction to succeed, then there will be no visibly satisfiable sequence between the two parties with a given prefix. We can guarantee weak interoperability under UniPro without considering potential future accidental satisfaction in our definitions. This is why our definitions of tree pruning are so far-reaching. Definition 6.15. Given a set T of UniPro trees, the redundancy pruning of T , written redundant(T ), is the set {T | T ∈ T and T is not redundant}. If Bob informs Alice that he does not have a cached copy of policy P , then any visibly satisfiable sequence culminating in R’s disclosure will not involve a cached policy disclosure of P . Therefore, we can safely remove those trees where policy node P has a cached node as its visibility child. Definition 6.16. Given a set T of UniPro trees and a set N of uncached notifications, the uncached pruning of T by N , written nocache(T , N ), is the set containing all the trees T in T such that T does not contain any policy node P where P ’s visibility child is a cached node and uncached(P ) ∈ N . Definition 6.17. Given a disclosure tree T and a set D of denial policy declarations, a set S dec of nondenial policy declarations, a set S def of policy definitions, a set N of uncached notifications and a set C of credential disclosures, let S be the union of all the above sets. The evolution of T by S, written evolve(T, S), is nocache(redundant(deny(visibility_reduce(satisf action_reduce(expand(T, Sdec ∪ Sdef ), C), Sdef ), D)), N ). As a special case when T is the disclosure tree containing only a root node R, where R is the originally requested service, then we say evolve(T, S) is the set of trees of S, written trees(R, S). As readers may expect, the set of trees of a current negotiation serves as a indicator whether there is still hope for the two parties to establish trust. Formally, we have the following definition and lemma. Lemma 6.1. Let S contain all the disclosures Alice and Bob have made at a certain stage of a negotiation. If there exists a visibly satisfiable safe disclosure sequence for a resource R with prefix S, then either R ∈ S or there exists a UniPro tree T ∈ trees(R, S) such that all the credentials and policies in T appear in the sequence and are not disclosed in S. 110
Proof. Suppose R ∈ S. Let GS be the sequence of disclosures corresponding to S. Suppose the visible satisfiable sequence is G = GS (R1 , . . . , Rn = R). We prove the lemma by induction on n. When n = 1, R must be unlocked by credentials disclosed in S, or R must be a policy that the other party has cached. Then trees(R, S) contains a UniPro tree where the root node is the only node, or the root has a child which is a cached node (since uncached(R) ∈ S). In all three cases, the lemma holds. Assume when n ≤ k, the lemma holds. When n = k + 1, if R ∈ S, the lemma holds. Otherwise, consider the following situations: 1. R is a service or a credential protected by policy P . In this case, if (R ← P ) ∈ S, then trees(R, S) contains a single UniPro tree, whose root is its only node. The lemma holds. If (R ← P ) ∈ S, then the sequence GS (R1 , . . . , Rk ) is a visibly satisfiable sequence for P with prefix S. By the induction hypothesis, there is a UniPro tree T in trees(P, S) such that none of T ’s nodes represents resources other than those in (R 1 , . . . , Rk ). By attaching T to R as its subtree, we get a UniPro tree belonging to trees(R, S). The lemma holds. 2. When R is a policy P , similarly, if neither P ← P nor P = P belongs to S, then trees(P, S) must contain either a tree with a single node P or a tree where the root’s only child is a cached node, depending on whether uncached(P ) belongs to S. Either way, the lemma holds. If P = P is disclosed, then since the sequence is visibly satisfiable for P with prefix S, there is a minimal indirect solution for P in G. For each resource R in the solution, we either have R ∈ S or have a subsequence of G that is visibly satisfiable for R with prefix S. For the latter case, by the induction hypothesis, there is a UniPro tree T in trees(R , S) such that only resources in the subsequence appear in T . By attaching each such T to P , we get a UniPro tree for P which belongs to trees(P, S). If P ← P belongs to S but not P = P, then there is a subsequence of G that is visibly satisfiable for P with prefix S. By the induction hypothesis, there is a UniPro tree T in trees(P , S) such that each node in T represents a resource in the subsequence. By attaching T to P and letting P be the visibility child of P , we get a UniPro tree in trees(P, S). The lemma holds. In theory, a party may examine a UniPro tree to determine what further disclosures are helpful to advance a negotiation toward a potential success. 111
Definition 6.18. A UniPro tree T ’s evolvable leaves for Alice, denoted evolvable(T, Alice), are the set of leaf nodes N such that one of the following holds: 1. N represents a resource that belongs to Alice. 2. N is a cached node and the parent of N represents a policy that belongs to Bob. 3. N is an uncached node and the parent of N represents a policy that belongs to Alice. If evolvable(T, Alice) = ∅, we say T is evolvable for Alice. An evolvable leaf for Alice tells what Alice can possibly send in the next message so that a negotiation can advance. In definition 6.18, in case 1, Alice can either disclose R’s policy declaration or disclose R, depending on whether the negotiation is just beginning or R’s access control policy has been satisfied. For case 2, suppose the parent of the cached node represents policy P . Then Alice can check her cached policies to see if she has a copy of P . If she does, she may disclose policy P . Otherwise, she may send an uncached notification disclosure in her next message. Similarly, for case 3, suppose the parent of the uncached node represents policy P . Then Alice may disclose the policy declaration of P to Bob. To guarantee a successful negotiation whenever possible, Alice needs to make sure that after her next message, Bob does have at least one evolvable leaf, so that he can continue the negotiation — an idea with which the reader should be quite familiar by now.
6.4.4 The UniPro Tree Strategy As in chapters 4 and 5, in order to get a closed family, we will first identify the most cautious strategy s in the family. Then we prove that the set of strategies generated by s forms a closed family. Given Alice’s local policies and all the messages exchanged between Alice and Bob, one interesting question is whether Alice can be sure that it is safe to terminate a negotiation without violating weak interoperability. Let us look at an example. Suppose Alice has the following policy definitions and declarations.
R←P P ← true, P = P1 ∧ P2 P1 ← true, P1 = B1 P2 ← f alse, P2 = B2 112
Since P2 will never be disclosed and {P 1 , P2 } is the only indirect solution for R’s policy, there seems to be no visibly satisfiable safe disclosure sequence leading to R’s disclosure. However, if Alice does not receive uncached(P2 ) from Bob, Bob may possibly have a cached copy of P2 . Thus Alice cannot assume that she cannot establish trust under weak interoperability. On the other hand, if Bob does disclose uncached(P2 ) to Alice, then Alice can safely terminate the negotiation without worrying about violating weak interoperability. In general, unless Bob has disclosed uncached(P ), Alice must assume that Bob has a cached copy of her undisclosed policy P . Formally, we have the concept of Alice’s local trees, defined as follows. Definition 6.19. Suppose R is the resource to which access was originally requested. Let T be the UniPro tree with only the root node R. The local set of trees for Alice, written local_trees(R, S, L A ), is nocache(redundant(deny(visibility_reduce(satisf action_reduce(expand(T, Sdef ∪ ), D)), N ) Sdec ), C), Sdef
where • S is the set of all the disclosures made so far during a trust negotiation. • LA is the set of Alice’s local policy definitions, declarations and cached policies. • Sdef is the set of all the policy definitions and cached policies in S ∪ L A . • C is the set of all the credential disclosures in S. • Sdec is the set of all the non-denial policy declarations in S ∪ L A . • D is the set of all the denial policy declarations in S ∪ L A . is the set of all the policy definitions in S plus all of Alice’s the cached policies. • Sdef
• N contains uncached(P ) for all policy P such that either uncached(P ) ∈ S or P is Bob’s policy that appears in a policy declaration or definition disclosure in S and Alice does not have a cached copy of P .
113
Intuitively, Alice’s local trees assume that Bob can see all her policy definitions. In the above definition, we only calculate the visibility reduction of the policy definition disclosures in S and Alice’s cached policies. The reason is as follows. There are two ways that a negotiation may fail: either a party cannot see the content of a policy or a party cannot satisfy a policy. The purpose of the local set of trees is to help us check for both possible failures. If P ’s definition has not been disclosed, we still need to keep P ’s visibility child in the UniPro trees. Meanwhile, we add satisfaction children to P , according to P ’s definition. By keeping both types of children, we will be able to detect both kinds of failures in the pruning step. Lemma 6.2. Let S be the set of all the disclosures that have been made so far during a trust negotiation, and let LA be the set of Alice’s policy definitions, policy declarations and cached policies. If local_trees(R, S, LA ) = ∅, then there is a choice of Bob’s undisclosed policy definitions, policy declarations, uncached policies and credentials, such that there exists a visibly satisfiable disclosure sequence for R with prefix S. Proof. Let T ∈ local_trees(R, S, LA ). According to the definition of the local set of trees, any leaf node N in T is one of the following: 1. a policy node of Bob’s; 2. a credential node of Bob’s; 3. a credential node of Alice’s; 4. a cached node whose parent represents a policy of Alice’s; or 5. an uncached node whose parent represents a policy of Bob’s. N cannot represent a policy P of Alice’s, because if P is not satisfied by credentials in S, then P will have satisfaction children in T . If P is satisfied by S, then the subtree rooted at P will have been pruned out by the satisfaction reduction operation. In either case, P cannot be a leaf node. N cannot be a cached node whose parent represents a policy P of Bob’s because if Alice has a cached copy of P , then N will be removed during visibility reduction. If Alice does not have a cached copy of P , then N will be removed during uncached node pruning. In either case, N cannot be a leaf node.
114
N cannot be an uncached node whose parent represents a policy P of Alice’s because N should have P as its child in T , where P is the policy for P . We choose Bob’s resources, policy declarations and cached policies as follows. 1. Suppose N represents Alice’s credential C. Since C is a leaf node, we have C’s policy P has been satisfied by credentials in S, and C is unlocked. 2. Suppose N represents Bob’s credential C. If (C ← P ) ∈ S, then we choose C ← true. Otherwise, since C is a leaf node, C’s policy must be satisfied by credentials in S. In either case, C is unlocked. 3. Suppose N represents Bob’s policy P . Then P = P does not belong to S. Otherwise, since P is a leaf node, P must be satisfied by credentials in S. Then the node P should have been removed from T during the satisfaction reduction operation. Further, suppose P ← P . Then P is satisfied by credentials in S. Otherwise, P should have either a cached node or an uncached node as its visibility child. Since P = P is not in S, we choose P = true. 4. Suppose N represents a cached node whose parent is Alice’s policy P . Then we choose for Bob to have a cached copy of P . 5. Suppose N represents an uncached node whose parent is Bob’s policy P . Then we choose for Bob to have P ← true and P = true. Now let us consider the traversal of T as follows. For a credential node or a service node C, we traverse the subtree rooted at C’s satisfaction child before we traverse C. For a policy node, we first traverse the subtree rooted at its visibility child, except when the visibility child is a cached node. In this case, we traverse the node itself, i.e., the definition of the policy is disclosed. Finally, we traverse those subtrees rooted at the policy node’s satisfaction children. Let the resulting sequence of traversal of resources and policy definitions be G and let GS be a safe disclosure sequence containing exactly resources and policy definitions disclosed in S. Next we prove that the sequence GS G is a visibly satisfiable disclosure sequence for R with prefix S, by induction on the size of the tree. Suppose there are n nodes in the tree and the root is a node N . When n = 1, the root N is the only node in T . According to the way we chose Bob’s resources, if N represents a service or a credential of Bob’s or Alice’s, then N is unlocked by credentials in S. If N 115
represents Bob’s policy, then N = true and the policy P that protects N has been satisfied by credentials in S. Therefore the sequence GS (N ) is visibly satisfiable for the resource that N represents with prefix S. Assume when n ≤ k, the proposition holds. When n = k + 1, if the root N represents a service or a credential, then consider the subtree T rooted at its satisfaction child P . Since the size of T is no more than k, by the induction hypothesis, there is a visibly satisfiable sequence for P with prefix S. By appending N to the end of the sequence, we get a visibly satisfiable sequence for N with prefix S. If the root N represents a policy P , suppose P is the visibility child of P , and R 1 , . . . , Rt are the satisfaction children of P . By the induction hypothesis, for each child of P , there is a visibly satisfiable sequence for the child with prefix S. Let those sequences be G P , G1 , . . . , Gt , respectively. Consider the sequence GS GP (P ) G1 · · · Gt obtained by concatenating all the sequences together and putting P ’s definition disclosure after G P . According to the definition of visibly satisfiable sequences, the resulting sequence is visibly satisfiable for P with prefix S. The above lemma tells us that if Alice’s local set of trees is not empty, then Alice should not terminate a negotiation. Otherwise, we may cause a potentially successful negotiation to fail, given the disclosures that have been made so far. On the other hand, according to lemma 6.1, if Alice’s local set of trees is empty, then it is safe for her to terminate the negotiation. Based on the above two observations, we define the UniPro strategy as follows. Definition 6.20. Suppose Alice and Bob are the two negotiating parties. Let M = (m 1 , . . . , mk ) be a sequence of messages such that m i = ∅ and R ∈ mi for 1 ≤ i ≤ k. Let LA and LB be the local policy declarations, policy definitions and cached policies of Alice and Bob respectively. Let S M = 1≤i≤k mi . Assume it is Alice’s turn to send the next message to Bob. The UniPro tree strategy (UTS) is a strategy such that U T S(M, LA , R) satisfies the following conditions: 1. U T S(M, LA , R) = {∅} if and only if the following conditions hold: • trees(R, SM ) contains no evolvable tree for Alice. Or • local_trees(R, SM , LA ) = ∅. 116
2. Otherwise, U T S(M, LA , R) contains all messages m such that one of the following conditions holds: • m = {R}, if R’s access control policy is satisfied by credentials in S M . • m is a non-empty message containing safe disclosures such that trees(R, S M ∪ m ) contains at least one evolvable tree for Bob, and no non-empty proper subset of m has this property. Theorem 6.3. The set of strategies generated by UTS is a family under weak interoperability, i.e., any two strategies in the set are weakly interoperable. Proof. Suppose Alice and Bob adopt strategies s 1 and s2 respectively, and s1 and s2 belong to the set of strategies generated by UTS. We only need to prove that when the negotiation fails, there is no visibly satisfiable disclosure sequence for the requested resource R with prefix the set of resources disclosed so far. When the negotiation fails, without loss of generality, we assume it is Alice who sends the failure message. Suppose that before Alice sends the failure message, M = (m 1 , . . . , mk ) is the sequence of exchanged messages. Therefore mk is the latest message in M that Bob sent to Alice. Let L A and LB be the local policy declarations, policy definitions and uncached policies of Alice and Bob respectively. Let SM = 1≤i≤k mi . Since ∅ ∈ s1 (M, LA , R) and s1 U T S, we must have U T S(M, LA , R) = {∅}. According to definition 6.20, one of the following must be true: 1. trees(R, SM ) contains no evolvable tree for Alice. 2. local_trees(R, SM ∪ LA ) = ∅. When condition 1 holds but condition 2 does not hold, we must have U T S((m 1 , . . . , mk−1 ), LB , R) = {∅}. Otherwise, since s2 U T S and R ∈ mk , mk must be a superset of a minimal set m such that trees((R, SM −mk )∪m ) has at least one evolvable tree for Alice. This means condition 1 should not hold. Since U T S((m1 , . . . , mk−1 ), LB , R) = {∅}, then right before Bob sent mk , one of the above conditions was true for Bob and LB . Iterating this argument backward, we see that, since condition 1 does not hold at the beginning of the negotiation, condition 2 must have been true in some previous stage of the negotiation. When condition 2 holds, according to lemma 6.1, there is no visibly satisfiable sequence leading to the disclosure of resource R with prefix S M .
117
Theorem 6.4. If a strategy s and U T S are weakly interoperable, then s U T S. Proof. Suppose that Alice is the local party and is using s. Assuming U T S s, then there is a choice of M, LA and R such that ∃m ∈ s(M, LA , R) such that ∀m ∈ U T S(M, LA , R), m ⊆ m . Then both of the following must be true: • local_trees(R, SM , LA ) = ∅. • trees(R, SM ) has at least one evolvable tree for Alice. Otherwise, according to definition 6.20, U T S(M, LA , R) = {∅} and ∅ ⊆ m . Also, we have R ∈ m . Otherwise, R’s policy has been satisfied by S M and {R} ∈ U T S(M, LA , R). U T S(M, LA , R) contains all the minimal sets m of disclosures such that trees(R, S M ∪ m) has at least one evolvable UniPro tree for Bob. Since U T S s, trees(R, S M ∪ m ) has no evolvable tree for Bob. Thus, after sending m , UTS at Bob will send a failure message and end the negotiation. However, since local_trees(R, SM , LA ) = ∅, according to lemma 6.2, there is a choice of Bob’s undisclosed policy definitions, policy declarations and cached policies such that there is a visibly satisfiable disclosure sequence for R with prefix S M , which means that s is not weakly interoperable with UTS. We call the family generated by UTS the UTS family. By theorems 6.3 and 6.4, we get the following corollary immediately. Corollary 6.1. The UTS family is closed. Theorem 6.5. Let s1 and s2 be strategies in the UTS family and let s be a hybrid of s1 and s2 . Then s is also in the UTS family.
6.4.5 Cached Policies and Policy Definition Disclosures To use cached policies in trust negotiation, we must address several issues. First, there should be a way for Bob to determine whether he has a cached copy of a policy P of Alice’s. Second, Bob should be able to determine whether his cached copy is still up-to-date. Third, even if Bob has an up-to-date cached copy of P , Alice may claim that Bob’s cached copy is out-of-date and deny that Bob has satisfied the policy. We 118
should allow Bob to prove his possession of the right cached policy to an arbitrator when such a dispute arises. The basic idea of our approach to handling these problems is to require that each policy ID be associated with a hash of the policy’s contents. Such a hash may later serve as evidence that Bob possesses a cached copy of the right policy. In this section, we will extend the definition of policy-related disclosures to include such hashes. Let R ← P be a policy declaration belonging to Alice, where P = P. Let K Alice and KBob be the public keys of Alice and Bob respectively, let h be a one-way hash function, and let S Alice be Alice’s signature mechanism. Given a message M , KAlice (M ) denotes the encryption of M using key K Alice . • A policy declaration disclosure for R is the tuple (R ← P, h(P = P), h). Note that only the hash of P = P is disclosed, not the actual policy definition. Thus, from the above disclosure, Bob only learns that R has an access control policy P , whose definition hashes to h(P = P) under hash function h. • A policy definition disclosure of P from Alice to Bob is the tuple (P = P[, h(P = P), KAlice , KBob , h, SAlice (h(P = P), KAlice , KBob , h)]). The second part of the disclosure is optional, as indicated by brackets. The optional part is a cached policy certificate that Alice issues to Bob, stating that Bob has a copy of P ’s definition and that the definition hashes to h(P = P) under hash function h. The cached policy certificates let Alice control whether Bob can cache P . A cached policy certificate only contains the hash of the content of P . The benefit is two-fold. First, the hash value of a policy is much smaller than P = P. Second, even if the certificate is intercepted by a third party, the content of P will not be leaked. The one-way hash function h guarantees that it is hard for an attacker to find the content of P = P from its hash value. In practice, when there are standard policies widely distributed to prevent unnecessary disclosures of common credentials and resources, e.g., one’s driver’s license and one’s credit card numbers, an attacker may launch a dictionary attack to recover the content of P by hashing every commonly used policy and comparing it with the hash value in a policy declaration disclosure. To protect against such an attack, Alice may append a pseudorandomly generated bitstring with appropriate length before hashing P = P , which is a salting technique commonly used to circumvent dictionary attacks. 119
• Suppose Bob has a cached copy of the definition of Alice’s policy P . Then a cached policy disclosure from Bob to Alice is the 5-tuple (h(P = P), KAlice , KBob , h, SAlice (h(P = P), KAlice , KBob , h)). Essentially, Bob sends his cached policy certificate to Alice and proves that he has a cached copy of P. When Bob receives a policy declaration disclosure (R ← P, h(P = P), h), he can use the hash function h and the hash value as a key to determine whether he possesses a copy of P . If he does, he can prove so by sending the certificate back to Alice. After that, a mutual authentication needs to be conducted to show that Alice and Bob do possess the corresponding private keys for K Alice and KBob respectively. At this point, Alice believes that Bob does have a copy of P and may consider P to have been disclosed during the negotiation. If Bob does not have a certified cached copy of P , even if he knows, for example, P = B1, and asks Alice to satisfy B1’s policy, Alice may choose not to respond. Therefore, Alice can control whether a policy definition disclosure can be cached by others and used later. The hash of P = P in a policy declaration disclosure serves as a key for Bob to identify the correct cached copy of P , and can also be considered as Alice’s commitment to P ’s definition. When Bob discloses credentials that satisfy P , Alice cannot claim that P is not satisfied, because the hash value guarantees that Bob’s copy of P is the same as Alice’s. In case a dispute arises over whether P is satisfied, Bob may present an arbitrator with his copy of the policy, the policy declaration disclosure (R ← P, h(P = P), h) from Alice, the cached policy certificate and the credentials he has disclosed, which will prove he is entitled to gain access to R. If Alice gives a cached policy certificate to Bob, she wants Bob to use it to accelerate future trust negotiations. However, Alice may want to prevent a party from using cached policies if, for example, Bob’s private key has been compromised. This can be easily achieved by appending to the policy a different pseudorandomly generated bitstring before a policy declaration disclosure is made. If this is done, Bob will not be able to determine that he possesses a cached copy of P . The problem of cached policies will become complicated if we want to support the delegation of cached policies, i.e., Alice gives Bob the authority to transfer a cached policy to a third party Carol, with whom she 120
may never have negotiated trust before. For example, in the medical record example shown in chapter 6.2, McKinley Clinic may give Alice a cached copy of the policy for access to her medical record. Alice needs to transfer the cached policy to a social worker Carol before Carol can negotiate trust with McKinley Clinic and gain access to Alice’s record. In general, the delegation of cached policies can be handled in a way similar to credential distribution and credential chain verification in X.509. Besides telling Carol the content of the cached policy, Alice also issues a credential to Carol, which is signed by Alice and certifies the transfer of the policy to Carol. Later on, Carol may prove that she knows the content of the policy by presenting both the cached policy certificate issued to Alice by McKinley Clinic and the policy transfer certificate issued by Alice. A detailed design of the delegation protocol is a topic for future work. Typically, a cached policy represents a certain relationship between two parties, which may be quite sensitive information. For example, if Alice has any cached policies from the CIA, then we can infer with high confidence that Alice has a relationship with the CIA. How to prevent unintended leakage of such information in UniPro is another important topic that needs to be addressed in future work.
121
Chapter 7
Attacks on Trust Negotiation Like any open system connected to the Internet, trust negotiation may be subject to a variety of attacks launched against different aspects of the system. In this chapter, we give an overview of possible attacks on trust negotiation and counter-measures against them. Information exchange in trust negotiation relies on a secure communication channel between negotiation participants. Thus, any attacks against communication channels may also be launched against trust negotiation, e.g., eavesdropping, replay attacks, man-in-the-middle attacks and impersonation. Many techniques have been proposed in the literature and widely adopted in real systems to provide secure communications against the above attacks, which can be easily adopted in trust negotiation. Currently researchers in the Internet Security Research Labs at Brigham Young University are investigating efficient ways to integrate trust negotiation into a variety of communication protocols, such as SSL/TLS [38, 33, 37, 70, 44], SOAP [17] and IPsec [5]. An attacker may also attack trust negotiation systems through the underlying credential infrastructures, such as credential forgery and theft. Credential forgery and theft can be effectively addressed through advanced digital signature and authentication techniques For example, it has been proposed to integrate one’s biometrics into digital credentials [14, 68]. Since a party may have multiple identities acquired from different security domains, attackers may pool their credentials together to get a service that each of them separately cannot get. For example, suppose the access control policy for a car rental discount requires that a customer be a driver in Champaign, Illinois and be a graduate student at the University of Illinois. Alice is a driver in Illinois, i.e., her driver’s license is issued by the Department of Motor Vehicles in Champaign, Illinois, but she is not a graduate student. Carol,
122
on the other hand, is a graduate student at the University of Illinois, but her driver’s license has just been revoked due to driving under the influence of alcohol. Clearly, neither Alice nor Carol can get the discount. However, by pooling their credentials together, they may be able to convince Bob’s car rental company, that they are one entity, who is therefore qualified to get the discount. They can do this by presenting Alice’s driver’s license and authenticating to the identity (driver’s license number) on that license, and presenting Carol’s student ID and authenticating to that identity (student number) also. The authentication procedures will typically require them to demonstrate knowledge of the private keys associated with the public keys associated with those two identities. One extreme form of credential pooling is for Alice to tell her private key for her driver’s license to Carol, which is also called credential lending or transferring. Many cryptographic techniques have been proposed to prevent credential pooling, especially in the context of anonymous credential systems [26, 27, 29, 65, 22, 21], which otherwise would offer few deterrents to pooling and lending. One of the approaches [22] assumes that everybody has a master secret, which is embedded into all of their credentials. When Alice presents multiple credentials, Bob is able to verify whether the master secrets embedded in all the credentials are the same. If Alice and Carol collude by pooling their credentials together, since the master secrets in their credentials are different, the pooling will be detected by Bob. Another technique to deter credential lending, i.e., Alice sharing her private keys with Carol, is to include Alice’s very sensitive private information (e.g., her credit card number and social security number) in each of Alice’s credentials, encrypted with her public key, so that giving out her private key is equivalent to giving out this sensitive private information [36, 40, 65]. Denial-of-service is a natural attack on trust negotiation at the application level. For example, an attacker may initiate a large number of sessions of trust negotiation with the server, and disclose either very complex policies or many credentials to the server. The purpose of such an attack is to cause the server to expend an excessive amount of computational resources so that the server cannot conduct normal trust negotiations with other clients. Defending against denial-of-service attacks is a very hard problem, especially when they are launched in a distributed manner by a group of coordinated attackers. Recently, client puzzles have been proposed as a technique to defend against distributed denial-of-service attacks [ 52, 32, 82]. The idea is to require a client to accept a puzzle from the server and solve it before the client can conduct further interaction with the server. This approach forces an attacker to do a lot of computation itself, limiting the possible scale of an attack. 123
Hardware attacks become relevant when smart cards are used as thin clients in trust negotiation. There are two classes of attacks against smart cards: active attacks and passive attacks. In active attacks, an attacker tries to physically alter or manipulate a smart card. For example, an attack may try to increase voltages to chips in order to clear security bits while keeping other sensitive information intact. In passive attacks, an attacker tries to recover keys in a smart card through observing information leaked through side channels, such as power comsumption, timing and error messages [57, 55]. Many techniques have been proposed to protect smart cards, such as reduction of size and power consumption of smart cards, introduction of unpredictable variations on software execution behavior, and secure operating system support [ 91]. As indicated by Schneier [76], people are often the weakest links in the security chain of a system. It has been shown that social engineering is still the best way to crack the security of a system [ 60]. Many users can be easily tricked into revealing their passwords and PINs to another person over the phone or in instant messages, without conducting any form of authentication. There seems to be no easy way to prevent social engineering attacks, other than effective training and awareness of such attacks among users. Though we have introduced the concept of negotiation protocols, in a highly decentralized environment, it is very hard to enforce adherence to those protocols. A malicious user may lie about the protocols that they use, or the families of their strategies that they adopt. To deter acts, policies and negotiating parties can make use of reputation services [30, 59]. Through a negotiation feedback mechanism, malicious users can quickly acquire a bad reputation. One’s reputation can be encoded in a credential that can be referred to in a policy. Another major type of attack on trust negotiation is the violation of individual users’ privacy. Ideally, a user’s private information should flow to others under the awareness and consent of the user. In practice, however, such a goal is very hard to fulfill. Next we list some of the possible ways that one’s privacy may be violated. Private information propagation Once a trust negotiation is finished, no matter whether it is successful or not, Alice has gathered some information about Bob. After this point, it is hard for Bob to control how the gathered information will be used by Alice. Alice may actively initiate trust negotiation with others with the purpose of collecting information instead of establishing trust. She can later either sell the information to an online marketing company or simply make it public. As an example, consider the online-project-document example shown in chapter 6.1. By using UniPro, we are able to 124
protect a user from knowing the sensitive constraints of the document’s access control policy during trust negotiation. However, if all the users who negotiate trust with the server share their experience with others, they may find out that whenever a user’s employee ID is issued by IBM or by Microsoft, access to the documents is granted. Thus, sensitive information has been recovered due to information propagation and sharing. Though the P3P standard [81] enables an individual to be aware of the privacy practice policy of a server before disclosing her sensitive information, it is difficult to check how well that policy is enforced. Also, trust negotiation makes it possible for any individual to be an information collector, which causes P3P to be not quite applicable. Many researchers have observed that the use of unlinkable pseudonymous credentials can alleviate this problem [21]. Besides specifying P3P policies, it is becoming an increasing concern for companies and organizations to effectively enforce privacy practice policies. In [3], Agrawal et al. presented a server-centric approach to enforcing P3P policies through query translation and rewriting in databases. Agrawal et al. [2] also proposed principles for designing databases that enforce a company’s privacy policies. Karjoth et al. [53] proposed a privacy-centric access control language and designed an architecture for privacy policy enforcement in the entire life cycle of customers’ information, based on the principle of separation of duty. Only with controls like these in place can a customer have some confidence that her private information will be handled in a certain way. Her policies for her private information may need to ask the other party for certification that a particular suite of privacy practice enforcement tools is in use at that party. Information gathering and analysis Once Alice has gathered enough information from Bob, she may be able to infer more sensitive information about Bob through the seemingly insensitive information. For example, if Alice knows Bob’s address, which is located near the center of the campus of a university, then she may reasonably infer that Bob is a student in the university and his age is probably in the range of 18 to 30. Such inferences will be much more powerful when information from multiple sources or credentials is collected. Inference prevention techniques developed by the database community, such as those proposed in [9, 10, 25, 34], can be applied. However, many of those techniques require tracing a user’s knowledge of an entity in order to effectively prevent inference. This is especially 125
hard in the context of trust negotiation, where Alice and Bob are usually from different organizations and do not have identities in the same security domain. Further, Alice may assume identities from different domains during different interactions with Bob, which makes it hard for Bob to tell whether he is interacting with the same person during different trust negotiations. It is also impractical for an individual to keep track of every interaction with all others. Linkable behavior If Alice discloses her identities during trust negotiation, then it is possible for a server or a set of colluding servers and credential issuers to link her different sessions of trust negotiation together, so that her behavior in the set of transactions can be analyzed, without her consent. Unlinkability is an important design goal of anonymous credential systems. In the anonymous credential system proposed in [22], Alice obtains a pseudonym when getting a credential from a security domain. The pseudonym is embedded into the credential in such a way that Alice never needs to disclose the pseudonym when proving her possession and the validity of the credential. Therefore, even if a collusion exists among credential issuers and the parties negotiating trust with Alice, they will not be able to link together different sessions of trust negotiation conducted by the same user. Extraneous information gathering One simple way for an attacker to gather excessive private information from users is to set up a phony web page, which claims to offer a very attractive deal. However, the access control policy for the deal may require many credentials, such as one’s library cards, health club cards and apartment rental contracts, which are totally irrelevant to the service. One way to handle such a violation of one’s privacy is to scope the disclosure of credentials. For example, Alice may divide possible online transactions into several categories such as auctions, health care transactions and e-book downloading. She can then specify credentials relevant to transactions in each category. Therefore, when an attacker asks for a credential irrelevant to a transaction, Alice will refuse to disclose it even if the attacker has satisfied the access control policy for that credential. Information inference through observing one’s behavior Ideally, Alice’s sensitive information should not be known by others unless its corresponding access control policy is satisfied. However, there are pitfalls in the basic model of trust negotiation that can be exploited by an attacker to infer Alice’s private information through observing her behavior, i.e., her response to an access control policy. For example, suppose an attacker, Bob, asks Alice to prove that her age on her driver’s license is over 21. If 126
Alice responds with the policy for her driver’s license, then Bob is able to infer with high confidence that Alice’s age is probably over 21. On the other hand, if Alice terminates the negotiation, then Bob will know that her age is very likely to be less than 21. In either case, sensitive information is leaked even though Alice’s access control policy for her driver’s license is enforced. We have proposed two techniques, policy filtering and policy migration, as approaches to preventing such inferences. We will discuss them in detail in chapter 8. Alice’s behavior can also leak other information. For example, by observing what information Alice chooses to disclose in a negotiation, it may be possible to guess what strategy she is using or not using. For example, she might be using a strategy that performs little computation but makes irrelevant disclosures. Such a strategy may be popular among mobile computer users. By observing the irrelevant disclosures and coupling this with other information, the other party may be able to guess Alice’s current location or destination. To guard against this kind of attack, Alice can switch randomly between strategies in the same family. (The main families studied in this thesis allow such switching.) The price of this additional privacy, however, is that Alice may be unable to tailor her strategic decisions to her own needs.
127
Chapter 8
Privacy Preservation in Trust Negotiation Access control policies play a central role in protecting one’s privacy. Ideally, Alice’s sensitive information should not be known by Bob unless Bob has satisfied the corresponding access control policy. In automated trust negotiation, each resource that may be disclosed is associated with an access control policy, specifying under what circumstances that resource can be disclosed. The underlying assumption is that if a resource is not disclosed, information in that resource will not become known to others. However, depending on the way two parties interact with each other, one’s private information may flow to others in various forms. Though resource disclosures are the major form of information flow, controlling disclosures alone is far from sufficient for providing strong protection for users’ private information. Let us revisit the online transaction example shown in chapter 2, which we repeat here. Suppose Alice is a graduate student who wants to buy textbooks at the beginning of a semester. She surfs the web and finds a good deal from Bob, who is the owner of a small online book store. Bob offers a special discount to graduate students whose GPA is over 3.0. The negotiation process may look as follows. Step 1 Alice requests the special discount for this transaction. Step 2 Bob replies with the policy for the discount, requesting Alice to show 1) her student ID to prove that she is a graduate student; and 2) her official transcript to prove that her GPA is over 3.0. Step 3 Alice does not mind showing her student ID to others. But her official transcript contains some quite sensitive information. Besides disclosing her student ID, she also tells Bob that in order to see her official transcript, Bob must prove that his online book store belongs to the Better Business Bureau. Step 4 Fortunately, Bob does have a Better Business Bureau membership card. And he is willing to tell 128
anybody this fact. So he discloses his BBB membership card to Alice. Step 5 At this point, Alice knows that she can trust Bob and discloses her official transcript to Bob. Step 6 Now Bob has received both Alice’s student ID and her official transcript. After verifying that she is a graduate student and her GPA is over 3.0, Bob gives Alice the special discount for this transaction. Once Bob tells Alice his access control policy for getting the discount, normally Alice will check her own credentials and see whether she can satisfy Bob’s policy. If she can, since her official transcript is sensitive, she will respond with her policy for that credential, as happened in step 3. On the other hand, if she cannot satisfy Bob’s policy, a natural behavior is for Alice to terminate the negotiation, since it does no good to waste time on a negotiation that will definitely fail. However, by merely observing Alice’s response to the policy, Bob can easily infer whether her GPA is over 3.0, even though her official transcript is not disclosed yet. The main reason for such information flow is the overly strong semantics of the current interaction model of trust negotiation. When disclosed, an access control policy P is in effect a query, asking whether the other party possesses the right credentials to satisfy P. One’s behavior thereafter serves as a “yes/no” answer to the query, which is not protected by access control policies at all. From the above analysis, it seems we have two possible strategies to solve this problem — assigning a weaker semantics to users’ behavior or using additional policies to control when to make a response. In this chapter, we identify desiderata for this kind of inference prevention in trust negotiation. Then we analyze the pros and cons of existing approaches according to the desiderata. Following that, we introduce policy filtering and policy migration as approaches to inference prevention, and discuss their advantages and limitations.
8.1 Privacy Vulnerability in Trust Negotiation As in chapter 5, we model a credential as a set of attribute-value pairs {C.a 1 = v1 , . . . , C.ak = vk }, where ai is an attribute (field) name and v i is an atomic uninterpreted value for that attribute, for 1 ≤ i ≤ k. C is a locally-assigned name for the credential, such as a random number. Credential names should not give away any information about credential contents, and may be changed between negotiations. Each credential will 129
contain an issuer field and will typically refer to one or more entities by their public keys, such as through an owner_publickey field. When Bob receives a credential from Alice, he may go to a public credential server to get the public key of the issuer, then use it to verify the signature of the credential. Further, Bob can generate challenges according to the owner_publickey and verify that Alice is actually the owner of the credential. In [79], Seamons et al. identified two types of privacy vulnerability. The first type is called attributesensitive credentials. The GPA vulnerability discussed at the beginning of this chapter belongs to this type. Suppose Alice’s credential has an attribute (e.g., birth-date, address or social security number) whose value is considered sensitive. In the basic interaction model for trust negotiation described in chapters 4 and 5, if Bob’s access control policy P specifies a constraint on that sensitive attribute, then depending on whether Alice issues a counter request in response to P, Bob can infer whether Alice owns a credential satisfying that constraint. Through a series of probes similar to a binary search, this vulnerability can be exploited to determine the exact value of a sensitive attribute such as one’s age or credit rating. If Alice considers an attribute to be sensitive, then given a constraint P on that attribute, typically, no matter whether the value of the attribute can satisfy P or not, her response after she receives P should be considered sensitive. Therefore we call this symmetric sensitivity. Another property of sensitive attributes is that only the value of the attribute is considered sensitive. For example, Alice does not mind Bob knowing that her driver’s license has a birth_date attribute. The second type of vulnerability, which is identified in [79] and [86] independently, is called possessionsensitive credentials, i.e., the fact that Alice has or does not have a certain credential is considered sensitive. As an extreme case, suppose an attacker Eve wants to find out who works for the CIA, which is considered very sensitive information. She may set up a web page claiming to offer a very attractive deal. When Alice wants to get the deal, Eve replies with an access control policy asking Alice to show a credential issued by the CIA to her. If Alice responds with a policy (possibly a very restrictive one), then Eve will infer that Alice is connected to the CIA, because otherwise, Alice would just terminate the negotiation and leave. Sometimes, the fact that Alice does not possess a credential may also be sensitive. For example, before a cautious patient gets advice from an online medical clinic, she may want to verify that the doctor in the clinic does have a valid medical practice license issued by a state board of medical practice. Any decent clinic will be more than willing to show the license. If the clinic chooses to terminate the negotiation after 130
being asked for the license, the patient can infer with high confidence that the clinic is phony. The sensitivity shown in the above two examples is not symmetric. If a person is not connected to the CIA, she will be unlikely to mind others knowing that (after all, many people do not want to have anything to do with covert agencies). In this case, non-possession is typical, natural and not sensitive. In the second example, a qualified doctor should be willing to show her medical license to anybody who wants to see it. Thus possessing such a credential is not sensitive at all. Due to this property, we call sensitivity in this situation asymmetric sensitivity. As mentioned earlier, there are two basic strategies to provide stronger protection for users’ privacy in trust negotiation — assigning a weaker semantics to users’ behavior or using additional access control policies to control when to make a response. However, no matter what our approach is, privacy protection is not the only concern. Recall that the primary goal of trust negotiation is to establish trust between strangers. There is potentially a conflict between success in trust establishment and privacy preservation. For example, one may be extremely cautious and act in a very passive way — only disclosing credentials when their policies are satisfied and never responding with any counter requests. This approach guarantees that the above vulnerabilities cannot be exploited. But meanwhile, it may result in unnecessary credential disclosures (as did the eager strategy introduced by Winsborough et al. [88]) or premature termination of a potentially successful negotiation, missing valuable business opportunities. On the other hand, the negotiation protocols proposed in chapter 4 and chapter 5 guarantee successful trust establishment whenever possible, but are subject to information leaks. It is desirable to find a balance between these requirements. To do so, we have identified the following desiderata for privacy protection in trust negotiation. 1. The privacy protection scheme should be easy to deploy in existing trust negotiation systems. The management overhead imposed on human users should be as low as possible. Ideally, a human user should only have to specify access control policies and what credentials are considered attributesensitive or possession-sensitive. With such information, there should be a general algorithm that dictates what a security agent needs to do to protect those sensitive credentials. 2. Whenever possible, the privacy protection scheme should avoid relying on pre-arranged coordination of a large group of parties. For example, one way to protect possession-sensitive credentials is to have a large group of parties agree to respond in the same way when asked to show a certain cre131
dential, no matter whether they think that credential is possession-sensitive or not. The deployment of such an approach may require significant management effort, especially in widely decentralized environments. 3. Avoidance of unnecessary failure of trust negotiations should also be considered when a privacy protection scheme is adopted. For example, we should avoid approaches where a trust negotiation always fails whenever an attribute-sensitive or possession-sensitive credential is involved.
8.2 Attribute-Sensitive Credential Protection Seamons et al. [79] have suggested that the concept of policy graphs be extended to protect requesters’ privacy. When a requester responds to the disclosure of the source node of a policy graph, the other party will not be able to infer whether the requester can satisfy the constraints in the other policy nodes in that graph. Based on this observation, when receiving a policy P, the requester can first pass P to a policy mediator. The mediator is responsible for organizing P into a policy graph G such that the source node of P does not contain any constraints on the requester’s sensitive attributes. Then only the source node of G is passed to the security agent of the requester. For example, suppose an online liquor store’s policy graph is buying_liquor ← x.type = “driver’s license” ∧ x.issuer = “DMV” ∧ x.age ≥ 21 1 and the requester, Alice, is sensitive about her age. Alice’s mediator will transform the policy into the following policy graph (as shown in figure 8.1): buying_liquor ← x.age ≥ 21 ← x.type = “driver’s license” ∧ x.issuer = “DMV” and only pass x.type = “driver’s license” ∧x.issuer = “DMV” to Alice’s security agent. If the store is aware of the existence of such a mediator, then even if Alice sends back a counter request, the store can only infer that Alice does have a valid driver’s license (which Alice does not consider to be sensitive information) but nothing valuable about her age. In this section, we generalize the proposal of Seamons et al. [79] into a policy filtering mechanism. 1
In practice, the constraint on the credential’s age attribute should be expressed as a comparison between the credential’s birth_date attribute and a specific date. Also, we need to specify that the other party should authenticate to the owner of the credential. We omit such detailed constraints in order to focus on the issue of sensitive credentials.
132
buy_liquor
x.type =“driver’s license” ∧ x.issuer = “DMV” ∧ x.age ≥ 21
transformed by Alice’s mediator
buy_liquor
x.age ≥ 21
x.type = “driver’s license” ∧ x.issuer = “DMV” ∧ x.age ≥ 21
Figure 8.1: Policy transformation when the age attribute in Alice’s driver’s license is sensitive Definition 8.1. Let A = {a1 , . . . , ak } be the set of Alice’s sensitive attributes and let P be a policy. The filtering of P by A, denoted as f ilter(P, A), is the policy obtained by replacing each attribute value restriction r in P by true if the restriction involves an attribute a ∈ A. Alice specifies the set A of attributes she considers sensitive. Whenever she receives a policy P from Bob, she only evaluates f ilter(P, A) and sends her response accordingly. Since the filtered policy does not have constraints on sensitive attributes, Alice’s response to the policy will be the same no matter what values she has for those attributes. Therefore, Bob cannot infer values of her sensitive attributes. One interesting question is what happens if f ilter(P, A) = true. If this is possible, we cannot expect Alice to act as if the policy has already been satisfied. There are two key observations that ensure that a filtered policy cannot be true. First, any non-trivial policy P should contain restrictions on issuers. Otherwise, Alice can simply issue herself credentials satisfying P, which makes P always satisfiable 2 . Second, if Alice considers the identity of the issuer of a credential to be sensitive, then the credential is possession-sensitive, as shown in the example of finding people connected to the CIA (section 8.1). We will 2 Some researchers [15] consider self-certified information, e.g., one’s food preference when booking a flight ticket online, as special certificates. Even in this situation, for the purpose of accountability, a service provider has to specify that the issuer of such special certificates is the user herself.
133
discuss possession-sensitive credentials in section 8.3. Next we analyze the policy filtering approach according to the three desiderata. 1. Policy filtering is easy to deploy in a trust negotiation system. Alice only needs to tell her security agent which attributes are sensitive. The policy filtering algorithm is straightforward, thus can be easily implemented in a security agent. Of course, sometimes it may not be easy to figure out exactly which attributes are sensitive, because of the semantic relationships between one’s attributes. However, this is a basic problem for database security, and how to address it is out of the scope of this thesis. 2. Policy filtering does not require the coordination of a group of users. The protective power comes from the fact that Alice omits constraints on her sensitive attributes when responding to a policy. The decision on which attributes are sensitive is totally up to Alice. 3. The success of a trust negotiation will not be jeopardized by policy filtering. If a set C of credentials satisfies policy P, then C also satisfies f iltering(P, A) for any A. Therefore, Alice will not terminate a negotiation that may potentially succeed. On the other hand, the filtering process decreases the selectivity of a policy. Sometimes a filtered policy may become so general that there are many possible ways to satisfy it. This will result in many rounds of messages being wasted on credentials that are actually not relevant for the success of a trust negotiation. However, we believe that this is a reasonable tradeoff in order to protect one’s privacy. As discussed in chapter 5, when trying to satisfy Bob’s policy P, Alice needs to bind a credential C to P, indicating that C is relevant to P. If we introduce policy filtering into trust negotiation, variable binding needs to be extended. Otherwise, Bob may believe that P has a minimal solution including C when this is not the case. To prevent this dispute, we may extend the TrustBuilder protocol 2 to include variable bindings with policy filtering. In other words, when Alice filters Bob’s policy P, she will tell Bob so in her variable bindings to P. By doing so, Bob may understand that Alice may not be able to satisfy P even though she binds C to P. One problem is that if Alice intends to extract extra information from Bob, she may require Bob to satisfy the policies of arbitrary irrelevant credentials through variable bindings with policy filtering. However, as we argued above, the constraints on the issuer of an attribute-sensitive credential are not filtered during policy 134
filtering. If a credential C is relevant to f ilter(P, A), then C must satisfy P’s constraints on C’s issuer. Therefore, if Alice claims that a credential can be bound to policy P with policy filtering and later Bob finds that the credential cannot satisfy P’s constraints on the credential’s issuer, Bob will be able to detect the attack. In other words, Alice’s attack can only work well if she has a lot of credentials whose issuers satisfy P’s constraints on credentials’ issuers. Overall, policy filtering is an effective yet light-weight approach to protecting one’s attribute-sensitive credentials. We believe it can be incorporated into trust negotiation systems as a basic mechanism to protect users’ privacy in trust negotiation systems.
8.3 Possession-Sensitive and Non-Possession Sensitive Credential Protection Seamons et al. [79] proposed non-response as a way to protect possession-sensitive credentials. For example, suppose Alice works for the CIA. If Bob requires that Alice show a credential issued by the CIA before she can access Bob’s service, Alice will not respond to that request, as if she does not possess such a credential. She can disclose the credential later when Bob happens to disclose the right credentials that satisfy the policy for disclosing her CIA credential. This approach is easy to deploy in trust negotiation and does not rely on the cooperation of a large group of other users. But clearly a potentially successful negotiation may fail because of Alice’s conservative response. Similarly, for credentials where non-possession is sensitive, Seamons et al. [79] proposed to act as if one has that credential. For example, if Alice’s driver’s license has been revoked due to driving under the influence, she may assign a policy P to a “virtual” driver’s license. When Bob requires Alice to show her driver’s license, Alice responds with policy P. Only after P is satisfied by Bob will Alice tell Bob that she actually does not have a valid driver’s license. Therefore, the policy P actually specifies under what circumstances Alice can tell others that fact she does not own a driver’s license. This approach works fine in this example, because typically even if an individual has a valid driver’s license, she will still have a policy to control to whom it can be disclosed. But for credentials that most people are willing to show to anybody (e.g., a company’s Better Business Bureau membership certificate), this approach is not effective. The fact that there is a policy associated with Alice’s BBB certificate strongly indicates that Alice actually does not 135
belong to the BBB. Winsborough’s and Li’s approach [86, 85] is based on the principle, “Discuss sensitive topics only with appropriate opponents”. Their framework focused on protecting one’s roles (which are also called attributes in their work). For example, being an CIA agent is a role. Therefore, protecting the fact that a user has a CIA agent role in their framework is the analogue to protecting the fact that that a user has an agent credential issued by the CIA in our framework. In their approach, for each sensitive credential, no matter whether Alice possesses it or not, she has an acknowledgment policy (an ack policy). Alice only acknowledges whether she has a credential or not after the corresponding ack policy is satisfied. The management overhead of this approach is high. For each sensitive credential Alice possesses, she now needs an access control policy for its disclosure and also an ack policy to determine with whom she can discuss this credential. And it is widely known that designing and maintaining good policies is a hard task, especially for individual users. Further, as for the approaches proposed by Seamons et al. in [79], ack policies are not effective in protecting credentials that most people do not have or are willing to show freely. To make it work for those credentials, we have to organize a large group of users who agree to act in the same way to protect the interests of a small portion of the people. In fact, if a CIA credential is the only credential Bob requires from Alice, then without the pre-arranged support of a large group of users, there is no way that Alice can protect the fact that she possesses one without jeopardizing the success of her negotiation. The reason is that people without a CIA agent credential will simply admit it and terminate the negotiation. Any other action Alice takes will directly reveal the fact that she does possess the credential. However, if a CIA credential is not the only required credential, can Alice protect her possessionsensitive credentials without jeopardizing the success of a negotiation, even without the cooperation of a large group of users? The basic idea of our approach is to integrate sensitive credentials’ policies into the policies of other credentials that are relevant to the negotiation but are not sensitive. Such an approach makes it hard for an attacker to automatically distinguish the behavior of a party who possesses sensitive credentials from that of those who do not. On the other hand, the policies for sensitive credentials are still implicitly enforced during trust negotiation. Thus, users’ access control safeguards are not compromised. Since we are dealing with possession-sensitive credentials, for simplicity, in this section we model cre136
dentials and resources as uninterpreted symbols, as we did in chapters 3 and 4. To begin the discussion, we assume that Alice has only one possession-sensitive or non-possession sensitive credential, denoted C ∗ . For simplicity, we further assume that C ∗ only appears in the policy of R, the resource that Alice originally tried to access. We will revisit these assumptions at the end of the section. We also assume that policies can be freely disclosed. If C∗ is a possession-sensitive credential of Alice’s, then we consider the following scenario: Alice has C∗ ← P , where P is not logically equivalent to true, while all the other users do not possess C, i.e., they have C∗ ← f alse. Note that in practice, Alice may not be the only person who possesses C ∗ . However, since we assume that there is no large group of cooperating users, effectively Alice is on her own. Similarly, if C∗ is a non-possession sensitive credential of Alice, then Alice has C ∗ ← f alse and a second policy P to control to whom she is willing to disclose this denial policy of C ∗ , which suggests to others that she does not possess C ∗ . Meanwhile, all the other users have C ∗ ← true.
8.3.1 The TrustBuilder-Relevant Strategy and the Disclosure Tree Strategy In this section, we describe two strategies in the DTS family presented in chapter 4, which will be useful when we discuss protection for possession-sensitive and non-possession sensitive credentials. The first strategy is a version of the TrustBuilder-Relevant Strategy, which works as follows. After Alice receives a message from Bob, Alice identifies the set m of all the unlocked credentials and policies that are syntactically relevant to R and have not been disclosed yet. If there are none, Alice identifies syntactically relevant denial policies that have not been disclosed yet 3 . Then Alice sends m to Bob as her next message. Alice terminates the negotiation if she cannot make any new syntactically relevant disclosures. The TrustBuilder-Relevant Strategy is simple and easy to deploy because it does not maintain any internal structures to trace the dependency relationship between credentials. On the other hand, a party using this strategy may make unnecessary disclosures. For example, suppose Alice requests access to Bob’s resource R and Bob has R ← A1∧A2. Further, suppose Alice has A1 ← B1 and A2 ← f alse. Clearly, after receiving R’s policy from Bob, we can see that Alice will not be able to gain access to R since she does not possess credential A2 or else is unwilling to disclose it. However, under the TrustBuilder-Relevant Strategy, Alice will disclose A1 ← B1 as her next message instead of terminating the negotiation. Nevertheless, due to its 3
It is easy to prove that this modified version of the TrustBuilder-Relevant Strategy still belongs to the DTS family.
137
simplicity, we expect that the TrustBuilder-Relevant Strategy will be popular for use in trust negotiation. It is especially suitable for clients with limited computational resources, e.g., PDAs and smart cards. One key observation here is that, by using this strategy, though theoretically there is no hope to establish trust, Alice may still continue the negotiation until she cannot make any safe disclosures that are syntactically relevant. A different strategy of considerable theoretical interest is the Disclosure Tree Strategy, which is the most cautious strategy in the DTS family. This strategy carefully maintains internal structures to capture the current status of a trust negotiation, which will help to determine which disclosures are absolutely necessary to advance the negotiation. After receiving a message from the other party, it chooses as its next message a minimal set of disclosures that will allow the other party to continue the negotiation. If there are several minimal sets satisfying the above condition, a user may choose the one that fits her needs best. For example, suppose R ← A1 ∨ A2 and Alice has A1 ← B1 and A2 ← true. When receiving R’s policy from Bob, there are two minimal sets of disclosures that Alice can make. She can disclose A2 if she wants to gain access to R immediately. Or she may disclose A1 ← B1 if she wants to extract more information from Bob. Because the Disclosure Tree Strategy always makes minimal information disclosures during a trust negotiation, it exemplifies the potential actions of cautious users who have ample computational resources. The key observation here is that, when using the Disclosure Tree Strategy, Alice may choose not to disclose a syntactically relevant credential even though it is unlocked during a trust negotiation.
8.3.2 Protection of Possession-Sensitive Credentials Suppose C∗ is Alice’s possession-sensitive credential, and Carol is a user who does not possess C ∗ . Consider the following two examples: Example 1 Let Bob, the server, have R ← A1 ∧ C∗ . Suppose Alice has A1 ← true and C∗ ← B1, while Carol has A1 ← B1 and C∗ ← f alse. Further, suppose Carol adopts the TrustBuilder-Relevant Strategy. For Alice, considering R’s policy and the fact that A1 ← true, she may dynamically migrate the policy of C∗ to A1 and make A1’s policy become A1 ← B1. Clearly, if Bob can satisfy this augmented policy of A1, then it is equivalent to satisfying the policy of C ∗ . Therefore, by disclosing A1 ← B1 to Bob, Alice preserves the chance to establish trust (to some extent, as we will see later). Meanwhile, her response is exactly the same as that of Carol. As described in section 8.3.1, 138
since Carol adopts the TrustBuilder-Relevant Strategy, after receiving R’s policy, she will reply with A1 ← B1, even though theoretically trust cannot be established. Thus, Bob cannot tell by observing her behavior whether Alice possesses C ∗ . Example 2 Let R ← A1∨C∗ . Suppose Alice has A1 ← B1 and C∗ ← B2, while Carol has A1 ← B1∨B2 and C∗ ← f alse. Because Carol adopts the TrustBuilder-Relevant Strategy, she will reply with A1 ← B1 ∨ B2. For Alice, she may migrate the policy of C ∗ to A1 and make A1 ← B1 ∨ B2. As in Example 1, disclosing A1’s augmented policy to Bob does not reduce the chance to have a successful negotiation. Meanwhile, Alice’s response is exactly the same as Carol’s, and Carol does not possess C∗ . The above two examples reflect the basic idea of our policy migration approach to protecting possession sensitive credentials: 1. Integrate the policy of a possession-sensitive credential into that of another relevant credential. And, meanwhile, 2. Preserve the potential success of the current trust negotiation. In other words, if theoretically Alice and Bob can establish trust, then this must still be true after applying policy migration. More precisely, if there is a safe disclosure sequence for R under the original policies, then there must also be a safe disclosure sequence for R under the modified version of the policies. Further, if a successful trust negotiation is not possible, then after policy migration, both parties must eventually recognize the failure. The first point allows Alice to “hide” the policy of C ∗ and never directly disclose it, so that Bob cannot distinguish Alice’s response from that of other users. This is how Alice’s privacy is protected. The second point says that migration of the policy of C ∗ should not compromise the success or failure of a trust negotiation. After we migrate C∗ ’s policy to another credential C, C’s disclosure is still controlled by its original policy PC . Its augmented policy is only for the purpose of disclosure to Bob so that C ∗ ’s policy does not need to be disclosed. In the first example above, after the policy migration, i.e., after conjoining C ∗ ’s policy with that of A1, the potential success of the trust negotiation is not always preserved. For example, suppose Bob has policy 139
B1 ← A1. Then there exists a safe disclosure sequence (A1, B1, C ∗ , R). However, after Alice discloses A1 ← B1, from Bob’s point of view, he will find a circular dependency between A1 and B1, which may make him believe that there is no hope to establish trust, and terminate the negotiation prematurely. On the other hand, the policy migration in the second example does preserve the potential success of the trust negotiation. The intuition is that, by changing A1’s policy to A1 ← B1 ∨ B2, from Bob’s point of view, the policy has been weakened. Thus, if there is a safe disclosure sequence containing A1 in the original policies, we can still find such a sequence when we have A1 ← B1 ∨ B2. Further, if there is a safe disclosure sequence containing C ∗ but not A1, then B2 must appear in the sequence. Thus, after Alice’s policy migration, Bob will see a safe disclosure sequence for A1. By following this sequence, after B2 is disclosed, Alice can disclose C ∗ instead of A1, which will also satisfy R’s policy. Formally, we have the following problem: Given R ← P and the policies for the credentials C 1 , . . . , Ck , C∗ that occur in P , is there a way to assign new policies to C 1 , . . . , Ck , such that by only disclosing to the other party these new policies, but not the policy of C ∗ , the potential success of a trust negotiation is preserved? We have the following theorem. Theorem 8.1. Suppose C∗ is possession-sensitive for Alice. Given R ← P , let C 1 ∨· · ·∨Ct be the disjunctive normal form of P , where each Ci , 1 ≤ i ≤ t, is a conjunction of credentials. If there exists C i such that C∗ does not appear in Ci , then there is a policy migration for C ∗ that will preserve the potential success of the trust negotiation. We call a disjunct an independent disjunct if C ∗ does not appear in it. The construction of the policy migration is as follows. For each credential C, we use P C to represent its policy. Given Bob’s policy P , let P be a policy obtained by replacing each credential C in P by P C . We call P the mirror equivalent of P . Intuitively, if the credentials disclosed by Bob can satisfy P , then Alice will be able to disclose credentials that satisfy P . (This intuition can also be used as the basis of another kind of negotiation strategy, as discussed in section 8.3.4.) Without loss of generality, suppose disjuncts C 1 , . . . , Ci−1 involve C∗ while Ci , . . . , Ct do not. Let P be the mirror equivalent of C 1 ∨ · · · ∨ Ci−1 . We call P the migrating component. For each credential C appearing in Ci , we change its policy to C ← PC ∨ P . We call PC ∨ P the covering policy of C, because it helps us to preserve the intent of the original policy of C ∗ . For C∗ , its covering policy is f alse. For all the 140
other credentials, their covering policies are the same as their original ones. We want to emphasize that the covering policy of C is not used to control C’s actual disclosure. Alice’s disclosure of credential C is still controlled by her original policy P C . As an example, suppose P = (A1 ∧ C∗ ) ∨ (A2 ∧ A3). Then the covering policies will be A1 ← P A1 , C∗ ← f alse, A2 ← (PA2 ) ∨ ((PA1 ) ∧ (PC∗ )) and A3 ← (PA3 ) ∨ ((PA1 ) ∧ (PC∗ )). Let Poriginal be the mirror equivalent of P when the original policies of credential C 1 , . . . , Cn are used, and let Pcovering be the mirror equivalent of P when the covering policies are used. In the above example, Poriginal = (PA1 ∧ PC∗ ) ∨ (PA2 ∧ PA3 ) and Pcovering = (PA2 ∨ (PA1 ∧ PC∗ )) ∧ (PA3 ∨ (PA1 ∧ PC∗ )). It is not hard to prove that after the above policy migration, P original ≡ Pcovering . After policy migration, Alice simply discloses to Bob the covering policies of all the credentials appearing in R’s policy except that of C ∗ . Such a response is exactly the same as what Carol, who does not possess C∗ , will do when the TrustBuilder-Relevant strategy is used. Therefore, by observing Alice’s response, Bob cannot tell whether Alice possesses C ∗ or not. Meanwhile, the way that we construct the policy migration guarantees that the potential success of trust negotiation is preserved, as will be proved below. Therefore, we will not miss any chance to establish trust. Proof. We need to prove that the above policy migration preserves the potential success of a trust negotiation, i.e., there exists a safe disclosure sequence under the original policies if and only if there also exists a safe disclosure sequence under the covering policies. Suppose there exists a safe disclosure sequence G = (C 1 , . . . , Ck = R) according to the original policies. Without loss of generality, we assume G is a minimal sequence, i.e., by removing any credentials from the sequence, the resulting sequence is not a safe disclosure sequence any more. If C ∗ does not appear in G, then G is also a safe disclosure sequence according to the covering policies, because for any credential C = C∗ , C’s original policy entails its covering policy. Otherwise, if C i = C∗ is in G, since we assume C∗ only appears in R’s policy, we can move C∗ to the position right before R and the sequence is still safe. Thus, we assume Ck−1 = C∗ . Since G is a minimal sequence, before R is disclosed, a minimal solution for R’s policy that contains C∗ must have been disclosed. According to the way covering policies are constructed, before C∗ is disclosed, the covering policies of those credentials appearing in the independent disjunct C i are satisfied by {C1 , . . . , Ck−2 }. Therefore, we can replace C∗ in G with the credentials in C i if they are not
141
in the sequence yet, which will give us a safe disclosure sequence under the covering policies. On the other hand, suppose there exists a minimal safe disclosure sequence G according to the covering policies. Then we need to prove that there also exists a safe disclosure sequence according to the original policies. Before R is disclosed, a minimal solution {C 1 , . . . , Cq } for R’s policy must have been disclosed in the sequence. For each Cj , 1 ≤ j ≤ q, whose covering policy is not the same as its original policy, its covering policy is PCj ∨ P , where P is the migrating component and PCj is the original policy of C j . When Cj is disclosed in the sequence, if P Cj is satisfied, then we still keep C j in the sequence. Otherwise, the migrating component P must have been satisfied by credentials disclosed before C j . According to the way P is constructed, there must be at least one conjunct C l of R’s policy where C∗ appears in Cl and all the policies of credentials occurring in C l are satisfied by credentials disclosed before C j . Suppose , A1, . . . , At, C , R), is a safe disclosure Cj = A1 ∧ · · · ∧ At ∧ C∗ . Then, the sequence (C1 , . . . , Ci−1 ∗
sequence according to the original policies. What happens if C∗ appears in every minimal solution for R’s policy? Example 1 shows a possible way — migrating the policy of C∗ to credentials in the same minimal solution through conjunction. In detail, for each minimal solution {C 1 , . . . , Ck , C∗ }, Alice chooses one credential C i and makes its covering policy Ci ← PCi ∧ PC∗ , while the covering policies of credentials that are never chosen are the same as their original ones. Alice discloses all the other credentials’ covering policies to Bob but not that of C ∗ (C∗ ← f alse). However, this approach cannot always preserve the potential success of a trust negotiation. Intuitively, by putting the policy of C∗ in conjunction with a credential C’s policy and disclosing it to Bob, the policy of C is strengthened from Bob’s point of view. Thus, as is possible in Example 1, Bob may find that there is no hope to establish trust according to the policies received from Alice, while he would conclude the opposite according to the original policies. In this situation, there is essentially a tradeoff between privacy protection and trust establishment. In practice, to minimize the change to the potential success of a trust negotiation, we should migrate the policy of C∗ to the policies of as few credentials as possible. Although potential success will not always be preserved, still the parties are more likely to establish trust under this approach than they would be if Alice simply tells Bob C ∗ ← f alse when Bob asks for her possession-sensitive credentials. Proposition 8.1. Let C∗ be a possession-sensitive credential and suppose R ← A1 ∧ C ∗ . Suppose there 142
exists a safe disclosure sequence (C 1 , . . . , Ci = A1, Ci+1 = C∗ , Ci+2 = R). Then after migrating the policy of C∗ to A1 such that A1 ← PA1 ∧ PC∗ and C∗ ← f alse, there is still a safe disclosure sequence for A1. Proof. Since A1 and C∗ are both Alice’s credentials, A1 is not in any minimal solution for the policy of C ∗ . Therefore, the set of credentials {C 1 , . . . , Ci−1 } is a solution for the policies of both C ∗ and A1. Thus, it is also a solution for PC∗ ∧ PA1 . So the sequence (C1 , . . . , Ci = A1) is a safe disclosure sequence leading to A1’s disclosure according to the new policy of A1. During a trust negotiation, after Alice discloses the covering policy of A1 to Bob, once the covering policy is satisfied by Bob, Alice can disclose both A1 and C ∗ to Bob and gain access to R consequently. Proposition 8.2. Let A1, . . . , At, C∗ be a minimal solution for R’s policy, where C ∗ is a possession-sensitive credential. Suppose there exists a safe disclosure sequence (C1 , . . . , Ci = C∗ , Ci+1 = Aq, Ci+2 = R). Then after migrating the policy of C ∗ to produce Aq ← PAq ∧ PC∗ , there is still a safe disclosure sequence for R according to the new policies. The proof of proposition 8.2 is similar to that of proposition 8.1, and we omit it here. When there is more than one possession-sensitive credential in R’s policy, as long as there is a disjunct in R’s policy that does not involve any possession-sensitive credential, we can still preserve the potential success of a trust negotiation through policy migration by using a similar approach. In detail, let C 1 , . . . , Ck be disjuncts involving at least one possession-sensitive credential and let C k+1 be independent of all possessionsensitive credentials. Then the migrating component P should be the mirror equivalent of C 1 ∧ · · · ∧ Ck . For each credential C in Ck+1 , we set its covering policy to be C ← P C ∨ P . The proof of preservation of potential success is similar to that of theorem 8.1. Similarly, the possession-sensitive credential C ∗ does not have to appear in R’s policy. The theorems presented in this section will still hold whenever Alice’s possession-sensitive credentials occur in only one policy P that is relevant to the negotiation. In that case, Alice needs to find an independent disjunct in P to migrate C∗ ’s policy to, subject to the condition that at least one credential in that disjunct has not already had its policy disclosed. If no such credentials are available, then policy migration cannot be used. We will discuss the situation where possession-sensitive credentials appear in multiple policies, possibly spread across both parties, in a later section. 143
8.3.3 Protection of Non-Possession Sensitive Credentials Recall that if C∗ is a non-possession sensitive credential for Alice, then we have the following scenario: Alice does not possess credential C ∗ but has a policy PC∗ to control to whom she is willing to disclose the denial policy for C∗ . In other words, Alice will admit the fact that she does not possess C ∗ only if Bob has satisfied PC∗ . Meanwhile, in the worst case, all the other users have C ← true. Clearly, if C ∗ is the only credential required to gain access to R, Alice cannot effectively protect the fact that she does not possess C∗ , because all other users will disclose C ∗ immediately. Any other action Alice takes will reveal this sensitive fact. (Alice may intentionally unplug her connection with the Internet and make Bob believe that the negotiation is interrupted because of a failure of the network. Such a physical approach is out of the scope of this paper.) When there are more credentials involved in R’s policy, the protection of non-possession sensitive credentials is very similar to that of possession-sensitive credentials. We try to migrate P C∗ to the policies of other credentials so that Alice will behave the same as certain users who do have C ∗ and adopt the Disclosure Tree Strategy. Let us look at the following examples. Suppose R ← A1 ∧ C∗ . Obviously, since Alice does not have C∗ , there is no way that trust can be established. Alice can make the covering policy of A1 be A1 ← P C∗ and disclose it to Bob. From Alice’s response, Bob cannot infer that Alice does not possess C ∗ , since a user adopting the Disclosure Tree Strategy may make the same response. If Bob cannot satisfy policy P C∗ , Alice will naturally terminate the negotiation. Otherwise, Alice can tell Bob that she does not possess C ∗ , since Bob is qualified to know the truth. In either case, Bob cannot infer the sensitive fact from Alice’s behavior. On the other hand, suppose R ← A1 ∨ C∗ . Alice can migrate PC∗ to the policy of A1 such that A1 ← PA1 ∨ PC∗ , and disclose it to Bob. Note that Bob cannot infer that Alice does not have C ∗ based on the fact that Alice does not disclose C ∗ , because a party adopting the Disclosure Tree Strategy will not necessarily disclose every unlocked and relevant credential. Later on, if Bob has satisfied P A1 , then Alice may disclose A1 and gain access to R thereafter. If Bob has satisfied P C∗ , similar to the above example, Alice may tell Bob that she does not possess C ∗ . The problem comes when Bob indicates that he can satisfy neither PA1 nor PC∗ . Now the situation boils down to the same as when C ∗ is the only credential required to gain access to R, a case that cannot be effectively handled in the current approach to trust negotiation.
144
In general, we have the following theorem. Theorem 8.2. Suppose C∗ is non-possession sensitive for Alice. If {C ∗ } is not a minimal solution for Bob’s policy for R, then there is a policy migration for P C∗ that satisfies the following conditions: 1. If there is a safe disclosure sequence for R under the original policies, then there is also one under the covering policies. 2. If there is a safe disclosure sequence G = (C 1 , . . . , Ck , R) under the covering policies, then either there is also one under the original policies, or P C∗ is satisfied by {C1 , . . . , Ck }. In other words, after Ck is disclosed in the sequence, it is safe for Alice to tell Bob that she does not possess C ∗ . Proof. Suppose R ← P . Let C1 ∨ · · · ∨ Ct be the disjunctive normal form of P , where each C i , i = 1, . . . , t, is a disjunct. The construction of the policy migration is as follows. For each C i that involves C∗ , we choose one credential C = C∗ from Ci and make C ← PC ∨ PC∗ the covering policy for C. For all the other credentials, their covering policies are the same as their original ones. Let P original be the mirror equivalent of P when the original policies of Alice’s credentials are used and let P covering be the mirror equivalent of P when the covering policies are used. It is easy to see that P covering ≡ Poriginal ∨ PC∗ . Clearly, for any credential C = C ∗ , its covering policy is weaker than or the same as its original policy, i.e., if C’s original policy can be satisfied by Bob, so can its covering policy. Therefore, if there is a safe disclosure sequence G according to Alice’s original policies, then after the above policy migration, G is also a safe disclosure sequence according to the covering policies. On the other hand, suppose that according to the disclosed covering policies, there exists a safe disclosure sequence G. Since Alice never discloses the policy of C ∗ , G does not involve C∗ . Let Ci be a disjunct of R’s policy that was satisfied before R is disclosed in G. If the original policy of every credential C in C i is satisfied before C is disclosed, then G is also a safe disclosure sequence according to the original policies of Alice. Otherwise, according to the way that covering policies are constructed, before R is disclosed, P C∗ must be satisfied. When there is more than one non-possession sensitive credential in R’s policy, as long as there is no disjunct in the disjunctive normal form of R’s policy that contains only non-possession sensitive credentials, we can still handle it in a similar way. We will omit the details of this extension in this paper. 145
Similarly, the possession-sensitive credential C ∗ does not have to appear in R’s policy. The theorems presented in this section will still hold whenever Alice’s possession-sensitive credentials occur in only one policy that is relevant to the negotiation (as long as there is a suitable disjunct available). However, as discussed above, it is possible that the migration will not preserve the potential success of the negotiation.
8.3.4 Discussion One potential alternative for protecting possession-sensitive credentials is to require each party to always disclose the mirror equivalent of R’s policy. That is, after Bob discloses R’s policy P , Alice only discloses P ’s mirror equivalent P , without telling Bob the policy of each individual credential appearing in P . Similarly, Bob will disclose the mirror equivalent of P in his next message. This process continues until one party finds that either the current policy can be satisfied by a set of unprotected credentials or there is no solution to the current policy. Such a negotiation process is called a parsimonious negotiation strategy, first introduced by Winsborough et al. in [88]. Policy migration has several advantages over this approach. By disclosing the policy of each individual credential separately, a party can control the direction of the progress of a trust negotiation according to its own preference. For example, if there are multiple ways in which Alice might be able to satisfy Bob’s policy for R, she might clearly prefer one set of disclosures over another. Most families of negotiation strategies include strategies that will allow Alice to steer the direction of the negotiation toward what she views as the most desirable disclosure sequence. This flexibility and autonomy is desirable in decentralized systems. Further, in the worst case, the size of the mirror equivalent of R’s policy may increase exponentially with the number of rounds of messages, which will result in high communication cost. This problem is also avoided by allowing the disclosure of the policy of each individual credential. Compared to ack policies and non-response, policy migration has the following advantages: 1. Policy migration is very easy to deploy in current trust negotiation systems. It does not require any new extensions to the components of the existing trust negotiation model, e.g., the organization of policies, the format and semantics of messages, or the information allowed to be exchanged. Also, its management overhead is low. Unlike ack policies and non-response proposed in [86, 85], a user only needs to specify what credentials are considered possession-sensitive or non-possession sensitive. The
146
major protection is supplied by the security agent using a policy migration algorithm, which is simple and easy to implement in the situation discussed in this paper. 2. Policy migration is self-contained. It does not require any pre-arranged cooperation from a large group of users. The protection power of policy migration comes from the fact that Alice will behave in the same way as certain ordinary users who do not have Alice’s possession-sensitive credential, or do have Alice’s non-possession sensitive credential. Bob cannot rely on observing an unusual response from Alice to infer whether she has a specific possession-sensitive credential, or does not possess a non-possession sensitive credential. 3. Policy migration provides a nice balance between the potential success of a trust negotiation and the protection of possession-sensitive and non-possession sensitive credentials. In most cases, the potential success of a trust negotiation is preserved when we migrate the constraints in the policy of a possession-sensitive or non-possession sensitive credential. Therefore, success of a trust negotiation is still guaranteed. Specifically, we have identified a large group of policies under which policy migration can always preserve the potential success of a trust negotiation. The version of policy migration presented in this paper has limitations that need to be addressed in future work. In particular, policy migration needs to be extended to handle the case where possession-sensitive and non-possession sensitive credentials appear in multiple policies belonging to multiple parties. In general, if Alice’s possession and non-possession sensitive credentials are mentioned in many policies that are relevant to the negotiation, then policy migration can still be used to protect her privacy. However, in this situation policy migration can become more complex. Alice must do bookkeeping to remember what covering policies she has used where, and reason more carefully about when to disclose a possessionsensitive credential or to tell Bob the fact that she does not possess a non-possession sensitive credential. To make this happen, Alice’s negotiation software may need to use a highly accurate representation of the progress of a trust negotiation, such as a version of the disclosure trees [96] originally developed for use in proofs of correctness of the interactions between the strategies used by two negotiating parties. Another interesting question is how to generalize policy migration to handle the situation where both Alice and Bob have possession or non-possession sensitive credentials involved in a trust negotiation. Intuitively, as long as the covering policies of Bob and Alice do not strengthen the semantics of their corre147
sponding original policies, the potential success of the trust negotiation will not be jeopardized and their privacy will be protected. However, the higher the number of sensitive credentials involved in the negotiation, the more management effort will be required. Mechanisms are needed to manage policy migration so that complex situations such as this can be handled efficiently. Even with the extensions described above, policy migration will not be a complete solution to the problem of protecting possession-sensitive and non-possession sensitive credentials. 1. Policy migration is designed to prevent inferences through simple observation of one’s behavior during trust negotiation, such as one might expect from an automated attack program. Therefore, the human-intelligible meaning of policies is not considered. In practice, typically, when a credential is possession-sensitive, its policy tends to be very specific and strict. For example, Alice may specify that only people working for the NSA can see her CIA agent card. If we migrate such a constraint to Alice’s driver’s license, then its covering policy may require one to be either a police officer or be working for the NSA, which is clearly an unusual policy for one’s driver’s license. In fact, it is well known that the content of an access control policy may reveal the sensitive nature of a credential. Several approaches have been proposed to protect sensitive policies [15, 77, 93]. By combining policy migration with sensitive policy protection schemes, we may get a more comprehensive solution. 2. Policy migration is subject to comparison attacks. Bob may negotiate trust with Alice on several occasions. Suppose that during a previous trust negotiation where her CIA agent card is not involved at all, Alice discloses her driver’s license’s policy to Bob. Later, during a more sensitive trust negotiation which involves her CIA agent card, Alice may migrate the policy for her CIA agent card to that of her driver’s license. If Bob maintains a copy of Alice’s original driver’s license’s policy, he will be able to guess that the one received later is a covering policy, which can be used to infer that Alice is actually connected to the CIA. Such an attack is hard to prevent because it is unlikely for Alice to remember each of her interactions with all other parties. Further, even if Alice does remember, or has never interacted with Bob before, Bob may still get a copy of Alice’s original policy from a third party Carol, who negotiated trust with Alice before. As mentioned in section 8.1, it is difficult for Alice to control the propagation of her private information once it has been disclosed to others. Overall, the effect of policy migration is to make inferences regarding possession-sensitive and non148
possession sensitive credentials harder instead of making them impossible. In the original model of trust negotiation, without proper protection, inference is quite simple and can easily be automated. By using policy migration, one has to analyze the semantics of a policy or keep track of a user’s policies before the inference can succeed. This process requires more human intervention, which makes it more difficult to be conducted by computers in an efficient way. To provide more comprehensive solutions to privacy protection is an important area for future work on automated trust negotiation. We will discuss this topic further in chapter 10.
149
Chapter 9
Related Work This work is related to many research areas, including access control, public key infrastructures, trust management in decentralized systems and privacy protection. Much work has been done in each of these areas, and it is impossible to cover all of them thoroughly in this chapter. For interested readers, there are many excellent books and surveys for each area [1, 7, 18, 23, 28, 72, 73]. In the following, we describe the work that most heavily influences trust negotiation, forms key components of trust negotiation or is complementary to trust negotiation.
9.1 Access Control Basics 9.1.1 Access Control Policies There are two main approaches to access control policies — discretionary access control and mandatory access control. In discretionary access control, there are no system-wide access control polices. The access control for an object is specified by the owner of the object. Thus, typically a user may have different access rights for different objects. Further, different users may have different access rights for the same object. Most file systems and database management systems support discretionary access control. For example, in UNIX file systems, suppose user Alice is the owner of a file discussion_notes.txt. Then Alice has the authority to determine who can read or modify the file through specifying the group of the file and setting its file tags appropriately. Further, in many discretionary access control systems, Alice can choose, at her discretion, to give user Bob the right to grant access to discussion_notes.txt to other users.
150
Discretionary access control is very flexible. However, it does not provide strict control over the information flow in a system because it does not have constraints on copying information from one object to another. For example, suppose the file discussion_notes.txt belongs to the group research and Alice specifies that only members in the group research can read the file. If Bob is in the group research, he will be able to read the file and copy it into another file notes_backup.txt. Since Bob is the owner of notes_backup.txt now, he has the authority to determine who can access this file. Thus, after information flows from discussion_notes.txt to notes_backup.txt, Alice loses control of the information. Bob may later allow Eve to read notes_backup.txt even though Eve is not a member of the group research. Due to the same reason, discretionary access control is subject to trojan-horse attacks. Suppose Alice has a file secret.dat which she does not allow anybody except herself to read. In order to get the secret, Eve may create a file foo.dat and give Alice the privilege to write foo.dat. She then tricks Alice into running a trojan horse program such as a chess game. While Alice is playing the game, because the program is run by Alice, the program has the privilege to read secret.dat and copy it to foo.dat, since Eve gives Alice write permission to foo.dat. Eve can later get the secret by reading foo.dat. In mandatory access control, access control policies are made centrally by administrators instead of by owners of individual objects. Each data object is assigned a classification level (e.g., top secret, secret, confidential and unclassified), and each user has a clearance level. Mandatory access control ensures that all users only have access to those objects for which they have a clearance. The levels are partially or totally ordered (e.g., top secret > secret > confidential > unclassified). Two restrictions for access control are as follows [6]. 1. Simple-Security Property: A user can read an object only if the object’s classification level is lower than or equal to the user’s clearance level. 2. *-Property: A user can write an object only if the object’s classification level is higher than or equal to the user’s clearance level. The simple-security property is straightforward while the *-property seems counter intuitive at first glance. The purpose of the *-property is to prevent a user from copying data in a higher classification level to a lower classification. Therefore, the mandatory model can effectively prevent the trojan horse attack 151
described above. Suppose Alice has a secret clearance level while Bob has an unclassified clearance level. If Bob launches the attack described earlier, when the trojan horse program tries to copy secret.dat to foo.dat, since the classification level of foo.dat is unclassified and Alice has a secret clearance level, the write operation will be prohibited by the system. Mandatory access control is only used today in highly secure systems in which the data has relatively static and strict classification levels, such as multilevel secure military or government applications or mission critical data applications. However, mandatory access control is not quite appropriate for the requirements of government and industrial organizations that process unclassified but sensitive information. In these systems, access control policies are typically derived from general regulations, laws and the operational structure of an organization, which cannot be easily captured through specifying classification levels. Rolebased access control was proposed to model access control policies in such environments. In role-based access control, access control decisions are based on the roles and responsibilities that a user assumes in an organization. The definition of roles and role hierarchies relies on a careful analysis of the operational structure of an organization. For example, roles defined in a university may include president, dean, staff, faculty, student, teaching_assistant, etc. Roles can typically be organized into a hierarchy. For example, student includes teaching_assistant. Depending on her responsibilities, a user may assume one or more roles. In order to take an action, a user needs to assume an appropriate role to get the right privilege. Therefore the definition of roles is relatively stable while the roles a user can assume may evolve frequently depending on changes in the user’s responsibilities. When assigning roles to users, the principle of minimum privilege should be followed. A user should be assigned to the least role that gives her enough privileges for her to perform her job. With proper administration, role-based access control systems allow users to perform a broad range of authorized operations with great flexibility. Since authorizations are based on roles, which can be naturally mapped to the operational activity of an organization, a high level view can be easily defined regarding who has privileges with respect to a particular object. Further, management of users’ privileges is also eased because assigning or revoking roles is a more abstract and management-friendly process than dealing with users’ rights on specific objects.
152
object
File A
File B
jsmith
read append
read write delete
kgreen
read
read append
Directory C
subject
ehanks
read write delete
Laserjet B/W printer
list
print
list create
print
print restart
Laserjet color printer
print
Figure 9.1: An example access matrix for an operating system
9.1.2 Access Control Mechanisms An access control decision in a system is traditionally modeled as a tuple < s, o, a >, where s is a subject, o is an object and a is an action type, meaning that the system allows subject s to take action a on object o. The fundamental conceptual model for access control is the access matrix model [58]. In this model, the access control decisions in a system are modeled as a matrix M, where the rows of M represent subjects (e.g., users or processes) in the system and the columns of M represent objects (e.g., files and services) in the system. The rights in a cell specify the permitted kinds of access of the subject (row) to the object (column). For example, in an operating system, subjects include all the users known to the system, while objects may include files, devices and services. An example access matrix is shown in figure 9.1. We see from the example that all the users can read File A. However, only user ehanks has the right to delete the file. Similarly, all users can use the Laserjet black and white printer to print documents. But due to the high cost of color printing, only user ehanks has the right to print through the Laserjet color printer. An access matrix is only a conceptual model. In a reasonably large system, the access matrix tends to be very large and sparse. Full materialization of the matrix would be very inefficient. In practice, there are two popular approaches to solve this problem. One is the access control list approach and the other one is the capability list approach. These two approaches represent two different ways to partition an access control
153
matrix. In the approach of access control lists, each column of the access matrix is stored with the object corresponding to that column. In other words, for each object we store which subjects have which access rights on that object. If a subject does not have any access rights for the object, the subject will not appear in the list at all. For the example shown in figure 9.1, the access control list for the color printer will only contain user ehanks. On the other hand, in the approach of capability lists, each row of the access matrix is stored with the subject corresponding to that column. For each subject, we store a list of the objects the subject can access, as well as the manners of access. If the subject does not have any access right for an object, the list will not contain the object. In the example shown in figure 9.1, object File B and object Directory C will not appear in the capability list of user ehanks. In the access control list approach, it is easy to determine all the subjects that have access to a specified object. Also, it is straightforward to revoke all the subjects’ access on an object. However, revoking a specific user’s rights on all objects turns out to be a hard problem because we have to check every object’s access control lists. To alleviate this problem, many systems further organize subjects into a hierarchical structure such as groups and roles. The access control list for an object contains groups and roles, instead of specific subjects. Therefore, when a user’s privileges have changed, we usually only need to change the groups or roles that the user belongs to and seldom need to change access control lists. On the other hand, the capability list approach makes it easy to determine the access rights of each user. Revoking all the privileges of a subject is also straightforward. But it is more difficult to determine all the subjects who can access a specific object. In practice, per-object access control mechanisms usually win out. Therefore, most operating systems protect files by means of access control lists. In distributed systems, however, a combination of the above two approaches is more popular [41, 35].
9.2 Public Key Infrastructure In the literature, the term Public Key Infrastructure (PKI) is often used to specifically refer to X.509 [ 47]. In this section, however, we discuss PKI in a broader sense, i.e., a public key infrastructure is a framework
154
specifying how digital credentials are created, distributed, stored and revoked. Most proposed public key infrastructures are only concerned with identity certificates (also known as public key certificates), which bind public key/private key pairs to users’ identities such as names or email addresses. Such identity certificates can serve as a basis for authentication, encryption and digital signatures in highly decentralized computing environments. In this section, we survey three different approaches to PKI: X.509, the web-of-trust approach of PGP, and anonymous credential systems. Automated trust negotiation can use credentials from any or all of these approaches.
9.2.1 X.509 The X.509 PKI has five components. Certification Authorities (CAs) CAs are responsible for issuing and revoking identity certificates. Organizational Registration Authorities (ORAs) An ORA’s responsibility is to verify the binding between public keys and certificate holders’ identities and other attributes. Certificate holders Certificate holders may use certificates to authenticate themselves when interacting with others, or digitally signing documents. Clients When receiving a digitally signed document, a client verifies that the signer’s certificate is valid. Repositories A repository stores and publishes certificates and Certificate Revocation Lists (CRLs). In order to get an identity certificate, an entity first needs to send a certificate request to a registration authority for approval. The registration authority verifies the true identity and other attributes of the entity (for example, by checking the requester’s driver’s license), then forwards the certificate request to a certification authority for signing. The certificate authority verifies the certificate request and makes sure it has been approved by the registration authority, then signs the certificate. The CA also sends a copy of the certificate to a repository so that other people who want to communicate with the requester securely can get the corresponding public key.
155
When a certificate needs to be revoked, for example, if one’s key is compromised, an entity or the repository authority will contact the CA. Then the CA updates its revocation list and also publishes it in the revocation list repository. To achieve better scalability, CAs are organized into a hierarchy. The root CA certifies the authority of other CAs, and a certified CA can further certify other CAs. A typical scenario is that the CA of a security domain is certified by the root CA so that it can assume the responsibility to issue identity certificates inside that security domain. Therefore, in order to verify an identity certificate, in general, one has to follow the certificate path until reaching the root CA. This process is called credential chain discovery. The most controversial parts of X.509 are the concept of a root CA and certificate revocation. The root CA is essentially a party that is required to be trusted by everyone in the infrastructure. On a small scale, this may not be a problem. But if we want to deploy X.509 in a very large and decentralized environment like the Internet, it is very hard to agree on a root CA that everybody will accept. Though currently there are some companies and organizations, such as VeriSign and TRUSTe, who are acting as the de facto root CAs, it is not clear who the root CA could be when identity certificates need to be issued to large numbers of individual users. The second controversial part of X.509 is the use of certificate revocation lists (CRLs). Due to scalability reasons, the certificate revocation list is only updated periodically, which leads to concerns regarding the freshness of the list. Also, a server is required to check the revocation list from a repository every time it receives a certificate or signed document from somebody. This imposes a great burden on the server and makes it very vulnerable to denial-of-service attacks. A large amount of work has been done to address this problem. Some proposed to do revocation completely without CRLs (for example, [71]) while others worked to improve the efficiency of CRLs [67, 56]. The original identity certificates in X.509 only bind public keys to identities. X.509 v.3 certificates later extended key binding to general properties (attributes).
9.2.2 PGP PGP (Pretty Good Privacy) is a public key system designed to let people exchange messages privately and securely. Nowadays it is widely used in providing secure email services. In PGP, without consulting any CAs, a user can freely create her own public key/private key pair, so that 156
others can send messages to her securely by encrypting the messages with her public key. In order to let people be aware of her public key, she may either contact others directly or make her public key publicly available. For example, she may list her public key on her home page. Or she can self-sign a certificate stating that her public key is K, then publish it in a certificate server. Because everybody can freely publish a key certificate, it is quite possible for an attacker to post a phony key with the name Alice. Later on the attacker may intercept messages sent to Alice and decrypt them. Users need to be very careful to ensure that they encrypt messages with the public key actually belonging to the intended recipient. This is where digital certificates play a key role. Unlike X.509, PGP adopts a “web of trust” model, which is a highly decentralized infrastructure. Anybody can act as a certificate authority by issuing certificates that certify others’ public keys. However, such a certificate is only useful for those who trust the issuer. For example, if Alice certifies that Bob’s public key is Kb and Carol trusts Alice’s judgment, then Carol will believe Bob’s key is really K b , even if she does not get the key directly from Bob or she never meets Bob personally. In PGP, a user Alice keeps a key ring which lists 1. The degree to which Alice believes a particular key is valid, i.e., it really belongs to the declared entity. 2. The degree to which Alice trusts the judgment of the owner of a particular key when the owner certifies others’ keys. For example, Alice may believe that Bob’s key is K b . But she may not trust the certificates that Bob issues. In PGP, a user always trusts her own key, which is called ultimate trust, the highest level of trust in keys. Besides ultimate trust, PGP defines three levels of trust that a user may have regarding the validity of a particular key: complete trust, marginal trust and untrusted. There are also three levels of trust regarding the judgment of a particular key’s owner: valid, marginally valid and invalid. It is up to the user to assign the trust level for each key and their holder. For example, Alice may specify that she trusts that a user’s key is really Kb if it is certified by a valid user or by two marginally valid users in her key ring. Such an approach is very similar to the reputation systems commonly used in e-business environments. Note that the web of trust model actually includes the hierarchical trust model used in X.509. For example, the root CA can be regarded as a user whose trust level is always valid in everybody’s key ring. A more detailed discussion of 157
the web of trust model can be found elsewhere [54]. While in X.509 it is only the issuer who revokes a certificate, in PGP only the owner of a particular key or a revoker designated by the owner can do the revocation. In order to let others know about the revocation in a timely manner, the owner may post it on a certificate server.
9.2.3 Anonymous Credential Systems Anonymous credential systems (also called pseudonym systems) [19, 21, 22, 26, 27, 29, 65] enable business transactions to be conducted in an anonymous yet authenticated manner. We use the idemix system [21], which was developed by IBM Zurich Research Laboratory, as an example to show how anonymous credential systems work. In the idemix system, each user has a single master secret. There are three basic interactive protocols between a user and an organization: pseudonym registration, credential issuing and credential verification. Pseudonym registration Before Alice gets a credential from an organization, she has to first register a pseudonym with the organization. The pseudonym is generated in such a way that Alice’s master secret is linked to Alice’s pseudonym in every organization. In order to register a pseudonym, Alice may need to show credentials obtained outside the anonymous credential system, e.g., her driver’s license. Credential issuing If Alice is eligible to get a credential that attests that she possesses attribute a, the issuing organization produces a credential by signing a statement containing a and Alice’s pseudonym within the organization. As usual, the credential is signed using the organization’s private key. Credential verification Suppose an organization O V wants to verify that Alice has a credential attesting to attribute a, issued by another organization O I . By using zero-knowledge proofs, Alice will convince OV of the following facts: (1) Alice has a credential issued by O I to some pseudonym; (2) The pseudonym in the credential is linked to a master secret which Alice knows; (3) The credential certifies that Alice has attribute a. The actual content of the credential is never disclosed to the verifier O V . After the verification, OV does not even know the pseudonym in the credential. The idemix’s credential verification approach is a strong technique to protect one’s privacy during online interactions. It allows Alice to interact with the same organization multiple times by showing 158
the same credential, yet the organization cannot link her interactions together. For the same reason, even if the organization O V colludes with the credential issuer O I , they still cannot determine Alice’s true identity or her pseudonym used during the interaction. Further, Alice can show credentials issued by different organizations to the verifier and prove that she is the owner of all of them, because all the pseudonyms on those credentials are linked to her master secret. This property is important for trust negotiation, because Alice may need to prove that she possesses multiple attributes certified by different organizations, in order to obtain access to a resource. There are two ways to achieve non-transferability, i.e., to prevent malicious users from sharing their credentials to get services that no individual one of them can get. The first one is to include an individual’s important personal information (e.g., one’s bank account number and PIN) in all her credentials. In this case, sharing a credential with others is equivalent to giving away such sensitive information. However, such important personal information may not always exist. As a second approach, Camenisch et al. [22] proposed to achieve all-or-nothing non-transferability. In other words, sharing just one credential is equivalent to sharing all the credentials of a user with others. The philosophy to achieve non-transferability in idemix is to discourage people from doing so, instead of preventing it. In the idemix system, a user can choose which information in a credential, and which aspects of that information, to disclose (prove) to another party. For example, suppose a credential asserts that Alice’s age is 24. Then Alice can prove to Bob that her age is over 18 without revealing the exact value of her age. This property is desirable in trust negotiation because it minimizes the information revealed during an interaction and enhances privacy protection. Since Alice never actually discloses her credentials in idemix, one may wonder whether we still need access control policies for credential disclosures. In fact, even though in idemix credential verification is realized through zero-knowledge proofs, the end result of that proof (e.g., the information that Alice is over 18) still flows to another party. So for the purpose of information flow control, access control policies are necessary. Another interesting question is that since Alice’s pseudonyms cannot be linked by an organization even when they collude with the issuers of Alice’s credentials, why are we still concerned about information flow?
159
For example, Alice may prove to Bob that she is working for the CIA. Then Bob knows that there is some person working for the CIA (which everyone already knows anyway), but he cannot link this information to any specific individual. However, during a trust negotiation, multiple attributes pertaining to Alice may be revealed. Bob knows that all the attributes relate to the same person. By combining these attributes together, Bob may be able to figure out the true identity of Alice. Therefore, the release of information contained in credentials should still be governed by access control policies. We have a more detailed discussion of this topic in chapter 10.
9.3 Trust Management in Decentralized Environments Systems have emerged that use property-based and capability-based credentials to manage trust in decentralized, distributed systems [43, 51, 88]. Johnson et al. [51] use attribute certificates (property-based credentials) and use-condition certificates (policy assertions) for access control. Use-condition certificates enable multiple, distributed stakeholders to share control over access to resources. In their architecture, the access control policy evaluation engine retrieves the certificates associated with a user to determine if the use conditions are met. Their work could use our approach to protect sensitive certificates. Islam et al. [48] show how to control downloaded executable content based on role-based access control models. Their system assumes that all the appropriate credentials accompany requests for downloaded content. Their work could be extended using our approach to disclose policies and conduct negotiations.
9.3.1 The Trust Establishment Project The Trust Establishment (TE) Project at the IBM Haifa Research Laboratory [43] has developed a system for establishing trust between strangers according to policies that specify constraints on the contents of public-key certificates. They adopt the web-of-trust model [97, 54]. For example, McKinley Clinic may allow doctors from other hospitals to access its databases of anonymous medical data for research purposes. An entity is recognized as a hospital if it is certified either by McKinley Clinic itself or by two hospitals that are already recognized by McKinley Clinic. Therefore, when Alice requests access to its databases, McKinley Clinic will require Alice to show a credential certifying that Alice is a doctor, and meanwhile the
160
issuer of that credential should be a hospital recognized by McKinley Clinic. In TE’s model, each credential contains at least the following fields: issuer, subject, certType, version, profileURL, issuerCertRepository and subjectCertRepository. The last three fields are worthy of further explanation. • profileURL: To let entities have a common understanding of the semantics of credentials, TE adopts a Certificate Profiling mechanism. Certificate types are globally defined and agreed to by all entities. Each credential is an instance of a certain credential type, as indicated by the certType field. Global credential profiles define each credential type’s syntax (i.e., field names, type of values for each field and which fields are mandatory) and semantics (i.e., explanation of the meaning of each field). When receiving a credential whose type Alice is not familiar with, Alice will visit the certificate profile (as indicated by the profileURL field) to get the syntax and the semantics of the credential. For any systems relying on general-purpose property credentials, one fundamental issue is how to ensure that any entity can understand a credential issued by any other entity. The general idea of the profiling mechanism can be adopted in trust negotiation. However, the semantics of a certificate type in TE is only represented by free text, which is not easy for security agents to understand and process in an automated manner. For trust negotiation, it is desirable to design a credential typing system with formal semantics [61]. • issuerCertRepository and subjectCertRepository: A certificate repository is the place that an entity stores all the certificates that others issue to it. When Alice presents her doctor certificate, McKinley Clinic needs to verify that the issuer of her certificate is qualified to be recognized as a hospital. To do so, McKinley Clinic needs to collect more certificates from the issuer’s certificate repository. Collecting supporting credentials is effectively a credential chain discovery process. However, it is not a good approach to make a certificate repository freely accessible to everybody. Otherwise, one’s privacy will be severely jeopardized. Two policy languages were proposed in [43], both of which are based on XML. DTPL (Definite Trust Policy Language) supports a monotonic semantics, while TPL (Trust Policy Language), an extension to DTPL, supports negative certificates. DTPL is user-friendly and expressive. The TE system does not consider the sensitive information in a user’s certificates. Thus, trust establishment is unilateral. Trust negotiation can be integrated with the TE system to protect sensitive credentials 161
and gradually establish trust.
9.3.2 KeyNote KeyNote is a capability-based trust management system developed by Blaze et al. [11, 12] at AT&T LabsResearch. It is designed to manage delegation of authority for a particular application. It is not for establishing trust between strangers, since clients are assumed to possess credentials that represent authorization of specific actions with the application server. In KeyNote, a credential describes the conditions under which one principal authorizes actions requested by other principals. KeyNote policies delegate authority on behalf of the associated application to otherwise untrusted parties. KeyNote credentials express delegation in terms of actions that are relevant to a given application. KeyNote policies do not interpret the meaning of credentials for the application. This is unlike policies designed for use with property-based credentials, which typically derive roles from credential attributes. The Simple Public Key Infrastructure [46] uses a similar approach to that of KeyNote, by embedding authorization directly in certificates. Since a credential in KeyNote is an authorization assertion and does not describe the general properties of an entity, the protection of sensitive credentials is not considered in KeyNote.
9.3.3 SD3 SD3 [50] (Secure Dynamically Distributed Datalog) is another trust management system developed at AT&T Labs-Research. Similar to KeyNote, SD3 allows users to specify high level security policies through a policy language. The detailed policy evaluation and certificate verification is handled by SD3. Since the policy language in SD3 is an extension of datalog, security policies are a set of assumptions and inference rules. Compared to KeyNote, SD3 offers two unique features. First, SD3 supports credential retrieval. SD3 is able to automatically contact a remote party to gather further credentials during the evaluation of a policy. Second, SD3’s policy evaluation is separated into two steps. In the first step, given a query (e.g., whether an entity is entitled to access a resource), a policy evaluator should not only output the answer for the query, but also a proof of the answer from the assumptions and rules specified in an application. In the second step, the answer and the proof are passed to a simple checker, which verifies whether the proof is correct. By doing 162
so, only the simple checker is required to be trusted by the system. The policy evaluator can be customized or completely provided by a third party, while the enforcement of security policies is still guaranteed 1 . The separation of the policy evaluator and the simple checker is very helpful for the design of a secure yet flexible system. The TrustBuilder prototype can adopt this approach to provide reusable components without jeopardizing the security of a trust negotiation agent. Similar to KeyNote, SD3 does not consider the protection of sensitive credentials. Policy evaluation in SD3 is modeled as a distributed query evaluation process, which assumes that all the parties are cooperative and always willing to provide credentials to support a query evaluation. Such an assumption does not always hold in open computing environments.
9.3.4 Service Accessibility Framework Bonatti and Samarati introduced a uniform framework and model to regulate service access and information release over the Internet [15]. Their framework is composed of a language with formal semantics and a policy filtering mechanism. Their language can be easily extended to be used in automated trust negotiation. Further, the policy filtering mechanism introduced in their work can be integrated with our work to provide better protection of sensitive access control policies. For example, service renamings in their policy filtering mechanism are used in this thesis to distinguish between local and remote credentials and to hide credential semantics. However, in their framework, the negotiation process is assumed to not exceed two rounds of information exchange. In this thesis, we consider the general process of bilateral trust establishment, where multiple rounds of information exchange can take place.
9.3.5 RT : A Role-based Trust-management Framework Li et al. [64, 62] introduced a role-based trust-management language RT 0 , which can be easily used to map entities to roles based on the properties described in their credentials. In RT 0 , the concepts of roles and attributes are interchangeable. Four types of credentials are defined, which correspond to four different ways to assert the attributes of an entity. Depending on its type, a credential is either similar to a certificate, where attributes of an entity are directly asserted by an issuer; or similar to a policy, which defines under 1 In fact, this feature guarantees that there will be no unauthorized access, but it may be subject to a denial-of-service attack. A malicious policy evaluator may always generate wrong proofs and cause authorized access to be denied.
163
what circumstances an entity is considered qualified to assume a role and gain access to a resource. For example, the Type-1 credential is of the form A.r ← B, meaning that entity A asserts that entity B has attribute r in A’s domain. Holding such a credential allows B to demonstrate directly its attribute asserted by A. However, Type-2 credentials of the form A.r ← B.r 1 mean that if an entity has attribute r 1 in the domain of B, then it is qualified to have attribute r in the domain of A. A type-2 credential is in fact a rule specifying what properties an entity should have in order to be qualified to assume a role or possess an attribute in another domain. Such a unified treatment of credentials and policies provides benefits in terms of policy evaluation and analysis [63]. RT0 was later extended into a family of trust management languages [61], including RT1 , where roles are parameterized, RT T , where separation of duty is supported, and RT D , which handles delegation. The RT family of trust management languages is designed specifically for trust negotiation, with strict semantics for role/attribute definition. In this thesis, we assume that parties have obtained and cached all relevant credentials before negotiation begins. In [64], Li et al. present an algorithm to locate and retrieve credentials that are not available locally. This credential chain discovery is an important component of trust negotiation, and should be supported by trust negotiation software packages.
9.3.6 The TrustBuilder Project The prototype trust negotiation system for the TrustBuilder Project is being designed and developed at the Internet Security Research Lab at Brigham Young University, under Prof. Kent E. Seamons. The implementations utilize the IBM Trust Establishment (TE) system [43, 42] to create X.509v3 certificates. Attributes associated with credential owners are stored in user-defined extensions of X.509v3 certificates. The TE system supports XML role-based access control policies that TrustBuilder uses to govern access to sensitive credentials, policies, and services. The TE runtime system includes a compliance checker that TrustBuilder uses to verify whether a set of certificates satisfies an access control policy and to determine which credentials satisfy a policy. Recently, the prototype system has been extended to support the RT framework for trust negotiation [62, 64]. The goal of the prototype system is to create scalable, reusable trust negotiation components that can be used with a variety of communication protocols, such as SSL [38], TLS [33] and HTTPS [69]. More information on the current status of the TrustBuilder prototypes can be found at http://isrl.cs.byu.edu. 164
Chapter 10
Conclusions One of the Internet’s significant differences from a traditional distributed system is that the Internet provides an environment where different parties may make connections and interact without being previously known to each other. Such an environment enables flexible and efficient cooperation among organizations and corporations. Dynamic collaboration, which is common in joint military activities, joint corporate ventures and crisis response, often demands unanticipated resource sharing across organizational boundaries. Traditional access control approaches, which are typically based on a single security domain and are centrally administered, are not adequate for the purpose of authorization in dynamic collaboration. The unanticipated resource sharing inherent in open computing requires nimble security facilities that will help organizations and individuals to rapidly and efficiently access each other’s resources and integrate the information provided by the resources, while offering specific privacy guarantees. Automated trust negotiation is a new approach to authorization and authentication in open, flexible systems. In open computing environments, interactions often happen between entities from different security domains. Therefore, identity alone is often inadequate for the purpose of authorization. Instead, in the same way as people interact in daily life, one’s properties or attributes serve as bases for trust establishment and access control. In automated trust negotiation, one’s properties are demonstrated through the use of digital credentials. To prevent a local resource from being accessed by arbitrary outsiders, in trust negotiation, the resource has an access control policy indicating what properties an outsider needs to have before the resource can be accessed. An outsider can disclose appropriate credentials to prove that she does have the required properties. Credentials often contain sensitive information about an entity. Thus, their disclosure should also be
165
protected by access control policies. The same is true of access control policies themselves. Since both negotiating parties may have a variety of relevant resources protected by access control policies, trust must bes established through a bilateral, iterative sequence of credential disclosures instead of an unilateral oneshot authorization. Therefore, the goal of trust negotiation is to find a credential disclosure sequence leading to the “disclosure” of (granting of access to) a resource R to which the client originally requested access. The sequence must be safe in the sense that when a credential or other resource is disclosed, its access control policy must be satisfied by credentials disclosed before it in the sequence. The full deployment of automated trust negotiation will rely on the resolution of many challenging issues. In this thesis, we focused on two key problems: • Trust negotiation strategies — how to guarantee the success of trust establishment whenever possible and, meanwhile, support users’ autonomy during trust negotiation. • Sensitive information protection — how to prevent unintentional information flow during trust negotiation. In the following sections, we summarize this thesis (section 10.1) and discuss directions for future work (section 10.2).
10.1 Summary 10.1.1 Trust Negotiation Strategies In automated trust negotiation, each party adopts a trust negotiation strategy, which controls the content of messages that the party sends to others and determines when to terminate the negotiation. Intuitively, a strategy determines how cautious a party is about disclosing information to others (subject to the condition that the access control policy for that information has been satisfied). It is highly desirable that two parties always be able to establish trust whenever their access control policies allow, so that valuable cooperation opportunities will not be missed. There is a potential conflict between trust establishment and being cautious in information disclosure. We first studied how to guarantee the success of trust establishment under the model of two-party computation. In this model, Alice and Bob are fully cooperative with each other. They each hold part of the 166
information (i.e., resources and their access control policies) relevant to trust establishment. The problem that they want to solve is to find a safe credential disclosure sequence leading to the disclosure of the resource R to which Alice originally requested access. In this model, a strategy can be viewed as a distributed algorithm that Alice and Bob follow to find a safe disclosure sequence, by providing necessary information to each other. There are several desirable properties of strategies under this model. First, a strategy should be complete, in the sense that, by following the strategy faithfully, Alice and Bob should be able to establish trust whenever possible. Second, if there is no way that trust can be established, Alice and Bob should be able to find this out and terminate the negotiation. Third, the strategy should be efficient in terms of both communication and computation cost. In this thesis, we presented PRUNES, a strategy that possesses all the above properties. PRUNES is derived from a basic backtracking strategy, which searches the space of possible safe disclosure sequences in a depth-first manner. However, such a brute-force search is very expensive. Its communication and computation cost in the worst case is exponential in the number of credentials possessed by the two parties. PRUNES greatly improves the performance of the backtracking strategy based on the observation that a credential does not need to be requested a second time if the information exchanged between the two parties since the previous request has not significantly changed the status of the negotiation. Such an observation allows us to greatly prune the search space of safe disclosure sequences, and at the same time, still guarantee the success of a trust negotiation whenever possible. We proved that PRUNES is complete and efficient. Its worst case communication cost (the total number and size of messages exchanged between Alice and Bob) is bounded by O(n2 ), where n is the number of credentials in the possession of the two parties. Meanwhile, its computation cost is bounded by O(nm), where m is the total size of the access control policies of the two parties. PRUNES was the first complete and efficient strategy proposed for trust negotiation. Previously proposed strategies [88] either resulted in exponential communication and computation cost in the worst case or caused a large number of unnecessary credential disclosures, which is not appropriate for protecting users’ privacy. The model of two-party computation assumes that Alice and Bob follow the same strategy. However, because the Internet is a free-wheeling place with decentralized control, all parties that might need to ne167
gotiate trust — that is, all users, organizations, and software entities — should be free to choose whatever strategy meets their current needs. Generally, two strangers will often not wish to use the same strategy, and a party might prefer to use different strategies in different situations. In this thesis, we investigated how to still guarantee the success of a trust negotiation while giving Alice and Bob the freedom to autonomously choose strategies they like. We proposed a trust negotiation protocol, which formally defines the format of messages exchanged between Alice and Bob, and defines the signal that indicates that the negotiation has ended. We formalized the concept of a strategy as an algorithm whose inputs include all the disclosures made so far in a trust negotiation plus the local party’s credentials and access control policies. A strategy’s output is a set of safe disclosures that a party should send in its next message. The formalization of negotiation protocols and strategies lays the foundation for our study of interoperability between different strategies, i.e., the ability of two strategies to establish trust whenever possible. In order to reason about whether two parties can potentially establish trust as a negotiation unfolds, we proposed the concept of disclosure trees to accurately represent the status of a trust negotiation. Through the use of disclosure trees, we identified necessary and sufficient conditions for a successful negotiation. Based on these theoretical results, we presented a maximal set of mutually interoperable strategies called the disclosure tree strategy family (DTS family), which contains a wide range of strategies. The importance of our research on strategy interoperability and strategy families lies in the following aspects: • The concept of disclosure trees reveals the intrinsic structure and potential outcomes of an ongoing trust negotiation in a very intuitive way. Furthermore, we defined simple operations on disclosure trees which enable us to easily and accurately represent the incremental progress of a trust negotiation. • The DTS family of strategies provides users with maximal flexibility in choosing strategies to meet their requirements. Meanwhile, the success of a trust negotiation is guaranteed whenever possible, as long as the two parties are using strategies from the same family. Therefore the DTS family represents an elegant solution to the problem of supporting trust establishment and, meanwhile, preserving users’ autonomy in open computing environments. • The DTS family of strategies has the additionally highly desirable property that either party can dy168
namically change to a different strategy from the DTS family during an ongoing trust negotiation, without jeopardizing the success of trust establishment. This gives users the freedom to adaptively choose strategies according to the nature of the information involved during a trust negotiation. • The way we construct the DTS family represents a general method for designing strategy families. We first designed the disclosure tree strategy, which always discloses a minimal amount of information that will allow the other party to further advance the negotiation. Then we prove that the set of all strategies that disclose at least as much information as the disclosure tree strategy form a maximal set of interoperable strategies. Such a method can be applied to other trust negotiation protocols, for example, when structured credentials and sensitive policy protection are considered. We extended DTS to support credentials with internal structure. The resulting BTS family has the same strong points as the DTS family.
10.1.2 Sensitive Information Protection In trust negotiation, because of multiple rounds of information disclosure, information may flow to others in a variety of forms. Access control policies play a central role in protecting one’s sensitive information. However, credential disclosure is only one form of information flow. To provide strong protection of users’ sensitive information, we need to identify other forms of information flow in trust negotiation and design new techniques to control them properly. In this thesis, we showed through motivating examples that access control policies may contain sensitive information. Disclosing them indiscriminately may cause serious information leaks and jeopardize a party’s privacy. After analyzing the pros and cons of two approaches previously proposed in the literature, we identified desiderata for access control policy protection in trust negotiation to serve as a guide to our approach to this problem. Based on the desiderata, we presented a unified scheme for resource protection (UniPro) for trust negotiation. Compared to other approaches, UniPro has the following advantages and novel features: • In UniPro, access control policies are explicitly modeled as first-class resources. Therefore, the protection power provided by UniPro is the same for access control policies as for other resources (e.g., credentials and services). 169
• The semantics of UniPro strictly distinguishes between whether a party is entitled to access a resource, and whether a party is entitled to access the policy that protects that resource. This property provides new levels of freedom in policy protection, such as the ability to offer a service whose existence and policies are known only to pre-selected clients. For example, suppose the policy P for Alice’s medical record specifies that, to gain access to Alice’s record, one must be a social worker possessing a release-of-information credential issued by Alice. Clearly, the content of P suggests that Alice has some mental or emotional problem. To prevent such an inference, Alice may specify that nobody can see the content of P during a trust negotiation. Meanwhile, the social worker for Alice’s case may get a copy of P through an offline channel. Though the social worker cannot see the content of P during a trust negotiation, it does not prevent her from satisfying policy P and gaining access to Alice’s medical records, since whether the record can be accessed depends only on the satisfaction of P and is independent of whether a requester can see the content of P during the negotiation. • UniPro allows simple yet expressive policy composition, which enables users to exert fine-grained control over which users can see which parts of a policy. For example, suppose a web server for a multinational corporation automatically supports benefits enrollment and payroll processing services. The available credentials and associated policies vary dramatically from country to country. To ensure that its policies are scalable and maintainable, the server requests a credential indicating the client’s country of residence. Then it provides the policy associated with that country only. Suppose R represents the service and the corporation runs business in two countries, the US and Canada. Then R’s policy P is composed of two policies P U S and PCA , which specify regulations regarding benefit enrollment in the two countries respectively. By assigning different access control policies to P U S and PCA , the system can ensure that an employee can only see the benefit enrollment policy in the country where she is a resident. • UniPro does not dictate a particular choice of policy language. This allows UniPro to take advantage of human-friendly interface tools for policy capture and maintenance as such tools are developed, and also to take advantage of advances in the design of policy languages for trust negotiation.
170
• Though the structure of UniPro is simple, it provably generalizes previous approaches to protecting policies in trust negotiation. Some of the advantages of UniPro come at a price. In particular, a trust negotiation between Alice and Bob can fail because Alice cannot see one of Bob’s policies and is unwilling to blindly disclose her credentials in the hope of satisfying a policy that she cannot see. UniPro exposes this tradeoff, allowing policy designers to choose between greater privacy for their policies and an increased chance of negotiation failure. In this thesis, we investigated the impact of UniPro on strategy interoperability. By weakening the concept of interoperability, we designed the UTS family, a maximal set of strategies for UniPro that gives users a reasonable balance between policy protection and the success of trust negotiation. Ideally, the sensitive information in a credential should not be known to others unless its access control policy has been satisfied. However, there are pitfalls in trust negotiation that can be easily exploited by an attacker to infer one’s sensitive information even though access control policies are strictly enforced. In this thesis, we identified two types of vulnerabilities in trust negotiation. In the first type, an attacker can infer the sensitive value of an attribute in Alice’s credential by observing her reaction to the disclosure of an access control policy. We call credentials subject to such an attack attribute-sensitive credentials. Sometimes, the fact that that Alice does or does not possess a certain credential is also quite sensitive. An attacker can also infer such information from observing Alice’s behavior. We call credentials subject to this attack possession-sensitive and non-possession sensitive credentials. We propose policy filtering and policy migration as two techniques to protect attribute-sensitive credentials and possession-sensitive credentials, respectively. In policy filtering, suppose Alice considers her age attribute in her driver’s license to be sensitive. Then when Alice evaluates an access control policy P , which asks her to show her driver’s license and prove her age is over 21, she will deliberately omit any constraints on her age. Therefore, the response that Alice gives to P cannot be used to infer the value of her age attribute. Policy filtering will never cause a potentially successful negotiation to fail. However, policy filtering may cause a negotiation to involve credentials that are actually irrelevant to its success. This is because policy filtering weakens access control policies. However, we believe this is a necessary tradeoff in order to protect one’s sensitive information. Policy migration is targeted at protecting possession-sensitive and non-possession sensitive credentials. 171
Suppose Alice considers her CIA agent credential C possession-sensitive. When C is mentioned in Bob’s policy, instead of disclosing the policy for her CIA credential to Bob (which can be exploited by Bob to infer that Alice is working for the CIA), Alice can integrate her policy for C into the policies for other credentials and disclose those modified policies to Bob. In this way, the policy for her CIA credential is in fact enforced though Alice does not directly disclose this policy. We show that under policy migration, Alice’s response will be the same as the response that could be sent by another party who does not possess a CIA agent credential. Thus, in theory, Bob cannot tell whether Alice possesses a CIA agent credential from her behavior. Policy filtering and policy migration have several advantages over other approaches in the literature. • They are easy to deploy in trust negotiation systems. They do not require modification to the components of the existing trust negotiation systems and impose a low management overhead on human users. • Unlike some of the approaches proposed in [86, 85], policy filtering and policy migration do not rely on the pre-arranged cooperation of a large group of users, which is a desirable property for privacy protection in decentralized environments. • Policy filtering and policy migration provide a nice balance between the success of a trust negotiation and privacy protection. In particular, we showed under what circumstances policy migration can effectively protect one’s privacy without jeopardizing the success of a trust negotiation. Sensitive information protection and inference prevention is a hard problem, especially in the context of trust negotiation, where multiple rounds of information exchange take place. Policy filtering and policy migration are two techniques to alleviate the inference problem, but they do not give a complete solution to the problem. For example, Bob may be able to guess that Alice works for the CIA by using his human understanding of how the world works to detect odd aspects of the policies that Alice sends him — e.g., if she tells him that she will only show him her driver’s license if he works for the CIA. Further work is needed to develop more comprehensive approaches to privacy protection. In this thesis, we also discussed other possible attacks that violate one’s privacy, including propagation of private information and information gathering and analysis.
172
10.2 Future Work As we mentioned before, the full deployment of trust negotiation depends on the resolution of many challenging problems. In our future work in this area, we plan to explore the following directions. 1. Trust is a very broad concept. Depending on the specific context, applications may have different understandings of and requirements for trust and trust management. We believe that trust negotiation is only one step toward building a secure open computing environment. Specifically, trust negotiation enables strangers from different security domains to get familiar with each other. The trust built during this step may be strengthened in their future interactions through a different trust model. For example, consider a carefully managed online auction system. Trust negotiation will enable Alice to gain local identities, capabilities or roles, so that Alice has the privilege to do business inside the community. Meanwhile, inside the auction system, a reputation-based trust model may be more appropriate to ensure that transactions are conducted properly. On the other hand, trust negotiation may also take place between users inside the auction system, where a user’s reputation is taken as a special credential certified by the auction system. In our future work, we plan to investigate the integration of different trust models and provide a more comprehensive trust management framework for secure open computing. 2. In chapter 3, we model trust negotiation as a two-party computation problem. In the future, we plan to investigate whether the theory of secure multi-party function computation can be applied to trust negotiation. The problem of secure multi-party function computation is as follows: n players, P 1 , . . . , Pn , wish to evaluate a function F (x1 , . . . , xn ), where xi is a secret value provided by P i . The goal is to preserve the privacy of the player’s inputs and guarantee the correctness of the computation. Trust negotiation maps naturally to this formulation. We have players Alice and Bob, each of which has a set of credentials and corresponding access control policies. The output of the function they compute is a safe disclosure sequence. We would like to investigate how well privacy is protected under this model and whether there is an efficient way to conduct this secure two-party function computation. 3. Inference protection is a hard problem in trust negotiation. Currently our approach to this problem 173
is quite ad hoc, in the sense that we identify one possible way for an attacker to infer one kind of sensitive information, then we propose a solution to that problem. Such an approach cannot give us any guarantee of how good the protection really is. In our future work, we plan to formally model the information flow between two negotiation participants so that we can study inference prevention in a systematic way. 4. No matter what methods — even zero-knowledge proofs — Alice uses to prove that she has the credentials to satisfy a policy, the fact that Alice can satisfy the policy does flow to Bob. Therefore, Bob can still learn about Alice’s properties during the interaction. Even if none of Alice’s identities are disclosed (as in anonymous credential systems), by studying Alice’s attributes, it may still be possible for Bob to figure out Alice’s identity. For example, if Bob knows the zip code of Alice’s address and her date of birth, Bob will be able to narrow down Alice’s identity to a small group of possibilities, by studying publicly available information. This process can be very effective if there are powerful analytical tools (such as data mining software) available. In general, each attribute of Alice has a discriminating factor, in the sense that by knowing the value of this attribute, the set of possibilities for Alice’s identity can be narrowed down by a certain factor. During a trust negotiation, before Alice discloses the value of one of her attributes to Bob, she should consider the discriminating factor of that attribute and apply appropriate access control policies. Note that Alice needs to consider all the information she has previously disclosed to Bob in order to determine the dynamic discriminating factor for that attribute. Thus, access control policies should be dynamically associated with each credential, rather than statically assigned. In our future work, we plan to further study the model of information discriminating factors and propose a general framework for privacy protection for trust negotiation. 5. Access control policies are a cornerstone of trust negotiation. Organizations and individuals must have faith in their resources’ policies, or they will be afraid to open their systems to access from outside. To instill confidence in policies, the person in charge of security for a resource will need a policy editor, access to canned, composable, and reusable policies (e.g., the definitions of a non-profit company, a full-time student at an accredited university, a minority-owned business); and ways to analyze, understand, and test policies before they are deployed. Security managers will want tools for regression 174
testing (comparison of policy coverage under old and new sets of policies), consistency checking, and comparison of policies against higher-level specifications (when available). Without such tools, many organizations will be unable to change their security policies for fear that alterations will create security holes that leave them vulnerable. These concerns arise in automated trust negotiation and also in the growing number of other computational realms that rely on policies. In our future work, we will investigate the design of policy management systems. In particular, we are interested in the infrastructure for policy template distribution, the model for policy reuse and customization, and the analysis of policy correctness according to high-level policy requirements.
175
References [1] N. Adam and J. Wortman. Security-Control Methods for Statistical Databases: A Comparative Study. ACM Computing Surveys, 21(4), 1989. [2] R. Agrawal, J. Kiernan, R. Srikant, and Y. Xu. Hippocratic Databases. In 28th International Conference on Very Large Data Bases, Hong Kong, Aug. 2002. [3] R. Agrawal, J. Kiernan, R. Srikant, and Y. Xu. Implementing P3P Using Database Technology. In 19th International Conference on Data Engineering, Bangalore, Mar. 2003. [4] K. R. Apt, D. S. Warren, and M. Truszczynski, editors. The Logic Programming Paradigm: A 25-Year Perspective. Springer-Verlag, 1999. [5] R. Atkinson. Security Architecture for the Internet Protocol. In http://www.ietf.org/rfc/rfc2401.txt, Nov. 1998. [6] D. Bell and L. LaPadula. Secure Computer Systems: Mathematical Foundations and Model. Technical Report M74-244, Mitre Corporation, Belford, MA, 1975. [7] C. Bennett. Regulating Privacy: Data Protection and Public Policies in Europe and the United States. Cornell University Press, 1992. [8] E. Bina, V. Jones, R. McCool, and M. Winslett. Secure Access to Data Over the Internet. In Conference on Parallel and Distributed Information Systems, Sept. 1994. [9] J. Biskup and P. Bonatti. Lying versus refusal for known potential secrets. Data & Knowledge Engineering, 38(2), 2001.
176
[10] J. Biskup and P. Bonatti. Controlled Query Evaluation for Known Policies by Combining Lying and Refusal. In International Symposium on Foundations of Information and Knowledge Systems, Salzau Castle, Germany, Feb. 2002. [11] M. Blaze, J. Feigenbaum, J. Ioannidis, and A. Keromytis. The KeyNote Trust Management System Version 2. In Internet Draft RFC 2704, Sept. 1999. [12] M. Blaze, J. Feigenbaum, and A. D. Keromytis. KeyNote: Trust Management for Public-Key Infrastructures. In Security Protocols Workshop, Cambridge, UK, 1998. [13] M. Blaze, J. Feigenbaum, and M. Strauss. Compliance Checking in the PolicyMaker Trust Management System. In Financial Cryptography, British West Indies, Feb. 1998. [14] G. Bleumer. Biometric yet Privacy Protecting Person Authentication. In International Workshop on Information Hidding, volume 1525 of Lecture Notes in Computer Science. Springer, 1998. [15] P. Bonatti and P. Samarati. Regulating Service Access and Information Release on the Web. In Conference on Computer and Communications Security, Athens, Nov. 2000. [16] P. Bonatti, S. Vimercati, and P. Samarati. A Modular Approach to Composing Access Control Policies. In ACM Conference on Computer and Communication Security, Athens, Greece, Nov. 2000. [17] D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. Nielsen, S. Thatte, and D. Winer. Simple Object Access Protocol (SOAP) 1.1. World Wide Web Consortium, May 2000. [18] M. Branchaud. A Survey of Public Key Infrastructures. Master’s thesis, Department of Computer Science, McGill University, Montreal, Mar. 1997. [19] S. Brands. Rethinking Public Key Infrastructures and Digital Certificates: Building in Privacy. The MIT Press, 2000. [20] C. Breed. Pki: The myth, the magic and the reality. Information Security, June 1999. [21] J. Camenisch and E. Herreweghen. Design and Implementation of the Idemix Anonymous Credential System. In ACM Conference on Computer and Communication Security, Washington D.C., Nov. 2002.
177
[22] J. Camenisch and A. Lysyanskaya. Efficient Non-Transferable Anonymous Multi-Show Credential System with Optional Anonymity Revocation. In EUROCRYPT 2001, volume 2045 of Lecture Notes in Computer Science. Springer, 2001. [23] S. Castano, M. Fugini, G. Martella, and P. Samarati. Database Security. Addison-Wesley & ACM Press, 1995. [24] D. Chadwick, A. Otenko, and E. Ball. Role-Based Access Control With X.509 Attribute Certificates. IEEE Internet Computing, 7(2), Mar. 2003. [25] L. Chang and I. Moskowitz. An Integrated Framework for Database Privacy Protection. In 14th IFIP WG11.3 Working Conference on Data and Application Security, Amsterdam, Aug. 2000. [26] D. Chaum. Security without Identification: Transactions Systems to Make Big Brother Obsolete. Communications of the ACM, 24(2), 1985. [27] D. Chaum and J. Evertse. A Secure and Privacy-Protecting Protocol for Transmitting Personal Information Between Organizations. In CRYPTO’86, volume 263 of Lecture Notes in Computer Science. Springer, 1987. [28] F. Chin and G. Ozsoyoglu. Auditing and Inference Control in Statistical Databases. IEEE Transactions on Software Engineering, 8(6), 1982. [29] I. Damgård. Payment Systems and Credential Mechanism with Provable Security Against Abuse by Individuals. In CRYPTO’88, volume 403 of Lecture Notes in Computer Science. Springer, 1990. [30] E. Damiani, S. Vimercati, S. Paraboschi, P. Samarati, and F. Violante. A Reputation-based Approach for Choosing Reliable Resources in Peer-to-Peer Networks. In ACM Conference on Computer and Communication Security, Washington, DC, Nov. 2002. [31] D. Damianou, N. Dulay, E. Lupu, and M. Sloman. The Ponder Policy Specification Language. In 2nd International Workshop on Policies for Distributed Systems and Networks, Bristol, UK, Jan. 2001. [32] D. Dean and A. Stubblefield. Using Client Puzzles to Protect TLS. In Annual USENIX Security Symposium, Washington, D.C., Aug. 2001. 178
[33] T. Dierks and C. Allen. The TLS Protocol Version 1.0. In http://www.ietf.org/rfc/rfc2246.txt, Jan. 1999. [34] I. Dinur and K. Nissim. Revealing Information While Preserving Privacy. In ACM SIGACT-SIGMODSIGART Symposium on Principles of Database Systems, San Diego, CA, June 2003. [35] L. Doorn, M. Abadi, M. Burrows, and E. Wobber. Secure Network Objects. In J. Vitek and C. Jensen, editors, Secure Internet Programming, Security Issues for Mobile and Distributed Objects, pages 395– 412. Springer, 1999. [36] C. Dwork, J. Lotspiech, and M. Naor. Digital Signets: Self-Enforcing Protecction of Digital Information. In Symposium on the Theory of Computing, Philadelphia, PA, May 1996. [37] S.
Farrell.
TLS
Extension
for
Attribute
Certificate
Based
Authorization.
In
http://www.ietf.org/proceedings/99jul/I-D/draft-ietf-tls-attr-cert-01.txt, Aug. 1998. [38] A. Frier, P. Karlton, and P. Kocher. The SSL 3.0 Protocol. Netscape Communications Corp., Nov. 1996. [39] D.
Gamberoni.
In-Person
Proofing
at
Post
Offices
(IPP)
Program.
In
http://www.ribbs.usps.gov/files/fedreg/usps2003/03-15211.PDF, June 2003. [40] O. Goldreich, B. Pfitzman, and R. Rivest. Self-Delegation with Controlled Propagation — or — What If You Lose Your Laptop. In CRYPTO’98, volume 1642 of Lecture Notes in Computer Science. Springer, 1998. [41] L. Gong. A Secure Identity-Based Capability System. In IEEE Symposium on Security and Privacy, Oakland, CA, May 1989. [42] A. Herzberg and Y. Mass. Relying Party Credentials Framework. In The Cryptographer’s Track at RSA Conference, San Francisco, CA, Apr. 2001. [43] A. Herzberg, J. Mihaeli, Y. Mass, D. Naor, and Y. Ravid. Access Control Meets Public Key Infrastructure, Or: Assigning Roles to Strangers. In IEEE Symposium on Security and Privacy, Oakland, CA, May 2000. 179
[44] A. Hess, J. Jacobson, H. Mills, R. Wamsley, K. Seamons, and B. Smith. Advanced Client/Server Authentication in TLS. In Network and Distributed System Security Symposium, San Diego, CA, Feb. 2002. [45] http://www.cio-dpi.gc.ca/pki-icp/. Government of Canada Public Key Infrastructure. [46] http://www.ietf.org/html.charters/spki-charter.html. Simple Public Key Infrastructure (SPKI). [47] International Telecommunication Union. Rec. X.509 - Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, Aug. 1997. [48] N. Islam, R. Anand, T. Jaeger, and J. R. Rao. A Flexible Security System for Using Internet Content. IEEE Software, 14(5), Sept. 1997. [49] R. Jarvis. Selective Disclosure of Credential Content during Trust Negotiation. Master’s thesis, Dept. of Computer Science, Brigham Young University, Apr. 2003. [50] T. Jim. SD3: A Trust Management System With Certified Evaluation. In IEEE Symposium on Security and Privacy, Oakland, CA, May 2001. [51] W. Johnson, S. Mudumbai, and M. Thompson. Authorization and Attribute Certificates for Widely Distributed Access Control. In IEEE International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, 1998. [52] A. Juels and J. Brainard. Client Puzzle: A Cryptographic Defense Against Connection Depletion Attacks. In Network and Distributed System Security Symposium, San Diego, CA, Feb. 1999. [53] G. Karjoth, M. Schunter, and M. Waidner. Platform for Enterprise Privacy Practices: Privacy-enabled Management of Customer Data. In 2nd Workshop on Privacy Enhancing Technologies, San Francisco, CA, Apr. 2002. [54] R. Khare and A. Rifkin. Weaving a Web of Trust. World Wide Web Journal, special issue on security, 2(3), 1997. [55] P. Kocher. Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems. In http://www.cryptography.com/resources/whitepapers/TimingAttacks.pdf, Dec. 1995. 180
[56] P. Kocher. On Certificate Revocation and Validation. In International Conference on Financial Cryptography, Anguilla, British West Indies, Feb. 1998. [57] P. Kocher, J. Jaffe, and B. Jun. Differential Power Analysis. In CRYPTO’99, volume 1666 of Lecture Notes in Computer Science. Springer, 1999. [58] B. Lampson. Protection. In 5th Princeton Symposium on Information Science and Systems, Princeton, New Jersey, Mar. 1971. [59] S. Lee, R. Sherwood, and B. Bhattacharjee. Cooperative Peer Groups in NICE. In IEEE Infocom, San Francisco, CA, Apr. 2003. [60] J.
Leyden.
Office
Workers
Give
Away
Passwords
for
a
Cheap
Pen.
In
http://www.theregister.co.uk/content/55/30324.html, Apr. 2003. [61] N. Li and J. Mitchell. RT: A Role-based Trust-management Framework. In DARPA Information Survivability Conference and Exposition (DISCEX), Washington, D.C., Apr. 2003. [62] N. Li, J. Mitchell, and W. Winsborough. Design of a Role-based Trust-management Framework. In IEEE Symposium on Security and Privacy, Berkeley, California, May 2002. [63] N. Li, W. Winsborough, and J. Mitchell. Beyond Proof-of-compliance: Safety and Availability Analysis in Trust Management. In IEEE Symposium on Security and Privacy, Berkeley, California, May 2003. [64] N. Li, W. Winsborough, and J. Mitchell. Distributed Credential Chain Discovery in Trust Management. Journal of Computer Security, 11(1), Feb. 2003. [65] A. Lysyanskaya, R. Rivest, A. Sahai, and S. Wolf. Pseudonym Systems. In Selected Areas in Cryptography, 1999, volume 1758 of Lecture Notes in Computer Science. Springer, 2000. [66] MANBIZ IPP LLC. Frequent Asked Questions. [67] P. McDaniel and A. Rubin. A Response to "Can We Eliminate Certificate Revocation Lists?". In International Conference on Financial Cryptography, Anguilla, British West Indies, Feb. 2000.
181
[68] S. More and R. Impagliazzo.
Anonymous Credentials with Biometrically-Enforced Non-
Transferability. In ACM Workshop on Privacy in the Electronic Society, Washington, DC, Oct. 2003. [69] E. Rescorla. HTTP Over TLS. In http://www.ietf.org/proceedings/99jul/I-D/draft-ietf-tls-https-02.txt, Sept. 1998. [70] E. Rescorla. SSL and TLS, Designing and Building Secure Systems. Addison-Wesley, 2001. [71] R. Rivest. Can We Eliminate Certificate Revocation Lists? In International Conference on Financial Cryptography, Anguilla, British West Indies, Feb. 1998. [72] M. Rotenberg. Fair Information Practices and the Architecture of Privacy. Stanford Technology Law Review, 1, 2001. [73] A. Rubin and D. Greer. A Survey of the World Wide Web Security. IEEE Computer, 31(9), 1998. [74] K. Sagonas, T. Swift, and D. Warren. Xsb as an efficient deductive database engine. In Proceedings of the 1994 ACM SIGMOD International Conference on Management of Data, pages 442–453, Minneapolis, MN, May 1994. ACM Press. [75] B. Schneier. Applied Cryptography, second edition. John Wiley and Sons. Inc., 1996. [76] B. Schneier. Secrets & Lies. Wiley Computer Publishing, 2000. [77] K. Seamons, M. Winslett, and T. Yu. Limiting the Disclosure of Access Control Policies during Automated Trust Negotiation. In Network and Distributed System Security Symposium, San Diego, CA, Feb. 2001. [78] K. Seamons, M. Winslett, T. Yu, B. Smith, E. Child, J. Jacobsen, H. Mills, and L. Yu. Requirements for Policy Languages for Trust Negotiation. In 3rd International Workshop on Policies for Distributed Systems and Networks, Monterey, CA, June 2002. [79] K. Seamons, M. Winslett, T. Yu, L. Yu, and R. Jarvis. Protecting Privacy during On-line Trust Negotiation. In 2nd Workshop on Privacy Enhancing Technologies, San Francisco, CA, Apr. 2002. [80] R. Shinghal. Formal Concepts in Artificial Intelligence. Chapman & Hall Computing, 1992. 182
[81] W3C, http://www.w3.org/TR/WD-P3P/Overview.html. Platform for Privacy Preferences (P3P) Specification. [82] X. Wang and M. Reiter. Defending Against Denial-of-Service Attacks with Puzzle Auctions. In IEEE Symposium on Security and Privacy, Berkeley, CA, May 2003. [83] D. Wijesekera and S. Jajodia. Policy Algebras for Access Control - The Propositional Case. In ACM Conference on Computer and Communication Security, Philadelphia, PA, Nov. 2001. [84] D. Wijesekera and S. Jajodia. Policy Algebras for Access Control - The Predicate Case. In ACM Conference on Computer and Communication Security, Washington, DC, Nov. 2002. [85] W. Winsborough and N. Li. Protecting Sensitive Attributes in Automated Trust Negotiation. In ACM Workshop on Privacy in the Electronic Society, Washington, DC, Nov. 2002. [86] W. Winsborough and N. Li. Towards Practical Automated Trust Negotiation. In 3rd International Workshop on Policies for Distributed Systems and Networks, Monterey, California, June 2002. [87] W. Winsborough, K. Seamons, and V. Jones. Negotiating Disclosure of Sensitive Credentials. In Second Conference on Security in Communication Networks, Amalfi, Italy, Sept. 1999. [88] W. Winsborough, K. Seamons, and V. Jones. Automated Trust Negotiation. In DARPA Information Survivability Conference and Exposition, Hilton Head Island, SC, Jan. 2000. [89] M. Winslett, T. Yu, K. Seamons, A. Hess, J. Jarvis, B. Smith, and L. Yu. Negotiating Trust on the Web. IEEE Internet Computing, special issue on trust management, 6(6), Nov. 2002. [90] W. Winslett, N. Ching, V. Jones, and I. Slepchin. Using Digital Credentials on the World-Wide Web. Journal of Computer Security, pages 255–267, 1997. [91] M. Witteman. Advances in Smartcard Security. Information Security Bulletin, July 2002. [92] T. Yu, X. Ma, and M. Winslett. PRUNES: An Efficient and Complete Strategy for Automated Trust Negotiation over the Internet. In ACM Conference on Computer and Communication Security, Athens, Greece, Nov. 2000.
183
[93] T. Yu and M. Winslett. A Unified Scheme for Resource Protection in Automated Trust Negotiation. In IEEE Symposium on Security and Privacy, Oakland, CA, May 2003. [94] T. Yu and M. Winslett. Policy Migration for Sensitive Credentials in Trust Negotiation. In ACM Workshop on Privacy in the Electronic Society, Washington, DC, Oct. 2003. [95] T. Yu, M. Winslett, and K. Seamons. Interoperable Strategies in Automated Trust Negotiation. In ACM Conference on Computer and Communication Security, Philadelphia, PA, Nov. 2001. [96] T. Yu, M. Winslett, and K. Seamons. Supporting Structured Credentials and Sensitive Policies through Interoperable Strategies in Automated Trust Negotiation. ACM Transactions on Information and System Security, 6(1), Feb. 2003. [97] P. Zimmerman. PGP User’s Guide. MIT Press, 1994.
184
Vita Ting Yu was born in Beijing, China. He received his B.S. degree in Computer Science from Peking University in 1997. He started his graduate studies at the University of Minnesota in August 1997 and received his M.S. degree in Computer Science in 1998, for his work on the analysis of the connectivity of network topology. Ting continued his PhD studies at the University of Illinois at Urbana-Champaign after the Master’s degree. His Ph.D. thesis focused on automated trust negotiation, which dynamically establishes trust between entities in open computing environments. He proposed a maximal set of negotiation strategies to guarantee the success of trust establishment while preserving the autonomy of each negotiating party, and designed advanced resource protection schemes to preserve users’ privacy during trust establishment.
185
