wdiff rfc7106.original rfc7106.txt

Network Working Group
Internet Engineering Task Force (IETF) E. Ivov
Internet-Draft
Request for Comments: 7106 Jitsi
Intended status:
Category: Informational November 04, 2013
Expires: May 08, January 2014
ISSN: 2070-1721

A Group Text Chat Purpose for Conference and Service URIs in the Session
Initiation Protocol (SIP) SIP
Event Package for Conference State
draft-ivov-grouptextchat-purpose-04

Abstract

This document defines and registers a value of "grouptextchat"
("Group Text Chat") value for the URI <purpose> element of SIP's Conference
Event Package [RFC4575]. Package.

Status of This Memo

This Internet-Draft document is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents not an Internet Standards Track specification; it is
published for informational purposes.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid 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 maximum candidate for any level of six months 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 updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on May 08, 2014.
http://www.rfc-editor.org/info/rfc7106.

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.

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 . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 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 such as a (e.g., web
page,
page), availability of recordings recordings, and others. more.

Details describing auxiliary services available for a conference are
included within a <service-uris> child element of the <conference-
description>
<conference-description> element. Such details are presented as a
set of <entry> child elements 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
also 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 a the "URI purposes" Purposes" sub-
registry under the existing registry: http://www.iana.org/assignments
/sip-parameters. "Session Initiation Protocol (SIP)
Parameters" registry.

This specification adds the "grouptextchat" value in to this "URI
purposes"
Purposes" sub-registry. The new value allows conference mixers or
focus agents to advertise a multi-user chat location (i.e. (i.e., a chat
room) associated with the current conference.

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 would
allow allows
for instant text communication between participants of the
conference. Suitable URI schemes include sip: and sips: [RFC3261]
for SIP signalled 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, agent
can mimic these settings within the conference call, actually muting,
kicking,
kicking out, or banning participants in 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
signalled
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 happens,
clients supporting the "grouptextchat" purpose could either present
the user with a choice or join multiple of joining individual chats or simply opening
all of them simultaneously. Either way way, there is to be no
expectation about any content synchronization between chat rooms. If it exists
synchronization exists, such behaviour behavior would be entirely
implementation specific.

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 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] [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 the above these are possible, clients will need to clearly display the
address of the destination chat room (before and after it has been
joined) so that users could can notice possible discrepancies.

As an example, let's consider a situation where in which an attacker would
trick tricks
participants into joining a conference chat at
xmpp:attack@evil.example.com rather than the chat at xmpp:dev-
sprint@conference.example.com,
xmpp:dev-sprint@conference.example.com, which was originally
advertised for this conference. In the absence of any SIP layer 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. Client Therefore, client developers are hence 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 again, these conditions are only satisfied if the corresponding
deployment conventions have been followed and they cannot be
universally required by clients. Hence the suggestion to have them
as 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 choose to
require an explicit user action before joining chat rooms on behalf
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 them the joins but only when
they can confirm a relationship between the room and the conference (e.g.
(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 the an auxiliary chatroom 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

The

IANA is requested to add a new predefined has added the value "grouptextchat"
in to the "URI purposes" sub-registry Purposes" sub-
registry of the http://www.iana.org/
assignments/sip-parameters "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:
EMail: emcho@jitsi.org