idnits 2.17.1 draft-ivov-grouptextchat-purpose-04.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 abstract seems to contain references ([RFC4575]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 04, 2013) is 3819 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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 November 04, 2013 5 Expires: May 08, 2014 7 A Group Text Chat Purpose for Conference and Service URIs in the Session 8 Initiation Protocol (SIP) Event Package for Conference State 9 draft-ivov-grouptextchat-purpose-04 11 Abstract 13 This document defines and registers a value of "grouptextchat" 14 ("Group Text Chat") value for the URI element of SIP's 15 Conference Event Package [RFC4575]. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on May 08, 2014. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Security Considerations . . . . . . . . . . . . . . . . . . . 4 53 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 54 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4.1. Normative References . . . . . . . . . . . . . . . . . . 5 56 4.2. Informative References . . . . . . . . . . . . . . . . . 5 57 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 60 1. Introduction 62 The Conference Event Package [RFC4575] defines means for a SIP User 63 Agent (UA) to obtain information about the state of the conference, 64 the types of media that are being used, the number and state of 65 current participants, additional sources of information such as a web 66 page, availability of recordings and others. 68 Details describing auxiliary services available for a conference are 69 included within a child element of the element. Such details are presented as a set of 71 child elements each containing the URI allowing access the 72 corresponding auxiliary service. In addition to the URI, entries can 73 also contain a descriptive element and are expected to 74 also have a element that specifies their nature as 75 illustrated in the following example: 77 78 Agenda: This sprint's goals 79 80 81 http://conference.example.com/dev-group/ 82 web-page 83 84 85 87 In addition to the "web-page" purpose mentioned above, [RFC4575] also 88 defines several other possible values in a "URI purposes" sub- 89 registry under the existing registry: http://www.iana.org/assignments 90 /sip-parameters. 92 This specification adds the "grouptextchat" value in this "URI 93 purposes" sub-registry. The new value allows conference mixers or 94 focus agents to advertise a multi-user chat location (i.e. a chat 95 room) associated with the current conference. 97 The actual URI carried by the entry with the "grouptextchat" purpose 98 can be of any type as long as the content that it points to would 99 allow for instant text communication between participants of the 100 conference. Suitable URI schemes include sip: and sips: [RFC3261] 101 for SIP signalled Message Session Relay Protocol (MSRP) conferences, 102 xmpp: [RFC5122] for XMPP Multi-User Chat (MUC), irc: for Internet 103 Relay Chat, http: or https: for web-based chat, and others. 105 The following example shows one possible use case: 107 108 Agenda: The goals for this development sprint. 109 110 111 xmpp:dev-sprint@conference.example.com 112 grouptextchat 113 114 115 117 It is worth pointing out that, in addition to simply adding text 118 messaging capabilities to an audio/video conference, group chats can 119 also be used for defining roles, giving permissions, muting, kicking 120 and banning participants, etc. A conference mixer or focus agent, 121 can mimic these settings within the conference call, actually muting, 122 kicking, or banning participants in the call as these actions occur 123 in the chat room. Such an approach requires no additional 124 specification and is purely an implementation decision for the 125 conferencing software. 127 It is also worth mentioning that it is possible for the grouptextchat 128 URI to match the URI of the conference. This would typically be the 129 case in scenarios where the conference focus also provides a SIP 130 signalled MSRP chat service at the same URI. 132 Also, in some cases, servers could potentially advertise more than a 133 single chat room for a specific conference. When this happens 134 clients supporting the "grouptextchat" purpose could present the user 135 with a choice or join multiple chats simultaneously. Either way 136 there is to be no expectation about any content synchronization 137 between chat rooms. If it exists such behaviour would be entirely 138 implementation specific. 140 2. Security Considerations 142 Advertising group text chats over SIP could provide malicious 143 entities with the following attack vector: if a malicious entity is 144 capable of intercepting and modifying conference package event 145 notifications, it could trick participants into joining a third party 146 chat room where the attacker could eavesdrop on the conversation and 147 potentially even impersonate some of the participants. 149 Similar attacks are already possible with the "participation" 150 defined in [RFC4575] which is why it recommends "a 151 strong means for authentication and conference information 152 protection" as well as "comprehensive authorization rules". Clients 153 can integrity protect and encrypt notification messages using end-to- 154 end mechanisms such as S/MIME or hop-by-hop mechanisms such as TLS. 155 When none of the above are possible, clients will need to clearly 156 display the address of the destination chat room (before and after it 157 has been joined) so that users could notice possible discrepancies. 159 As an example, let's consider a situation where an attacker would 160 trick participants into joining a conference chat at 161 xmpp:attack@evil.example.com rather than the chat at xmpp:dev- 162 sprint@conference.example.com, which was originally advertised for 163 this conference. In the absence of any SIP layer security, 164 displaying the full URI of the target chat room to the user would be 165 the only way of actually detecting the problem. 167 Obviously, relying on human-performed string comparison is a rather 168 meek form of protection. Client developers are hence encouraged to 169 implement additional checks that would allow users to request via 170 configuration that target chat room satisfy some basic criteria, such 171 as: 173 o target chat rooms belong to the same domain as the conference 174 service that is advertising them. 176 o chat room names (user part of the chat room URI) match the name of 177 the conference. 179 Once again these conditions are only satisfied if the corresponding 180 deployment conventions have been followed and they cannot be 181 universally required by clients. Hence the suggestion to have them 182 as configuration options. 184 An additional security consideration might be the possibility for a 185 large-scale conference to perform a flooding attack on a chat room. 186 To help prevent this, clients could choose to require an explicit 187 user action before joining chat rooms on behalf of users. In cases 188 where such a constraint could be considered to have negative impact 189 on usability and where automatic joins are seen as important, clients 190 may still perform them but only when they can confirm a relationship 191 between the room and the conference (e.g. they both belong to the 192 same administrative domain, or domains that the client is provisioned 193 to consider as related). 195 Furthermore, an attack on the auxiliary chatroom might be easier (or 196 harder) than an attack on the main conference depending on the 197 security policies in effect. Once again, clients would have to make 198 sure that users are appropriately notified about the security levels 199 of each component of the conference and that user-specified privacy 200 restrictions are applied to all of them. 202 3. IANA Considerations 204 The IANA is requested to add a new predefined value "grouptextchat" 205 in the "URI purposes" sub-registry of the http://www.iana.org/ 206 assignments/sip-parameters registry as follows: 208 Value: grouptextchat 209 Description: The URI can be used to join a multi-user chat directly 210 associated with the conference 211 Document: [this document] 213 4. References 215 4.1. Normative References 217 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 218 Initiation Protocol (SIP) Event Package for Conference 219 State", RFC 4575, August 2006. 221 4.2. Informative References 223 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 224 A., Peterson, J., Sparks, R., Handley, M., and E. 225 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 226 June 2002. 228 [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers 229 (IRIs) and Uniform Resource Identifiers (URIs) for the 230 Extensible Messaging and Presence Protocol (XMPP)", RFC 231 5122, February 2008. 233 Appendix A. Acknowledgements 234 Thanks to Jonathan Lennox, Mary Barnes, Paul Kyzivat, Peter Saint- 235 Andre, Rifaat Shekh-Yusef, and Saul Ibarra Corretge for their input. 237 Author's Address 239 Emil Ivov 240 Jitsi 241 Strasbourg 67000 242 France 244 Phone: +33-177-624-330 245 Email: emcho@jitsi.org