RFC 7106

A Group Text Chat Purpose for Conference and Service URIs in the SIP Event Package for Conference State

📅 published January 2014, from ietf

RFC 7106: A Group Text Chat Purpose for Conference and Service URIs in the SIP Event Package for Conference State 🦋

okay bestie, let's get into it 💅 This is an IETF doc (the Internet Engineering Task Force, the group that writes the Internet's rulebook 📖). It's RFC 7106, written by E. Ivov (Emil Ivov from Jitsi) and published January 2014 as Category: Informational 🌸 ISSN 2070-1721. Its header doesn't list anything it obsoletes or updates, so it stands on its own ✨

The whole point: it adds a new grouptextchat purpose value to SIP's conference event package, so a conference can point you to its group chat room 💬

Abstract ✨

This doc defines and registers the value grouptextchat ("Group Text Chat") for the URI <purpose> element of SIP's Conference Event Package 🎀

Status of This Memo 📜

This doc is not an Internet Standards Track spec. It's published for information only 💖

It is a product of the IETF, so it reflects the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✅ Not everything the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🧐

You can find out the current status of this doc, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc7106 🔗

Copyright (c) 2014 IETF Trust and the people listed as the document authors. All rights reserved 💜

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Read those carefully, because they spell out your rights and restrictions for this doc 📖 Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🌈

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
4.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
  4.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
  4.2.  Informative References  . . . . . . . . . . . . . . . . .   5
Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   6

1. Introduction ✨

Okay so, the Conference Event Package [RFC4575] is how a SIP User Agent (UA) finds out what's going on in a conference 👀 It tells you the state of the call, what media is in use, how many people are there and whether they're active, extra info sources (like a web page), whether recordings exist, and more 🎀

Auxiliary services for a conference live in a <service-uris> child of <conference-description>. Each one is an <entry> holding the URI you use to reach that service. Entries can also have a descriptive <display-text>, and they're expected to have a <purpose> that says what kind of thing they are 💅 Here's an example:

<conference-description>
<subject>Agenda: This sprint's goals</subject>
  <service-uris>
    <entry>
      <uri>http://conference.example.com/dev-group/</uri>
      <purpose>web-page</purpose>
    </entry>
  </service-uris>
</conference-description>

Besides the web-page purpose from above, [RFC4575] also defines several other values in the "URI Purposes" sub-registry, which lives under the existing "Session Initiation Protocol (SIP) Parameters" registry 🧚

This spec adds the grouptextchat value to that "URI Purposes" sub-registry 🎉 It lets conference mixers or focus agents advertise a multi-user chat location (a chat room) tied to the current conference 💬

The URI in an entry with the grouptextchat purpose can be any type, as long as whatever it points to lets participants do instant text communication 🙌 Suitable schemes include sip: and sips: [RFC3261] for SIP-signaled Message Session Relay Protocol (MSRP) conferences, xmpp: [RFC5122] for XMPP Multi-User Chat (MUC), irc: for Internet Relay Chat, http: or https: for web-based chat, and others 🌸

Here's one possible use case:

<conference-description>
<subject>Agenda: The goals for this development sprint.</subject>
  <service-uris>
    <entry>
      <uri>xmpp:dev-sprint@conference.example.com</uri>
      <purpose>grouptextchat</purpose>
    </entry>
  </service-uris>
</conference-description>

Also, group chats are about more than texting during an audio/video call 🔥 They can also be used to define roles, hand out permissions, mute people, kick them out, and ban them, and so on 👑 A conference mixer or focus agent can mirror those settings in the call itself, actually muting, kicking, or banning people on the call as those actions happen in the chat room 🙈 This needs no extra spec and is purely an implementation decision for the conferencing software 💖

It's also possible for the grouptextchat URI to match the URI of the conference 🫶 That's typically the case when the conference focus agent also runs a SIP-signaled MSRP chat service at the same URI ✨

