Network Working Group                                             K. Ono
Internet-Draft                                           NTT Corporation
Expires: April 25, 2006                                   H. Schulzrinne
                                                     Columbia University
                                                        October 22, 2005


                          Trust Path Discovery
                   draft-ono-trust-path-discovery-01

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 April 25, 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 April 25, 2006                 [Page 1]

Internet-Draft            Trust Path Discovery              October 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
     4.1  Trust Indicators . . . . . . . . . . . . . . . . . . . . .   5
     4.2  Usage of Trust Indicators  . . . . . . . . . . . . . . . .   6
   5.   Requirements . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1  Generic Requirements . . . . . . . . . . . . . . . . . . .   6
     5.2  Security Requirements  . . . . . . . . . . . . . . . . . .   7
   6.   Operations on Trust Paths  . . . . . . . . . . . . . . . . .   7
     6.1  Push-base Model vs. Query-base Model . . . . . . . . . . .   7
   7.   Generating Trust Paths and Destination List  . . . . . . . .   8
     7.1  Trust Paths  . . . . . . . . . . . . . . . . . . . . . . .   8
     7.2  Destination List . . . . . . . . . . . . . . . . . . . . .   9
   8.   Propagating Trust Paths  . . . . . . . . . . . . . . . . . .  10
     8.1  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.2  Network Model  . . . . . . . . . . . . . . . . . . . . . .  11
     8.3  Propagation of Users' Trust Paths via Opinion Servers  . .  13
     8.4  Propagation of Domains' Trust Paths  . . . . . . . . . . .  13
   9.   Aggregating Trust Paths  . . . . . . . . . . . . . . . . . .  13
   10.  Opinion Event Package  . . . . . . . . . . . . . . . . . . .  13
     10.1   Publication and Subscription . . . . . . . . . . . . . .  13
     10.2   Destination List . . . . . . . . . . . . . . . . . . . .  14
   11.  Message Formats of Trust Paths . . . . . . . . . . . . . . .  14
     11.1   Examples of Trust Paths  . . . . . . . . . . . . . . . .  14
   12.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  16
   13.  Security Considerations  . . . . . . . . . . . . . . . . . .  16
   14.  Changes  . . . . . . . . . . . . . . . . . . . . . . . . . .  17
   15.  References . . . . . . . . . . . . . . . . . . . . . . . . .  17
     15.1   Normative References . . . . . . . . . . . . . . . . . .  17
     15.2   Informative References . . . . . . . . . . . . . . . . .  18
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  19
        Intellectual Property and Copyright Statements . . . . . . .  20







Ono & Schulzrinne        Expires April 25, 2006                 [Page 2]

Internet-Draft            Trust Path Discovery              October 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 April 25, 2006                 [Page 3]

Internet-Draft            Trust Path Discovery              October 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 [10].  Sender-based filtering performs based on
      user's name or URI or server's.  For example of server-based
      filtering, Certified Server Validation [11] uses DNS to provide
      indications what kind of assertions a domain offers for its users.
      Third-party accreditation services [12] 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 [13] uses DNS to provide the proper IP addressees of an
      SMTP sender.  DomainKeys [14] 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 [2], SIP identity [15]
      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 April 25, 2006                 [Page 4]

Internet-Draft            Trust Path Discovery              October 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., a
   mail transfer agent, 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".

   Our approach requires that the identities of the friends are
   authenticated using some of the anti-spoofing mechanisms shown in
   Section 2.

4.  What Indicates a Trust Relationship?

