Network Working Group K. Ono Internet-Draft NTT Corporation Expires: January 11, 2006 H. Schulzrinne Columbia University July 10, 2005 Trust Path Discovery draft-ono-trust-path-discovery-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 11, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Chained or transitive trust can be used to determine whether incoming communication is likely to be desirable or not. We can build a chained trust relationship by introducing friends to out friends, for example. We propose mechanisms for discovering trust paths and binary responsive trustworthiness. The trust paths are based on a chain of trust relationships between users, a user and a domain, and domains. We apply this model to relatively low-value trust Ono & Schulzrinne Expires January 11, 2006 [Page 1] Internet-Draft Trust Path Discovery July 2005 establishment, suitable for deciding whether to accept communication requests such as emails, calls, or instant messages from strangers. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [1]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protection Mechanisms for Unsolicited Bulk Messages . . . . 4 3. Our Goal and Approach . . . . . . . . . . . . . . . . . . . 5 4. What Indicates a Trust Relationship? . . . . . . . . . . . . 5 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1 Generic Requirements . . . . . . . . . . . . . . . . . . . 5 5.2 Security Requirements . . . . . . . . . . . . . . . . . . 6 6. Operations on Trust Paths . . . . . . . . . . . . . . . . . 6 6.1 Generating Trust Paths . . . . . . . . . . . . . . . . . . 6 6.2 Propagating Trust Paths . . . . . . . . . . . . . . . . . 7 6.3 Aggregating Trust Paths . . . . . . . . . . . . . . . . . 8 7. Network Architecture . . . . . . . . . . . . . . . . . . . . 9 7.1 Peering Model . . . . . . . . . . . . . . . . . . . . . . 9 7.2 Client-server Model . . . . . . . . . . . . . . . . . . . 9 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . 10 8.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1 Normative References . . . . . . . . . . . . . . . . . . 12 11.2 Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . 14 Ono & Schulzrinne Expires January 11, 2006 [Page 2] Internet-Draft Trust Path Discovery July 2005 1. Introduction When dealing with strangers in electronic interactions, establishing trust is the core challenge as mere authentication does not yield more than a name or URI. Trust depends on the interaction. Different levels of trust are required based on the potential impact and risk of the interaction. We focus here on relatively low-risk interactions where more potential parties are trustworthy. There are some methods to determine the trustworthiness of a stranger in networks. One method is to ask the third party, such as a reputation system that rates the entity by some numerical scale such as "trust points". The trust points are based on evaluations that other anonymous entities have performed, including the experience from past transactions. Such trust points are often used for e-commerce, such as auction sites or small sellers aggregated by a large e-commerce site. Another method is to ask trusted friends for their evaluation of the stranger. Their opinions are subjective. We generally trust our own friends more than the unknown third party, but the circle of our friends is small and none of them may know the stranger directly. For communication interactions, instead of a trust scale, only a simple question needs to be answered, namely whether the person making the trust statement would be willing to accept communications from the stranger. The underlying model is that the number of individuals generating unsolicited bulk mails or spam, spit (Spam over Internet Telephony) and other undesirable communications is very small compared to the total population, and thus the likelihood that even a friend-of-a- friend would know or trust such a spammer is also very low. Also, communications often occur in subsets of the total human population that share common values or profession, making it likely that legitimate strangers are known indirectly. In this document, we are not too concerned with establishing trust or bona fides within the spammer community itself. They are invited to address this problem in appropriate fora. Instead of determining the reputation of an individual, it is often sufficient to gauge the trustworthiness of a whole DNS domain. If the domain has a positive reputation and maintains strict rules for minting identifiers for its users, as is common for many large enterprises, we can trust users within the domain without having to establish trust to each individual. Ono & Schulzrinne Expires January 11, 2006 [Page 3] Internet-Draft Trust Path Discovery July 2005 This is not likely to be true for high-value and high-risk transactions such as selling a used car, but as noted above, we are focusing on lower-risk transactions in this document. For gathering trustworthy opinions of our friends or community, we need to find trust paths where we can apply transitive trust. This document proposes mechanisms for discovering trust paths and binary responsive trustworthiness. The trust paths are based on a chain of trust relationship between users, a user and a domain, and domains, in terms of receiving messages, such as emails, calls, or instant messages. We believe that it can provide one component of a system to reduce the amount of unsolicited bulk communication. 2. Protection Mechanisms for Unsolicited Bulk Messages A variety of mechanisms have been proposed to protect recipient against undesirable communications: o Anti-spam mechanisms: Many existing anti-spam mechanisms rely on filtering messages at the receiver, either based on content or sender. However, content-based filtering has limited applicability to emails and instant messages[3]. Sender-based filtering performs based on user's name or URI or server's. For example of server-based filtering, Certified Server Validation [4]uses DNS to provide indications what kind of assertions a domain offers for its users. Third-party accreditation services [5] can attest that an SMTP sender follows certain policies or is otherwise trust worthy. o Anti-spoofing mechanisms: Anti-spoofing mechanisms authenticate originators of messages and calls and nodes that relay such messages or calls. For example, Sender ID [6] uses DNS to provide the proper IP addressees of an SMTP sender. DomainKeys [7] uses a secure hash of the content that a recipient can verify using the domain's public key that is obtained by DNS. For calls or instant messages in SIP [8], SIP identity [9] provides an authentication mechanism of originators. The authentication server located in the originator's domain authenticates the originator by HTTP Digest authentication. The authentication server generates a secure hash of several important headers and the message body on behalf of the originator. The recipient can verify the secure hash using the domain's public key. The destination user authenticates the originator domain by the verification. As a result, the destination user authenticate Ono & Schulzrinne Expires January 11, 2006 [Page 4] Internet-Draft Trust Path Discovery July 2005 the originator via the authentication server. 3. Our Goal and Approach Our goal is to help a recipient of a communication attempt, i.e., an email receiver, callee or target of an instant message, judge whether to accept the message from a stranger. This requires a binary decision of trust. That stranger may then later be added to a whitelist or blacklist, once the recipient has confirmed that future communication is desirable or not. Our approach is to find a chain of trust relationships that exist among individuals or among domains. If a friend of ours tells us that the stranger is his/her own friend, we can decide to accept the communication attempt. If the stranger belongs to a certain trust domain, we might accept it. We call the chains of trust relationships, "trust paths". 4. What Indicates a Trust Relationship? We distinguish trust relationships between users and between domains. Below, we provide examples of how such trust relationships might be established. o Trust relationship between users. e.g., Alice trusts Bob. * Alice has Bob in her watcher list [10], i.e., she has allowed Bob to subscribe to her presence information. [Note: This does not indicate that Bob trusts Alice. In other words, if Bob has Alice in his buddy list, the entry does not indicate that Bob trusts Alice.] * A log contains an email, call, or message from Alice to Bob. * Bob is listed in Alice's white list. o Trust relationship between a user and a domain. e.g., Alice trusts a domain, "A.com". * Alice has registered her SIP contact address in the domain. o Trust relationship between domains. e.g., "A.com" trusts "B.com". * History of transactions. * Contracts or agreements. 5. Requirements 5.1 Generic Requirements Below are some of generic requirements for mechanisms to discover trust paths. Ono & Schulzrinne Expires January 11, 2006 [Page 5] Internet-Draft Trust Path Discovery July 2005 REQ-GEN-1: The solution SHOULD be simple and scalable because the number of users and connections of their friends are huge. REQ-GEN-2: It SHOULD enable entities to obtain the trust path prior to being needed, for quick determination at starting a session. Open Issue: This requirement conflicts with one of the security requirements caused by privacy-sensitivity of the trust path information. REQ-GEN-3: It SHOULD enable entities to set the maximum length of the trust path. The reliability of trust paths diminishes as their length increases. 5.2 Security Requirements Below are security requirements for mechanisms to discover trust paths. REQ-SEC-1: The solution MUST enable entities to obtain a trust path from a trusted and authenticated entity. REQ-SEC-2: It MUST enable entities to obtain a trust path from a trusted entity without revealing its content to unauthorized third parties and while protecting its integrity against modification by entities not on the trust path. REQ-SEC-3: It MUST enable entities to detect forgery of a trust path. REQ-SEC-4: It SHOULD enable entities to reveal only parts of the trust path to a recipient, particularly since trust path information is privacy sensitive. 6. Operations on Trust Paths Trust paths are chains of trust relationships between entities. Each entity generates its own trust paths and exchanges them with each other. In order to quickly discover trust paths, we propose that entities propagate trust information immediately after generating or aggregating trust paths. 6.1 Generating Trust Paths Trust paths are generated from an entity's trust indicators. Trust paths MUST consist of the following information. The message format is shown in Figure 3. Ono & Schulzrinne Expires January 11, 2006 [Page 6] Internet-Draft Trust Path Discovery July 2005 o Entities identity: Originator's URI and friends' URIs. URIs are for users or domains. o Binary opinion of trust: A true/false opinion whether the trustee considers the individual or domain listed a desirable originator of communication. o Export policy: The export policy determines whether a recipient should further propagate this information. Note: Information propagated over many hops is likely to be less reliable, so it is desirable to limit the length of the chain. However, there is no single limit that works in all circumstances, so we rely on including the number of hops that a trust tuple has traversed and then having recipients make decisions on whether to further propagate trust tuples that have traveled far. In addition, the trust path MAY contain the weight on the trustworthiness of individuals or domains. Recipients of trust paths may weigh them differently depending on who has forwarded them. However, we decided against including weights in the trust paths, since this appears difficult to make commensurate among participants. 6.2 Propagating Trust Paths Propagating trust paths is somewhat similar to propagating path vectors in routing protocol such as BGP [11]. Figure 1 depicts an example of trust relationships among five people. Alice mutually trusts Bob and Dave. Bob mutually trusts Alice and Carol. Carol mutually trusts Bob and Ed. Dave (D) <---------------------> Ed (E) ^ ^ | | | | * * Alice (A) <---> Bob (B) <---> Carol (C) A<->B or A*->B: A mutually trusts B. Figure 1: Trust relationship and indicators Ono & Schulzrinne Expires January 11, 2006 [Page 7] Internet-Draft Trust Path Discovery July 2005 1. Alice creates her own trust paths based on her own trust indicators. A: {A,B} and {A,D} 2. Alice sends out the trust paths to all entities that Alice trusts, here Bob and Dave. A->B: {A,B},{A,D}, A->D: {A,B},{A,D} Note: Alice can vary her trust paths according to the recipients. 3. Bob creates his own trust paths based on his own trust indicators before receiving Alice's trust paths. He accepts her trust paths because he trusts her. If not, he drops them. B: {B,A},{B,C} 4. Bob adds his name to the trust path except ones that already includes his name. He sends the modified trust paths to all trusting entities except Alice. B->C: {B,A},{B,C},{B,A,D} 5. Ed sends his trust path to Carol. E->C: {E,D},{E,C} 6. Since Carol trusts Bob and Ed, she accepts these trust paths. Although Carol doesn't directly know Alice nor Dave, now she knows them via Bob and Ed. She receives two paths to Dave, {E,D} from Ed and {B,A,D} from Bob, and then she selects shorter path, {E,D}. C: {C,B},{C,E},{C,B,A},{C,E,D} 6.3 Aggregating Trust Paths As Carol selects shorter path in the example of Figure 1, an entity needs to aggregate receiving trust paths and its own trust paths. An entity SHOULD select the shortest path to the same entity. An entity SHOULD select the most reliable path to the same entity according to the local preference based on the weight of the trustworthiness. If an entity receives different opinions on the same entity, trustworthy and un-trustworthy, it is safer to prioritise the negative opinion, un-trustworthy. If an entity receives a trust path that has any conflict of trustworthiness, the entity MUST drop the trust path. The number of opinions the same entity MAY be summed up in order to indicate objectivity. The aggregation mechanism depends on local policy. Ono & Schulzrinne Expires January 11, 2006 [Page 8] Internet-Draft Trust Path Discovery July 2005 7. Network Architecture Trust paths can be processed and propagated in a peering model or client-server model, both of which we described below. 7.1 Peering Model In a peering model, all entities support the same operations on trust paths. Advantages: o Fewer types of operation messages: To exchange trust paths, only a simple message sending mechanism is needed, in addition to a mechanism to manage peering connections. Disadvantages: o Difficulties in peer authentication: Each entity needs to authenticate each other when propagating its trust paths. This requires pre-shared key or self-signed certificate of all entities. * Option 1: Pre-shared key between entities. Requiring a pre-shared key each between two users is not feasible. However, a group shared-key among all her friends or parts of them is feasible. The group shared-key could be published as one of her events. If they directly connect to each other by using TLS, this option is not appropriate, because TLS requires their certificates. * Option 2: Self-signed certificates. This is feasible since self-signed certificates can be exchanged among entities via credential servers[12]. As a result, it requires servers for this purpose. 7.2 Client-server Model In a client-server model, users connect to opinion server as shown in Figure 2, which in turn peer with each other. Since multiple users are likely to share the same server, the number of entities that need to connect with each other is smaller. Ono & Schulzrinne Expires January 11, 2006 [Page 9] Internet-Draft Trust Path Discovery July 2005 Opinion Server ------------------- Opinion Server (op.A.com) (op.B.com) | | | | Alice (A) Bob (B) Figure 2: Client-server model Advantages: o Easier user authentication: Each entity does not need to authenticate each other when propagating its trust paths. Entities can use transitive trust for mutual user authentication. Each user mutually authenticates the opinion server that he belong to. The opinion server authenticates the user by using Digest authentication with his credential such as a password, and the user authenticates the opinion server by using TLS with its certificate. Each opinion server also authenticates each other by using TLS with their certificates. o Higher service availability: Trust paths remain available even if a user's end system is temporarily unreachable. o Less connections at users' side: Users need to connect only to their own opinion servers. This reduces connection cost at user's side, also makes firewall traversal easier. Disadvantages: o Relatively more types of operation messages: At least, two types of message are mandatory needed. One is for a user to publish his trust paths to his opinion server, and another is for a user to query its friend's trust paths to the friend's opinion server. * Open Issue: How can a user know his friend's opinion server? Is this the same as to find his friend's presence server? To sum up, the client-server model has some advantages. It is RECOMMENDED to use opinion servers that store trust paths and propagate them on behalf of users. 8. Message Formats The message format of trust paths uses the XML [2] data format. The data size of the trust paths depends on the number of its friends and the length of the chain. When sending trust paths to neighbors, entities SHOULD use TCP as a transport protocol. Ono & Schulzrinne Expires January 11, 2006 [Page 10] Internet-Draft Trust Path Discovery July 2005 8.1 Examples Below are examples of trust paths, one is generated locally and has only one hop trust path, and another is propagated and has two hops. sip:alice@A.com sip:bob@B.com sip:dave@D.com yes yes 2005-07-04T20:57:29Z Figure 3: An example of one hop trust path sip:bob@B.com sip:alice@A.com yes yes 2005-07-05T20:57:29Z sip:alice@A.com sip:bob@B.com sip:dave@D.com yes yes 2005-07-04T20:57:29Z Ono & Schulzrinne Expires January 11, 2006 [Page 11] Internet-Draft Trust Path Discovery July 2005 Figure 4: An example of two hops trust paths 9. IANA Considerations TBD 10. Security Considerations TBD 11. References 11.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. 11.2 Informative References [3] Rosenberg, J., "The Session Initiation Protocol (SIP) and Spam", draft-ietf-sipping-spam-00 (work in progress), February 2005. [4] Crocker, D., "Certified Server Validation (CSV)", draft-ietf-marid-csv-intro-02 (work in progress), February 2005. [5] Leslie, J., "Domain Name Accreditation (DNA)", draft-ietf-marid-csv-dna-02 (work in progress), February 2005. [6] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", draft-lyon-senderid-code-01 (work in progress), May 2005. [7] Delany, M., "Domain-based Email Authentication Using Public- Keys Advertised in the DNS (DomainKeys)", draft-delany-domainkeys-base-02 (work in progress), March 2005. [8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [9] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-05 (work in progress), May 2005. Ono & Schulzrinne Expires January 11, 2006 [Page 12] Internet-Draft Trust Path Discovery July 2005 [10] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004. [11] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [12] Jennings, C. and J. Peterson, "Certificate Management Service for The Session Initiation Protocol (SIP)", draft-ietf-sipping-certs-01 (work in progress), February 2005. Authors' Addresses Kumiko Ono Network Service Systems Laboratories NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-shi, Tokyo 180-8585 Japan Email: kumiko@cs.columbia.edu, ono.kumiko@lab.ntt.co.jp Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA Email: schulzrinne@cs.columbia.edu Ono & Schulzrinne Expires January 11, 2006 [Page 13] Internet-Draft Trust Path Discovery July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ono & Schulzrinne Expires January 11, 2006 [Page 14]