RFC 7081
CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP)
CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) 💖
Okay, the official deets 🎀: this is RFC 7081, from the IETF (Internet Engineering Task Force) 🌸. It's Informational (the Status section explains what that means) and it came out in November 2013 🍓. Its ISSN is 2070-1721 ✨.
The authors are E. Ivov from Jitsi 🦋, P. Saint-Andre from Cisco Systems, Inc. 💅, and E. Marocco from Telecom Italia 🧚. The title block doesn't list anything this document obsoletes or updates 🙈.
Abstract
Bestie, this doc suggests strategies for using SIP and XMPP together, both in user-facing clients and in deployed servers 📱. Most of the strategies are configuration tweaks plus minimal software changes to existing clients and servers ⚙️. The goal is one full-featured, real-time communication service that borrows complementary feature subsets from each protocol 🔥. Usually that means SIP handles telephony and XMPP handles instant messaging and presence 💬.
Here's the plot twist: it does not define any new protocols or syntax for SIP or XMPP 🙅♀️. It also doesn't try to standardize "best current practices" 🧐. It's just practical guidance for anyone curious about combining SIP and XMPP for real-time communication 💜.
Status of This Memo
Not a standards track spec, just published for informational purposes 📚.
This document is a product of the IETF and represents the consensus of the IETF community ✨. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑. Not every IESG-approved doc is eligible for any level of Internet Standard, so check Section 2 of RFC 5741 for that 🤓.
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7081 🌈.
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) as in effect on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc 🫶. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License ⚖️.
Table of Contents 📑
1. Introduction ....................................................2
2. Client Bootstrap ................................................5
3. Operation .......................................................6
3.1. Server-Side Setup ..........................................7
3.2. Service Management .........................................7
3.3. Client-Side Discovery and Usability ........................8
3.4. Indicating a Relationship 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 Strategies ................................13
7. Security Considerations ........................................14
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................16
Appendix A. Acknowledgements ......................................181. Introduction 🌸
Historically, SIP [RFC3261] and XMPP [RFC6120] have been built and used for different things 🎀. SIP's main goal from the very start was providing a way to make "Internet telephone calls" 📞. XMPP, from its Jabber days, has mostly been about instant messaging, presence [RFC6121], and related stuff like groupchat rooms [XEP-0045] 💬.
These trends stuck around over the years, even after each protocol got the features it was originally missing 😭:
- In the SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) working group, the IETF defined a bunch of protocols and extensions. These let SIP do regular instant messaging and presence, and they also cover features like multi-party chat, server-stored contact lists, and file transfer [RFC6914] 💅.
- The XMPP community and the XMPP Standards Foundation also worked on XMPP Extension Protocols (XEPs) that let XMPP set up end-to-end sessions. These are often called Jingle [XEP-0166], and their most popular use is audio and video calling [XEP-0167] 📹.
So even though SIP got messaging and presence, and XMPP got voice and video, SIP is still the go-to for telephony-like services, and XMPP is still the go-to for IM and presence 👑. That means lots of adopters end up needing features that no single-protocol solution offers, even though those features already exist separately in SIP and XMPP implementations 🤯. Seamlessly using both together would therefore appeal to service providers and users alike ✨. Most often, the service would use SIP only for audio, video, and telephony, and rely on XMPP for everything else, like chat, contact-list management, presence, whiteboarding, and exchanging files 🦋. Since these services and clients combine 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 🍓
This document suggests different configuration options and minimal changes to existing software, so clients and servers can offer these hybrid services with a great user experience 🌈. It covers server discovery, figuring out a SIP Address of Record (AOR) while using XMPP, and figuring out an XMPP Jabber Identifier (JID) from incoming SIP requests 🔍. Most of the text is about client behavior, but it also suggests some server-side configurations and operational strategies 🖥️. It also talks about significant security considerations that can come up when you offer a dual-protocol solution, and it gives advice for avoiding security mismatches that would leave end users with weaker communications security 🔐. Real talk, that last part is important.
Quick note: this doc focuses on SIP and XMPP coexisting in end-user-oriented clients 📱. It does not define how to map protocols between SIP and XMPP, like a server-side gateway between a SIP network and an XMPP network would need. A separate series of documents does define those mappings 📚. It also doesn't describe service policies for inter-domain communication ("federation") between providers. For example, it doesn't cover how a provider offering CUSAX would talk to a SIP-only or XMPP-only service 🤷♀️. And it doesn't explain why a provider might pick SIP or XMPP for a given feature 🙃.
The doc mainly focuses on cases where one provider controls both the SIP and XMPP services 🫶. That assumption makes client implementation and server deployment way simpler, since a single provider can enforce common or coordinated policies across both sides of a CUSAX service. That's not possible when one provider runs SIP and a different provider runs XMPP 💅. Because this doc is informational, though, clients can totally apply some of the guidelines even when there's no established relationship between the SIP and XMPP services. For example, a client might let users easily start a call to a phone number or SIP URI found in a vCard or pulled from a user directory 📇. But the strategies for those cases are up to application developers 🛠️.
Another simplifying assumption: this doc only discusses one client, not coordination among multiple endpoints controlled by the same user 📱💻. Think user agents running at the same time on a laptop, tablet, and mobile phone. User agents on separate endpoints might themselves be CUSAX clients, or they might each handle different parts of an interaction. For instance, a user might use her mobile phone for audio and her tablet for video and text chat 🎧. But that kind of usage complicates the guidelines for user agent developers, so for now it's left as an implementation matter ⭐.
It's important to know that this doc does not try to standardize "best current practices" in the sense defined in the Internet Standards Process [RFC2026] 🙈. Instead, it gathers informational documentation about strategies that might help people implementing and deploying combined SIP/XMPP software and services 🌸. With enough use and the right changes based on experience, these strategies might someday become the basis for standardizing best current practices 🦋.
2. Client Bootstrap ✨
okay so the big problem with using two separate protocols for one service is how annoying it is to actually use 😭. Email is the classic example: SMTP for outgoing mail, and POP3 or IMAP (Post Office Protocol version 3 and friends) for incoming mail. Standard service discovery, like the proper DNS records, helps a user agent find the right host(s) to connect to 🧭, but it doesn't hand over the detailed info needed to actually configure the user agent. So it's honestly complicated for inexperienced users to set up a mail client with a new service, and that's why Internet service providers keep writing configuration instructions for all the different mail clients 💀. Client developers and communication device manufacturers try to help with so-called "wizard" interfaces that let people set up accounts for a bunch of popular email services 🧙♀️. That's an improvement, sure, but the user experience is still clearly suboptimal 🙈.
Now, CUSAX users can totally configure their separate SIP and XMPP accounts by hand (often with "wizards"), but service providers offering CUSAX services to users of dual-stack SIP/XMPP clients ought to provide online provisioning 💅. This is typically a web-based service at an HTTPS URL. (Single-purpose SIP services or XMPP services could offer this too, and it's especially helpful when the two halves of a CUSAX service need several configuration options in common.) The specifics of these mechanisms are outside the scope of this document, but they should let a service provider remotely configure clients from minimal user input, like just a user ID and password 🔐. As far as the authors are aware, there isn't yet an open protocol for endpoint configuration that's available and adopted. Still, application developers are encouraged to explore the potential for future progress in this space, maybe building on something like WebFinger [RFC7033] 🌈.
By default, when a CUSAX client is used with SIP and XMPP accounts that have a CUSAX relationship (see Section 3.4), the client should disable audio and video calling over XMPP and disable instant messaging and presence over SIP ✨. (It's up to the implementation whether a CUSAX client lets a user override these defaults in various ways, e.g., by domain, by individual contact, or by device. Main character choice, fr.) The big win here is that a client gets the most relevant features from both SIP and XMPP when it's working in a CUSAX context 🦋. Note that this default configuration does NOT apply to stand-alone SIP accounts or XMPP accounts, since other settings are likely to be more appropriate for those (see Section 3.4 for details). Different vibes, different settings 💜.
Once a client has been provisioned, it needs to independently log into the SIP account and the XMPP account that make up the CUSAX "service", and then maintain both connections 🔌.
To make the user experience better, a CUSAX client may wish to show the XMPP connection as an "instant messaging" or a "chat" account, and the SIP connection as a "Voice and Video" or a "Telephony" connection 📱. The exact naming is entirely up to implementers, obviously. The point is that when SIP and XMPP are components of a service from a single provider, this kind of presentation can help users understand why they're seeing two different connections for what they perceive as one service 🫶. That's especially true when one connection drops while the other is still active 😵💫. Alternatively, a CUSAX client's developers or a CUSAX service's providers might decide to force a client to fully disconnect unless both aspects are successfully connected 🚫.
Clients may also choose to delay their XMPP connection until they've been successfully registered on SIP 🎀. This helps avoid the chaos where a user looks online to her contacts, but calling her client fails because it's still connecting to the SIP side of the CUSAX service 📞💀.
3. Operation ✨
Once a CUSAX client has been provisioned and authorized to connect to the corresponding SIP and XMPP services, it proceeds by retrieving its XMPP roster 📋.
The client should use XMPP for most forms of communication with the contacts on this roster, which happens naturally because those contacts were retrieved through XMPP 💬. Audio/video features, though, are typically disabled in the XMPP stack, so media-related communication based on those features (e.g., direct calls, conferences, desktop streaming, etc.) happens over SIP 🎥. The rest of this section describes the deployment, discovery, usability, and linking semantics that let CUSAX clients use SIP for these features seamlessly 🧚.
3.1. Server-Side Setup
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 for the user's address at the SIP audio/video service provided by the CUSAX server 📇. There are no limitations on the form of that number. For example, while it's desirable to keep some consistency between SIP AORs and XMPP JIDs, that's by no means required 🤷♀️. It is quite important, though, 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 isn't vCard storage over XMPP as described by [XEP-0054] or [XEP-0292].)
Administrators may also choose to include the video tel type defined in [RFC6350] for accounts that would be capable of handling video communication 🎬.
To make sure the approach above is always respected, service providers might consider validating the values of vCard tel fields before storing changes 🧐. Of course, this validation is only feasible when 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) which SIP AOR corresponds to a given XMPP user 🧠.
3.2. Service Management
Running a stand-alone SIP service or XMPP service is not always easy 😮💨. Combining the two into one unified service adds extra challenges, including:
- The necessity of opening additional ports on the client side if SIP functionality is added to an existing XMPP deployment, or vice versa 🚪.
- The potential for important differences in security posture across SIP and XMPP (e.g., SIP servers and XMPP servers might support different Transport Layer Security (TLS) ciphersuites) 🔒.
- The need for, ideally, a common authentication backend and other infrastructure that is shared across the SIP and XMPP aspects of the combined service 🗝️.
- Coordinated monitoring and logging of the SIP and XMPP servers to enable the correlation of incidents and the pinpointing of problems 🕵️♀️.
- The difficulty of troubleshooting client-side issues, e.g., if the client loses connectivity for XMPP but maintains its SIP connection 🤯.
Separating functionality (SIP for media, XMPP for IM and presence) can help ease the operational burden to some extent 🫧. Still, service providers are urged to address the challenges above, and similar issues, when preparing to launch a CUSAX service 🚀.
Beyond the issues listed above, service providers might want to be aware of more subtle operational issues that can come up 👀. For example, if a provider uses different network operators for the SIP service and the XMPP service, end-to-end connectivity might be more reliable or consistent in one service than in the other 📡. Similar issues can arise when the media path and the signaling path go over different networks, even in stand-alone SIP or XMPP services 🌐. Providers of CUSAX services are advised to consider the potential for such topologies to cause operational challenges 🧩.
3.3. Client-Side Discovery and Usability
When rendering the roster for a particular XMPP account, CUSAX clients should make sure users see 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 this document advises. The usefulness of this feature isn't limited to CUSAX, either. Numbers get stored in vCards or directories so they can be dialed and called, after all 💖. So as long as an XMPP client has any means of conducting a call, it may wish to let the user easily dial any numbers it learned through whatever means 🌸.
Clients with 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] to decide whether to enable or disable starting video calls 🎥✨. (In other words, if there's no video tel type for a particular contact, the client could disable the "video call" button for that contact. Iconic behaviour, tbh 💅.)
Besides discovering phone numbers from vCards or user directories, clients may also check for alternative communication methods advertised in XMPP presence broadcasts and Personal Eventing Protocol nodes, as described in "XEP-0152: Reachability Addresses" [XEP-0152] 🦋. However, these are merely hints, so a receiving client ought not associate a SIP address and an XMPP address unless it has some way to verify the relationship. That might look like the vCard of the XMPP account listing the SIP address and the vCard of the SIP account listing the XMPP address, or the relationship being made explicit in a record from a trusted directory 🔍. Alternatively, or when vCard or directory data isn't available, a CUSAX client could take the user's own address book as the canonical source for contact addresses 📖💜.
3.4. Indicating a Relationship between SIP and XMPP Accounts 💫
Okay so, for usability, if a client only has ONE account that can make calls, it should just start the call right away when the user asks, without making them pick an account first 📞✨. This is SO good for CUSAX users, because their only calling account is usually the SIP side of their service. From their point of view, calls just work at the click of a button 🫶💖.
Things get messier when a client has more than the two XMPP and SIP accounts that the CUSAX provider set up. Users often add their own stand-alone XMPP or SIP accounts (or accounts for other communications protocols), and any of those might do both calling and instant messaging 🙈. Now there's real ambiguity, because every telephony-capable account could be used to call the numbers the client picked up from vCards or directories. Not it 💀.
To cut down on that confusion, client implementers and CUSAX service providers may choose to mark a special relationship between a service's SIP and XMPP accounts 🎀. For example, say Alice's service provider 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 relationship to alice@sip.example.com, meaning they're two sides of the same service 🦋. Then whenever Alice starts a call to someone on her XMPP roster, the client would prefer to place that call through her example.com SIP account, even if other options exist (like the XMPP account where the vCard came from, or a SIP account with another provider) 👑. In the same way, the client would prefer to start text chats using her XMPP account 💜.
On the other hand, if no relationship has been set up or found between a SIP account and an XMPP account, and the client knows about more than one telephony-capable account, it ought to show the user the option of using XMPP Jingle as one way to have audio and video calls with a contact who has an XMPP address 🌈. This helps a CUSAX user still complete audio and video calls with XMPP users who aren't part of a CUSAX deployment 🧚.
3.5. Matching Incoming SIP Calls to XMPP JIDs 🔍
When a SIP call comes in, a CUSAX client may want to figure out who's calling and find the matching XMPP roster entry, so the user can switch to chatting or any other XMPP-based option 💬. To do this, a CUSAX client could search the user's roster for an entry whose vCard has a tel field that matches the caller's number 📇. Going through the whole roster and fetching every contact's vCard can be a lot of work, though, so the receiving client may instead guess who the caller is based on a SIP Call-Info header whose purpose header field parameter is set to impp, as described in [RFC6993] ✨. To make this work, the sending client would need to include that Call-Info header in the SIP messages it sends when it starts a call. Here's an example:
Call-Info: <xmpp:alice@xmpp.example.com> ;purpose=imppHeads up, though: the information in the Call-Info header should only be treated as a cue 🚩. The real AOR-to-JID binding still needs to be confirmed, either by a vCard for a contact in the receiving user's roster or through some other trusted method (like an enterprise directory) 🔐. If that check passes, the client doesn't need to search the whole roster and fetch every vCard, which is a huge win 🙌. Skipping the check, though, could let any caller (including malicious ones) borrow someone else's identity and pull off scams or Man-in-the-Middle attacks 😱💀. Not okay!!
That said, even though an AOR-to-JID binding can be a helpful hint for the user, nothing in the paragraph above should be read as necessarily discouraging users, clients, or service providers from accepting calls from people who aren't established contacts (like someone who isn't on the user's roster) 🤷♀️. Whether to do that is a policy decision for the user, client, or service provider 🫧.
It's also worth knowing that callers who want to stay anonymous, as described in [RFC3325], won't provide any Call-Info information 🥷.
4. Multi-Party Interactions 👯♀️
CUSAX clients that support the SIP conferencing framework [RFC4353] can tell when a call they're in is actually a conference, and then they can subscribe to conference state updates as per [RFC4575] 📡. A regular SIP user agent might also use the same conference URI for text using the Message Session Relay Protocol (MSRP) 💌. But SIP's instant messaging features would normally be turned off (or just not supported) in CUSAX deployments, so an XMPP Multi-User Chat (MUC) room [XEP-0045] tied to the conference can be announced and discovered through <service-uris> with the grouptextchat purpose [GROUPTEXTCHAT] 🍓. In the other direction, an XMPP MUC room can advertise the SIP URI of an associated service for audio and video by using the audio-video-uri field of the muc#roominfo data form [XEP-0004], which carries extended information [XEP-0128] about the MUC room inside XMPP service discovery [XEP-0030]. See [XEP-0045] for an example 🔎. Together, these methods let a CUSAX-aware SIP conference server advertise an associated XMPP chat room, and let a CUSAX-aware XMPP chat room advertise an associated SIP conference server 🌸.
If a CUSAX client joins the MUC room tied to a particular call, it should not rely on any synchronization between the two 🙅♀️. The SIP conference and the XMPP MUC room work independently, each issuing and delivering its own state updates 🔄. So it's possible that some peers are reachable in only one of the two, either temporarily or permanently 😵💫. That's typically what happens with single-stack clients that have only joined the SIP call or only the XMPP MUC room. This is why it's so important for CUSAX clients to clearly show users how involved each participant is. A user needs to be able to tell at a glance whether someone can receive text messages, audio/video, or both 👀💅.
At the level of the CUSAX service, the XMPP MUC room and the SIP conference can also be integrated more tightly 💞. Permissions, roles, kicks, and bans done in the MUC room can easily be copied into the SIP call by the conference focus or mixer 👑. For example, if a MUC member gets muted, the conference mixer can choose to mute that participant's media stream too 🤫. Still, the details and exact level of that integration are entirely up to implementers and service providers 🎀.
The approach above is one fairly lightweight way to combine SIP and XMPP multi-party features without needing tight integration between the two 🦋. Like the rest of this document, it is by no means normative 📝. Implementations and future documents may define other methods or offer other suggestions for improving the unified communications experience for multi-user chats and conference calls 🌈✨.
5. Federation 🌍
In theory, there's no technical reason federation (i.e., communication between domains) would need special behavior from CUSAX clients 🤓. Still, differences in administration policies can sometimes lead to confusing user experiences 😬.
Here's an example. Let's say atlanta.example.com follows the CUSAX policies described in this document. So all XMPP users at atlanta.example.com have vCards that match their SIP identities 📇. That means Alice is used to making free, high-quality SIP calls to everyone on her roster 💕. She can also call the Public Switched Telephone Network (PSTN) just by dialing numbers 📱. She might even be used to those calls being billed to her online account, so she'd be careful about how long they last 💸. That's not a problem for her, because she can easily tell a free SIP call (one she made by calling a roster entry) apart 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's no SIP server, and Bob uses an XMPP-only client 📴. But Bob added his mobile number to his vCard so his contacts can reach him easily 📲. Alice's client would pick up that number and let Alice start a call to Bob's mobile phone 😳.
That could be a problem. Apart from the fact that Bob's address is from a different domain, Alice wouldn't have any obvious cues telling her this is actually a PSTN call 🫣. On top of the possibly lower audio quality, she might also end up with unexpected charges 💀💸.
To avoid issues like this, providers who run a CUSAX service for users in their domain may choose to give extra cues (for example, a service-generated signal that triggers a warning in the CUSAX client's interface, an auditory tone, or a spoken message) that a call would incur unexpected charges 🔔.
Another scenario comes up when a SIP service only allows communication with numbers inside its own domain. In that case, Alice might not be able to call Bob's mobile phone at all 📵. So providers should make sure calls to numbers outside their domain are flagged with an appropriate audio or text warning ⚠️💖.
6. Summary of Suggested Strategies 💅
okay so this section is basically the cheat sheet 📝✨ it lists every strategy the spec suggests for CUSAX user agents (the clients) and then for CUSAX services (the providers). so let's go bestie 🫶
The following strategies are suggested for CUSAX user agents:
- By default, prefer SIP for audio and video and XMPP for messaging and presence. 📞💬
- 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) for which SIP should be used. 🌸
- Provide online provisioning options for providers to remotely set up SIP and XMPP accounts so that users wouldn't need to go through a multi-step configuration process. ✨ no more setup marathon, iconic 👑
- Provide online 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). 🙅♀️
- Present a "Call" option for each roster entry that has a properly set "tel" field in the vCard or equivalent. 📲💖
- 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. 🦋 one account? just call, no questions asked
- 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. 🧚
- If known, indicate the existence of a special relationship between the SIP and XMPP accounts of a CUSAX service. 🎀
- 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" account. 🌈
- Optionally, determine the identity of the audio/video caller and a corresponding XMPP roster entry so that the user could use textual chatting or other forms of communication that require XMPP. 💜
- Optionally, delay the XMPP connection until after a SIP connection has been successfully registered. ⭐
- Optionally, check for alternative communication methods (SIP addresses advertised over XMPP and XMPP addresses advertised over SIP). 🍓
The following strategies are suggested for CUSAX services:
- Use online provisioning and configuration of accounts so that users won't need to set up two separate accounts for the CUSAX service. 💅
- Use online provisioning so that calling features are disabled for all XMPP accounts. 🙈
- Ensure that at least one of the vCard "tel" fields for each XMPP user is properly populated with a SIP URI that is reachable through the SIP service. 🫶
- Optionally, include the "video" tel type for accounts that are capable of handling video communication. 🎥
- Optionally, provision clients with information indicating that specific SIP and XMPP accounts are related in a CUSAX service. 🔗
- Optionally, attach a
Call-Infoheader with an "impp" purpose to all SIP INVITE messages, so that clients can more rapidly associate a caller with a roster entry and display a "Caller ID". 📞✨ this one is giving "know who's calling before you even pick up"
7. Security Considerations 🔐
okay the security part is the one where we get a little dramatic 😭 but it's important, I promise 🫶
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:
- 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 Salted Challenge Response Authentication Mechanism (SCRAM) authentication [RFC5802] 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. 🙀 two different locks on the same door, bestie - 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. 💀 this is the part that's lowkey scary, because you'd think you're fully covered and you're really not
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. 🚨 everyone's job here is to keep the two sides matching, and if they don't match, the user gets told and gets a chance to fix it
Section 5 discusses potential issues that may arise due to a mismatch between client capabilities, such as calls being initiated with costs that are not expected by 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. 💸 nobody wants a surprise bill, so give people the heads up
Refer to the specifications for the relevant SIP and XMPP features for detailed security considerations applying to each "stack" in a CUSAX client. 📚
8. References 📖
8.1. Normative References
[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.
[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.8.2. Informative References
[GROUPTEXTCHAT] Ivov, E., "A Group Text Chat Purpose for Conference
and Service URIs in the Session Initiation Protocol
(SIP) Event Package for Conference State", Work
in Progress, June 2013.
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP)
for Asserted Identity within Trusted Networks",
RFC 3325, November 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.
[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.
[RFC6350] Perreault, S., "vCard Format Specification",
RFC 6350, August 2011.
[RFC6914] Rosenberg, J., "SIMPLE Made Simple: An Overview of
the IETF Specifications for Instant Messaging and
Presence Using the Session Initiation Protocol
(SIP)", RFC 6914, April 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.
[RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr,
"WebFinger", RFC 7033, September 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,
September 2013.
[XEP-0166] Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R.,
Egan, S., and J. Hildebrand, "Jingle", XSF XEP 0166,
December 2009.
[XEP-0167] Ludwig, S., Saint-Andre, P., Egan, S., McQueen, R.,
and D. Cionoiu, "Jingle RTP Sessions", XSF XEP 0167,
December 2009.
[XEP-0292] Saint-Andre, P. and S. Mizzi, "vCard4 Over XMPP",
XSF XEP 0292, September 2013.Appendix A. Acknowledgements 🙌
this is the thank-you section 🥹 the spec is inspired by the "SIXPAC" work of Markus Isomaki and Simo Veikkolainen, and Markus also gave a bunch of suggestions for improving the document. the authors also thanked a long list of 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, Spencer MacDonald, 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. 🌟
Benoit Claise, Barry Leiba, and Pete Resnick provided helpful and substantive feedback during IESG review. 🧚
The document shepherd was Mary Barnes. The sponsoring Area Director was Gonzalo Camarillo. 👑
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.itThat's the whole spec, bestie! 🌈✨ You made it through all four parts 🎀💅
📦 where this page comes from
- ietf: rfc7081 2013-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms