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 This XML Schema defines the p2p-chat protocol messages. 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. 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. An integer time-to-live value. Note that the value range is restricted. The name of a channel. Note that it has to be treated case-insensitive. A fully qualified domain name of a listening endpoint. Note that it has to be treated case-insensitive. An IPv4 address of a listening endpoint. Strauss & Schmidt Expires January 6, 2005 [Page 17] Internet-Draft P2P Chat Protocol July 2004 A TCP port number of a listening endpoint. 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. 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. Strauss & Schmidt Expires January 6, 2005 [Page 18] Internet-Draft P2P Chat Protocol July 2004 A certificate consists of the user id to which the certificate belongs and the certificate itself in the Base64-encoded DER representation. 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. No encryption. 64(56) bit DES in Cipher Block Chaining mode with PKCS #5 padding. 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. MD5 digest (encrypted with the senders private key). 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. This is the root element. It represents a p2p-chat protocol message. Strauss & Schmidt Expires January 6, 2005 [Page 20] Internet-Draft P2P Chat Protocol July 2004 The "hello" message is the first message sent by each peer of a newly established connection. The peer may send an informal greeting text. 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. 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. The "join" message signal the subscription of a user to a non-closed channel. The "leave" message signal the unsubscription of a user from a non-closed channel. 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. A node can make its direct peer nodes aware of a list of peer addresses through a "peers" message. A user may send a "getcertificate" message to request a certificate for a given user ID. 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. A user may request a channel key for a given closed channel through a "getkey" message. 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. Routing messages are exchanged on links to form a converging knowledge on the network topology on every node. Strauss & Schmidt Expires January 6, 2005 [Page 24] Internet-Draft P2P Chat Protocol July 2004 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. 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. Strauss & Schmidt Expires January 6, 2005 [Page 25] Internet-Draft P2P Chat Protocol July 2004 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]