Internet Draft M. Barnes Document: draft-barnes-simple-imsx-prot-eval-00.txt Category: Informational Nortel Networks Expires: December 2002 June 2002 IMSX Protocol Evaluation for Session Based IM 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. Abstract This document is submitted to the SIMPLE WG as part of the ongoing discussion on the selection of the protocol for support of Session Based Instant Messaging. It evaluates the suitability of the IMSX protocol as a transport for Session Based IM. IMSX defines a BEEP profile for exchanging CPIM messages after SIP has performed its session setup signaling. This document evaluates IMSX against the IMPP requirements and its ability to interoperate with other IM systems based upon the CPIM profile. Table of Contents 1. Overview......................................................1 1.1 Background................................................1 1.2 IMSX Session Model........................................2 2. Comparison with IMPP Requirements.............................2 3. Comparison against the CPIM profile...........................5 4. Applicability of IMSX to IM Session Normative Guidelines......6 5. Conclusions...................................................8 6. Security Considerations.......................................8 7. References.................................................8 1. Overview 1.1 Background The SIMPLE Working Group bases its requirements on those established by the IMPP Working Group [2] and defines interoperability with other IM protocols with the common message format requirements as defined in CPIM [5]. The Working Group is Barnes Expires - December 2002 [Page 1] IMSX Protocol Evaluation for Session Based IM June 2002 currently evaluating two protocols as a basis for Session Based IM. IM Simple Exchange (IMSX) [3], which defines a profile for using the BEEP protocol [4], is one of the candidates. This document summarizes how well IMSX meets the IMPP requirements. In addition, IMSX is compared against the Abstract Instant Messaging Service as defined by CPIM to see how well it suits the interoperation philosophy. This document also provides some brief discussion on the applicability of IMSX with regards to the Guidelines for Instant Message Sessions [9]. 1.2 IMSX Session Model In the "session" model, an IM application determines that it wishes to communicate with another IM application. These applications, termed the initiating and responding applications (respectively) are conceptually identified using the IM URI, as specified in Section 5.1 of CPIM [5]. The initiating application determines that it will use IMSX to communicate with the responding application, so it uses the SIP URI for this purpose. For example, if the IM application uses IMSX to communicate with an IM application identified as "im:barney@rubble.com" , the URI "sip:barney@rubble.com" is utilized for this purpose. The initiating application ensures that it is running a BEEP entity that implements the IMSX profile, and determines the transport information associated with the BEEP entity (typically IP address and TCP port number). The initiating application then constructs an appropriate SDP to be carried in a SIP INVITE. The initiating application then waits for a response. The SIP INVITE is received by the responding application, which determines that it wishes to communicate with the initiating application. The responding application ensures that it is running a BEEP entity that implements the IMSX profile. It then determines the transport information associated with the BEEP entity (typically IP address and TCP port number), and sends its own SDP with a 200 response code. Ultimately, the initiating application receives the response and acknowledges it with a SIP ACK message. Upon receipt of the response, the initiating application activates its BEEP entity, and, using the transport information in the response, establishes a BEEP session. If successful, the initiating application tunes the session as appropriate, and starts the IMSX profile. 2. Comparison with IMPP Requirements This section contains an evaluation of IMSX against the requirements documented in [2]. or indicates the requirement documented in section x.x or x.x.x of [2]. <2.1> Namespace and Administration <2.1.1> The IMSX protocol is entirely independent of whether a PRESENCE SERVICE is available. <2.1.2> The IDENTIFIER for reaching the INSTANT INBOX for IMSX does not assume any PRESENTITIES. Barnes Expires - December 2002 [Page 2] IMSX Protocol Evaluation for Session Based IM June 2002 <2.1.3> Per <2.1.1.> the IMSX protocol is entirely independent of whether there is a PRESENCE SERVICE, but IMSX does not explicitly preclude the use of the same IDENTIFIER. <2.1.4> Not Applicable to IM, as ENTITIES are all PRESENCE Related. However, IMSX naming and administration within a DOMAIN is independent of that in any other DOMAIN. <2.1.5> IMSX/BEEP does not preclude having multiple DOMAINS within a NAMESPACE, thus assuring conformance with this requirement. <2.2> Scalability Although all the specific requirements for scalability appear to be applicable only to the PRESENCE SERVICE, due to the use of the term ENTITIES, it is assumed that Scalability should also apply to IM. IMSX, being based on BEEP, is inherently scalable. Some of the factors contributing to the scalability are: - BEEP allows for multiple channels over a single session - The communicating applications are loosely coupled. <2.3> Access Control <2.3.5> IMSX controls which other PRINCIPALS can send INSTANT MESSAGES to the INSTANT INBOX by allowing the PRINCIPAL to decline a SIP session being established to send INSTANT MESSAGES. Access control may also be asserted from the IMSX level, by rejecting channel creation or specific messages from other PRINCIPALS. <2.3.6.> IMSX controls which other PRINCIPALS can read INSTANT MESSAGES from that INSTANT INBOX with its support of a secure interface to that INSTANT INBOX. User authentication is achieved using the initial tuning profile. Authorization itself is an internal manner for each BEEP peer. As such, each peer may choose to restrict the operations it allows based on the authentication credentials provided. <2.3.7> This requirement is specific to the PRESENCE SERVICE, however, it should noted that IM Access control in IMSX is independent of presence. <2.4> Network Topology <2.4.3> BEEP is a peer to peer protocol designed to support the sending of the messages directly. However the use of message intermediaries is not precluded. A solution has been proposed whereby the sender opens a BEEP connection to the first intermediary. The first intermediary connects to the next intermediary (if it exists), and so on. The final intermediary connects to the receiver. Every message sent (either direction) will pass over pre-existing BEEP connections so the TCP setup delay and resources consumption for each hop for each message is avoided. <2.4.4> Middlebox traversal (NATs and FIREWALLS) for IMSX is a requirement that is currently not specifically addressed by BEEP. Barnes Expires - December 2002 [Page 3] IMSX Protocol Evaluation for Session Based IM June 2002 However, it is deemed equivalent to and addressed by the same mechanism which would be used for TCP based SIP media. <2.5> Message Encryption and Authentication IMSX defines the means for establishing the level of security through the tuning profile. Although use of the tuning attribute in the SDP announcement is a policy matter, at a minimum, all IMSX implementations must provide the following tuning profiles: tuning value profile -------------- ------------------------------------ authentication http://iana.org/beep/SASL/DIGEST-MD5 integrity http://iana.org/beep/SASL/DIGEST-MD5 privacy http://iana.org/beep/TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher all http://iana.org/beep/TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher and client-side certificates <2.5.1> IMSX provides a means to ensure confidence that an INSTANT MESSAGE has not been corrupted or tampered with as identified in the table in section <2.5> above. This would be achieved with a tuning value of "integrity" or "all" in the tuning profile. <2.5.2> IMS provides a means to ensure confidence that a received INSTANT MESSAGE has not been recorded or played back by an adversary as identified in the table in section <2.5> above. <2.5.3> IMS provides a means to ensure that a sent INSTANT MESSAGE is only readable by ENTITIES that the sender allows with its support of a secure interface. User authentication is achieved using the initial tuning profile. Authorization itself is an internal manner for each BEEP peer. As such, each peer may choose to restrict the operations it allows based on the authentication credentials provided. <2.5.4> The protocol allows any client to use the means to ensure non-corruption, non-playback, and privacy, but the protocol does NOT require that all clients use these means at all times. IMSX defines the means for establishing the level of security through the tuning profile. Use of the tuning attribute in the SDP announcement is a policy matter, however, at a minimum, all IMSX implementations must provide the following tuning profiles as identified in the table in section <2.5>. The protocol does not require that all clients use these means at all times; the clients may also turn off these mechanisms using a tuning attribute of "none". <4.1> Common Message Format The common message format requirements are met by the definitions defined in CPIM [5]. Evaluation of IMSX against CPIM is described in section 3 of this document. <4.2> Reliability Barnes Expires - December 2002 [Page 4] IMSX Protocol Evaluation for Session Based IM June 2002 <4.2.1> The Response Element defined by IMSX is sent to inform the sender of the INSTANT MESSAGE that the message had been received. The Response contains a Status element that indicates "Success", "Failure", or "Indeterminant". The textual content of the Response is a diagnostic which is meaningful to implementers, perhaps administrators and possibly even end users. <4.3> Performance <4.3.1> Once the BEEP session is tuned and the IMSX profile has been exchanged, the processing of the Message and Response elements should provide for a sufficiently rapid exchange of short messages. In addition, the first INSTANT MESSAGE could be piggybacked in the profile exchange up to a limit of 4K octets. <5.4> Security Requirements related to INSTANT MESSAGES All the security requirements in section 5.4 of [1] are primarily met by IMSX through the use of TCP and TLS/SASL, unless otherwise specified below. All the requirements identified in this section deal with the scenario where a user A sends an INSTANT MESSAGE M to another user B. <5.4.1> A MUST receive confirmation of non-delivery <5.4.2> If M is delivered, B MUST receive the message only once. <5.4.3> The protocol MUST provide B means of verifying that sent the message. <5.4.4> B MUST be able to reply to the message via another instant message. <5.4.5> The protocol MUST NOT always require A to reveal A's IP address, for A to send an instant message. Since, IMSX is based upon the use of SIP for establishing the session, it could be said that IMSX does not meet this requirement as SIP typically reveals the IP Address in several headers including SDP. <5.4.6> The protocol MUST provide A means of ensuring that no other PRINCIPAL C can see the content of M. <5.4.7> The protocol MUST provide A means of ensuring that no other PRINCIPAL C can tamper with M, and B means to verify that no tampering has occurred. <5.4.8> B must be able to read M. <5.4.9> The protocol MUST allow A to sign the message, using existing standards for digital signatures. <5.4.10> B MUST be able to prevent A from sending him messages. For Session based IM, this can be accomplished by B refusing to setup the SIP Session used for IMSX. This may also be handled at the IMSX level by tearing down the channel or the entire session itself. 3. Comparison against the CPIM profile This section evaluates IMSX against the semantics and data formats defined for CPIM [5]. or indicates the requirement Barnes Expires - December 2002 [Page 5] IMSX Protocol Evaluation for Session Based IM June 2002 documented in section x.x or x.x.x of CPIM [5]. IMSX has defined its IMSX payload to be conformant to CPIM per the Common Service DTD and Message Service DTD defined in sections 6 and 7 of CPIM [5]. <2.1> Overview of the Messaging Service IMSX uses its profile and the BEEP message operation 'MSG' to send messages to a peer. IMSX uses its profile and the BEEP response operation 'RPY' to send responses. The transaction identifier is carried in the frame header of the BEEP message. <2.2> Identification of INSTANT INBOXes IMSX uses the IM application URI to identify the INSTANT INBOX for a given IM Session as defined in section 5.1 of [1]. This IM application URI is based on the specifications in RFC 2822 [6]. Thus, IMSX should be deemed to be conformant to the specifics necessary for interoperability as identified in <2.2.1> through <2.2.4>. SIP is used to set up the session, thus any required address resolution for Instant Inbox identification may also be performed at session establishment time. <2.3> Format of Instant Messages Each BEEP payload exchanged via IMSX consists of an XML document and possibly an arbitrary MIME content. MIME content is included in the BEEP payload by using a "multipart/related" [8], thus IMSX would be compatible with CPIM. <2.4> The Messaging Service Section 2.4 of CPIM [5] defines the abstract semantics for the communications between an application and the IM service. In contrast, IMSX is concerned with the semantics for the communications between two IM applications. However, IMSX does define the Message Operation in a manner similar in nature to CPIM's behavior as described in section 2.4.1 of [5]. IMSX does not address the looping of a message through a relay, as described in section 2.4.2 of [5], since its messaging is focused on the exchanges between end-users. <4> Security Considerations All the security requirements are met by IMSX primarily through the use of TCP, TLS/SASL. IMSX [3] defines a minimum set of tuning profiles that must be supported as countermeasures to the threats as described in section 4.1 of CPIM [5]. <4.3.1> End-to-end security for Instant Messages For end-to-end security in section 4.3.1, CPIM suggests MIME-based security (e.g. S/MIME). Although not explicitly specified in BEEP [4] or IMSX [3], IMSX could use S/MIME for the payload. 4. Applicability of IMSX to IM Session Normative Guidelines This section briefly discusses the applicable of IMSX against the Normative Guidelines described in section 5 of [9]. Barnes Expires - December 2002 [Page 6] IMSX Protocol Evaluation for Session Based IM June 2002 IMSX satisfies the following guidelines: o Preliminary signaling used to establish a session of instant messages MUST be capable of negotiating a common underlying transport protocol for instant messaging. o Session messaging MUST NOT use UDP as a transport layer because of UDP's lack of congestion control. Transport protocols used for session messaging MUST support congestion control. o A transport/session layer protocol for instant messaging sessions MUST explicitly specify the identities of the participants in the session, a unique session identifier, and sequencing information for messages in a session. o A transport/session layer solution for instant messaging sessions MUST support end-to-end confidentiality and integrity mechanisms for instant messages. o A transport/session layer solution for instant messaging sessions MUST support end-to-end mutual authentication. o A transport/session layer solution for instant messaging sessions SHOULD support a mechanism for specifying a single transport protocol end-to-end. Although, IMSX/BEEP was not explicitly defined to accommodate network intermediaries, it should be able to satisfy the following guidelines: o End-to-end security mechanisms for instant messaging sessions SHOULD accommodate network intermediaries that have been authorized to act on the session. For example, headers on which intermediaries need to operate might be kept in cleartext while the remainder of an instant message was encrypted from end-to-end. o A transport/session layer solution for instant messaging sessions MUST support a mechanism through which a participant in a session can discover the presence of an intermediary. Through the use of the STUN protocol [10], this guideline could be met with the IMSX/BEEP IM Session solution. IMSX doesnĘt meet several of the guidelines with regards to intermediaries, as these guidelines are not in the scope of the BEEP design intent. However, a complete IM Session solution should address the requirements for these guidelines, as they represent the true operational environment for the IM Session solution: o Intermediaries SHOULD NOT interpose themselves between endpoints in a session unless they are specifically authorized to do so by one of the principal participants in a session. o Any intermediaries interposing themselves in instant messaging sessions themselves MUST notify all participants of their presence through either the preliminary signaling or subsequent session messaging. Barnes Expires - December 2002 [Page 7] IMSX Protocol Evaluation for Session Based IM June 2002 5. Conclusions IMSX as defined meets the majority of the CPIM requirements with the exception of the Network topology requirements, defined by <2.4> in section 2, which were beyond the scope of the original design intent of BEEP: o Middlebox traversal (NATs and FIREWALLS) for IMSX is a requirement that is currently not specifically addressed by BEEP. However, it is deemed equivalent to and addressed by the same mechanism which would be used for TCP based SIP media. o IMSX does not address the proxy or relay requirements for support of IM. However, as described in section 2 for requirement <2.4.3>, a solution to this requirement is not beyond the scope of BEEP. Related to these requirements, as evaluated against the IM Session Guidelines in section 4, the IMSX/BEEP IM Session solution does not fully address intermediaries. Beyond the identified requirements, which are not fully met, additional disadvantages of IMSX as the Session IM protocol are: o BEEP does not currently support threading. o Requires the development of a new protocol for most existing SIP products. There are a few advantages of IMSX that arenĘt necessarily exposed through this detailed evaluation: o A user can use a single TCP connection for multiple IM Session connections to the same user. o Several channels may be multiplexed over the same TCP connection having different characteristics. o For this model of a single TCP connection, interleaving provides a fair share of the use of connection to support the multiple types of media. 6. Security Considerations Security considerations are addressed by requirements <2.3.> Access Control, <2.5> Message authentication and encryption and <5.4> Security Requirements related to INSTANT MESSAGES in section 2 of this document and requirements <4> in section 3 of this document. 7. References [1] Day, M., Rosenberg, J. and H. Sagano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. Barnes Expires - December 2002 [Page 8] IMSX Protocol Evaluation for Session Based IM June 2002 [2] Day, M., Aggarwal, S., Mohr, G., Vincent, J., "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000. [3] Rose, M., "IM Simple Exchange (IMSX)", draft-mrose-simple- exchange-01, Work in Progress, December, 2001. [4] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [5] Crocker, D., "Common Presence and Instant Messaging (CPIM)", draft-ietf-impp-cpim-02, work in progress, November, 2001. [6] Resnick, P., "INTERNET MESSAGE FORMAT", RFC 2822, STD 11, April 2001. [7] J. Galvin, S. Murphy, S. Crocker, and N. Freed, "Security multiparts for MIME: multipart/signed and multipart/encrypted,"Request for Comments 1847, Internet Engineering Task Force, Oct. 1995. [8] Levinson, E., "The MIME Multipart/Related Content-type", RFC2387, August 1998 [9] Mankin, A., Peterson, J., "Guidelines for Instant Message Sessions", draft-mankin-im-session-guide-00, work in progress, November, 2001. [10] Rosenberg, J., "STUN - Simple Traversal of UDP Through NATs", draft-ietf-midcom-stun-00, Work in progress, April 5, 2002. Acknowledgements The author would like to acknowledge the constructive input and feedback given by Sriram Parameswar, which helped to further refine this evaluation. AuthorĘs Address Mary Barnes Nortel Networks 2380 Performance Drive Phone: 1-972-684-5432 Richardson, TX USA Email: mbarnes@nortelnetworks.com Full Copyright Statement Copyright (C) The Internet Society (2002). 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 Barnes Expires - December 2002 [Page 9] IMSX Protocol Evaluation for Session Based IM June 2002 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 assigns. 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Barnes Expires - December 2002 [Page 10]