Movatterモバイル変換

Internet Engineering Task Force (IETF)                           E. IvovRequest for Comments: 7106                                         JitsiCategory: Informational                                     January 2014ISSN: 2070-1721A Group Text Chat Purpose for Conference and Service URIs in theSIP Event Package for Conference StateAbstract   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; seeSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://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 toBCP 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 2014Table of Contents1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .22.  Security Considerations . . . . . . . . . . . . . . . . . . .43.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .54.  References  . . . . . . . . . . . . . . . . . . . . . . . . .54.1.  Normative References  . . . . . . . . . . . . . . . . . .54.2.  Informative References  . . . . . . . . . . . . . . . . .5Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .61.  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 20142.  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 behalfIvov                          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.  References4.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)",RFC5122, February 2008.Ivov                          Informational                     [Page 5]

RFC 7106              Entry Purpose: GroupTextChat          January 2014Appendix 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.orgIvov                          Informational                     [Page 6]