Internet DRAFT - draft-ono-trust-path-discovery
draft-ono-trust-path-discovery
Network Working Group K. Ono
Internet-Draft H. Schulzrinne
Expires: December 28, 2006 Columbia University
June 26, 2006
Trust Path Discovery
draft-ono-trust-path-discovery-02
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 December 28, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
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 our 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 establishing relatively low-value
trust suitable for deciding whether to accept communication requests
Ono & Schulzrinne Expires December 28, 2006 [Page 1]
Internet-Draft Trust Path Discovery June 2006
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. Trust Indicators . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. What are Trust Indicators? . . . . . . . . . . . . . . . . 5
4.2. How to Utilize Trust Indicators . . . . . . . . . . . . . 6
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Generic Requirements . . . . . . . . . . . . . . . . . . . 7
5.2. Security Requirements . . . . . . . . . . . . . . . . . . 7
6. Operations on Trust Paths . . . . . . . . . . . . . . . . . . 7
6.1. Push-based Model vs. Query-based Model . . . . . . . . . . 8
6.2. Generating Trust Paths and Exchange Peer List . . . . . . 9
6.3. Propagating Trust Paths . . . . . . . . . . . . . . . . . 11
6.4. Aggregating Trust Paths . . . . . . . . . . . . . . . . . 13
6.5. Querying Trust Paths at Reference URI . . . . . . . . . . 14
7. Opinion Event Package . . . . . . . . . . . . . . . . . . . . 14
7.1. Publication and Subscription . . . . . . . . . . . . . . . 14
7.2. Exchange Peer List . . . . . . . . . . . . . . . . . . . . 14
8. Message Formats of Trust Paths . . . . . . . . . . . . . . . . 15
8.1. Examples of Trust Paths . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Changes from -01.txt . . . . . . . . . . . . . . . . . . . 16
11.2. Changes from -00.txt . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Ono & Schulzrinne Expires December 28, 2006 [Page 2]
Internet-Draft Trust Path Discovery June 2006
1. Introduction
When dealing with strangers in electronic interactions, establishing
trust for authorization is the core challenge as mere authentication
does not yield more than a name or URI. Trust depends on the type of
interaction, such as e-commerce and answering the phone. The level
of trust required depends on the potential impact and risk of the
interaction. We focus here on relatively low-risk interactions where
more potential parties are trustworthy, such as emails, calls or
instant messages.
There are several methods to determine the trustworthiness of a
stranger in networks. One method is to ask a 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 opinions of the stranger. We generally trust our own friends
more than the unknown third party.
However, we assume that the number of people in the circle of our
friends is relatively small, given the number of members at a popular
reputation system, 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 communication
requests 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
Ono & Schulzrinne Expires December 28, 2006 [Page 3]
Internet-Draft Trust Path Discovery June 2006
establish trust to each individual.
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. The
trust paths are based on a chain of trust relationships between
users, a user and a domain, and domains, in terms of accepting
communication requests, such as a call. This document defines trust
indicators to generate trust paths and a set of requirements for a
mechanism to obtain binary trustworthiness by making use of the trust
paths. Additionally, this document proposes a mechanism that
combines a push-based and a query-based model for exchanging the
trust paths among entities. 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 recipients
against undesirable communication:
o Anti-spam mechanisms:
Many existing anti-spam mechanisms rely on filtering messages at
the receiver, either based on content or sender. Content-based
filtering, however, has limited applicability to calls and instant
messages [10].
Sender-based filtering performs based on user's name or URI, or
server's. A simple example of user-based filtering is to use a
whitelist or blacklist stored at user terminals, and relay nodes
when they filter messages on behalf of users. For an example of
server-based filtering, Certified Server Validation [11] uses DNS
to provide indications what kind of assertions a domain offers to
its users. Third-party accreditation services [12] can attest
that an SMTP sender follows certain policies or is otherwise
trustworthy.
o Anti-spoofing mechanisms:
Anti-spoofing mechanisms authenticate originators of messages and
calls, and nodes that relay such messages and calls. For example,
Sender ID [13] uses DNS to provide the proper IP addresses of an
SMTP sender. DomainKeys [14] uses a secure hash of the content
Ono & Schulzrinne Expires December 28, 2006 [Page 4]
Internet-Draft Trust Path Discovery June 2006
that a recipient can verify using the domain's public key that is
obtainable by DNS.
For calls or instant messages in SIP [2], SIP identity [15]
provides a mechanism for authenticating 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
SIP headers and the message body on behalf of the originator. The
recipient can verify the secure hash using the public key of the
originator's domain. As a result, the destination user
authenticates 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 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 chains of trust relationships that exist
between individuals, an individual and a domain, and domains. If a
friend of ours tells us that the stranger is his or her 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. Trust Indicators
We provide what indicates trust relationships. We also provide how
we can utilize trust indicators to find trust paths.
4.1. What are Trust Indicators?
Below, we provide examples of how such trust relationships might be
established, between users, a user and a domain, and domains. We can
handle these activity records as trust indicators.
Ono & Schulzrinne Expires December 28, 2006 [Page 5]
Internet-Draft Trust Path Discovery June 2006
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 relationships 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
anybody does not deserve to be trusted, even if a large number
of users at the same domain are listed at Alice's whitelist.]
o Trust relationship between domains. e.g., "A.com" trusts "B.com".
* A relay server of A.com has accepted many emails, calls, or
messages from a relay server of B.com.
* A.com has contracted to relay traffic from B.com.
4.2. How to Utilize Trust Indicators
First, trust indicators are utilized to generate "trust paths" that
contain the identifiers that the generator trusts, then these trust
paths are exchanged among the trusted identifiers.
We need to consider the types of identifiers in trust paths,
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 sender-based
filtering. 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 a trust path that
unify the type of identifiers for each application.
When exchanging trust paths, users and domains limit the identifiers
to those peers having closer relationships than those for filtering,
because the exchange has potentially more risk (i.e., requiring more
efforts or a breach of privacy). For example, trust paths generated
from a user's watcher list generally show closer relationships than
those from his or her mail log, because disclosing his or her
Ono & Schulzrinne Expires December 28, 2006 [Page 6]
Internet-Draft Trust Path Discovery June 2006
presence requires a closer relationship than sending only emails.
5. Requirements
5.1. Generic Requirements
Below are some of generic requirements for mechanisms to discover
trust paths.
REQ-GEN-1: The solution MUST be simple and scalable enough to handle
the circle of friends in a few hops.
REQ-GEN-2: It SHOULD require a recipient less of the costs to obtain
trust paths than the originator.
REQ-GEN-3: It SHOULD enable entities to obtain the trust path prior
to being needed or quickly enough for determining whether
they accept a voice call.
REQ-GEN-4: 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 trust paths
from one or more trusted and authenticated entities.
REQ-SEC-2: It MUST enable entities to obtain trust paths from one or
more trusted entities without revealing its content to
unauthorized third parties.
REQ-SEC-3: It MUST enable entities to detect forgery of a trust path.
REQ-SEC-4: It SHOULD enable entities to select parts of the trust
path to be revealed.
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 peers
based on its trust indicators in advance or on demand. We call a
model push-based where each entity propagates its own trust paths to
Ono & Schulzrinne Expires December 28, 2006 [Page 7]
Internet-Draft Trust Path Discovery June 2006
its community in advance of receiving a communication attempt message
from a stranger. On the other hand, we call a model query-based
where an entity sends queries following its trust paths about the
stranger. We discuss two exchange models, the push-based and the
query-based to meet the above requirements, and explain operations
required for the exchange.
6.1. Push-based Model vs. Query-based Model
The push-based model enables entities to quickly determine the
trustworthiness of a stranger, since they exchange their trust paths
beforehand. Additionally, this model enables them to free from
guessing the appropriate query based on the name of the 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.
In the query-based model, if the name of the stranger contains a good
hint for the query, entities can query efficiently limited users and
domains about the trustworthiness. If not, they need to ask all
users or domains whom they trust, then the trustees need to ask their
trustees. This query procedure needs to be recursive in certain
cycles. It would be not so efficient. We estimate that the
possibility that the name of stranger contains some hints is very
low, because the user part of the name contains few hints, though the
domain part of the name often contains some hints. Therefore, the
query-based model has no advantage of efficiency in the query
procedure, compared to the propagation procedure in the push-based
model, and does not meet the REQ-GEN-2 and REQ-GEN-3 requirements.
Trust paths are potentially privacy-sensitive, especially when they
contain trust relationships between users. In the push-based model,
entities need to exclude privacy-sensitive information from their
trust paths propagating. In the query-based model, entities need to
give binary responses to queries on the basis of their trust paths.
Such queries and responses are less privacy-sensitive than the
exchange of trust paths, but they are still potentially privacy-
sensitive if they are related to their private relationships.
Therefore, entities need to exclude privacy-sensitive information
from their trust paths to be used as the basis for the responses. In
the both models, trust paths can contain public information only.
To moderate the disadvantages of both models, we take an approach
combined two models, a via-reference model where entities find trust
paths via references. It enables entities to search trust paths
bidirectionally. If a stranger shows the recipient an URI containing
a referrer's opinion about him or her, the URI may reduce the number
of chains to reach the stranger, since the URI are a possible
Ono & Schulzrinne Expires December 28, 2006 [Page 8]
Internet-Draft Trust Path Discovery June 2006
intersection for the trust paths between the stranger and the
recipient. We call the URI a "reference URI".
In Figure 1, Dave wants to call to Alice who does not know him
directly. Before his calling, Dave obtains some URIs to show his
references from the circle of his friends, e.g., Bob and Carol, for
Alice in order to check his trustworthiness via them. Dave selects
some URIs of referrers, e.g., Bob, who are potentially in the circle
of Alice's friends. When Dave makes calls to Alice, he provides
Bob's reference URI within a call attempt message, e.g., an INVITE
method in SIP.
When Alice receives the call attempt message with the reference URIs,
she queries the reference URI about Dave's trustworthiness, if if Bob
allows her to query the URI. If not, Alice asks her friends to
access the URI. If Dave belongs to the circle of Bob's friends at
Bob's reference URI, Alice will accept the call from Dave. If not,
Alice might reject his call. In this way, this approach requires
neither finding a complete trust path between Alice and Dave
beforehand nor querying the complete trust path after receiving the
call attempt. This enables the recipient to reduce the query cost of
the trust path so that this satisfies REQ-GEN-2 and REQ-GEN-3.
Alice (A) Bob (B) Carol (C) Dave (D)
| | | |
| |<-----|<-----| 1. Push D's
| | | | trust path
| |----->|----->| 2. Be pushed B's
| | | | trust path
| | | |
|<-----|------|------| 3. Call to A
| | | | w/B's reference
4. Query B about D |----->| | |
5. Get the response |<-----| | |
| | | |
6. Judge using the response | | | |
| | | |
Figure 1: Overview of Via-reference Exchange Model
In the via-reference model, an originator need to exchange his or her
trust paths with fewer hops than in the push-based model. Yet, trust
paths can contain public information only.
6.2. Generating Trust Paths and Exchange Peer List
All trust paths and the exchange peer list are generated from trust
indicators described in Section 4.1.
Ono & Schulzrinne Expires December 28, 2006 [Page 9]
Internet-Draft Trust Path Discovery June 2006
A user SHOULD generate one or more trust paths containing who trusts
whom and the exchange peer list. A user MAY generate multiple list
of exchange peer separately considering with a privacy issue, such as
private and business.
6.2.1. Trust Paths
Trust paths MUST consist of tuples containing the following
information.
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 Reference URI: The reference URI that shows the referrer's trust
paths or just provides the query function for somebody's
trustworthiness based on the referrer's opinion.
o Pairs of identifiers: Originator URI and the list of neighbor
URIs. A user URI pairs with the list of domain URIs or the list
of user URIs that have the same type of URI. A domain URI pairs
with the list of domain URIs.
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: Policy 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 path has traversed and then having recipients make
decisions on whether to further propagate trust paths that have
traveled far.
o Time stamp: The time in GMT when the trust path was generated.
In addition, a trust path MAY contain the expiry time and the weight
of 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 subscription duration.
Ono & Schulzrinne Expires December 28, 2006 [Page 10]
Internet-Draft Trust Path Discovery June 2006
Weight of 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 mandatory data in the trust paths, since this
appears difficult to make commensurate among participants.]
6.2.2. Exchange Peer List
The list is a subset of neighbor URIs in the trust paths of an
entity. The list limits the entities that the trust paths can be
propagated to or be accessed by.
As described in Section 4.2, users exchange their trust paths only
with a limited set of entries extracted from the users' watcher list.
Therefore, the user identifiers in the exchange peer list contains
only SIP-URIs, while the exchange peer list for domains contains
domain URIs.
Users and domains have to translate from the exchange peer 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.
6.3. Propagating Trust Paths
6.3.1. Overview
Propagating trust paths is somewhat similar to propagating path
vectors in routing protocol such as BGP [17].
Figure 2 depicts an example of trust relationships among five people.
We assume mutual trust relationships between Alice and Bob, Bob and
Carol, Carol and Ed, Ed and Dave, and Dave and Alice.
Ono & Schulzrinne Expires December 28, 2006 [Page 11]
Internet-Draft Trust Path Discovery June 2006
Dave (D) <---------------------> Ed (E)
^ ^
| |
| |
v v
Alice (A) <---> Bob (B) <---> Carol (C)
A <-> B: A and B trusts each other mutually.
Figure 2: 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 those trust paths except ones that already
include 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 directly knows neither 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}, unless they contain different opinions.
C: {C,B},{C,E},{C,B,A},{C,E,D}
6.3.2. Network Model
Trust paths can be processed and propagated in a peering model or
client-server model. Entities SHOULD use a client-server model where
an opinion server stores their trust paths of users and propagate
them on behalf of users and domains since the server make user
Ono & Schulzrinne Expires December 28, 2006 [Page 12]
Internet-Draft Trust Path Discovery June 2006
authentication easier. Additionally, the via-reference model
requires higher service availability of trust paths at reference
URIs.
o Easier user authentication:
Entities do not need to authenticate each other when propagating
their trust paths. Entities can apply transitive trust to mutual
user authentication. Each user authenticates the opinion server
that he or she belongs to, and vice versa. The opinion server
authenticates the user by using Digest authentication with his or
her credential such as a password, and the user authenticates the
opinion server by using TLS with its public key certificate.
Opinion servers also authenticate each other directly or via SIP
proxy servers by using TLS with their certificates.
o Higher service availability:
Trust paths at reference URIs remain available even if a user's
end system is temporarily unreachable.
6.3.3. Propagation of Users' Trust Paths via Opinion Servers
Propagation via opinion servers benefits user entities by being free
from the presence status of a peer (i.e., on-line or off-line). A
user has access to his friends' trust paths at their opinion servers
at any time 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 server to check
if the trust paths were recently updated. There are two ways to
recognize the update: one is a periodical access and another is the
subscription mechanism [3]. We apply the subscription mechanism to
the propagation, since this can provide rapid update notification.
We also apply the publication mechanism [4] between users and their
opinion servers. The specification is described in Section 7.
6.3.4. Propagation of Domains' Trust Paths
The propagation method of users' trust path is also applicable to
domain servers. They maintain 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 ways than the publication
mechanism for intra-domain communication, while they MUST use the
subscription mechanism for inter-domains communication.
6.4. Aggregating Trust Paths
As Carol selects a shorter path in the example of Figure 2, an entity
needs to aggregate receiving trust paths with its own trust paths.
An entity SHOULD select the shortest path to the same entity, unless
Ono & Schulzrinne Expires December 28, 2006 [Page 13]
Internet-Draft Trust Path Discovery June 2006
the trust paths contain different opinions. 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
untrustworthy, it is safer to prioritize the negative opinion,
untrustworthy.
6.5. Querying Trust Paths at Reference URI
When an entity receives a communication attempt from a stranger
attached with a reference URI, it MAY access the reference URI to
obtain the trustworthiness of the stranger, i.e., in a SIP call, a
SIP UA MAY receive a INVITE method with the reference URI at one of
the parameters of SIP identity. If the referrer is a friend of the
recipient, the recipient can directly access the reference URI. If
not, the recipient queries its friends about the referrer and access
the reference URI to obtain the trustworthiness of the stranger. The
entities to be queried SHOULD NOT expand the query to their friends,
since the query time is limited and longer trust paths are useless to
determine the trustworthiness of the stranger.
7. Opinion Event Package
7.1. Publication and Subscription
When a user generates or aggregates new trust paths, he MUST send his
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 [5] [6].
7.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.
7.2. Exchange Peer List
For the authorization of accessing user's trust paths at an opinion
Ono & Schulzrinne Expires December 28, 2006 [Page 14]
Internet-Draft Trust Path Discovery June 2006
server, a user MUST set the exchange peer 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.
8. Message Formats of Trust Paths
The message format of trust paths uses the XML [7] data format. The
data size of the trust paths depends on the number of a user's
friends and the length of the chain.
8.1. Examples of Trust Paths
TBD
9. IANA Considerations
This document proposes a new event package, "opinion", and new
Content-Types, "application/tpdf+xml" and "application/
tpdf.diff+xml".
10. Security Considerations
In the generation phase, some entities generate wrong trust paths
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 [8]
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
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. User and domain entities, and an opinion
server MUST support TLS. User and domain entities MUST authenticate
Ono & Schulzrinne Expires December 28, 2006 [Page 15]
Internet-Draft Trust Path Discovery June 2006
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.
11. Changes
11.1. Changes from -01.txt
o Changed text for the generic requirement of simplicity and
scalability, and the constraint from SHOULD to MUST.
o Added a generic requirement about balancing the costs to find
trust paths between an originator and the recipient.
o Added via-reference model as a combination of push-based and
query-based models.
o Added Reference URI as an attribute of trust path.
o Added the operation of querying trust paths at reference URI
o Changed "destination list" to "exchange peer list"
o Removed examples of trust paths
o Updated references
o Changed an author's address
11.2. Changes from -00.txt
o Added the usage of trust indicators.
o Added the comparison between push-based model and query-based
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.
12. References
12.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.
Ono & Schulzrinne Expires December 28, 2006 [Page 16]
Internet-Draft Trust Path Discovery June 2006
[3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[4] Niemi, A., "Session Initiation Protocol (SIP) Extension for
Event State Publication", RFC 3903, October 2004.
[5] Niemi, A., Lonnfors, M., and E. Leppanen, "Publication of
Partial Presence Information",
draft-ietf-simple-partial-publish-04 (work in progress),
March 2006.
[6] Lonnfors, M., "Session Initiation Protocol (SIP) extension for
Partial Notification of Presence Information",
draft-ietf-simple-partial-notify-07 (work in progress),
June 2006.
[7] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
[8] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275,
March 2002.
[9] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
12.2. Informative References
[10] Rosenberg, J., "The Session Initiation Protocol (SIP) and
Spam", draft-ietf-sipping-spam-02 (work in progress),
February 2006.
[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",
RFC 4406, April 2006.
[14] Delany, M., "Domain-based Email Authentication Using Public-
Keys Advertised in the DNS (DomainKeys)",
draft-delany-domainkeys-base-04 (work in progress), March 2006.
[15] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-06 (work in progress), October 2005.
Ono & Schulzrinne Expires December 28, 2006 [Page 17]
Internet-Draft Trust Path Discovery June 2006
[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., Peterson, J., and J. Fischl, "Certificate
Management Service for The Session Initiation Protocol (SIP)",
draft-ietf-sip-certs-00 (work in progress), May 2006.
Ono & Schulzrinne Expires December 28, 2006 [Page 18]
Internet-Draft Trust Path Discovery June 2006
Authors' Addresses
Kumiko Ono
Columbia University
Department of Computer Science
New York, NY 10027
USA
Email: kumiko@cs.columbia.edu
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
USA
Email: hgs@cs.columbia.edu
Ono & Schulzrinne Expires December 28, 2006 [Page 19]
Internet-Draft Trust Path Discovery June 2006
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 (2006). 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 December 28, 2006 [Page 20]
