idnits 2.17.1 draft-ivov-xmpp-cusax-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 29, 2013) is 3863 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-ivov-grouptextchat-purpose-03 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Ivov 3 Internet-Draft Jitsi 4 Intended status: Informational P. Saint-Andre 5 Expires: April 02, 2014 Cisco Systems, Inc. 6 E. Marocco 7 Telecom Italia 8 September 29, 2013 10 CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the 11 Extensible Messaging and Presence Protocol (XMPP) 12 draft-ivov-xmpp-cusax-08 14 Abstract 16 This document suggests some strategies for the combined use of the 17 Session Initiation Protocol (SIP) and the Extensible Messaging and 18 Presence Protocol (XMPP). Such strategies aim to provide a single 19 fully featured real-time communication service by using complementary 20 subsets of features from each of the protocols. Typically such 21 subsets would include telephony capabilities from SIP and instant 22 messaging and presence capabilities from XMPP. This document does 23 not define any new protocols or syntax for either SIP or XMPP, and by 24 intent it does not attempt to standardize "best current practices". 25 However, implementing the suggested strategies outlined in this 26 document may require modifying or at least reconfiguring existing 27 client and server-side software. Also, it is not the purpose of this 28 document to make recommendations as to whether or not such combined 29 use should be preferred to the mechanisms provided natively by each 30 protocol (for example, SIP's SIMPLE or XMPP's Jingle. It merely aims 31 to provide guidance to those who are interested in such a combined 32 use. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 02, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Client Bootstrap . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.1. Server-Side Setup . . . . . . . . . . . . . . . . . . . . 7 71 3.2. Service Management . . . . . . . . . . . . . . . . . . . 7 72 3.3. Client-Side Discovery and Usability . . . . . . . . . . . 8 73 3.4. Indicating a Relation Between SIP and XMPP Accounts . . . 9 74 3.5. Matching Incoming SIP Calls to XMPP JIDs . . . . . . . . 10 75 4. Multi-Party Interactions . . . . . . . . . . . . . . . . . . 11 76 5. Federation . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 6. Summary of Suggested Strategies . . . . . . . . . . . . . . . 13 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 82 9.2. Informative References . . . . . . . . . . . . . . . . . 16 83 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 86 1. Introduction 88 Historically SIP [RFC3261] and XMPP [RFC6120] have often been 89 implemented and deployed with different purposes: from its very start 90 SIP's primary goal has been to provide a means of conducting 91 "Internet telephone calls". XMPP on the other hand, has, from its 92 Jabber days, been mostly used for instant messaging and presence 93 [RFC6121], as well as related services such as groupchat rooms 94 [XEP-0045]. 96 For various reasons, these trends have continued through the years 97 even after each of the protocols had been equipped to provide the 98 features it was initially lacking: 100 o In the context of the SIMPLE working group, the IETF has defined a 101 number of protocols and protocol extensions that not only allow 102 for SIP to be used for regular instant messaging and presence but 103 that also provide mechanisms for elaborated features such as 104 multi-party chat, server-stored contact lists, and file transfer 105 [RFC6914]. 107 o Similarly, the XMPP community and the XMPP Standards Foundation 108 have worked on defining a number of XMPP Extension Protocols 109 (XEPs) that provide XMPP implementations with the means of 110 establishing end-to-end sessions. These extensions are often 111 jointly referred to as Jingle [XEP-0166] and arguably their most 112 popular use case is audio and video calling [XEP-0167]. 114 Although SIP has been extended for messaging and presence and XMPP 115 has been extended for voice and video, the reality is that SIP 116 remains the protocol of choice for telephony-like services and XMPP 117 remains the protocol of choice for IM and presence services. As a 118 result, a number of adopters have found themselves needing features 119 that are not offered by any single-protocol solution, but that 120 separately exist in SIP and XMPP implementations. The idea of 121 seamlessly using both protocols together would hence often appeal to 122 service providers and users. Most often, such a service would employ 123 SIP exclusively for audio, video, and telephony services and rely on 124 XMPP for anything else varying from chat, contact list management, 125 and presence to whiteboarding and exchanging files. Because these 126 services and clients involve the combined use of SIP and XMPP, we 127 label them "CUSAX" for short. 129 +------------+ +-------------+ 130 | SIP Server | | XMPP Server | 131 +------------+ +-------------+ 132 \ / 133 media \ / instant messaging, 134 signaling \ / presence, etc. 135 \ / 136 +--------------+ 137 | CUSAX Client | 138 +--------------+ 140 Figure 1: Division of Responsibilities 142 This document explains how such hybrid offerings can be achieved with 143 a minimum of modifications to existing software while providing an 144 optimal user experience. It covers server discovery, determining a 145 SIP Address of Record (AOR) while using XMPP, and determining an XMPP 146 Jabber Identifier ("JID") from incoming SIP requests. Most of the 147 text here pertains to client behavior but it also suggests certain 148 server-side configurations and operational strategies. The document 149 also discusses significant security considerations that can arise 150 when offering a dual-protocol solution, and provides advice for 151 avoiding security mismatches that would result in degraded 152 communications security for end users. 154 Note that this document is focused on coexistence of SIP and XMPP 155 functionality in end-user-oriented clients. By intent it does not 156 define methods for protocol-level mapping between SIP and XMPP, as 157 might be used within a server-side gateway between a SIP network and 158 an XMPP network (a separate series of documents has been produced 159 that defines such mappings). More generally, this document does not 160 describe service policies for inter-domain communication (often 161 called "federation") between service providers (e.g., how a service 162 provider that offers a combined SIP-XMPP service might communicate 163 with a SIP-only or XMPP-only service), nor does it describe the 164 reasons why a service provider might choose SIP or XMPP for various 165 features. 167 This document concentrates on use cases where the SIP services and 168 XMPP services are controlled by one and the same provider, since that 169 assumption greatly simplifies both client implementation and server- 170 side deployment (e.g., a single service provider can enforce common 171 or coordinated policies across both the SIP and XMPP aspects of a 172 CUSAX service, which is not possible if a SIP service is offered by 173 one provider and an XMPP service is offered by another). Since this 174 document is of an informational nature, it is not unreasonable for 175 clients to apply some of the guidelines here even in cases where 176 there is no established relationship between the SIP and the XMPP 177 services (for example, it is reasonable for a client to provide a way 178 for its users to easily start a call to a phone number recorded in a 179 vCard or obtained from a user directory). However, the rules to 180 follow in such cases are left to application developers (although 181 they might be described in a future document). 183 This document makes a further simplifying assumption by discussing 184 only the use of a single client, not use of and coordination among 185 multiple endpoints controlled by the same user (e.g., user agents 186 running simultaneously on a laptop computer, tablet, and mobile 187 phone). Although user agents running on separate endpoints might 188 themselves be CUSAX clients or might engage in different aspects of 189 an interaction (e.g., a user might employ her mobile phone for audio 190 and her tablet for video and text chat), such usage complicates the 191 guidelines for developers of user agents and therefore is left as a 192 matter of implementation for now. 194 It is important to note that this document does not attempt to 195 standardize "best current practices" in the sense defined in 196 [RFC2026]. Instead, it collects together informational documentation 197 about some strategies that might prove helpful to those who implement 198 and deploy combined SIP-XMPP software and services. With sufficient 199 use and appropriate modification to incorporate the lessons of 200 experience, these strategies might someday form the basis for 201 standardization of best current practices. 203 2. Client Bootstrap 205 One of the main problems of using two distinct protocols when 206 providing one service is the impact on usability. Email services, 207 for example, have long been affected by the mixed use of SMTP for 208 outgoing mail and POP3 or IMAP for incoming mail. Although standard 209 service discovery methods (such as the proper DNS records) make it 210 possible for a user agent to locate the right host(s) at which to 211 connect, they do not provide the kind of detailed information that is 212 needed to actually configure the user agent for use with the service. 213 As a result, it is rather complicated for inexperienced users to 214 configure a mail client and start using it with a new service, and 215 Internet service providers often need to provide configuration 216 instructions for various mail clients. Client developers and 217 communication device manufacturers on the other hand often ship with 218 a number of wizards that enable users to easily set up a new account 219 for a number of popular email services. While this may improve the 220 situation to some extent, the user experience is still clearly sub- 221 optimal. 223 While it should be possible for CUSAX users to manually configure 224 their separate SIP and XMPP accounts (often by means of so-called 225 "wizard" interfaces), service providers offering CUSAX services to 226 users of dual-stack SIP/XMPP clients ought to provide means of online 227 provisioning, typically by means of a web-based service at an HTTP 228 URI (naturally single-purpose SIP services or XMPP services could 229 offer online provisioning as well, but they can be especially helpful 230 where the two aspects of the CUSAX service need to have several 231 configuration options in common). Although the specifics of such 232 mechanisms are outside the scope of this document, they should make 233 it possible for a service provider to remotely configure the clients 234 based on minimal user input (e.g., only a user ID and password). As 235 far as the authors are aware, no open protocol for endpoint 236 configuration is yet available and adopted; however, application 237 developers are encouraged to explore the potential for future 238 progress in that space (e.g., perhaps based on technologies such as 239 WebFinger [I-D.ietf-appsawg-webfinger]). 241 A CUSAX client should make it possible for a user to configure the 242 software so that a given feature (say, video conferencing or textual 243 chat) to use by default a given protocol (say, SIP for video 244 conferencing and XMPP for textual chat). In particular, it is 245 suggested that CUSAX clients allow for audio and video calling 246 features to be disabled over XMPP, and for instant messaging and 247 presence features to be disabled over SIP. It is a matter of 248 implementation whether a CUSAX client enables a user to override such 249 defaults in various ways (e.g., by domain, by individual contact, or 250 by device). 252 The main advantage of this approach is that clients would be able to 253 continue to function properly and use the complete feature set of 254 standalone SIP and XMPP accounts. 256 Once clients have been provisioned, they need to independently log 257 into the SIP and XMPP accounts that make up the CUSAX "service" and 258 then maintain both these connections. 260 In order to improve the user experience, when reporting connection 261 status clients may also wish to present the XMPP connection as an 262 "instant messaging" or a "chat" account. Similarly they could also 263 depict the SIP connection as a "Voice and Video" or a "Telephony" 264 connection. The exact naming is of course entirely up to 265 implementers. The point is that, in cases where SIP and XMPP are 266 components of a service offered by a single provider, such 267 presentation could help users better understand why they are being 268 shown two different connections for what they perceive as a single 269 service. It could alleviate especially situations where one of these 270 connections is disrupted while the other one is still active. 271 Naturally, the developers of a CUSAX client or the providers of a 272 CUSAX service might decide not to accept such situations and force a 273 client to completely disconnect unless both aspects are successfully 274 connected. 276 Clients may also choose to delay their XMPP connection until they 277 have been successfully registered on SIP. This would help avoid the 278 situation where a user appears online to its contacts but calling it 279 would fail because their clients is still connecting to the SIP 280 aspect of their CUSAX service. 282 3. Operation 284 Once a CUSAX client has been provisioned and authorized to connect to 285 the corresponding SIP and XMPP services it would proceed by 286 retrieving its XMPP roster. 288 The client should use XMPP for all forms of communication with the 289 contacts from this roster, which will occur naturally because they 290 were retrieved through XMPP. Audio/video features however, would 291 typically be disabled in the XMPP stack, so any form of communication 292 based on these features (e.g. direct calls, conferences, desktop 293 streaming, etc.) would happen over SIP. The rest of this section 294 describes deployment, discovery, usability and linking semantics that 295 allow CUSAX clients to fall back and seamlessly use SIP for these 296 features. 298 3.1. Server-Side Setup 300 In order for CUSAX to function properly, XMPP service administrators 301 should make sure that at least one of the vCard [RFC6350] "tel" 302 fields for each contact is properly populated with a SIP URI or a 303 phone number when an XMPP protocol for vCard storage is used (e.g., 304 [XEP-0054] or [XEP-0292]). There are no limitations as to the form 305 of that number. For example while it is desirable to maintain a 306 certain consistency between SIP AORs and XMPP JIDs, that is by no 307 means required. It is quite important however that the phone number 308 or SIP AOR stored in the vCard be reachable through the SIP aspect of 309 this CUSAX service. (The same considerations apply even if the 310 directory storage format is not vCard.) 312 Administrators may also choose to include the "video" tel type 313 defined in [RFC6350] for accounts that would be capable of handling 314 video communication. 316 To ensure that the foregoing approach is always respected, service 317 providers might consider validating the values of vCard "tel" fields 318 before storing changes. Of course such validation would be feasible 319 mostly in cases where a single provider controls both the XMPP and 320 the SIP service since such providers would "know" (e.g., based on use 321 of a common user database for both services) what SIP AOR corresponds 322 to a given XMPP user. 324 3.2. Service Management 325 The task of operating and managing a SIP service or an XMPP service 326 is not always easy. Combining the two into a unified service 327 introduces additional challenges, including: 329 o The necessity of opening additional ports on the client side if 330 SIP functionality is added to an existing XMPP deployment or vice- 331 versa. 333 o The potential for subtle differences in security posture across 334 SIP and XMPP (e.g., SIP servers and XMPP servers might support 335 different TLS ciphersuites). 337 o The need for, ideally, a common authentication backend and other 338 infrastructure that is shared across the SIP and XMPP aspects of 339 the combined service. 341 o Coordinated monitoring and logging of the SIP and XMPP servers to 342 enable the correlation of incidents and the pinpointing of 343 problems. 345 o The difficulty of troubleshooting client-side issues, e.g. if the 346 client loses connectivity for XMPP but maintains its SIP 347 connection. 349 Although separation of functionality (SIP for media, XMPP for IM and 350 presence) can help to ease the operational burden to some extent, 351 service providers are urged to address the foregoing challenges and 352 similar issues when preparing to launch a CUSAX service. 354 Beyond the issues listed above, service providers might want to be 355 aware of more subtle operational issues that can arise. For example, 356 if a service provider uses different network operators for the SIP 357 service and the XMPP service, end-to-end connectivity might be more 358 reliable or consistent in one service than in the other service. 359 Similar issues can arise when the media path and the signaling path 360 go over different networks, even in standalone SIP or XMPP services. 361 Providers of CUSAX services are advised to consider the potential for 362 such topologies to cause operational challenges. 364 3.3. Client-Side Discovery and Usability 366 When rendering the roster for a particular XMPP account CUSAX clients 367 should make sure that users are presented with a "Call" option for 368 each roster entry that has a properly set "tel" field. This is the 369 case even if calling features have been disabled for that particular 370 XMPP account, as advised by this document. The usefulness of such a 371 feature is not limited to CUSAX. After all, numbers are entered in 372 vCards or stored in directories in order to be dialed and called. 374 Hence, as long as an XMPP client has any means of conducting a call 375 it may wish to make it possible for the user to easily dial any 376 numbers that it learned through whatever means. 378 Clients that have separate triggers (e.g., buttons) for audio calls 379 and video calls may choose to use the presence or absence of the 380 "video" tel type defined in [RFC6350] as the basis for choosing 381 whether to enable or disable the possibility for starting video calls 382 (i.e., if there is no "video" tel type for a particular contact, do 383 not provide a way for the user to start a video call with that 384 contact). 386 In addition to discovering phone numbers from vCards or user 387 directories, clients may also check for alternative communication 388 methods as advertised in XMPP presence broadcasts and Personal 389 Eventing Protocol nodes as described in XEP-0152: Reachability 390 Addresses [XEP-0152]. However, these indications are merely hints, 391 and a receiving client ought not associate a SIP address and an XMPP 392 address unless it has some way to verify the association (e.g., the 393 vCard of the XMPP account lists the SIP address and the vCard of the 394 SIP account lists the XMPP address, or the association is made 395 explicit in a record provided by a trusted directory). Alternatively 396 or in cases where vCard or directory data is not available, a CUSAX 397 client could take the user's own address book as the canonical source 398 for contact addresses. 400 3.4. Indicating a Relation Between SIP and XMPP Accounts 402 In order to improve usability, in cases where clients are provisioned 403 with only a single telephony-capable account they ought to initiate 404 calls immediately upon user request without asking users to indicate 405 an account that the call should go through. This way CUSAX users 406 (whose only account with calling capabilities is usually the SIP part 407 of their service) would have a better experience, since from the 408 user's perspective calls "just work at the click of a button". 410 In some cases however, clients will be configured with more than the 411 two XMPP and SIP accounts provisioned by the CUSAX provider. Users 412 are likely to add additional stand-alone XMPP or SIP accounts (or 413 accounts for other communications protocols), any of which might have 414 both telephony and instant messaging capabilities. Such situations 415 can introduce additional ambiguity since all of the telephony-capable 416 accounts could be used for calling the numbers the client has learned 417 from vCards or directories. 419 To avoid such confusion, client implementers and CUSAX service 420 providers may choose to indicate the existence of a special 421 relationship between the SIP and XMPP accounts of a CUSAX service. 423 For example, let's say that Alice's service provider has opened both 424 an XMPP account and a SIP account for her. During or after 425 provisioning, her client could indicate that alice@xmpp.example.com 426 has a CUSAX relation to alice@sip.example.com (i.e., that they are 427 two aspects of the same service). This way whenever Alice triggers a 428 call to a contact in her XMPP roster, the client would preferentially 429 initiate this call through her example.com SIP account even if other 430 possibilities exist (such as the XMPP account where the vCard was 431 obtained or a SIP account with another provider). 433 If, on the other hand, no relationship has been configured or 434 discovered between a SIP account and an XMPP account, and the client 435 is aware of multiple telephony-capable accounts, it ought to present 436 the user with the option of using XMPP Jingle as one method for 437 engaging in audio and video interactions with a contact who has an 438 XMPP address. This can help to ensure complete audio and video calls 439 with XMPP users who are not part of a CUSAX deployment. 441 3.5. Matching Incoming SIP Calls to XMPP JIDs 443 When receiving a SIP call, a CUSAX client may wish to determine the 444 identity of the caller and a corresponding XMPP roster entry so that 445 the receiving user could revert to chatting or other forms of 446 communication that require XMPP. To do so, a CUSAX client could 447 search the user's roster for an entry whose vCard has a "tel" field 448 matching the originator of the call. In addition, in order to avoid 449 the effort of iterating over the entire roster of the user and 450 retrieving vCards for all of the user's contacts, the receiving 451 client may guess at the identity of the caller based a SIP Call-Info 452 header whose 'purpose' header field parameter has a value of "impp" 453 as described in [RFC6993]. To enable this usage, a sending client 454 would need to include such a Call-Info header in the SIP messages 455 that it sends when initiating a call. An example follows. 457 Call-Info: ;purpose=impp 459 Note that the information from the Call-Info header should only be 460 used as a cue: the actual AOR-to-JID binding would still need to be 461 confirmed by the vCard of a contact in the receiving user's roster or 462 through some other trusted means (such as an enterprise directory). 463 If this confirmation succeeds the client would not need to search the 464 entire roster and retrieve all vCards. Not performing the check 465 might enable any caller (including malicious ones) to employ someone 466 else's identity and perform various scams or Man-in-the-Middle 467 attacks. 469 However, although an AOR-to-JID binding can be a helpful hint to the 470 user, nothing in the foregoing paragraph ought to be construed as 471 necessarily discouraging users, clients, or service providers from 472 accepting calls originated by entities that are not established 473 contacts of the user (e.g., as reflected in the user's roster); that 474 is a policy matter for the user, client, or service provider. 476 4. Multi-Party Interactions 478 CUSAX clients that support the SIP conferencing framework [RFC4353] 479 can detect when a call they are participating in is actually a 480 conference and can then subscribe for conference state updates as per 481 [RFC4575]. A regular SIP user agent would also use the same 482 conference URI for text communication with the Message Session Relay 483 Protocol (MSRP). However, given that SIP's instant messaging 484 capabilities would normally be disabled (or simply not supported) in 485 CUSAX deployments, an XMPP Multi-User Chat (MUC) [XEP-0045] 486 associated with the conference can be announced/discovered through 487 bearing the "grouptextchat" purpose 488 [I-D.ivov-grouptextchat-purpose]. Similarly, an XMPP MUC can 489 advertise the SIP URI of an associated service for audio/video 490 interactions using the 'audio-video-uri' field of the "muc#roominfo" 491 data form [XEP-0004] to include extended information [XEP-0128] about 492 the MUC room within XMPP service discovery [XEP-0030]; see [XEP-0045] 493 for an example. These methods would enable a CUSAX-aware SIP 494 conference server to advertise the existence of an associated XMPP 495 chatroom, and for a CUSAX-aware XMPP chatroom to advertise the 496 existence of an associated SIP conference server. 498 Once a CUSAX client joins the MUC associated with a particular call 499 it should not rely on any synchronization between the two. Both the 500 SIP conference and the XMPP MUC would function independently, each 501 issuing and delivering its own state updates. It is hence possible 502 that that certain peers would temporarily or permanently be reachable 503 in only one of the two conferences. This would typically be the case 504 with single-stack clients that have only joined the SIP call or the 505 XMPP MUC. It is therefore important for CUSAX clients to provide a 506 clear indication to users as to the level of participation of the 507 various participants. In other words, a user needs to be able to 508 easily understand whether a certain participant can receive text 509 messages, audio/video, or both. 511 At the level of the CUSAX service, it is also possible to enforce 512 tighter integration between the XMPP MUC and the SIP conference. 513 Permissions, roles, kicks and bans that are granted and performed in 514 the MUC can easily be imitated by the conference focus/mixer into the 515 SIP call. If, for example, a certain MUC member is muted, the 516 conference mixer can choose to also apply the mute on the media 517 stream corresponding to that participant. The details and exact 518 level of such integration is of course entirely up to implementers 519 and service providers. 521 The approach above describes one relatively lightweight possibility 522 of combining SIP and XMPP multi-party interaction semantics without 523 requiring tight integration between the two. As with the rest of 524 this document, this approach is by no means normative. 525 Implementations and future documents may define other methods or 526 provide other suggestions for improving the Unified Communications 527 user experience in cases of multi-user chats in conference calling. 529 5. Federation 531 In theory there are no technical reasons why federation would require 532 special behavior from CUSAX clients. However, it is worth noting 533 that differences in administration policies may sometimes lead to 534 potentially confusing user experiences. 536 For example, let's say atlanta.example.com observes the CUSAX 537 policies described in this document. All XMPP users at 538 atlanta.example.com are hence configured to have vCards that match 539 their SIP identities. Alice is therefore used to making free, high- 540 quality SIP calls to all the people in her roster. Alice can also 541 make calls to the PSTN by simply dialing numbers. She may even be 542 used to these calls being billed to her online account so she would 543 be careful about how long they last. This is not a problem for her 544 since she can easily distinguish between a free SIP call (one that 545 she made by calling one her roster entries) from a paid PSTN call 546 that she dialed as a number. 548 Then Alice adds xmpp:bob@biloxi.example.com. The Biloxi domain only 549 has an XMPP service. There is no SIP server and Bob uses a regular, 550 XMPP-only client. Bob has however added his mobile number to his 551 vCard in order to make it easily accessible to his contacts. Alice's 552 client would pick up this number and make it possible for Alice to 553 start a call to Bob's mobile phone number. 555 This could be a problem because, other than the fact that Bob's 556 address is from a different domain, Alice would have no obvious and 557 straightforward cues telling her that this is in fact a call to the 558 PSTN. In addition to the potentially lower audio quality, Alice may 559 also end up incurring unexpected charges for such calls. 561 In order to avoid such issues, providers maintaining a CUSAX service 562 for the users in their domain may choose to provide additional cues 563 (e.g., a service-generated signal that triggers a user interface 564 warning in a CUSAX client, an auditory tone, or a spoken message) 565 indicating that a call would incur charges. 567 A slightly less disturbing scenario, where a SIP service might only 568 allow communication with intra-domain numbers, would simply prevent 569 Alice from establishing a call with Bob's mobile. Providers should 570 hence make sure that calls to inter-domain numbers are flagged with 571 an appropriate audio or textual warning. 573 6. Summary of Suggested Strategies 575 The following strategies are suggested for CUSAX user agents: 577 1. By default, prefer SIP for audio and video, and XMPP for 578 messaging and presence. 580 2. Use XMPP for all forms of communication with the contacts from 581 the XMPP roster, with the exception of features that are based 582 on establishing real-time sessions (e.g. audio/video calls) in 583 which case use SIP. 585 3. Provide on-line provisioning options for providers to remotely 586 setup SIP and XMPP accounts so that users wouldn't need to go 587 through a multi-step configuration process. 589 4. Provide on-line provisioning options for providers to completely 590 disable features for an account associated with a given protocol 591 (SIP or XMPP) if the features are preferred in another protocol 592 (XMPP or SIP). 594 5. Present a "Call" option for each roster entry that has a 595 properly set "tel" field. 597 6. If the client is provisioned with only a single telephony- 598 capable account, initiate calls immediately upon user request 599 without asking users to indicate an account that the call should 600 go through. 602 7. If no relationship has been configured or discovered between a 603 SIP account and an XMPP account, and the client is aware of 604 multiple telephony-capable accounts, present the user with the 605 choice of reaching the contact through any of those accounts. 607 8. Optionally, indicate the existence of a special relationship 608 between the SIP and XMPP accounts of a CUSAX service. 610 9. Optionally, present the XMPP connection as an "instant 611 messaging" or a "chat" account and the SIP connection as a 612 "Voice and Video" or a "Telephony" acccount. 614 10. Optionally, determine the identity of the audio/video caller and 615 a corresponding XMPP roster entry so that the user could revert 616 to textual chatting or other forms of communication that require 617 XMPP. 619 11. Optionally, delay the XMPP connection until after a SIP 620 connection has been successfully registered. 622 12. Optionally, check for alternative communication methods (SIP 623 addresses advertised over XMPP, and XMPP addresses advertised 624 over SIP). 626 The following strategies are suggested for CUSAX services: 628 1. Use online provisioning and configuration of accounts so that 629 users won't need to setup two separate accounts for your service. 631 2. Use online provisioning so that calling features are disabled for 632 all XMPP accounts. 634 3. Ensure that at least one of the vCard "tel" fields for each XMPP 635 user is properly populated with a SIP URI or a phone number that 636 are reachable through your SIP service. 638 4. Optionally, include the "video" tel type for accounts that are 639 capable of handling video communication. 641 5. Optionally, provision clients with information indicating that 642 specific SIP and XMPP accounts are related in a CUSAX service. 644 6. Optionally, attach a "Call-Info" header with an "impp" purpose to 645 all your SIP INVITE messages, so that clients can more rapidly 646 associate a caller with a roster entry and display a "Caller ID". 648 7. Security Considerations 650 Use of the same user agent with two different accounts providing 651 complementary features introduces the possibility of mismatches 652 between the security profiles of those accounts or features. Two 653 security mismatches of particular concern are: 655 o The SIP aspect and XMPP aspect of a CUSAX service might offer 656 different authentication options (e.g., digest authentication for 657 SIP as specified in [RFC3261] and SCRAM authentication [RFC5802] 658 for XMPP as specified in [RFC6120]). Because SIP uses a password- 659 based method (digest) and XMPP uses a pluggable framework for 660 authentication via the Simple Authentication and Security Layer 661 (SASL) technology [RFC4422], it is also possible that the XMPP 662 connection could be authenticated using a password-free method 663 such as client certificates with SASL EXTERNAL even though a 664 username and password is used for the SIP connection. 666 o The Transport Layer Security (TLS) [RFC5246] ciphersuites offered 667 or negotiated on the XMPP side might be different from those on 668 the SIP side because of implementation or configuration 669 differences between the SIP server and the XMPP server. Even more 670 seriously, a CUSAX client might successfully negotiate TLS when 671 connecting to the XMPP aspect of the service but not when 672 connecting to the SIP aspect, or vice-versa. In this situation an 673 end user might think that the combined CUSAX session with the 674 service is protected by TLS, even though only one aspect is 675 protected. 677 Security mismatches such as these (as well as others related to end- 678 to-end encryption of messages or media) introduce the possibility of 679 downgrade attacks, eavesdropping, information leakage, and other 680 security vulnerabilities. User agent developers and service 681 providers must ensure that such mismatches are avoided as much as 682 possible (e.g., by enforcing common and strong security 683 configurations and policies across protocols). Specifically, if both 684 protocols are not safeguarded by similar levels of cryptographic 685 protection, the user must be informed of that fact and given the 686 opportunity to bring both up to the same level. 688 Section 5 discusses potential issues that may arise due to a mismatch 689 between client capabilities, such as calls being initiated with costs 690 contrary to the expectation of the end user. Such issues could be 691 triggered maliciously, as well as by accident. Implementers 692 therefore need to provide necessary cues to raise user awareness as 693 suggested in Section 5. 695 Refer to the specifications for the relevant SIP and XMPP features 696 for detailed security considerations applying to each "stack" in a 697 CUSAX client. 699 8. IANA Considerations 701 This document has no actions for the IANA. 703 9. References 704 9.1. Normative References 706 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 707 A., Peterson, J., Sparks, R., Handley, M., and E. 708 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 709 June 2002. 711 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 712 Protocol (XMPP): Core", RFC 6120, March 2011. 714 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 715 Protocol (XMPP): Instant Messaging and Presence", RFC 716 6121, March 2011. 718 9.2. Informative References 720 [I-D.ietf-appsawg-webfinger] 721 Jones, P., Salgueiro, G., Jones, M., and J. Smarr, 722 "WebFinger", draft-ietf-appsawg-webfinger-18 (work in 723 progress), August 2013. 725 [I-D.ivov-grouptextchat-purpose] 726 Ivov, E., "A Group Text Chat Purpose for Conference and 727 Service URIs in the Session Initiation Protocol (SIP) 728 Event Package for Conference State ", draft-ivov- 729 grouptextchat-purpose-03 (work in progress), June 2013. 731 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 732 3", BCP 9, RFC 2026, October 1996. 734 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 735 Session Initiation Protocol (SIP)", RFC 4353, February 736 2006. 738 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 739 Security Layer (SASL)", RFC 4422, June 2006. 741 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 742 Initiation Protocol (SIP) Event Package for Conference 743 State", RFC 4575, August 2006. 745 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 746 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 748 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 749 "Salted Challenge Response Authentication Mechanism 750 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 752 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 753 August 2011. 755 [RFC6914] Rosenberg, J., "SIMPLE Made Simple: An Overview of the 756 IETF Specifications for Instant Messaging and Presence 757 Using the Session Initiation Protocol (SIP)", RFC 6914, 758 April 2013. 760 [RFC6993] Saint-Andre, P., "Instant Messaging and Presence Purpose 761 for the Call-Info Header Field in the Session Initiation 762 Protocol (SIP)", RFC 6993, July 2013. 764 [XEP-0004] 765 Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and 766 P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007. 768 [XEP-0030] 769 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 770 Andre, "Service Discovery", XSF XEP 0030, June 2008. 772 [XEP-0045] 773 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 774 2012. 776 [XEP-0054] 777 Saint-Andre, P., "vcard-temp", XSF XEP 0054, July 2008. 779 [XEP-0128] 780 Saint-Andre, P., "Service Discovery Extensions", XSF XEP 781 0128, October 2004. 783 [XEP-0152] 784 Hildebrand, J. and P. Saint-Andre, "XEP-0152: Reachability 785 Addresses", XEP XEP-0152, February 2013. 787 [XEP-0166] 788 Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, 789 S., and J. Hildebrand, "Jingle", XSF XEP 0166, December 790 2009. 792 [XEP-0167] 793 Ludwig, S., Saint-Andre, P., Egan, S., McQueen, R., and D. 794 Cionoiu, "Jingle RTP Sessions", XSF XEP 0167, December 795 2009. 797 [XEP-0292] 798 Saint-Andre, P. and S. Mizzi, "vCard4 Over XMPP", XSF XEP 799 0292, September 2013. 801 Appendix A. Acknowledgements 803 This draft is inspired by the "SIXPAC" work of Markus Isomaki and 804 Simo Veikkolainen. Markus also provided various suggestions for 805 improving the document. 807 The authors would also like to thank the following people for their 808 reviews and suggestions: Sebastien Couture, Dan-Christian Bogos, 809 Richard Brady, Olivier Crete, Aaron Evans, Kevin Gallagher, Adrian 810 Georgescu, Saul Ibarra Corretge, David Laban, Gergely Lukacsy, Murray 811 Mar, Daniel Pocock, Travis Reitter, and Gonzalo Salgueiro. 813 Brian Carpenter, Ted Hardie, Paul Hoffman, and Benson Schliesser 814 reviewed the document on behalf of the General Area Review Team, the 815 Applications Area Directorate, the Security Directorate, and the 816 Operations and Management Directorate, respectively. 818 Benoit Claise, Barry Leiba, and Pete Resnick provided helpful and 819 substantive feedback during IESG review. 821 The document shepherd was Mary Barnes. The sponsoring Area Director 822 was Gonzalo Camarillo. 824 Authors' Addresses 826 Emil Ivov 827 Jitsi 828 Strasbourg 67000 829 France 831 Phone: +33-177-624-330 832 Email: emcho@jitsi.org 834 Peter Saint-Andre 835 Cisco Systems, Inc. 836 1899 Wynkoop Street, Suite 600 837 Denver, CO 80202 838 USA 840 Phone: +1-303-308-3282 841 Email: psaintan@cisco.com 842 Enrico Marocco 843 Telecom Italia 844 Via G. Reiss Romoli, 274 845 Turin 10148 846 Italy 848 Email: enrico.marocco@telecomitalia.it