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
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 of SIP-URIs
alice@mail.A.com
bob@mail.B.com, dave@mail.D.com
yes
yes
2005-07-04T20:57:29Z
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
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
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]