Network Working Group F. Strauss Internet-Draft S. Schmidt Expires: December 25, 2003 TU Braunschweig June 26, 2003 P2P CHAT - A Peer-to-Peer Chat Protocol draft-strauss-p2p-chat-03 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 25, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo presents a protocol for a peer-to-peer based chat system. Messages can be cryptographically signed and encrypted allowing authentic and closed group 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 December 25, 2003 [Page 1] Internet-Draft P2P Chat Protocol June 2003 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 Security . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. The Protocol . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 Protocol Message Format . . . . . . . . . . . . . . . . . 7 3.2 Protocol Message Exchange . . . . . . . . . . . . . . . . 7 3.3 Protocol Messages . . . . . . . . . . . . . . . . . . . . 7 3.3.1 HELLO . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3.2 QUIT . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.3 CHANNEL . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.4 GETPEERS . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.5 PEERS . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.6 GETCERTIFICATE . . . . . . . . . . . . . . . . . . . . . . 8 3.3.7 CERTIFICATE . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.8 GETKEY . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.9 KEY . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.10 MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . 10 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 14 Normative References . . . . . . . . . . . . . . . . . . . 13 Informative References . . . . . . . . . . . . . . . . . . 14 A. XML Schema Definition for Messages . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . 25 Strauss & Schmidt Expires December 25, 2003 [Page 2] Internet-Draft P2P Chat Protocol June 2003 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 switch to other 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 participant in the chat network. Note that there may be multiple nodes located on a common host. From the perspective of one node and regarding a given link, the peer is the node at the remote end of the link. See also "user". 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 connection 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. Users and nodes are in a 1:1 relationship. Channel: Communication is organized in channels. Each user may subscribe to and unsubscribe from a channel in order to control which text messages received at a node shall be presented to the 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 read it and send text messages to such a channel. Strauss & Schmidt Expires December 25, 2003 [Page 3] Internet-Draft P2P Chat Protocol June 2003 Closed channel: Closed channels are assiciated with a list of channel members. 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.) 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. 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 December 25, 2003 [Page 4] Internet-Draft P2P Chat Protocol June 2003 2. The Architecture 2.1 The Peer-to-Peer Network Each node within the chat network represents an active chat participant (not a host), i.e., there might be multiple nodes located on the same host. Upon startup, a node 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, but might be configurable. Each node MUST always be willing to accept incoming peer connections, even if its limit is reached. In that case, the peer might decide to close down other connections with an appropriate reason, but it might also serve a larger number of incoming connections simultaneously. 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. Most messages within the network are flooded: text messages, channel announcements, certificate lookups, certificates, etc. This simplifies the routing dramatically and it gives all peers a better chance to care about a consistent and persistent configuration (if their local ressources allow it), even if some peers disconnect temporarily. Due to another simplification there is no spanning tree approach. Each node simply forwards an incoming message on all links (except the one on which the message has been received), if it has not been received before and if the TTL counter, which is decremented on each hop, is not yet zero. This way messages appear twice on redundant links, but it simplifies the protocol significantly. In some situation it is reasonable to send a message just to the peer on a link, e.g. HELLO and QUIT messages, see below. In this case the TTL counter is simply initialized with the value 1. Furthermore, nodes that wish to reduce redundant traffic might also wish to reduce redundant links and shutdown those links that have been identified to be redundant. 2.2 Security In order to support signed messages and closed channel 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. However, implementations may also be operational (lacking these cryptographic functionalities), if the RSA keypair and X.509 certificates are not Strauss & Schmidt Expires December 25, 2003 [Page 5] Internet-Draft P2P Chat Protocol June 2003 available. Signing of the messages SHOULD be done whenever posible. The mandatory algorithms is MD5 with RSA. The concatenation of all text sub-nodes of the message starting at the message type node 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 mandatory symmetric algorithm is standard 64 (56) bit DES in Cipher Block Chaining (CBC) mode with padding enabled. Further symmetric algorithms may be added in the future. Strauss & Schmidt Expires December 25, 2003 [Page 6] Internet-Draft P2P Chat Protocol June 2003 3. The Protocol This section describes the peer-to-peer chat protocol version 1. 3.1 Protocol Message Format Each message represents a well-formed UTF-8 encoded 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 reasonable initial TTL values are only (except for experimental cases) "1" for messages sent only to a direct peer and "32" for broadcast messages. 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. Strauss & Schmidt Expires December 25, 2003 [Page 7] Internet-Draft P2P Chat Protocol June 2003 3.3.2 QUIT A peer may close down a connection at any point in time. To do this 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 once when the local user creates a channel and subsequently when a peer did not receive a CHANNEL message for a subscribed channel from any other node for a certain time and as long as the local user is still subscribed to that channel. This time SHOULD be a random value in the range between 50 and 60 seconds. In case of a closed channel, the message contains the list of channel members, who are allowed to retrieve the session key through a GETKEY/KEY message pair. Note that users who are on the list are allowed to add further members to the list by sending a new CHANNEL message with the extended list. There is no way to reduce the list, since it is obviously not possible to revoke a shared secret. Note furthermore, 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 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 SHOULD be sent with TTL = 1. 3.3.5 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 SHOULD be done with TTL = 1. 3.3.6 GETCERTIFICATE A node MAY request a certificate for a given user ID by broadcasting 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. Strauss & Schmidt Expires December 25, 2003 [Page 8] Internet-Draft P2P Chat Protocol June 2003 3.3.7 CERTIFICATE A node can send a certificate encapsulated in a CERTIFICATE message. This can be a broadcasted announcement by the owner of the certificate, e.g. when the node newly connects to the network or when the certificate has been changed. Furthermore, a CERTIFICATE message MUST be sent in response to a received GETCERTIFICATE message for the local user's ID and it SHOULD be sent in response to a GETCERTIFICATE message for another user's ID if the certificate is locally available. In the latter case, the received GETCERTIFICATE message SHOULD NOT be forwarded. 3.3.8 GETKEY A node may request a channel key for a given closed channel by broadcasting a GETKEY message. 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. 3.3.9 KEY A node can send a channel key encapsulated in a KEY message. Besides the channel and the used cipher, the key message contains a number of pairs of a user ID and the key encrypted for that user. For each of these pairs the sender MUST be sure that the user is a member of the closed channel and the public key used for the key encryption really belongs to that user. This is usually done through a certificate verification process. A KEY message can be sent as a broadcasted announcement by the creator of a closed channel immediately after sending the channel creating CHANNEL message. In this case the key is included several times, each time encrypted with the respective channel member's public key. Furthermore, a KEY message MUST be sent in response to a received GETKEY message if the key is locally available and the requestor is a member of the channel. In this case, the received GETKEY message SHOULD NOT be forwarded, and there has to be only one pair of the requestor's user ID and the appropriately encrypted channel key in the KEY message. 3.3.10 MESSAGE The users' text messages within channels are distributed in MESSAGE messages. 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). Strauss & Schmidt Expires December 25, 2003 [Page 9] Internet-Draft P2P Chat Protocol June 2003 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. At the current status the protocol takes no measures to protect against DoS attacks by peers. Strauss & Schmidt Expires December 25, 2003 [Page 10] Internet-Draft P2P Chat Protocol June 2003 5. Open Issues There are a lot of issues that could not be addressed within the scope of this document and the time frame of the project on which this document is based. Here are some of those issues that we are aware of, but that we did not address intentionally. MIME encoding or otherwise arbitrary content of messages is not supported. Only pure text messages in ASCII encoding can be exchanged. Implementations are free to support an 8-bit character set instead of pure 7-bit ASCII. In that case ISO-8859-1 is suggested. Explicit unicast one-to-one communication could be meaningful in some situations, e.g. for private messages. However, this is not supported by this specification. A more intelligent routing algorithm would be very reasonable so that messages are routed on paths with no subscribed or addressed receivers. However, for the current medium sized environment and for less complexity it seems reasonable to flood all messages on all paths. The current version of the protocol does not scale well and is vulnerable to DoS attacks. Strauss & Schmidt Expires December 25, 2003 [Page 11] Internet-Draft P2P Chat Protocol June 2003 6. Acknowledgements The protocol described in this memo is the output of a practical course on distributed systems that has been conducted at the Technical University of Braunschweig in April - July, 2003. Most of the work presented here is based on concepts developed by the approx. 48 participating students of that course during a two-weeks design phase and a subsequent protocol design colloquium in June, 2003. 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 PVS course. Strauss & Schmidt Expires December 25, 2003 [Page 12] Internet-Draft P2P Chat Protocol June 2003 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. Strauss & Schmidt Expires December 25, 2003 [Page 13] Internet-Draft P2P Chat Protocol June 2003 Informative References [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 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/ 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 December 25, 2003 [Page 14] Internet-Draft P2P Chat Protocol June 2003 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 December 25, 2003 [Page 15] Internet-Draft P2P Chat Protocol June 2003 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 December 25, 2003 [Page 16] Internet-Draft P2P Chat Protocol June 2003 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 certificate consists of the user id to which the certificate belongs and the certificate itself encoded in Base64. Strauss & Schmidt Expires December 25, 2003 [Page 17] Internet-Draft P2P Chat Protocol June 2003 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 one algorithm is defined, but others may be added in future revision of the protocol. MD5 digest (encrypted with the senders private key). Strauss & Schmidt Expires December 25, 2003 [Page 18] Internet-Draft P2P Chat Protocol June 2003 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. A symmetric session key consists of the channel name to which the key belongs and an identification of the used cipher algorithm, and a number of key sub-elements each containing a channel member and the key data for that user encrypted with his/her public key and encoded in Base64. This is the root element. It represents a p2p-chat protocol message. Strauss & Schmidt Expires December 25, 2003 [Page 19] Internet-Draft P2P Chat Protocol June 2003 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 December 25, 2003 [Page 20] Internet-Draft P2P Chat Protocol June 2003 The "channel" message announces an active channel. The existance of the members element denotes a closed channel. A peer may send a "getpeers" message to request a list of other peer addresses in order to extend its own list of potential connection peers. A node can make other nodes aware of a list of peer addresses through a "peers" message. Strauss & Schmidt Expires December 25, 2003 [Page 21] Internet-Draft P2P Chat Protocol June 2003 A peer may send a "getcertificate" message to request a certificate for a given user ID. A peer 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 node may request a channel key for a given closed channel Strauss & Schmidt Expires December 25, 2003 [Page 22] Internet-Draft P2P Chat Protocol June 2003 through a "getkey" message. A node can send a channel key encapsulated in a "key" message. The actual data parts of the key have to be encrypted with the according receivers' public keys. Its the duty of the sender of a "key" message to ensure that the public keys really belong the the receivers and that the receivers are really members of the channel. 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. Strauss & Schmidt Expires December 25, 2003 [Page 23] Internet-Draft P2P Chat Protocol June 2003 Strauss & Schmidt Expires December 25, 2003 [Page 24] Internet-Draft P2P Chat Protocol June 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Strauss & Schmidt Expires December 25, 2003 [Page 25] Internet-Draft P2P Chat Protocol June 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Strauss & Schmidt Expires December 25, 2003 [Page 26]