Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/rfc-ed-all/pdfrfc/rfc7106.txt.pdf Дата изменения: Wed Jan 22 10:05:08 2014 Дата индексирования: Fri Feb 28 12:47:46 2014 Кодировка:

Internet Engineering Task Force (IETF) Request for Comments: 7106 Category: Informational ISSN: 2070-1721

E. Ivov Jitsi January 2014

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 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. 2. 3. 4. Introduction . . . . . . Security Considerations . IANA Considerations . . . References . . . . . . . 4.1. Normative References 4.2. Informative References Appendix A. Acknowledgements 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 child element of the element. Such details are presented as a set of child elements, each containing the URI allowing access the corresponding auxiliary service. In addition to the URI, entries can also contain a descriptive element and are expected to have a element that specifies their nature as illustrated in the following example: Agenda: This sprint's goals http://conference.example.com/dev-group/ web-page In addition to the "web-page" purpose mentioned above, [RFC4575] also defines several other possible values in the "URI Purposes" subregistry 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. . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 4 5 5 5 5 6

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: Agenda: The goals for this development sprint. xmpp:dev-sprint@conference.example.com grouptextchat 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 URI to match the case in scenarios SIP-signaled MSRP mentioning that it is possible for the grouptextchat URI of the conference. This would typically be the where the conference focus agent also provides a 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" 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-toend 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. chat room names (user part of the chat room URI) match the name of the conference.

o

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 using a large-scale conference as leverage to attack on a chat room. To help prevent this, require an explicit user action before joining the possibility for perform a flooding clients could to 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 harder) than an attack on the security policies in make sure that users are levels of each component privacy restrictions are 3. IANA Considerations IANA has added the value "grouptextchat" to the "URI Purposes" subregistry of the "Session Initiation Protocol (SIP) Parameters" registry 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. 4.1. References Normative References Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006. an auxiliary chat room might be easier (or the main conference chat room depending on effect. Once again, clients would have to appropriately notified about the security of the conference and that user-specified applied to all of them.

[RFC4575]

4.2.

Informative References 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. Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", RFC 5122, February 2008.

[RFC3261]

[RFC5122]

Ivov

Informational

[Page 5]


RFC 7106

Entry Purpose: GroupTextChat

January 2014

Appendix A.

Acknowledgements

Thanks to Jonathan Lennox, Mary Barnes, Paul Kyzivat, Peter SaintAndre, Rifaat Shekh-Yusef, and Saul Ibarra Corretge for their input. Author's Address Emil Ivov Jitsi Strasbourg France

67000

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

Ivov

Informational

[Page 6]