summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7106.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7106.txt')
-rw-r--r--doc/rfc/rfc7106.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc7106.txt b/doc/rfc/rfc7106.txt
new file mode 100644
index 0000000..67fbd7a
--- /dev/null
+++ b/doc/rfc/rfc7106.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) E. Ivov
+Request for Comments: 7106 Jitsi
+Category: Informational January 2014
+ISSN: 2070-1721
+
+
+ A Group Text Chat Purpose for Conference and Service URIs in the
+ SIP Event Package for Conference State
+
+Abstract
+
+ This document defines and registers a value of "grouptextchat"
+ ("Group Text Chat") for the URI <purpose> element of SIP's Conference
+ Event Package.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7106.
+
+Copyright Notice
+
+ Copyright (c) 2014 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+Ivov Informational [Page 1]
+
+RFC 7106 Entry Purpose: GroupTextChat January 2014
+
+
+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
+
+ The Conference Event Package [RFC4575] defines means for a SIP User
+ Agent (UA) to obtain information about the state of the conference,
+ the types of media that are being used, the number and state of
+ current participants, additional sources of information (e.g., web
+ page), availability of recordings, and more.
+
+ Details describing auxiliary services available for a conference are
+ included within a <service-uris> child element of the
+ <conference-description> element. Such details are presented as a
+ set of <entry> child elements, each containing the URI allowing
+ access the corresponding auxiliary service. In addition to the URI,
+ entries can also contain a descriptive <display-text> element and are
+ expected to have a <purpose> element that specifies their nature as
+ illustrated in the following 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>
+
+ In addition to the "web-page" purpose mentioned above, [RFC4575] also
+ defines several other possible values in the "URI Purposes" sub-
+ registry under the existing "Session Initiation Protocol (SIP)
+ Parameters" registry.
+
+ This specification adds the "grouptextchat" value to this "URI
+ Purposes" sub-registry. The new value allows conference mixers or
+ focus agents to advertise a multi-user chat location (i.e., a chat
+ room) associated with the current conference.
+
+
+
+
+
+Ivov Informational [Page 2]
+
+RFC 7106 Entry Purpose: GroupTextChat January 2014
+
+
+ The actual URI carried by the entry with the "grouptextchat" purpose
+ can be of any type as long as the content that it points to allows
+ for instant text communication between participants of the
+ conference. Suitable URI 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.
+
+ The following example shows 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>
+
+ It is worth pointing out that, in addition to simply adding text
+ messaging capabilities to an audio/video conference, group chats can
+ also be used for defining roles, giving permissions, muting, kicking
+ out and banning participants, etc. A conference mixer or focus agent
+ can mimic these settings within the conference call, actually muting,
+ kicking out, or banning participants on the call as these actions
+ occur in the chat room. Such an approach requires no additional
+ specification and is purely an implementation decision for the
+ conferencing software.
+
+ It is also worth mentioning that it is possible for the grouptextchat
+ URI to match the URI of the conference. This would typically be the
+ case in scenarios where the conference focus agent also provides a
+ SIP-signaled MSRP chat service at the same URI.
+
+ Also, in some cases, servers could potentially advertise more than a
+ single chat room for a specific conference. When this happens,
+ clients supporting the "grouptextchat" purpose could either present
+ the user with a choice of joining individual chats or simply opening
+ all of them simultaneously. Either way, there is to be no
+ expectation about any content synchronization between chat rooms. If
+ synchronization exists, such behavior would be entirely
+ implementation specific.
+
+
+
+
+
+
+
+
+Ivov Informational [Page 3]
+
+RFC 7106 Entry Purpose: GroupTextChat January 2014
+
+
+2. Security Considerations
+
+ Advertising group text chats over SIP could provide malicious
+ entities with the following attack vector: if a malicious entity is
+ capable of intercepting and modifying conference package event
+ notifications, it could trick participants into joining a third-party
+ chat room where the attacker could eavesdrop on the conversation and
+ potentially even impersonate some of the participants.
+
+ Similar attacks are already possible with the "participation"
+ <conference-uris> defined in [RFC4575], which is why it recommends "a
+ strong means for authentication and conference information
+ protection" as well as "comprehensive authorization rules". Clients
+ can integrity protect and encrypt notification messages using end-to-
+ end mechanisms such as S/MIME or hop-by-hop mechanisms such as TLS.
+ When none of these are possible, clients need to clearly display the
+ address of the destination chat room (before and after it has been
+ joined) so that users can notice possible discrepancies.
+
+ As an example, let's consider a situation in which an attacker tricks
+ participants into joining a conference chat at
+ xmpp:attack@evil.example.com rather than the chat at
+ xmpp:dev-sprint@conference.example.com, which was originally
+ advertised for this conference. In the absence of any SIP-layer
+ security, displaying the full URI of the target chat room to the user
+ would be the only way of actually detecting the problem.
+
+ Obviously, relying on human-performed string comparison is a rather
+ meek form of protection. Therefore, client developers are encouraged
+ to implement additional checks that would allow users to request via
+ configuration that a target chat room satisfy some basic criteria,
+ such as:
+
+ o target chat rooms belong to the same domain as the conference
+ service that is advertising them.
+
+ o chat room names (user part of the chat room URI) match the name of
+ the conference.
+
+ Once again, these conditions are only satisfied if the corresponding
+ deployment conventions have been followed and they cannot be
+ universally required by clients. Therefore, they are suggested
+ configuration options.
+
+ An additional security consideration might be the possibility for
+ using a large-scale conference as leverage to perform a flooding
+ attack on a chat room. To help prevent this, clients could to
+ require an explicit user action before joining chat rooms on behalf
+
+
+
+Ivov Informational [Page 4]
+
+RFC 7106 Entry Purpose: GroupTextChat January 2014
+
+
+ of users. In cases where such a constraint could be considered to
+ have a negative impact on usability and where automatic joins are
+ seen as important, clients may still perform the joins but only when
+ they can confirm a relationship between the room and the conference
+ (e.g., they both belong to the same administrative domain, or domains
+ that the client is provisioned to consider as related).
+
+ Furthermore, 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. Once again, clients would have to
+ make sure that users are appropriately notified about the security
+ levels of each component of the conference and that user-specified
+ privacy restrictions are applied 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.
+
+
+
+
+
+
+
+Ivov Informational [Page 5]
+
+RFC 7106 Entry Purpose: GroupTextChat January 2014
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ivov Informational [Page 6]
+