Network Working Group F. Strauss
Internet-Draft S. Schmidt
Expires: January 6, 2005 TU Braunschweig
July 8, 2004
P2P CHAT - A Peer-to-Peer Chat Protocol
draft-strauss-p2p-chat-05
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 6, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This memo presents the second version of a protocol for a
peer-to-peer based chat system. Messages can be cryptographically
signed, encrypted and anonymized allowing authentic and closed group
communication as well as anonymous communication. This work is the
output of a practical course on distributed systems at the Technical
University of Braunschweig. It is experimental work that is not
intended to go to the IETF standards track.
Strauss & Schmidt Expires January 6, 2005 [Page 1]
Internet-Draft P2P Chat Protocol July 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Terms of Requirement Levels . . . . . . . . . . . . . . . 4
2. The Architecture . . . . . . . . . . . . . . . . . . . . . . 5
2.1 The Peer-to-Peer Network . . . . . . . . . . . . . . . . . 5
2.2 Routing . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Anonymous Communication . . . . . . . . . . . . . . . . . 6
3. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Protocol Message Format . . . . . . . . . . . . . . . . . 8
3.2 Protocol Message Exchange . . . . . . . . . . . . . . . . 8
3.3 Protocol Messages . . . . . . . . . . . . . . . . . . . . 8
3.3.1 HELLO . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.2 QUIT . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.3 CHANNEL . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.4 JOIN . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.5 LEAVE . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.6 GETPEERS . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.7 PEERS . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.8 GETCERTIFICATE . . . . . . . . . . . . . . . . . . . . 10
3.3.9 CERTIFICATE . . . . . . . . . . . . . . . . . . . . . 10
3.3.10 GETKEY . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.11 KEY . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.12 ROUTING . . . . . . . . . . . . . . . . . . . . . . 11
3.3.13 MESSAGE . . . . . . . . . . . . . . . . . . . . . . 11
3.3.14 OBSCURE . . . . . . . . . . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . 13
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
6. Normative References . . . . . . . . . . . . . . . . . . . . 14
A. XML Schema Definition for Messages . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . 27
Strauss & Schmidt Expires January 6, 2005 [Page 2]
Internet-Draft P2P Chat Protocol July 2004
1. Introduction
Chat systems allow groups of people to exchange text messages in
realtime within so-called channels: While each participant of a
channel can write messages to that channel, he/she can also read all
messages sent by other people to the same channel. Besides text
messages, the user can enter commands to his local chat application
in order to join or leave channels, list existing channels, etc.
Traditional chat systems are based on servers - either a single
server or a static network of servers. Each user has to connect to a
well-known server in order to start chat communication. In contrast
to that server approach, this document presents a peer-to-peer chat
architecture. This means that all nodes in the chat network behave
equally from the protocol point of view. To establish the network of
chat participants the nodes just have to know about a set of
potential peers. Only some of them have to be reachable, so that
those reachable can be integrated into the network of peer-to-peer
chat nodes.
1.1 Terminology
Node, Peer: A node is one active component in the chat network. Note
that there may be multiple nodes located on a common host. Note also
that one node may serve multiple local users. From the perspective
of one node and regarding a given link, the peer is the node at the
remote end of the link.
Link, connection: Two nodes may be connected through a link. Each
link, once established, can be used in both directions.
Message: Data transfered between two nodes on a link is encoded in a
message. Messages are XML documents. See Section 3.
User, User ID: A user is a (typically) human participant in the chat
network. Each user has an ID which is typically equal to his/her
email address, e.g. strauss@ibr.cs.tu-bs.de.
Channel: Communication is organized in channels. Each user (not the
node!) may subscribe to and unsubscribe from a channel in order to
control which text messages received at a node shall be presented to
that user. A channel is identified by a short one-word pattern, e.g.
"smalltalk".
Channel creator: Each user can create a new channel.
Public channel: Traffic on a public channel is not encrypted, thus
each user can join such a channel, read all messages on such a
Strauss & Schmidt Expires January 6, 2005 [Page 3]
Internet-Draft P2P Chat Protocol July 2004
channel and send text messages to such a channel.
Closed channel: Closed channels are associated with a list of channel
members given by their user IDs. This list is initialized by the
channel creator and may be extended by each channel member. (This is
not a security risk, since each member can decode and forward the
traffic, anyway.)
Anonymous channel: An anonymous channel exists that allows the users
to post messages anonymously. Every active user is automatically a
member of this channel.
Channel member: Participant of a closed channel.
Channel key: Messages to closed channels are encrypted using a common
symmetric channel key. The channel creator decides about the key
type and its parameters. The key is distributed through
asymmetrically encrypted key distribution messages to the channel
members.
Certificate: X.509 certificates are used to prove and verify user IDs
and to use their public keys to exchange the symmetric keys of closed
channels and encrypt anonymous messages in the path-obscuring state.
1.2 Terms of Requirement Levels
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].
Strauss & Schmidt Expires January 6, 2005 [Page 4]
Internet-Draft P2P Chat Protocol July 2004
2. The Architecture
2.1 The Peer-to-Peer Network
Zero, one or multiple users may be handled by one node within the
network. In turn, one or multiple nodes may be located on one host.
Upon startup of a node, it tries to connect to a limited number of
peer nodes. The list of peer nodes has to be stored in a persistent
local storage. The default upper limit of actively created peer
connections SHOULD be 4. Each node MUST always be willing to accept
incoming peer connections, even if its limit is reached. In that
case, the peer MIGHT close down a connection (the new one or one of
the formerly established connections) with an appropriate reason, but
it might also serve a larger number of incoming connections
simultaneously. If a connection is closed by a peer or lost due to
network errors, a node MUST NOT try to establish a new connection if
the number of connections is still higher than a specific limit which
SHOULD default to 2. These two threshold values MIGHT be
configurable.
Each connection can be used symmetrically, i.e., messages can be sent
in both directions, no matter which peer initiated the connection.
Connections can be closed down by both sides at any point in time.
The details of peer node and connection management are an
implementation issue.
2.2 Routing
The routing and distribution of messages within the network can be
devided into three cases:
Some messages (HELLO, QUIT, GETPEERS, PEERS, ROUTING) are only sent
from a sending node to a neighbouring peer node without further
forwarding. These messages are sent with ttl="1" and with
flood="false".
Some messages (GETCERTIFICATE, CERTIFICATE, GETKEY, KEY, MESSAGE,
OBSCURE) are multicasted to a set of receivers (maybe one, i.e.,
unicast). In this case the message is sent with an intitial value of
ttl="32" and with flood="false", and it contains an according
"receiver" element for every receiver, i.e. it is a so called
explicit multicast. When a node receives such a message, it can
recognize any local users for whom the message has to be processed,
and it also has to forward the message to any remaining receivers.
To do this, the routing table is used to determine the appropriate
outgoing links and to filter the set of remaining receivers that can
be reached on the shortest paths on those outgoing links. Updates to
Strauss & Schmidt Expires January 6, 2005 [Page 5]
Internet-Draft P2P Chat Protocol July 2004
the routing table are calculated based on the current state of the
table and subsequently received ROUTING messages (Section 3.3.12).
Some messages (CHANNEL, JOIN, LEAVE, MESSAGE in case of anonymous
messages) are flooded to the whole network. In this case the message
is sent with an intitial value of ttl="32" and with flood="true". If
a peer receives a flooded message for the second time, which can be
recognized through the message ID and a ring buffer backlog of
received message IDs, the message MUST be dropped.
2.3 Security
In order to support signed messages, closed channel communication and
anonymous communication, a user must have an RSA keypair, the
keylength being 1024 bit. In order to be able to prove his/her
identity each user must have a X.509 certificate for his/her public
key.
Signing of the messages SHOULD always be done with the exception of
anonymous messages. The mandatory algorithms are MD5 with RSA. The
concatenation of all text sub-nodes of the message starting at the
message type node, but excluding any receiver elements, form the
input to the signing process (see the XML Schema definition in
Appendix A for further details).
All messages of a closed channel MUST be encrypted using symmetric
cryptography. Therefore, the creator of a closed channel generates a
shared secret key which is sent encrypted to all participants (upon
request and optionally in advance) using the respective public key of
each participant. The RSA encryption MUST use the Electronic Code
Book (ECB) mode with the padding scheme PKCS1. The mandatory
symmetric algorithm is standard 64 (56) bit DES in Cipher Block
Chaining (CBC) mode with the padding scheme PKCS5 enabled. Further
symmetric algorithms may be added in the future.
2.4 Anonymous Communication
In order to allow anonymous posting of messages, an anonymous channel
is supported. This channel is omnipresent, i.e., does not need
channel anouncements, does not die etc. Each active user is
automatically a member of it.
Anonymous communication consits of two phases: the path-obscurring
and the posting of the message.
In the beginning, the sender creates a list of at least 3 and up to 5
random active users, which help in obscuring the path and thus the
sender's identity. The MESSAGE message that the sender wants to post
Strauss & Schmidt Expires January 6, 2005 [Page 6]
Internet-Draft P2P Chat Protocol July 2004
MUST be encrypted with the public key of the last user in the list
(RSA in ECB mode with PKCS1 padding). This data forms the content of
the OBSCURE message that is destined at the last user. This OBSCURE
message is then again encrypted with the public key of the last but
one user in the list and forms the content of another OBSCURE
message, which is destined at that user. This scheme MUST be
repeated until the list is empty. The final OBSCURE message, is sent
to the first user in the list.
Upon reception of an OBSCURE message, the user MUST decrypt the
content. If the decrypted message content is another OBSCURE message
it MUST be sent on to the receiver that is already placed in the
message. In case of the decrypted message being the message to be
posted, it MUST be flooded to the network.
In order to prevent message loss during the path-obscuring state, the
original sender SHOULD resend the message if it has not been posted
to the anonymous channel after a timeout. In this case, the sender
SHOULD create a different list of active users and encrypt the
message according to the above defined rules.
Strauss & Schmidt Expires January 6, 2005 [Page 7]
Internet-Draft P2P Chat Protocol July 2004
3. The Protocol
This section describes the peer-to-peer chat protocol version 2.
3.1 Protocol Message Format
Each message represents a well-formed XML [XML] document. Since
multiple messages are transported sequentially on a link, there MUST
be an unambiguous framing that separates messages from each other and
clearly allows to signal the end of a message. This is done by a
decimal ASCII encoded number that signals the length in octets of the
subsequent message. This number is terminated by a CR LF sequence
followed by the message. This means each message block consists of n
digits that represent the message length l, two bytes for the CR LF
sequence, and l bytes that represent the message itself.
An XML Schema definition for messages is given in Appendix A.
3.2 Protocol Message Exchange
Every message is of a specific message type given by the one and only
direct child element of the root element of the message XML document.
All protocol messages are handled asynchronously, i.e., a node MUST
NOT block and wait for a certain reply message when a request message
was sent.
The TTL value of each message MUST be decremented on each hop. Note
that the initial TTL values are mandatory, since they may be used to
derive routing information.
3.3 Protocol Messages
This section describes all protocol message types. The named message
types are equal to the name of the one and only direct child element
of the corresponding "chat-message" root element. Note that message
types are just written all caps in this document for readability.
3.3.1 HELLO
The HELLO message is the first message sent by each peer of a newly
established connection. The receiver of a HELLO message may decide
to close down the connection (after sending a QUIT message) if
something is not ok, e.g. the protocol version of the peer is not
supported. The HELLO message MUST always be sent with ttl="1".
3.3.2 QUIT
A peer may close down a connection at any point in time. To do this
Strauss & Schmidt Expires January 6, 2005 [Page 8]
Internet-Draft P2P Chat Protocol July 2004
in a friendly fashion, it MUST send a QUIT message as the last
message before closing the connection. The QUIT message SHOULD
contain a reason why the connection is closed. The QUIT message MUST
always be sent with ttl="1".
3.3.3 CHANNEL
A CHANNEL message for a specific channel is sent
o once when a local user creates a channel,
o when the node did not receive a CHANNEL message for the channel
for a certain time and as long as a local user is still subscribed
to that channel. This time SHOULD be a random value in the range
between 50 and 60 seconds.
o Furthermore, CHANNEL messages MIGHT be sent once for each known
channel to a newly connected peer node.
This ensures that channels keeps alive and known (including the
subscribers) to all nodes. A CHANNEL message MUST be sent with
ttl="32". The CHANNEL message is always flooded to the whole
network.
The CHANNEL message always contains the list of subscribed channel
members. In case of a closed channel only these users are allowed to
retrieve the session key through a GETKEY/KEY message pair. Users of
a closed channel are allowed to add further members to the list by
sending a new CHANNEL message with the extended list. CHANNEL
messages of closed channels MUST be signed by the sender to prevent
non-members from adding themselves or other users to the list.
There is no way to reduce the list, since it is obviously not
possible to revoke a shared secret. Note that a public channel
cannot later be turned into a closed channel. There is no way to
actively close or remove a channel. A channel is "gone", when there
are no more nodes that send regular CHANNEL messages.
3.3.4 JOIN
A user sends a JOIN message
o once when a local user subscribes to a channel,
o when a local user is already subscribed to a channel for which a
CHANNEL message is received that does not (yet) list that local
user.
The JOIN message is always flooded to the whole network.
3.3.5 LEAVE
A user sends a LEAVE message
o once when a local user unsubscribes from a channel,
Strauss & Schmidt Expires January 6, 2005 [Page 9]
Internet-Draft P2P Chat Protocol July 2004
o when a local user is not subscribed to a channel for which a
CHANNEL message is received that does (still) list that local
user.
The LEAVE message is always flooded to the whole network.
3.3.6 GETPEERS
A node MAY request a list of peers in order to extend its own list of
potential connection peers. This is done through a GETPEERS message
that MUST be sent with ttl="1".
3.3.7 PEERS
A node MAY make another node aware of a list of peer addresses
through a PEERS message. This is usually done in response to a
GETPEERS message and MUST be done with ttl="1".
3.3.8 GETCERTIFICATE
A user MAY request a certificate for a given user ID by sending a
GETCERTIFICATE message. This is usually caused by the wish to verify
the signature of a received message, when the according certificate
is not yet available at the local node. Note that the sender of the
GETCERTIFICATE (and the receiver of the response) is identified by a
user ID although certificates may be used to serve all users at the
local node.
3.3.9 CERTIFICATE
A user can send a certificate encapsulated in a CERTIFICATE message.
This MAY be done in advance (e.g., to all channel members before
sending a signed message to a channel) to avoid subsequent
GETCERTIFICATE/CERTIFICATE message traffic. Furthermore, a
CERTIFICATE message MUST be sent in response to a received
GETCERTIFICATE message for a local user.
3.3.10 GETKEY
A user may request a channel key for a given closed channel by
sending a GETKEY message to the one member that sent and signed the
channel announce. This MUST only be done if a previous CHANNEL
message has been received and the local user's ID is on the members
list of that channel.
If a GETKEY message is received and a KEY response (see below) can be
sent, the GETKEY message MUST be dropped and not forwarded to any
other receivers.
Strauss & Schmidt Expires January 6, 2005 [Page 10]
Internet-Draft P2P Chat Protocol July 2004
3.3.11 KEY
A user MUST send a channel key encapsulated in a KEY message in
response to a GETKEY message sent to the local user. The key MUST be
encrypted for that user. The sender MUST be sure that the receiver
is a member of the closed channel and the public key used for the key
encryption really belongs to the receiver. This is usually done
through a certificate verification process.
3.3.12 ROUTING
A node MUST send a ROUTING message on a regular basis to all its
neighbouring peers. Each entry of the ROUTING message represents a
known user and signals the number of hops it takes to reach that
user, i.e., the receiver of the ROUTING message can subsequently
reach those users via that link with n+1 hops.
The interval to send ROUTING messages SHOULD be 10 seconds.
Alternatively, the node MIGHT send ROUTING messages upon changes to
the local routing table, but it MUST NOT send more than one message
per second on each link.
Note that a node MIGHT also "learn" additional routing information
based on other messages than ROUTING messages through the sender and
TTL values.
3.3.13 MESSAGE
The users' text messages within channels are distributed in MESSAGE
messages. With the exception of anonymous MESSAGE messages, the
initial sender of a MESSAGE message MUST put all members of the
channel into the receivers list. In case of a closed channel,
messages MUST be sent encrypted with the channel key (which probably
must be retrieved through a GETKEY/KEY conversation first).
A node that receives a MESSAGE message MUST forward the message on
each link (except the incoming link) on which it can reach at least
one of the receivers through the shortest path. All receivers for
which the link does not supply the shortest path are removed before
forwarding.
In case of the MESSAGE message being the final message of an
anonyzation chain, its message ID MUST be inserted by the sender of
the message, and the anonymous originator MUST NOT have placed a
message ID in the message. Furthermore, the message MUST be destined
at the channel Anonymous.
Strauss & Schmidt Expires January 6, 2005 [Page 11]
Internet-Draft P2P Chat Protocol July 2004
3.3.14 OBSCURE
An anomymous message in the path-obscurring state. The content MUST
contain another OBSCURE message or a MESSAGE message which MUST be
encrypted with the receivers public key.
A node that receives an OBSCURE message MUST decrypt the content with
its private key and MUST send on the resulting message.
The message ID of an OBSCURE message MUST be inserted by its
immediate sender, i.e., not the initial creator of the OBSCURE
message chain.
Strauss & Schmidt Expires January 6, 2005 [Page 12]
Internet-Draft P2P Chat Protocol July 2004
4. Security Considerations
This document defines an application protocol to carry potentially
private or authentic information. The protocol addresses these needs
through the application of strong cryptographic digest and encryption
algorithms. X.509 certificates are used to verify identities of end
users. This document requires implementations to support a minimal
common set of cryptographic algorithms so that from the
specifications point of view secure communication can be guaranteed.
However, anonymous communication makes assumptions that cannot be
always guaranteed, i.e. an attacker is not able to trace the
complete path an anonymous message takes before being posted to the
anonymous channel.
At the current status the protocol takes no measures to protect
against DoS attacks by peers.
Strauss & Schmidt Expires January 6, 2005 [Page 13]
Internet-Draft P2P Chat Protocol July 2004
5. Acknowledgements
The protocol described in this memo is the output of a practical
course on distributed systems that has been conducted during two
terms at the Technical University of Braunschweig in April - July,
2003 and in the same summer term in 2004. A first step of the work
presented here has been developed by the approx. 48 participating
students of the first course in 2003 during a two-weeks design phase
and a subsequent protocol design colloquium. Then the second course
in 2004 improved routing concepts significantly and added anonymous
communication in a similar design and colloquium way.
The authors of this memo are just the editors who have put the design
decisions together in a common specification document along with some
refinements. Hence, the authors' thanks go to all the ambitious
students of the summer 2003 and summer 2004 PVS courses.
6 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)",
W3C Recommendation, October 2000.
Authors' Addresses
Frank Strauss
TU Braunschweig
Muehlenpfordtstrasse 23
38106 Braunschweig
Germany
Phone: +49 531 391-3266
EMail: strauss@ibr.cs.tu-bs.de
URI: http://www.ibr.cs.tu-bs.de/
Strauss & Schmidt Expires January 6, 2005 [Page 14]
Internet-Draft P2P Chat Protocol July 2004
Stefan Schmidt
TU Braunschweig
Muehlenpfordtstrasse 23
38106 Braunschweig
Germany
Phone: +49 531 391-3289
EMail: schmidt@ibr.cs.tu-bs.de
URI: http://www.ibr.cs.tu-bs.de/
Strauss & Schmidt Expires January 6, 2005 [Page 15]
Internet-Draft P2P Chat Protocol July 2004
Appendix A. XML Schema Definition for Messages
<?xml version="1.0"?>
<!-- $Id$
-
-->
<xsd:schema
targetNamespace="http://www.ibr.cs.tu-bs.de/chat-message"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.ibr.cs.tu-bs.de/chat-message"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xml:lang="en">
<xsd:annotation>
<xsd:documentation>
This XML Schema defines the p2p-chat protocol messages.
</xsd:documentation>
</xsd:annotation>
<!--
- Types
-->
<xsd:simpleType name="UserIDType">
<xsd:annotation>
<xsd:documentation>
Elements of this type represent a globally unique user
identification. It has to contain a user name part followed by
an @ character and a domain part. It is highly recommended to
use the users valid Internet email address. Note that it has
to be treated case-insensitive.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="[a-zA-Z0-9_\.\-]{1,127}@[a-zA-Z0-9_\.\-]{1,128}"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="MessageIDType">
<xsd:annotation>
<xsd:documentation>
Elements of this type are used to form a unique identification
for messages per user. The pair of a UserID and a MessageID
builds a globally unique message identification. How the
MessageID is actually built is an implementation issue. It
Strauss & Schmidt Expires January 6, 2005 [Page 16]
Internet-Draft P2P Chat Protocol July 2004
might be a persistent counter incremented with each message
generation, or it might be based on a timestamp, for example.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="[a-zA-Z0-9@_\.\-]{1,256}"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="TTLType">
<xsd:annotation>
<xsd:documentation>
An integer time-to-live value. Note that the value range is
restricted.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:int">
<xsd:minInclusive value="1"/>
<xsd:maxInclusive value="32"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ChannelNameType">
<xsd:annotation>
<xsd:documentation>
The name of a channel. Note that it has to be treated
case-insensitive.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="[a-zA-Z0-9_\.\-]{1,16}"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="DomainNameType">
<xsd:annotation>
<xsd:documentation>
A fully qualified domain name of a listening endpoint.
Note that it has to be treated case-insensitive.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
<xsd:simpleType name="IPv4AddressType">
<xsd:annotation>
<xsd:documentation>
An IPv4 address of a listening endpoint.
Strauss & Schmidt Expires January 6, 2005 [Page 17]
Internet-Draft P2P Chat Protocol July 2004
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="PortNumberType">
<xsd:annotation>
<xsd:documentation>
A TCP port number of a listening endpoint.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:int">
<xsd:minInclusive value="1"/>
<xsd:maxInclusive value="65535"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="PeerAddressType">
<xsd:annotation>
<xsd:documentation>
A peer address consists of a hostname (or if a hostname
is not available, an IPv4 address) and a TCP port number.
This pair specifies a potential listening peer endpoint
to which other peers might try to connect.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:choice>
<xsd:element name="hostname" type="DomainNameType"/>
<xsd:element name="ipaddress" type="IPv4AddressType"/>
</xsd:choice>
<xsd:element name="port" type="PortNumberType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="DestinationType">
<xsd:annotation>
<xsd:documentation>
A destination is part of a routing message. It signals
the number of hops to reach a user via the link on which
the routing message is sent.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="user" type="UserIDType"/>
<xsd:element name="hops" type="xsd:unsignedInt"/>
Strauss & Schmidt Expires January 6, 2005 [Page 18]
Internet-Draft P2P Chat Protocol July 2004
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="CertificateType">
<xsd:annotation>
<xsd:documentation>
A certificate consists of the user id to which the certificate
belongs and the certificate itself in the Base64-encoded DER
representation.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="user" type="UserIDType"/>
<xsd:element name="data" type="xsd:base64Binary"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="CipherType">
<xsd:annotation>
<xsd:documentation>
A label to identify a symmetric cipher algorithm. So far,
just one (reasonable) cipher is defined, but others may be
added in future revision of the protocol.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="NONE">
<xsd:annotation>
<xsd:documentation>
No encryption.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="DES-CBC">
<xsd:annotation>
<xsd:documentation>
64(56) bit DES in Cipher Block Chaining mode with PKCS #5
padding.
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="SignType">
<xsd:annotation>
<xsd:documentation>
A label to identify a message digest algorithm. So far, just
Strauss & Schmidt Expires January 6, 2005 [Page 19]
Internet-Draft P2P Chat Protocol July 2004
one algorithm is defined, but others may be added in future
revision of the protocol.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="MD5">
<xsd:annotation>
<xsd:documentation>
MD5 digest (encrypted with the senders private key).
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="SignatureType">
<xsd:annotation>
<xsd:documentation>
A Base64 encoded signature. It is calculated for the
concatenated UTF-8 encoded values (without attributes) of all
child elements of the chat-message element in depth-first
order.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:base64Binary"/>
</xsd:simpleType>
<!--
- Root Element and Message Types
-->
<xsd:element name="chat-message">
<xsd:annotation>
<xsd:documentation>
This is the root element. It represents a p2p-chat protocol
message.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:choice>
<xsd:element name="hello" type="HelloMessage"/>
<xsd:element name="quit" type="QuitMessage"/>
<xsd:element name="channel" type="ChannelMessage"/>
<xsd:element name="join" type="JoinMessage"/>
<xsd:element name="leave" type="LeaveMessage"/>
<xsd:element name="getpeers" type="GetPeersMessage"/>
<xsd:element name="peers" type="PeersMessage"/>
Strauss & Schmidt Expires January 6, 2005 [Page 20]
Internet-Draft P2P Chat Protocol July 2004
<xsd:element name="getcertificate" type="GetCertificateMessage"/>
<xsd:element name="certificate" type="CertificateMessage"/>
<xsd:element name="getkey" type="GetKeyMessage"/>
<xsd:element name="key" type="KeyMessage"/>
<xsd:element name="routing" type="RoutingMessage"/>
<xsd:element name="message" type="MessageMessage"/>
<xsd:element name="obscure" type="ObscureMessage"/>
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="ttl" type="TTLType" default="1"/>
<xsd:attribute name="flood" type="xsd:boolean" default="false"/>
<xsd:attribute name="signtype" type="SignType"/>
<xsd:attribute name="signature" type="SignatureType"/>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="HelloMessage">
<xsd:annotation>
<xsd:documentation>
The "hello" message is the first message sent by each peer of
a newly established connection. The peer may send an informal
greeting text.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="messageid" type="MessageIDType"/>
<xsd:element name="version" type="xsd:int"/>
<xsd:element name="greeting" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="QuitMessage">
<xsd:annotation>
<xsd:documentation>
The "quit" message is sent by a peer as the last message
before actively shutting down the connection. The peer SHOULD
give an informal reason why the connection is shut down.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="messageid" type="MessageIDType"/>
<xsd:element name="reason" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ChannelMessage">
<xsd:annotation>
<xsd:documentation>
Strauss & Schmidt Expires January 6, 2005 [Page 21]
Internet-Draft P2P Chat Protocol July 2004
The "channel" message announces an active channel. The
"closed" flag denotes whether it is a closed channel.
Each known subscriber is listed in a "member" child element.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="sender" type="UserIDType"/>
<xsd:element name="messageid" type="MessageIDType"/>
<xsd:element name="channel" type="ChannelNameType"/>
<xsd:element name="description" type="xsd:string"/>
<xsd:element name="member" type="UserIDType"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="closed" type="xsd:boolean" default="false"/>
</xsd:complexType>
<xsd:complexType name="JoinMessage">
<xsd:annotation>
<xsd:documentation>
The "join" message signal the subscription of a user to
a non-closed channel.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="sender" type="UserIDType"/>
<xsd:element name="messageid" type="MessageIDType"/>
<xsd:element name="channel" type="ChannelNameType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="LeaveMessage">
<xsd:annotation>
<xsd:documentation>
The "leave" message signal the unsubscription of a user from
a non-closed channel.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="sender" type="UserIDType"/>
<xsd:element name="messageid" type="MessageIDType"/>
<xsd:element name="channel" type="ChannelNameType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="GetPeersMessage">
<xsd:annotation>
<xsd:documentation>
A node may send a "getpeers" message to request a list of
Strauss & Schmidt Expires January 6, 2005 [Page 22]
Internet-Draft P2P Chat Protocol July 2004
other node addresses in order to extend its own list of
potential connection peers.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="messageid" type="MessageIDType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PeersMessage">
<xsd:annotation>
<xsd:documentation>
A node can make its direct peer nodes aware of a list of peer
addresses through a "peers" message.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="messageid" type="MessageIDType"/>
<xsd:element name="peer" type="PeerAddressType"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="GetCertificateMessage">
<xsd:annotation>
<xsd:documentation>
A user may send a "getcertificate" message to request a
certificate for a given user ID.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="sender" type="UserIDType"/>
<xsd:element name="receiver" type="UserIDType"/>
<xsd:element name="messageid" type="MessageIDType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="CertificateMessage">
<xsd:annotation>
<xsd:documentation>
A user can send a certificate encapsulated in
a "certificate" message. It's not only the owner of
the certificate who can send such a message.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="sender" type="UserIDType"/>
<xsd:element name="receiver" type="UserIDType"
Strauss & Schmidt Expires January 6, 2005 [Page 23]
Internet-Draft P2P Chat Protocol July 2004
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="messageid" type="MessageIDType"/>
<xsd:element name="certificate" type="CertificateType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="GetKeyMessage">
<xsd:annotation>
<xsd:documentation>
A user may request a channel key for a given closed channel
through a "getkey" message.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="sender" type="UserIDType"/>
<xsd:element name="receiver" type="UserIDType"/>
<xsd:element name="messageid" type="MessageIDType"/>
<xsd:element name="channel" type="ChannelNameType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="KeyMessage">
<xsd:annotation>
<xsd:documentation>
A user can send a channel key encapsulated in a "key"
message. The actual data part of the key has to be encrypted
with the according receiver's public key. It is the duty of
the sender of a "key" message to ensure that the public key
really belongs the the receiver and that the receiver is
really a member of the channel.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="sender" type="UserIDType"/>
<xsd:element name="receiver" type="UserIDType"/>
<xsd:element name="messageid" type="MessageIDType"/>
<xsd:element name="channel" type="ChannelNameType"/>
<xsd:element name="cipher" type="CipherType"/>
<xsd:element name="key" type="xsd:base64Binary"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="RoutingMessage">
<xsd:annotation>
<xsd:documentation>
Routing messages are exchanged on links to form a converging
knowledge on the network topology on every node.
</xsd:documentation>
Strauss & Schmidt Expires January 6, 2005 [Page 24]
Internet-Draft P2P Chat Protocol July 2004
</xsd:annotation>
<xsd:sequence>
<xsd:element name="messageid" type="MessageIDType"/>
<xsd:element name="destination" type="DestinationType"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="MessageMessage">
<xsd:annotation>
<xsd:documentation>
The "message" message carries the actual content of the chat
message in its text element. If the iv attribute is present
it is a message of a closed channel and uses the initialization
vector given by the iv attribute.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="sender" type="UserIDType"
minOccurs="0"/>
<xsd:element name="receiver" type="UserIDType"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="messageid" type="MessageIDType"
minOccurs="0"/>
<xsd:element name="channel" type="ChannelNameType"
minOccurs="0"/>
<xsd:element name="text">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="iv" type="xsd:base64Binary"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ObscureMessage">
<xsd:annotation>
<xsd:documentation>
The "obscure" is created by a user who intends to emit a
"message" message but remain anonymous as the sender of the
message. The "text" payload is in turn an "obscure" message
or a "message" message after decryption.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
Strauss & Schmidt Expires January 6, 2005 [Page 25]
Internet-Draft P2P Chat Protocol July 2004
<xsd:element name="receiver" type="UserIDType" />
<xsd:element name="messageid" type="MessageIDType"
minOccurs="0"/>
<xsd:element name="text" type="xsd:base64Binary" />
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
Strauss & Schmidt Expires January 6, 2005 [Page 26]
Internet-Draft P2P Chat Protocol July 2004
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 (2004). 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.
Strauss & Schmidt Expires January 6, 2005 [Page 27]