idnits 2.17.1 draft-ivov-xmpp-cusax-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2012) is 4202 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3264' is defined on line 285, but no explicit reference was found in the text == Unused Reference: 'RFC3489' is defined on line 289, but no explicit reference was found in the text == Unused Reference: 'RFC3711' is defined on line 294, but no explicit reference was found in the text == Unused Reference: 'RFC4474' is defined on line 298, but no explicit reference was found in the text == Unused Reference: 'RFC4566' is defined on line 302, but no explicit reference was found in the text == Unused Reference: 'RFC4787' is defined on line 305, but no explicit reference was found in the text == Unused Reference: 'RFC5245' is defined on line 320, but no explicit reference was found in the text == Unused Reference: 'RFC5389' is defined on line 328, but no explicit reference was found in the text == Unused Reference: 'RFC5751' is defined on line 332, but no explicit reference was found in the text == Unused Reference: 'RFC5766' is defined on line 336, but no explicit reference was found in the text == Unused Reference: 'RFC5853' is defined on line 344, but no explicit reference was found in the text == Unused Reference: 'RFC6189' is defined on line 356, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 9 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 E. Marocco 5 Expires: April 25, 2013 Telecom Italia 6 P. Saint-Andre 7 Cisco Systems, Inc. 8 October 22, 2012 10 Combined Use of the Session Initiation Protocol (SIP) and the 11 Extensible Messaging and Presence Protocol (CUSAX) 12 draft-ivov-xmpp-cusax-02 14 Abstract 16 This document describes current practices for combined use of the 17 Session Initiation Protocol (SIP) and the Extensible Messaging and 18 Presence Protocol (XMPP). Such practices 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 specification 23 does not define any new protocols or syntax for either SIP or XMPP. 24 However, implementing it may require modifying or at least 25 reconfiguring existing client and server-side software. Also, it is 26 not the purpose of this document to make recommendations as to 27 whether or not such combined use should be preferred to the 28 mechanisms provided natively by each protocol like for example SIP's 29 SIMPLE or XMPP's Jingle. It merely aims to provide guidance to those 30 who are interested in such a combined use. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 25, 2013. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Client Bootstrap . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Federation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 72 7. Informative References . . . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 Historically SIP [RFC3261] and XMPP [RFC6120] have often been 78 implemented and deployed with different purposes: from its very start 79 SIP's primary goal has been to provide a means of conducting 80 "Internet telephone calls". XMPP on the other hand, has, from its 81 Jabber days, been mostly used for instant messaging and presence 82 [RFC6121], as well as related services such as groupchat rooms 83 [XEP-0045]. 85 For various reasons, these trends have continued through the years 86 even after each of the protocols had been equipped to provide the 87 features it was initially lacking: 89 o Today, in the context of the SIMPLE working group, the IETF has 90 defined a number of protocols and protocol extensions that not 91 only allow for SIP to be used for regular instant messaging and 92 presence but that also provide mechanisms for elaborated features 93 such as multi-user chats, server-stored contact lists, file 94 transfer and others. 95 o Similarly, the XMPP community and the XMPP Standards Foundation 96 have worked on defining a number of XMPP Extension Protocols 97 (XEPs) that provide XMPP implementations with the means of 98 establishing end-to-end sessions. These extensions are often 99 jointly referred to as Jingle and their arguably most popular use 100 case are audio and video calls. 102 Despite these advances, SIP remains the protocol of choice for 103 telephony-like services, especially in enterprises where users are 104 accustomed to features such as voice mail, call park, call queues, 105 conference bridges and many others that are rarely (if at all) 106 available in Jingle-based software. XMPP implementations, on the 107 other hand, greatly outnumber and outperform those available for 108 instant messaging and presence extensions developed in the SIMPLE WG, 109 such as MSRP [RFC4975] and XCAP [RFC4825]. 111 For these reasons, in a number of cases adopters have found 112 themselves needing a set of features that are not offered by any 113 single-protocol solution but that separately exist in SIP and XMPP 114 products. The idea of seamlessly using both protocols together would 115 hence often appeal to service providers. 117 Most often the combined use of SIP and XMPP ("CUSAX") would employ 118 SIP exclusively for audio, video, and telephony services and rely on 119 XMPP for anything else varying from chat, contact list management, 120 and presence to whiteboarding and exchanging files. 122 This document explains how such hybrid offerings can be achieved with 123 a minimum of modifications to existing software while providing an 124 optimal user experience. It tries to cover points such as server 125 discovery, determining a SIP AOR while using XMPP and determining an 126 XMPP Jabber Identifier ("JID") from incoming SIP requests. Most of 127 the text here pertains to client behavior but it also recommends 128 certain server-side configurations. 130 Note that this document is focused on coexistence of SIP and XMPP 131 functionality in end-user-oriented clients. By intent it does not 132 define methods for protocol-level mapping between SIP and XMPP, as 133 might be used within a server-side gateway between a SIP network and 134 an XMPP network. A separate series of documents has been produced 135 that defines such mappings. 137 2. Client Bootstrap 139 One of the main problems of using two distinct protocols when 140 providing one service is the effect on usability. E-mail services, 141 for example, have long been affected by the mixed use of SMTP for 142 outgoing mail and POP3 or IMAP for incoming mail, making it rather 143 complicated for inexperienced users to configure a mail client and 144 start using it with a new service. As a result, Internet service 145 providers often need to provide configuration instructions for 146 various mail clients. Client developers and communication device 147 manufacturers on the other hand often ship with a number of wizards 148 that enable users to easily set up a new account for a number of 149 popular e-mail services. While this may improve the situation to 150 some extent, the user experience is still clearly sub-optimal. 152 While it should be possible for CUSAX users to manually configure 153 their separate SIP and XMPP accounts, dual-stack SIP/XMPP clients 154 ought to provide means of online provisioning. While the specifics 155 of such mechanisms are outside the scope of this specification, they 156 should make it possible for a service provider to remotely configure 157 the clients based on minimal user input (e.g., only a user ID and 158 password). 160 Because many of the features that a CUSAX client would privilege in 161 one protocol would also be available in the other, clients should 162 make it possible for such features to be disabled for a specific 163 account. In particular, it is suggested that clients allow for 164 audio/video calling features to be disabled for XMPP accounts. 165 Additionally, instant messaging and presence features should also be 166 made optional for SIP accounts. 168 The main advantage of the above would be that clients would be able 169 to continue to function properly and use the complete feature set of 170 stand-alone SIP and XMPP accounts. 172 Once client bootstrap has completed, clients need to log in 173 independently to the SIP and XMPP accounts that make up the CUSAX 174 "service" and then maintain both these connections. In order to 175 improve user experience, when reporting connection status clients may 176 also wish to present the CUSAX XMPP connection as an "instant 177 messaging" or a "chat" account. Similarly they could also depict the 178 SIP CUSAX connection as a "Voice and Video" or a "Telephony" 179 connection. The exact naming is of course entirely up to 180 implementers. The point is that, in cases where SIP and XMPP are 181 components of a service offered by a single provider, such 182 presentation could help users better understand why they are being 183 shown two different connections for what they perceive as a single 184 service. It could alleviate especially situations where one of these 185 connections is disrupted while the other one is successfully 186 maintained. 188 3. Operation 190 Once a CUSAX client has been provisioned/configured to connect to the 191 corresponding SIP and XMPP services it would proceed by retrieving 192 its XMPP roster. In order for CUSAX to function properly, XMPP 193 service administrators should make sure that at least one of the 194 vCard [RFC6350] "tel" fields for each contact is properly populated 195 with a SIP URI or a phone number when an XMPP protocol for vCard 196 storage (e.g., [XEP-0054] or [XEP-0292]) is used. There are no 197 limitations as to the form of that number (e.g. it does not need to 198 respect any equivalence with the XMPP JID). However, it ought to be 199 reachable through the SIP aspect of this CUSAX service. 201 To ensure that the foregoing approach is always respected, service 202 providers might consider (1) preventing clients (and hence users) 203 from modifying the vCard "tel" fields or (2) applying some form of 204 validation before recording changes. Of course such validation would 205 be feasible mostly in cases where one single provider controls both 206 the XMPP and the SIP service since such providers would "know" (e.g., 207 based on use of a common user database for both services) what SIP 208 AOR corresponds to a given XMPP user. 210 When rendering the XMPP roster CUSAX clients should make sure that 211 users are presented with a "Call" option for each roster entry that 212 has a properly set "tel" field even if calling has been disabled for 213 that particular XMPP account. The usefulness of such a feature is 214 not limited to CUSAX. After all, numbers are entered in vCards in 215 order to be dialed and called. Hence, as long as an XMPP client is 216 equipped with accounts that have calling features it may wish to 217 present the user with the option of using these accounts to reach 218 numbers from an XMPP vCard. In order to improve usability, in cases 219 where clients are provisioned with only a single telephony-capable 220 account they ought to do so immediately upon user request without 221 asking for confirmation. This way CUSAX users whose only account 222 with calling capabilities would often be the SIP part of their 223 service, would have a better user experience. If on the other hand, 224 the CUSAX client is aware of multiple telephony-capable accounts, it 225 ought to present the user with the choice of reaching the phone 226 number through any of them (including the source XMPP account where 227 the vCard was obtained) in order to guarantee proper operation for 228 XMPP accounts that are not part of a CUSAX deployment. 230 In addition to discovering phone numbers from vCards, clients may 231 also check presence broadcasts and the appropriate Personal Eventing 232 Protocol nodes as described in XEP-0152: Reachability Addresses 233 [XEP-0152]. 235 The client should use XMPP for all other forms of communication with 236 the contacts from its roster, which will occur naturally because they 237 were retrieved through XMPP and only voice/video features were 238 disabled in the XMPP stack. 240 When receiving SIP calls, clients may wish to determine the identity 241 of the caller and bind it to a roster entry so that users could 242 revert to chatting or other forms of communication that require XMPP. 243 To do so clients could search their roster for an entry whose vCard 244 has a "tel" field matching the originator of the call. 246 An alternate mechanism would be for CUSAX clients to add to their SIP 247 invite requests a Contact header containing the XMPP URI 248 corresponding to their JID as per [RFC5122]. 250 4. Federation 252 An alternate mechanism would be for CUSAX clients to add to 254 5. Security Considerations 256 Use of the same user agent with two different accounts providing 257 complementary features introduces the possibility of mismatches 258 between the security profiles of those accounts or features. For 259 example, the SIP aspect and XMPP aspect of the CUSAX service might 260 offer different authentication options (e.g., digest authentication 261 for SIP as specified in [RFC3261] and SCRAM authentication [RFC5802] 262 for XMPP as specified in [RFC6120]). Similarly, a CUSAX client might 263 successfully negotiate Transport Layer Security (TLS) [RFC5246] when 264 connecting to the XMPP aspect of the service but not when connecting 265 to the SIP aspect. Such mismatches could introduce the possibility 266 of downgrade attacks. User agent developers and service providers 267 ought to ensure that such mismatches are avoided as much as possible. 269 Refer to the specifications for the relevant SIP and XMPP features 270 for detailed security considerations applying to each "stack" in a 271 CUSAX client. 273 6. Acknowledgements 275 This draft is inspired by work from Markus Isomaki and Simo 276 Veikkolainen. 278 7. Informative References 280 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 281 A., Peterson, J., Sparks, R., Handley, M., and E. 282 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 283 June 2002. 285 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 286 with Session Description Protocol (SDP)", RFC 3264, 287 June 2002. 289 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 290 "STUN - Simple Traversal of User Datagram Protocol (UDP) 291 Through Network Address Translators (NATs)", RFC 3489, 292 March 2003. 294 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 295 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 296 RFC 3711, March 2004. 298 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 299 Authenticated Identity Management in the Session 300 Initiation Protocol (SIP)", RFC 4474, August 2006. 302 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 303 Description Protocol", RFC 4566, July 2006. 305 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 306 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 307 RFC 4787, January 2007. 309 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 310 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 312 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 313 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 315 [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers 316 (IRIs) and Uniform Resource Identifiers (URIs) for the 317 Extensible Messaging and Presence Protocol (XMPP)", 318 RFC 5122, February 2008. 320 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 321 (ICE): A Protocol for Network Address Translator (NAT) 322 Traversal for Offer/Answer Protocols", RFC 5245, 323 April 2010. 325 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 326 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 328 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 329 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 330 October 2008. 332 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 333 Mail Extensions (S/MIME) Version 3.2 Message 334 Specification", RFC 5751, January 2010. 336 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 337 Relays around NAT (TURN): Relay Extensions to Session 338 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 340 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 341 "Salted Challenge Response Authentication Mechanism 342 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 344 [RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, 345 A., and M. Bhatia, "Requirements from Session Initiation 346 Protocol (SIP) Session Border Control (SBC) Deployments", 347 RFC 5853, April 2010. 349 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 350 Protocol (XMPP): Core", RFC 6120, March 2011. 352 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 353 Protocol (XMPP): Instant Messaging and Presence", 354 RFC 6121, March 2011. 356 [RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media 357 Path Key Agreement for Unicast Secure RTP", RFC 6189, 358 April 2011. 360 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 361 August 2011. 363 [XEP-0045] 364 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, 365 February 2012. 367 [XEP-0054] 368 Saint-Andre, P., "vcard-temp", XSF XEP 0054, July 2008. 370 [XEP-0152] 371 Hildebrand, J. and P. Saint-Andre, "XEP-0152: Reachability 372 Addresses", XEP XEP-0152, October 2008. 374 [XEP-0292] 375 Saint-Andre, P. and S. Mizzi, "vCard4 Over XMPP", XSF 376 XEP 0292, October 2011. 378 Authors' Addresses 380 Emil Ivov 381 Jitsi 382 Strasbourg 67000 383 France 385 Phone: +33-672-811-555 386 Email: emcho@jitsi.org 388 Enrico Marocco 389 Telecom Italia 390 Via G. Reiss Romoli, 274 391 Turin 10148 392 Italy 394 Email: enrico.marocco@telecomitalia.it 395 Peter Saint-Andre 396 Cisco Systems, Inc. 397 1899 Wynkoop Street, Suite 600 398 Denver, CO 80202 399 USA 401 Phone: +1-303-308-3282 402 Email: psaintan@cisco.com