4.1  Trust Indicators

   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 [16] with 'active' status,
         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 for emails, calls or
         messages.

   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.
      *  Alice has trust relationship to many users belonging to the
         same domain which maintains strict rules for minting
         identifiers for its users.
         [Note: The domain which mints the users' identifiers for



Ono & Schulzrinne        Expires April 25, 2006                 [Page 5]

Internet-Draft            Trust Path Discovery              October 2005


         anybody does not deserve to be trusted, even if a large number
         of users at the same domain entry at Alice's whitelist.]

   o  Trust relationship between domains. e.g., "A.com" trusts "B.com".
      *  History of transactions.
      *  Contracts or agreements.

4.2  Usage of Trust Indicators

   The trust indicators are used to generate "trust paths" that contains
   the entries whom the generator trusts.  The entries are used in two
   phases: on exchanging their own trust indicators with others via a
   network, as the destination list, and on judging whether to accept
   the message from a stranger at local.

   In the exchange phase, users and domains limit the entries to peers
   with having closer relationship than those in the judging phase,
   because the exchange has potentially more risk (i.e., requiring more
   efforts or a breach of privacy).  For users, the trust paths
   generated from their watcher list generally show closer relationship
   than those from their mail log, because disclosing their presence
   requires the closer relationship than sending only emails.

   In the judging phase, we need to consider the type of an identifier
   in a trust path, especially for users.  The type of an identifier is
   either SIP-URI, tel-URI, presence URI, or email address, depending on
   the trust indicators to generate the trust paths.  The appropriate
   type is determined by the type of application which needs the
   judgement.  For example, an email address in a trust path is useful
   to judge whether to accept an email from a stranger, but not for a
   SIP voice call.  Therefore, a single user can have multiple chains of
   trust relationship that unify the type of identifiers, and can apply
   each chain for an application separately.

5.  Requirements

5.1  Generic Requirements

   Below are some of generic requirements for mechanisms to discover
   trust paths.

   REQ-GEN-1: The solution SHOULD be simple and scalable because the
              number of users and connections of their friends are huge.








Ono & Schulzrinne        Expires April 25, 2006                 [Page 6]

Internet-Draft            Trust Path Discovery              October 2005


   REQ-GEN-2: It SHOULD enable entities to obtain the trust path prior
              to being needed, for quick determination at starting a
              session.

   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 the destination list based
   on its trust indicators, and recursively exchanges them with the
   others in the destination list.  Although there are two ways of the
   exchange, push-base model and pull-base (query-model) model, we
   prefer push-base model where entities propagate trust paths
   immediately after generating or aggregating trust paths for the
   following reasons.

6.1  Push-base Model vs. Query-base Model

   Push-base model enables entities to quickly determine the
   trustworthiness of the stranger, since they discovered the trust
   paths in advance.  Additionally, this model enables them to free from
   guessing the appropriate query based on the name of stranger.  This
   model, however, may have some disadvantages of the efficiency in the
   procedure and privacy, since entities propagate trust paths
   independently of the stranger's name to be judged.



Ono & Schulzrinne        Expires April 25, 2006                 [Page 7]

Internet-Draft            Trust Path Discovery              October 2005


   In query-base model, if the name of the stranger contains a good hint
   for the query, entities can efficiently query the trustworthiness to
   limited users or domains.  If not, they need to ask all users or
   domains whom they trust and then the trustees need to ask their
   trustees.  This query procedure needs to be recursive in certain
   cycles.  It would not so efficient.

   We estimate that the possibility containing some hints at the name of
   the stranger is very low, because the user part of the name contains
   few hint, although the domain part of the name often contains some
   hints.  Therefore, query-base model has no advantage of efficiency in
   the query procedure, comparing to the propagation procedure in push-
   base model.

   Trust paths are potentially privacy-sensitive, especially when they
   contain trust relationships between users.  In push-base model,
   entities need to exclude privacy-sensitive information from their
   trust paths to be propagated.  In query-base model, entities need to
   respond to queries on the basis of their trust paths as basis.  The
   queries and responses are also potentially privacy-sensitive, if they
   are related to their privacy-sensitive relationship.  Therefore,
   entities need to exclude privacy-sensitive information from their
   trust paths to be used as the basis for the responses.  In the both
   model, trust paths can only contain public information.

7.  Generating Trust Paths and Destination List

   Both of trust paths and destination list are generated from an
   entity's trust indicators described in Section 4.1.

   A user SHOULD generate a single pair of trust paths and the
   destination list for its own URI.  A user MAY generate multiple pairs
   of trust paths and destination list separately for some categories,
   such as private and business, considering with a privacy issue.

7.1  Trust Paths

   Trust paths MUST consist of the following information.  The message
   format is shown in Section 11.

   o  Owner of trust paths: The owner's URI.  This is used as the
      identifier of a user or a domain for the authentication and
      authorization in the exchange/propagation phase.
   o  Pairs of entities' identifiers: Originator's URI and the list of
      neighbors' URIs.  A user URI pairs with the list of domains' URIs
      or the list of users' URIs that have the same type of URI.  A
      domain URI pairs with the list of domains' URIs.




Ono & Schulzrinne        Expires April 25, 2006                 [Page 8]

Internet-Draft            Trust Path Discovery              October 2005


   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.

   o  Time stamp: The time in GMT when the trust path is generated.

   In addition, the trust path MAY contain the expiry time and the
   weight on the trustworthiness of individuals or domains.

      Expiry time: the time duration for validity.  For example, when
      trust paths are extracted from watcher list that contains the
      subscription duration, entities MAY set the expiry time of the
      trust paths based on the duration.
      Weight on the trustworthiness: Trustworthiness of individuals or
      domains.  [Note: Recipients of trust paths may weigh them
      differently depending on who has forwarded them.  However, we
      decided against including weights as a mandatory data in the trust
      paths, since this appears difficult to make commensurate among
      participants.]

7.2  Destination List

   The destination list is a subset of neighbor's URIs in the trust
   paths.  As described in Section 4.2, users exchange only with limited
   entries extracted from the watcher list.  Therefore, the destination
   list for users contains only SIP-URIs.  On the other hand, the
   destination list for domains contains domain names.

   Users and domains have to translate from the destination list to the
   network addresses for the exchange.  Users' SIP-URIs are Address-of-
   Records (AoRs), from which a location service translates to contact
   addresses that contains FQDNs or IP addresses.  However, only SIP
   proxy/redirect servers can invoke the location service.  Therefore, a
   user needs another service such as a presence service in order to
   obtain the network addresses corresponding to the friends' AoRs.
   Since how to obtain the addresses depends on the network model for
   propagation, we describe the detail in the later discussion on the



Ono & Schulzrinne        Expires April 25, 2006                 [Page 9]

Internet-Draft            Trust Path Discovery              October 2005


   network model in Section 8.2.

8.  Propagating Trust Paths

8.1  Overview

   Propagating trust paths is somewhat similar to propagating path
   vectors in routing protocol such as BGP [17].

   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

   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}




