Network Working Group E. Ivov Internet-Draft Jitsi Intended status: Informational P. Saint-Andre Expires: February 28, 2014 Cisco Systems, Inc. E. Marocco Telecom Italia August 27, 2013 CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) draft-ivov-xmpp-cusax-07 Abstract This document describes suggested practices for combined use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). Such practices aim to provide a single fully featured real-time communication service by using complementary subsets of features from each of the protocols. Typically such subsets would include telephony capabilities from SIP and instant messaging and presence capabilities from XMPP. This specification does not define any new protocols or syntax for either SIP or XMPP. However, implementing the practices outlined in this document may require modifying or at least reconfiguring existing client and server-side software. Also, it is not the purpose of this document to make recommendations as to whether or not such combined use should be preferred to the mechanisms provided natively by each protocol (for example, SIP's SIMPLE or XMPP's Jingle). It merely aims to provide guidance to those who are interested in such a combined use. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on February 28, 2014. Ivov, et al. Expires February 28, 2014 [Page 1] Internet-Draft Combined Use of SIP and XMPP August 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Client Bootstrap . . . . . . . . . . . . . . . . . . . . . . 5 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Server-Side Setup . . . . . . . . . . . . . . . . . . . . 7 3.2. Service Management . . . . . . . . . . . . . . . . . . . 8 3.3. Client-Side Discovery and Usability . . . . . . . . . . . 8 3.4. Indicating a Relation Between SIP and XMPP Accounts . . . 9 3.5. Matching Incoming SIP Calls to XMPP JIDs . . . . . . . . 10 4. Multi-Party Interactions . . . . . . . . . . . . . . . . . . 11 5. Federation . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Summary of Suggested Practices . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Informative References . . . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction Historically SIP [RFC3261] and XMPP [RFC6120] have often been implemented and deployed with different purposes: from its very start SIP's primary goal has been to provide a means of conducting "Internet telephone calls". XMPP on the other hand, has, from its Jabber days, been mostly used for instant messaging and presence [RFC6121], as well as related services such as groupchat rooms [XEP-0045]. For various reasons, these trends have continued through the years even after each of the protocols had been equipped to provide the features it was initially lacking: Ivov, et al. Expires February 28, 2014 [Page 2] Internet-Draft Combined Use of SIP and XMPP August 2013 o In the context of the SIMPLE working group, the IETF has defined a number of protocols and protocol extensions that not only allow for SIP to be used for regular instant messaging and presence but that also provide mechanisms for elaborated features such as multi-user chats, server-stored contact lists, file transfer and others. o Similarly, the XMPP community and the XMPP Standards Foundation have worked on defining a number of XMPP Extension Protocols (XEPs) that provide XMPP implementations with the means of establishing end-to-end sessions. These extensions are often jointly referred to as Jingle and arguably their most popular use case is audio and video calling. Despite these advances, SIP remains the protocol of choice for telephony-like services, especially in enterprises where users are accustomed to features such as voice mail, call park, call queues, conference bridges and many others that are rarely (if at all) available in Jingle-based software. XMPP implementations, on the other hand, greatly outnumber and outperform those available for instant messaging and presence extensions developed in the SIMPLE WG, such as MSRP [RFC4975] and XCAP [RFC4825]. As a result, a number of adopters have found themselves needing features that are not offered by any single-protocol solution, but that separately exist in SIP and XMPP implementations. The idea of seamlessly using both protocols together would hence often appeal to service providers and users. Most often, such a service would employ SIP exclusively for audio, video, and telephony services and rely on XMPP for anything else varying from chat, contact list management, and presence to whiteboarding and exchanging files. Because these services and clients involve the combined use of SIP and XMPP, we label them "CUSAX" for short. +------------+ +-------------+ | SIP Server | | XMPP Server | +------------+ +-------------+ \ / media \ / instant messaging, signaling \ / presence, etc. \ / +--------------+ | CUSAX Client | +--------------+ Figure 1: Division of Responsibilities Ivov, et al. Expires February 28, 2014 [Page 3] Internet-Draft Combined Use of SIP and XMPP August 2013 This document explains how such hybrid offerings can be achieved with a minimum of modifications to existing software while providing an optimal user experience. It covers server discovery, determining a SIP Address of Record (AOR) while using XMPP, and determining an XMPP Jabber Identifier ("JID") from incoming SIP requests. Most of the text here pertains to client behavior but it also recommends certain server-side configurations and operational practices. The document also discusses significant security considerations that can arise when offering a dual-protocol solution, and provides advice for avoiding security mismatches that would result in degraded communications security for end users. Note that this document is focused on coexistence of SIP and XMPP functionality in end-user-oriented clients. By intent it does not define methods for protocol-level mapping between SIP and XMPP, as might be used within a server-side gateway between a SIP network and an XMPP network (a separate series of documents has been produced that defines such mappings). More generally, this document does not describe service policies for inter-domain communication (often called "federation") between service providers (e.g., how a service provider that offers a combined SIP-XMPP service might communicate with a SIP-only or XMPP-only service), nor does it describe the reasons why a service provider might choose SIP or XMPP for various features. This document concentrates on use cases where the SIP services and XMPP services are controlled by one and the same provider, since that assumption greatly simplifies both client implementation and server- side deployment (e.g., a single service provider can enforce common or coordinated policies across both the SIP and XMPP aspects of a CUSAX service, which is not possible if a SIP service is offered by one provider and an XMPP service is offered by another). Since this document is of an informational nature, it is not unreasonable for clients to apply some of the guidelines here even in cases where there is no established relationship between the SIP and the XMPP services (for example, it is reasonable for a client to provide a way for its users to easily start a call to a phone number recorded in a vCard or obtained from a user directory). However, the rules to follow in such cases are left to application developers (although they might be described in a future specification). Finally, this document makes a further simplifying assumption by discussing only the use of a single client, not use of and coordination among multiple endpoints controlled by the same user (e.g., user agents running simultaneously on a laptop computer, tablet, and mobile phone). Although user agents running on separate endpoints might themselves be CUSAX clients or might engage in different aspects of an interaction (e.g., a user might employ her Ivov, et al. Expires February 28, 2014 [Page 4] Internet-Draft Combined Use of SIP and XMPP August 2013 mobile phone for audio and her tablet for video and text chat), such usage complicates the guidelines for developers of user agents and therefore is left as a matter of implementation for now. 2. Client Bootstrap One of the main problems of using two distinct protocols when providing one service is the impact on usability. Email services, for example, have long been affected by the mixed use of SMTP for outgoing mail and POP3 or IMAP for incoming mail. Although standard service discovery methods (such as the proper DNS records) make it possible for a user agent to locate the right host(s) at which to connect, they do not provide the kind of detailed information that is needed to actually configure the user agent for use with the service. As a result, it is rather complicated for inexperienced users to configure a mail client and start using it with a new service, and Internet service providers often need to provide configuration instructions for various mail clients. Client developers and communication device manufacturers on the other hand often ship with a number of wizards that enable users to easily set up a new account for a number of popular email services. While this may improve the situation to some extent, the user experience is still clearly sub- optimal. While it should be possible for CUSAX users to manually configure their separate SIP and XMPP accounts (often by means of so-called "wizard" interfaces), service providers offering CUSAX services to users of dual-stack SIP/XMPP clients ought to provide means of online provisioning, typically by means of a web-based service at an HTTP URI (naturally single-purpose SIP services or XMPP services could offer online provisioning as well, but they can be especially helpful where the two aspects of the CUSAX service need to have several configuration options in common). Although the specifics of such mechanisms are outside the scope of this specification, they should make it possible for a service provider to remotely configure the clients based on minimal user input (e.g., only a user ID and password). As far as the authors are aware, no open protocol for endpoint configuration is yet available and adopted; however, application developers are encouraged to explore the potential for future progress in that space (e.g., perhaps based on technologies such as WebFinger [I-D.ietf-appsawg-webfinger]). Ivov, et al. Expires February 28, 2014 [Page 5] Internet-Draft Combined Use of SIP and XMPP August 2013 Because many of the features that a CUSAX client would prefer in one protocol would also be available in the other, clients should make it possible for such features to be disabled for a specific account. In particular, it is suggested that clients allow for audio and video calling features to be disabled for XMPP accounts, and that instant messaging and presence features should also be made optional for SIP accounts. The main advantage of this approach is that clients would be able to continue to function properly and use the complete feature set of standalone SIP and XMPP accounts. Once clients have been provisioned, they need to independently log into the SIP and XMPP accounts that make up the CUSAX "service" and then maintain both these connections as displayed in Figure 2. +--------------+ | Provisioning |-----------+ | Server | | +--------------+ v | +----------------+ | | User Directory | | +----------------+ | / \ | +------------+ +-------------+ | | SIP Server | | XMPP Server | | +------------+ +-------------+ | \ / | media \ / instant messaging, | signaling \ / presence, etc. | \ / | +--------------+ +---------------| CUSAX Client | +--------------+ Figure 2: Example Deployment In order to improve the user experience, when reporting connection status clients may also wish to present the XMPP connection as an "instant messaging" or a "chat" account. Similarly they could also depict the SIP connection as a "Voice and Video" or a "Telephony" connection. The exact naming is of course entirely up to implementers. The point is that, in cases where SIP and XMPP are components of a service offered by a single provider, such presentation could help users better understand why they are being shown two different connections for what they perceive as a single service. It could alleviate especially situations where one of these connections is disrupted while the other one is still active. Ivov, et al. Expires February 28, 2014 [Page 6] Internet-Draft Combined Use of SIP and XMPP August 2013 Naturally, the developers of a CUSAX client or the providers of a CUSAX service might decide not to accept such situations and force a client to completely disconnect unless both aspects are successfully connected. Clients may also choose to delay their XMPP connection until they have been successfully registered on SIP. This would help avoid the situation where a user appears online to its contacts but calling it would fail because their clients is still connecting to the SIP aspect of their CUSAX service. 3. Operation Once a CUSAX client has been provisioned and authorized to connect to the corresponding SIP and XMPP services it would proceed by retrieving its XMPP roster. The client should use XMPP for all forms of communication with the contacts from this roster, which will occur naturally because they were retrieved through XMPP. Audio/video features however, would typically be disabled in the XMPP stack, so any form of communication based on these features (e.g. direct calls, conferences, desktop streaming, etc.) would happen over SIP. The rest of this section describes deployment, discovery, usability and linking semantics that allow CUSAX clients to fall back and seamlessly use SIP for these features. 3.1. Server-Side Setup In order for CUSAX to function properly, XMPP service administrators should make sure that at least one of the vCard [RFC6350] "tel" fields for each contact is properly populated with a SIP URI or a phone number when an XMPP protocol for vCard storage is used (e.g., [XEP-0054] or [XEP-0292]). There are no limitations as to the form of that number. For example while it is desirable to maintain a certain consistency between SIP AORs and XMPP JIDs, that is by no means required. It is quite important however that the phone number or SIP AOR stored in the vCard be reachable through the SIP aspect of this CUSAX service. (The same considerations apply even if the directory storage format is not vCard.) Administrators may also choose to include the "video" tel type defined in [RFC6350] for accounts that would be capable of handling video communication. To ensure that the foregoing approach is always respected, service providers might consider (1) preventing clients (and hence users) from modifying the vCard "tel" fields or (2) applying some form of Ivov, et al. Expires February 28, 2014 [Page 7] Internet-Draft Combined Use of SIP and XMPP August 2013 validation before storing changes. Of course such validation would be feasible mostly in cases where a single provider controls both the XMPP and the SIP service since such providers would "know" (e.g., based on use of a common user database for both services) what SIP AOR corresponds to a given XMPP user (as indicated in Figure 2). 3.2. Service Management The task of operating and managing a SIP service or an XMPP service is not always easy. Combining the two into a unified service introduces additional challenges, including: o The necessity of opening additional ports on the client side if SIP functionality is added to an existing XMPP deployment or vice- versa. o The potential for subtle differences in security posture across SIP and XMPP (e.g., SIP servers and XMPP servers might support different TLS ciphersuites). o The need for, ideally, a common authentication backend and other infrastructure that is shared across the SIP and XMPP aspects of the combined service. o Coordinated monitoring and logging of the SIP and XMPP servers to enable the correlation of incidents and the pinpointing of problems. o The difficulty of troubleshooting client-side issues, e.g. if the client loses connectivity for XMPP but maintains its SIP connection. Although separation of functionality (SIP for media, XMPP for IM and presence) can help to ease the operational burden to some extent, service providers are urged to address the foregoing challenges and similar issues when preparing to launch a CUSAX service. 3.3. Client-Side Discovery and Usability Ivov, et al. Expires February 28, 2014 [Page 8] Internet-Draft Combined Use of SIP and XMPP August 2013 When rendering the roster for a particular XMPP account CUSAX clients should make sure that users are presented with a "Call" option for each roster entry that has a properly set "tel" field. This is the case even if calling features have been disabled for that particular XMPP account, as advised by this document. The usefulness of such a feature is not limited to CUSAX. After all, numbers are entered in vCards or stored in directories in order to be dialed and called. Hence, as long as an XMPP client has any means of conducting a call it may wish to make it possible for the user to easily dial any numbers that it learned through whatever means. Clients that have separate triggers (e.g., buttons) for audio calls and video calls may choose to use the presence or absence of the "video" tel type defined in [RFC6350] as the basis for choosing whether to enable or disable the possibility for starting video calls (i.e., if there is no "video" tel type for a particular contact, do not provide a way for the user to start a video call with that contact). In addition to discovering phone numbers from vCards or user directories, clients may also check for alternative communication methods as advertised in XMPP presence broadcasts and Personal Eventing Protocol nodes as described in XEP-0152: Reachability Addresses [XEP-0152]. However, these indications are merely hints, and a receiving client ought not associate a SIP address and an XMPP address unless it has some way to verify the association (e.g., the vCard of the XMPP account lists the SIP address and the vCard of the SIP account lists the XMPP address, or the association is made explicit in a record provided by a trusted directory). Alternatively or in cases where vCard or directory data is not available, a CUSAX client could take the user's own address book as the canonical source for contact addresses. 3.4. Indicating a Relation Between SIP and XMPP Accounts In order to improve usability, in cases where clients are provisioned with only a single telephony-capable account they ought to initiate calls immediately upon user request without asking users to indicate an account that the call should go through. This way CUSAX users (whose only account with calling capabilities is usually the SIP part of their service) would have a better experience, since from the user's perspective calls "just work at the click of a button". In some cases however, clients will be configured with more than the two XMPP and SIP accounts provisioned by the CUSAX provider. Users are likely to add additional stand-alone XMPP or SIP accounts (or accounts for other communications protocols), any of which might have both telephony and instant messaging capabilities. Such situations Ivov, et al. Expires February 28, 2014 [Page 9] Internet-Draft Combined Use of SIP and XMPP August 2013 can introduce additional ambiguity since all of the telephony-capable accounts could be used for calling the numbers the client has learned from vCards or directories. To avoid such confusion, client implementers and CUSAX service providers may choose to indicate the existence of a special relationship between the SIP and XMPP accounts of a CUSAX service. For example, let's say that Alice's service provider has opened both an XMPP account and a SIP account for her. During or after provisioning, her client could indicate that alice@xmpp.example.com has a CUSAX relation to alice@sip.example.com (i.e., that they are two aspects of the same service). This way whenever Alice triggers a call to a contact in her XMPP roster, the client would preferentially initiate this call through her example.com SIP account even if other possibilities exist (such as the XMPP account where the vCard was obtained or a SIP account with another provider). If, on the other hand, no relationship has been configured or discovered between a SIP account and an XMPP account, and the client is aware of multiple telephony-capable accounts, it ought to present the user with the choice of reaching the contact through any of those accounts. This includes the source XMPP account where the vCard was obtained (in case its telephony capabilities are not disabled through configuration or provisioning), in order to guarantee proper operation for XMPP accounts that are not part of a CUSAX deployment. 3.5. Matching Incoming SIP Calls to XMPP JIDs When receiving SIP calls, clients may wish to determine the identity of the caller and a corresponding XMPP roster entry so that users could revert to chatting or other forms of communication that require XMPP. To do so clients could search their roster for an entry whose vCard has a "tel" field matching the originator of the call. In addition, in order to avoid the effort of iterating over an entire roster and retrieving all vCards, CUSAX clients may use a SIP Call- Info header whose 'purpose' header field parameter has a value of "impp" as described in [RFC6993]. An example follows. Call-Info: ;purpose=impp Ivov, et al. Expires February 28, 2014 [Page 10] Internet-Draft Combined Use of SIP and XMPP August 2013 Note that the information from the Call-Info header should only be used as a cue: the actual AOR-to-JID binding would still need to be confirmed by a vCard entry or through some other trusted means (such as an enterprise directory). If this confirmation succeeds the client would not need to search the entire roster and retrieve all vCards. Not performing the check might enable any caller (including malicious ones) to employ someone else's identity and perform various scams or Man-in-the-Middle attacks. However, although an AOR-to-JID binding can be a helpful hint to the user, nothing in the foregoing paragraph ought to be construed as necessarily discouraging users, clients, or service providers from accepting calls originated by entities that are not established contacts of the user (e.g., as reflected in the user's roster); that is a policy matter for the user, client, or service provider. 4. Multi-Party Interactions CUSAX clients that support the SIP conferencing framework [RFC4353] can detect when a call they are participating in is actually a conference and can then subscribe for conference state updates as per [RFC4575]. A regular SIP user agent would also use the same conference URI for text communication with the Message Session Relay Protocol (MSRP). However, given that SIP's instant messaging capabilities would normally be disabled (or simply not supported) in CUSAX deployments, an XMPP Multi-User Chat (MUC) [XEP-0045] associated with the conference can be announced/discovered through bearing the "grouptextchat" purpose [I-D.ivov-grouptextchat-purpose]. Similarly, an XMPP MUC can advertise the SIP URI of an associated service for audio/video interactions using the 'audio-video-uri' field of the "muc#roominfo" data form [XEP-0004] to include extended information [XEP-0128] about the MUC room within XMPP service discovery [XEP-0030]; see [XEP-0045] for an example. Once a CUSAX client joins the MUC associated with a particular call it should not rely on any synchronization between the two. Both the SIP conference and the XMPP MUC would function independently, each issuing and delivering its own state updates. It is hence possible that that certain peers would temporarily or permanently be reachable in only one of the two conferences. This would typically be the case with single-stack clients that have only joined the SIP call or the XMPP MUC. It is therefore important for CUSAX clients to provide a clear indication to users as to the level of participation of the various participants. In other words, a user needs to be able to easily understand whether a certain participant can receive text messages, audio/video, or both. Ivov, et al. Expires February 28, 2014 [Page 11] Internet-Draft Combined Use of SIP and XMPP August 2013 Of course, tighter integration between the XMPP MUC and the SIP conference is also possible. Permissions, roles, kicks and bans that are granted and performed in the MUC can easily be imitated by the conference focus/mixer into the SIP call. If for example, a certain MUC member is muted, the conference mixer can choose to also apply the mute on the media stream corresponding to that participant. The details and exact level of such integration is of course entirely up to implementers and service providers. The approach above describes one relatively lightweight possibility of combining SIP and XMPP multi-party interaction semantics without requiring tight integration between the two. As with the rest of this specification, this approach is by no means normative. Implementation and future specifications may define other methods or provide other suggestions for improving the Unified Communications user experience in cases of multi-user chats in conference calling. 5. Federation In theory there are no technical reasons why federation would require special behavior from CUSAX clients. However, it is worth noting that differences in administration policies may sometimes lead to potentially confusing user experiences. For example, let's say atlanta.example.com observes the CUSAX policies described in this specification. All XMPP users at atlanta.example.com are hence configured to have vCards that match their SIP identities. Alice is therefore used to making free, high- quality SIP calls to all the people in her roster. Alice can also make calls to the PSTN by simply dialing numbers. She may even be used to these calls being billed to her online account so she would be careful about how long they last. This is not a problem for her since she can easily distinguish between a free SIP call (one that she made by calling one her roster entries) from a paid PSTN call that she dialed as a number. Then Alice adds xmpp:bob@biloxi.example.com. The Biloxi domain only has an XMPP service. There is no SIP server and Bob uses a regular, XMPP-only client. Bob has however added his mobile number to his vCard in order to make it easily accessible to his contacts. Alice's client would pick up this number and make it possible for Alice to start a call to Bob's mobile phone number. This could be a problem because, other than the fact that Bob's address is from a different domain, Alice would have no obvious and straightforward cues telling her that this is in fact a call to the PSTN. In addition to the potentially lower audio quality, Alice may also end up incurring unexpected charges for such calls. Ivov, et al. Expires February 28, 2014 [Page 12] Internet-Draft Combined Use of SIP and XMPP August 2013 In order to avoid such issues, providers maintaining a CUSAX service for the users in their domain may choose to provide additional cues (e.g., a user interface warning or an an audio tone or message) indicating that a call would incur charges. A slightly less disturbing scenario, where a SIP service might only allow communication with intra-domain numbers, would simply prevent Alice from establishing a call with Bob's mobile. Providers should hence make sure that calls to inter-domain numbers are flagged with an appropriate audio or textual warning. 6. Summary of Suggested Practices The following practices are suggested for CUSAX user agents: 1. By default, prefer SIP for audio and video, and XMPP for messaging and presence. 2. Use XMPP for all forms of communication with the contacts from the XMPP roster, with the exception of features that are based on establishing real-time sessions (e.g. audio/video calls) in which case use SIP. 3. Provide on-line provisioning options for providers to remotely setup SIP and XMPP accounts so that users wouldn't need to go through a multi-step configuration process. 4. Provide on-line provisioning options for providers to completely disable features for an account associated with a given protocol (SIP or XMPP) if the features are preferred in another protocol (XMPP or SIP). 5. Present a "Call" option for each roster entry that has a properly set "tel" field. 6. If the client is provisioned with only a single telephony- capable account, initiate calls immediately upon user request without asking users to indicate an account that the call should go through. 7. If no relationship has been configured or discovered between a SIP account and an XMPP account, and the client is aware of multiple telephony-capable accounts, present the user with the choice of reaching the contact through any of those accounts. 8. Optionally, indicate the existence of a special relationship between the SIP and XMPP accounts of a CUSAX service. Ivov, et al. Expires February 28, 2014 [Page 13] Internet-Draft Combined Use of SIP and XMPP August 2013 9. Optionally, present the XMPP connection as an "instant messaging" or a "chat" account and the SIP connection as a "Voice and Video" or a "Telephony" acccount. 10. Optionally, determine the identity of the audio/video caller and a corresponding XMPP roster entry so that the user could revert to textual chatting or other forms of communication that require XMPP. 11. Optionally, delay the XMPP connection until after a SIP connection has been successfully registered. 12. Optionally, check for alternative communication methods (SIP addresses advertised over XMPP, and XMPP addresses advertised over SIP). The following practices are suggested for CUSAX services: 1. Use online provisioning and configuration of accounts so that users won't need to setup two separate accounts for your service. 2. Use online provisioning so that calling features are disabled for all XMPP accounts. 3. Ensure that at least one of the vCard "tel" fields for each XMPP user is properly populated with a SIP URI or a phone number that are reachable through your SIP service. 4. Optionally, include the "video" tel type for accounts that are capable of handling video communication. 5. Optionally, provision clients with information indicating that specific SIP and XMPP accounts are related in a CUSAX service. 6. Optionally, attach a "Call-Info" header with an "impp" purpose to all your SIP INVITE messages, so that clients can more rapidly associate a caller with a roster entry and display a "Caller ID". 7. Security Considerations Use of the same user agent with two different accounts providing complementary features introduces the possibility of mismatches between the security profiles of those accounts or features. Two security mismatches of particular concern are: o The SIP aspect and XMPP aspect of a CUSAX service might offer different authentication options (e.g., digest authentication for SIP as specified in [RFC3261] and SCRAM authentication [RFC5802] Ivov, et al. Expires February 28, 2014 [Page 14] Internet-Draft Combined Use of SIP and XMPP August 2013 for XMPP as specified in [RFC6120]). Because SIP uses a password- based method (digest) and XMPP uses a pluggable framework for authentication via the Simple Authentication and Security Layer (SASL) technology [RFC4422], it is also possible that the XMPP connection could be authenticated using a password-free method such as client certificates with SASL EXTERNAL even though a username and password is used for the SIP connection. o The Transport Layer Security (TLS) [RFC5246] ciphersuites offered or negotiated on the XMPP side might be different from those on the SIP side because of implementation or configuration differences between the SIP server and the XMPP server. Even more seriously, a CUSAX client might successfully negotiate TLS when connecting to the XMPP aspect of the service but not when connecting to the SIP aspect, or vice-versa. In this situation an end user might think that the combined CUSAX session with the service is protected by TLS, even though only one aspect is protected. Security mismatches such as these (as well as others related to end- to-end encryption of messages or media) introduce the possibility of downgrade attacks, eavesdropping, information leakage, and other security vulnerabilities. User agent developers and service providers must ensure that such mismatches are avoided as much as possible (e.g., by enforcing common and strong security configurations and policies across protocols). Specifically, if both protocols are not safeguarded by similar levels of cryptographic protection, the user must be informed of that fact and given the opportunity to bring both up to the same level. Section 5 discusses potential issues that may arise due to a mismatch between client capabilities, such as calls being initiated with costs contrary to the expectation of the end user. Such issues could be triggered maliciously, as well as by accident. Implementers therefore need to provide necessary cues to raise user awareness as suggested in Section 5. Refer to the specifications for the relevant SIP and XMPP features for detailed security considerations applying to each "stack" in a CUSAX client. 8. IANA Considerations This document has no actions for the IANA. 9. Informative References [I-D.ietf-appsawg-webfinger] Ivov, et al. Expires February 28, 2014 [Page 15] Internet-Draft Combined Use of SIP and XMPP August 2013 Jones, P., Salgueiro, G., and J. Smarr, "WebFinger", draft-ietf-appsawg-webfinger-17 (work in progress), August 2013. [I-D.ivov-grouptextchat-purpose] Ivov, E., "A Group Text Chat Purpose for Conference and Service URIs in the Session Initiation Protocol (SIP) Event Package for Conference State ", draft-ivov- grouptextchat-purpose-03 (work in progress), June 2013. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006. [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006. [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007. [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011. [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, March 2011. [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, August 2011. Ivov, et al. Expires February 28, 2014 [Page 16] Internet-Draft Combined Use of SIP and XMPP August 2013 [RFC6993] Saint-Andre, P., "Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP)", RFC 6993, July 2013. [XEP-0004] Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007. [XEP-0030] Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- Andre, "Service Discovery", XSF XEP 0030, June 2008. [XEP-0045] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 2012. [XEP-0054] Saint-Andre, P., "vcard-temp", XSF XEP 0054, July 2008. [XEP-0128] Saint-Andre, P., "Service Discovery Extensions", XSF XEP 0128, October 2004. [XEP-0152] Hildebrand, J. and P. Saint-Andre, "XEP-0152: Reachability Addresses", XEP XEP-0152, February 2013. [XEP-0292] Saint-Andre, P. and S. Mizzi, "vCard4 Over XMPP", XSF XEP 0292, October 2011. Appendix A. Acknowledgements This draft is inspired by the "SIXPAC" work of Markus Isomaki and Simo Veikkolainen. Markus also provided various suggestions for improving the document. The authors would also like to thank the following people for their reviews and suggestions: Sebastien Couture, Dan-Christian Bogos, Richard Brady, Olivier Crete, Aaron Evans, Kevin Gallagher, Adrian Georgescu, Saul Ibarra Corretge, David Laban, Gergely Lukacsy, Murray Mar, Daniel Pocock, Travis Reitter, and Gonzalo Salgueiro. Brian Carpenter, Ted Hardie, Paul Hoffman, and Benson Schliesser reviewed the document on behalf of the General Area Review Team, the Applications Area Directorate, the Security Directorate, and the Operations and Management Directorate, respectively. Ivov, et al. Expires February 28, 2014 [Page 17] Internet-Draft Combined Use of SIP and XMPP August 2013 Authors' Addresses Emil Ivov Jitsi Strasbourg 67000 France Phone: +33-177-624-330 Email: emcho@jitsi.org Peter Saint-Andre Cisco Systems, Inc. 1899 Wynkoop Street, Suite 600 Denver, CO 80202 USA Phone: +1-303-308-3282 Email: psaintan@cisco.com Enrico Marocco Telecom Italia Via G. Reiss Romoli, 274 Turin 10148 Italy Email: enrico.marocco@telecomitalia.it Ivov, et al. Expires February 28, 2014 [Page 18]