Servers could also advertise more than one chat room for a single conference 🦋 When that happens, clients that support the grouptextchat purpose can either show the user a choice of which chats to join, or just open all of them at once 💅 Either way, there's no expectation that the chat rooms stay in sync with each other 🙅‍♀️ If they do sync, that behavior is entirely implementation specific 🌈

2. Security Considerations 🔐

Okay this part is serious, bestie 😭 Read it carefully.

Advertising group text chats over SIP could give malicious entities an attack vector 💀 If an attacker can intercept and modify conference package event notifications, they could trick participants into joining a third-party chat room, where the attacker could eavesdrop on the conversation and maybe even impersonate some of the participants 😱

This is similar to attacks that are already possible with the "participation" <conference-uris> defined in [RFC4575], which is why that doc recommends "a strong means for authentication and conference information protection" as well as "comprehensive authorization rules" 🧠 Clients can integrity protect and encrypt notification messages with end-to-end mechanisms like S/MIME, or hop-by-hop mechanisms like TLS 🔒 When none of those are possible, clients need to clearly display the address of the destination chat room (both before and after joining) so users can spot any discrepancies 👀

Let's walk through an example. Say an attacker tricks participants into joining a conference chat at xmpp:attack@evil.example.com instead of the chat at xmpp:dev-sprint@conference.example.com, which was the one originally advertised for this conference 🚨 Without any SIP-layer security, showing the user the full URI of the target chat room would be the only way to catch the problem 🫣

Obviously, relying on humans to compare strings is a pretty weak form of protection 🥲 So client developers are encouraged to add extra checks that let users configure whether a target chat room satisfies some basic criteria, such as:

  • target chat rooms belong to the same domain as the conference service that is advertising them.
  • chat room names (the user part of the chat room URI) match the name of the conference.

These conditions only hold if the matching deployment conventions have been followed, and clients can't require them universally 🙃 So they're suggested configuration options, not hard rules 🌸

One more security thought: a large-scale conference could be used as leverage to flood a chat room 😬 To help prevent this, clients could require an explicit user action before joining chat rooms on users' behalf 🛑 If that kind of constraint would hurt usability, and automatic joins are seen as important, clients may still do the joins, but only when they can confirm a relationship between the room and the conference (for example, if they belong to the same administrative domain, or to domains the client is provisioned to treat as related) 🧩

Finally, an attack on an auxiliary chat room might be easier (or harder) than an attack on the main conference chat room, depending on the security policies in effect ⚖️ Again, clients have to make sure users are properly notified about the security levels of each part of the conference, and that user-specified privacy restrictions apply to all of them 🫶

3. IANA Considerations 🗂️

IANA has added the value grouptextchat to the "URI Purposes" sub-registry of the "Session Initiation Protocol (SIP) Parameters" registry <http://www.iana.org/assignments/sip-parameters>, as follows 🎀

  Value: grouptextchat
  Description: The URI can be used to join a multi-user chat directly
     associated with the conference
  Document: [this document]

4. References 📚

4.1. Normative References 💜

[RFC4575]  Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
           Initiation Protocol (SIP) Event Package for Conference
           State", RFC 4575, August 2006.

4.2. Informative 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.

[RFC5122]  Saint-Andre, P., "Internationalized Resource Identifiers
           (IRIs) and Uniform Resource Identifiers (URIs) for the
           Extensible Messaging and Presence Protocol (XMPP)", RFC
           5122, February 2008.

Appendix A. Acknowledgements 🫶

Thanks to Jonathan Lennox, Mary Barnes, Paul Kyzivat, Peter Saint-Andre, Rifaat Shekh-Yusef, and Saul Ibarra Corretge for their input 🌟

Author's Address 📮

Emil Ivov
Jitsi
Strasbourg  67000
France

Phone: +33-177-624-330
EMail: emcho@jitsi.org

That's the whole doc, bestie! 🌈💖 Emil from Jitsi basically said: if you're advertising a group chat for a conference, give it the grouptextchat purpose, and be careful about which room people actually land in 🫶

📦 where this page comes from