Ono & Schulzrinne        Expires April 25, 2006                [Page 10]

Internet-Draft            Trust Path Discovery              October 2005


   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}

8.2  Network Model

   Trust paths can be processed and propagated in a peering model or
   client-server model, both of which we described below.

8.2.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.
      *  Note: It require all user entities to use presence service in
         order to obtain the contact addresses of peers on the
         destination list.  Domain entities can obtain the contact
         addresses of peers by DNS.

   Disadvantages:
   o  Difficulties in peer authentication for users:
      Each entity needs to authenticate each other when propagating its
      trust paths.  This requires pre-shared key or self-signed
      certificate of all user entities that propagate their trust paths.
      For domain server entities, this is not a disadvantage since they
      have their public key certificates that can be used for
      authentication.
      *  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 [3], 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[18].  As a
         result, it requires servers for this purpose.





Ono & Schulzrinne        Expires April 25, 2006                [Page 11]

Internet-Draft            Trust Path Discovery              October 2005


8.2.2  Client-server Model

   In a client-server model, users connect to opinion servers as shown
   in Figure 2, which in turn peer with each other.  Since a single
   server is more likely to accommodate many users, the number of user
   entities that need to connect with each other is smaller.

   As for domain server entities, they might connect to "root" or
   "super" opinion servers beyond their own domains, only if the domains
   form some alliance.  They usually have their own opinion servers.

   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 public key certificate.  Each
      opinion server also authenticates each other directly or via SIP
      proxy severs 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 put 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.
   o  Note: In order to obtain the name of his friend's opinion server,
      it requires that the presence service provides it as an extension
      element.




Ono & Schulzrinne        Expires April 25, 2006                [Page 12]

Internet-Draft            Trust Path Discovery              October 2005


   To sum up, the client-server model has some advantages for users,
   while  these two models are almost the same for domain servers where
   they have their own opinion servers.  It is RECOMMENDED for entities
   to use opinion servers that store their trust paths and propagate
   them on behalf of users and domains.

8.3  Propagation of Users' Trust Paths via Opinion Servers

   Propagation via opinion servers benefits user entities by being free
   from the presence status of peer (i.e., online or offline).  A user
   can access to his friends' trust paths at their opinion servers at
   anytime when the servers run.  Although their trust paths themselves
   are not as frequently changed as their presence status, they often
   add some trust paths by exchanging them with their friends.
   Therefore, they need to access their friends' opinion sever to check
   if the trust paths are updated or not.  There are two ways to know
   the update: one is a periodical access and another is the
   subscription mechanism [4].  We apply the subscription mechanism to
   the propagation, since this can provide rapid update notification.
   We also apply the publication mechanism [5] between users and their
   opinion servers.  The specification is described in Section 10.

8.4  Propagation of Domains' Trust Paths

   The propagation way of users' trust path is also applicable to that
   of domain servers.  They have their own trust paths and propagate
   them each other.  The difference to the users' way is that domain
   servers usually have their own opinion servers inside their domains.
   Therefore, domain servers MAY use other way than the publication
   mechanism for inner-domain communication, while they MUST use the
   subscription mechanism for inter-domains communication.

9.  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
   MAY 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 prioritize the negative opinion,
   un-trustworthy.

10.  Opinion Event Package

10.1  Publication and Subscription

   When a user generates or aggregates new trust paths, he MUST send his



Ono & Schulzrinne        Expires April 25, 2006                [Page 13]

Internet-Draft            Trust Path Discovery              October 2005


   own trust paths to his opinion server in the PUBLISH request.  When a
   user needs to know his friends' trust paths, he MUST subscribe each
   of his friends' opinion servers to know their trust paths by sending
   the SUBSCRIBE requests.  The opinion servers that accept the
   subscriptions, MUST send the NOTIFY requests containing updated trust
   paths to the subscribers.

   For scalability, a user and an opinion server SHOULD support both of
   the partial publication mechanism and partial notification mechanism,
   such as [6] [7].

10.1.1  Package Definition

   The name of this event package is "opinion".  The Content-Type is
   'application/tpdf+xml' for the publication and notification of trust
   paths, and 'application/tpdf-diff+xml for the partial publish and
   notification.

10.2  Destination List

   For the authorization of accessing user's trust paths at an opinion
   server, a user MUST set the destination list as the authorization
   list for his trust paths.  Since the destination list is only updated
   by the user, the watcher list mechanism for this is not needed.

11.  Message Formats of Trust Paths

   The message format of trust paths uses the XML [8] data format.  The
   data size of the trust paths depends on the number of its friends and
   the length of the chain.

11.1  Examples of Trust Paths

   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.
















Ono & Schulzrinne        Expires April 25, 2006                [Page 14]

Internet-Draft            Trust Path Discovery              October 2005


   <?xml version="1.0" encoding="UTF-8"?>
   <trust-path xmlns="urn:ietf:params:xml:ns:tpdf"
       entity="sip:alice@A.com">
     <path>
      <tuple id="sf02sf">
      <origin>sip:alice@A.com</origin>
      <neighbor>sip:bob@B.com, sip:dave@D.com</neighbor>
      <trustworthy>yes</trustworthy>
      <export-allowed>yes</export-allowed>
      <timestamp>2005-07-04T20:57:29Z</timestamp>
      </tuple>
     </path>
   </trust-path>


          Figure 3: An example of one hop trust path of SIP-URIs



   <?xml version="1.0" encoding="UTF-8"?>
    <trust-path xmlns="urn:ietf:params:xml:ns:tpdf"
       entity="sip:alice@A.com">
     <path>
      <tuple id="sf02sf">
       <origin>alice@mail.A.com</origin>
       <neighbor>bob@mail.B.com, dave@mail.D.com</neighbor>
       <trustworthy>yes</trustworthy>
       <export-allowed>yes</export-allowed>
       <timestamp>2005-07-04T20:57:29Z</timestamp>
      </tuple>
     </path>
    </trust-path>


       Figure 4: An example of one hop trust path of email addresses
















Ono & Schulzrinne        Expires April 25, 2006                [Page 15]

Internet-Draft            Trust Path Discovery              October 2005


   <?xml version="1.0" encoding="UTF-8"?>
    <trust-path xmlns="urn:ietf:params:xml:ns:tpdf"
       entity="sip:bob@B.com">
     <path>
      <tuple id="is02sf">
       <origin>sip:bob@B.com</origin>
       <neighbor>sip:alice@A.com</neighbor>
       <trustworthy>yes</trustworthy>
       <export-allowed>yes</export-allowed>
       <timestamp>2005-07-05T20:57:29Z</timestamp>
      </tuple>
      <tuple id="sf02sf">
       <origin>sip:alice@A.com</origin>
       <neighbor>sip:bob@B.com, sip:dave@D.com</neighbor>
       <trustworthy>yes</trustworthy>
       <export-allowed>yes</export-allowed>
       <timestamp>2005-07-04T20:57:29Z</timestamp>
      </tuple>
     </path>
   </trust-path>


         Figure 5: An example of two hops trust paths of SIP-URIs


12.  IANA Considerations

   This document proposes a new event package, "opinion", and new
   Content-Types, "application/tpdf+xml" and "application/
   tpdf.diff+xml".

13.  Security Considerations

   In the generation phase, some entities generate a wrong trust path
   that includes a hostile entity as a trustworthy one.  Additionally,
   in the aggregation phase, some entities improperly add or modify
   trust paths propagated from other entities.  Therefore, the
   traceability of the trust paths SHOULD be supported.  Entities SHOULD
   attach the signature, before the propagation, using XML-signature [9]
   to the path element of the trust path data generated from their own
   trust indicators.  Since the aggregation of the trust paths makes the
   signature invalid, entities SHOULD log the trust paths that contains
   generator's signature before the aggregation.  Entities SHOULD check
   if the signature exists and is valid, when the trust path is
   propagated by the originator of the trust paths.

   In the propagation phase, we have to consider impersonating a user or
   domain entity, as well as an opinion server, by a malicious user or



Ono & Schulzrinne        Expires April 25, 2006                [Page 16]

Internet-Draft            Trust Path Discovery              October 2005


   server.  Additionally, we have to consider tampering trust paths by a
   malicious one.  To protect against these attacks, user entities and
   opinion servers MUST authenticate mutually, and the data integrity of
   transmitted trust paths MUST be protected.  Since they use the
   publication and subscription mechanisms for the propagation of the
   trust paths, authentication and data integrity protection follow
   those of the mechanisms.  A user and domain entities, and an opinion
   server MUST support TLS.  A user and domain entities MUST
   authenticate an opinion server with the public key certificate during
   the TLS handshake protocol.  If there is no direct TLS connection,
   transitive trust MUST be applied.  An opinion server MUST
   authenticate a user who belongs to the server by HTTP Digest
   Authentication, whereas using by the SIP identity mechanism for a
   user who does not belong to.

14.  Changes

   Changes from -00.txt
   o  Added the usage of trust indicators.
   o  Added the comparison between push-base model and query-base mode.
   o  Added text for the destination list.
   o  Applied the publication and subscription mechanism to propagate
      users' trust paths.
   o  Clarified the difference between the operations of users' trust
      paths and domains'.
   o  Simplified the data format for trust paths.
   o  Added text in the Security Consideration.

15.  References

15.1  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, March 1997.

   [2]  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.

   [3]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
        RFC 2246, January 1999.

   [4]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
        Notification", RFC 3265, June 2002.

   [5]  Niemi, A., "Session Initiation Protocol (SIP) Extension for
        Event State Publication", RFC 3903, October 2004.




Ono & Schulzrinne        Expires April 25, 2006                [Page 17]

Internet-Draft            Trust Path Discovery              October 2005


   [6]  Lonnfors, M., "Publication of Partial Presence Information",
        draft-ietf-simple-partial-publish-03 (work in progress),
        July 2005.

   [7]  Lonnfors, M., "Session Initiation Protocol (SIP) extension for
        Partial Notification of  Presence Information",
        draft-ietf-simple-partial-notify-06 (work in progress),
        October 2005.

   [8]  Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.

   [9]  Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
        Language) XML-Signature Syntax and Processing", RFC 3275,
        March 2002.

15.2  Informative References

   [10]  Rosenberg, J., "The Session Initiation Protocol (SIP) and
         Spam", draft-ietf-sipping-spam-00 (work in progress),
         February 2005.

   [11]  Crocker, D., "Certified Server Validation (CSV)",
         draft-ietf-marid-csv-intro-02 (work in progress),
         February 2005.

   [12]  Leslie, J., "Domain Name Accreditation (DNA)",
         draft-ietf-marid-csv-dna-02 (work in progress), February 2005.

   [13]  Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail",
         draft-lyon-senderid-code-01 (work in progress), May 2005.

   [14]  Delany, M., "Domain-based Email Authentication Using Public-
         Keys Advertised in the DNS (DomainKeys)",
         draft-delany-domainkeys-base-02 (work in progress), March 2005.

   [15]  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.

   [16]  Rosenberg, J., "A Watcher Information Event Template-Package
         for the Session Initiation Protocol (SIP)", RFC 3857,
         August 2004.

   [17]  Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
         RFC 1771, March 1995.

   [18]  Jennings, C. and J. Peterson, "Certificate Management Service
         for The Session Initiation Protocol (SIP)",



Ono & Schulzrinne        Expires April 25, 2006                [Page 18]

Internet-Draft            Trust Path Discovery              October 2005


         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 April 25, 2006                [Page 19]

Internet-Draft            Trust Path Discovery              October 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 April 25, 2006                [Page 20]