One document matched: draft-ivov-grouptextchat-purpose-04.xml

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<rfc category="info" ipr="trust200902"
     docName="draft-ivov-grouptextchat-purpose-04">

<?rfc toc='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes'?>
<?rfc iprnotified='no' ?>
<?rfc strict='yes' ?>
<?rfc compact='yes' ?>
  <front>
    <title abbrev="Entry Purpose: GroupTextChat">A Group Text Chat
      Purpose for Conference and Service URIs in the Session Initiation
      Protocol (SIP) Event Package for Conference State
    </title>

    <author initials='E.' surname='Ivov' fullname='Emil Ivov'>
      <organization abbrev='Jitsi'>Jitsi</organization>
      <address>
        <postal>
          <street></street>
          <city>Strasbourg</city>
          <code>67000</code>
          <country>France</country>
        </postal>
        <phone>+33-177-624-330</phone>
        <email>emcho@jitsi.org</email>
      </address>
    </author>

    <date/>

    <keyword>SIP</keyword>
    <keyword>Conference Event Package</keyword>
    <keyword>service-uris</keyword>
    <keyword>conference-uris</keyword>
    <keyword>URI purpose</keyword>

    <abstract>
      <t>
        This document defines and registers a value of "grouptextchat"
        ("Group Text Chat") value for the URI <purpose> element of
        SIP's Conference Event Package <xref target="RFC4575"/>.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="intro">
      <t>
        The Conference Event Package <xref target="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 web page, availability of recordings
        and others.
      </t>
      <t>
        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
        also have a <purpose> element that specifies their nature
        as illustrated in the following example:
      </t>
      <figure>
                <artwork>
<![CDATA[
<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>
]]>
        </artwork>
      </figure>
      <t>
        In addition to the "web-page" purpose mentioned above,
        <xref target="RFC4575"/> also defines several other possible
        values in a "URI purposes" sub-registry under the existing
        registry: http://www.iana.org/assignments/sip-parameters.
      </t>
      <t>
        This specification adds the "grouptextchat" value in 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.
      </t>
      <t>
        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 for instant text communication between
        participants of the conference. Suitable URI schemes include
        sip: and sips: <xref target="RFC3261"/> for SIP signalled
        Message Session Relay Protocol (MSRP) conferences, xmpp:
        <xref target="RFC5122"/> for XMPP Multi-User Chat (MUC), irc:
        for Internet Relay Chat, http: or https: for web-based chat, and
        others.
      </t>
      <t>
        The following example shows one possible use case:
      </t>
      <figure>
        <artwork>
<![CDATA[
<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>
]]>
        </artwork>
      </figure>
      <t>
        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 and banning participants, etc. A conference mixer
        or focus agent, can mimic these settings within the conference
        call, actually muting, kicking, or banning participants in 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.
      </t>
      <t>
        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 also provides a SIP signalled MSRP chat service at the
        same URI.
      </t>
      <t>
        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
        present the user with a choice or join multiple chats
        simultaneously. Either way there is to be no expectation about
        any content synchronization between chat rooms. If it exists
        such behaviour would be entirely implementation specific.
      </t>
    </section>
    <section title="Security Considerations" anchor="security">
      <t>
        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.
      </t>
      <t>
        Similar attacks are already possible with the "participation"
        <conference-uris> defined in <xref target="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 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 notice possible discrepancies.
      </t>
      <t>
        As an example, let's consider a situation where an attacker
        would trick 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.
      </t>
      <t>
        Obviously, relying on human-performed string comparison is a
        rather meek form of protection. Client developers are hence
        encouraged to implement additional checks that would allow users
        to request via configuration that target chat room satisfy some
        basic criteria, such as:
      </t>
      <t>
        <list style="symbols">
          <t>
            target chat rooms belong to the same domain as the
            conference service that is advertising them.
          </t>
          <t>
            chat room names (user part of the chat room URI) match the
            name of the conference.
          </t>
        </list>
      </t>
      <t>
        Once 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 configuration options.
      </t>
      <t>
        An additional security consideration might be the possibility
        for a large-scale conference 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 negative impact on usability and where automatic joins are
        seen as important, clients may still perform them 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).
      </t>
      <t>
        Furthermore, an attack on the auxiliary chatroom might be easier
        (or harder) than an attack on the main conference 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.
      </t>
    </section>

    <section title="IANA Considerations" anchor="iana">
      <t>
        The IANA is requested to add a new predefined value
        "grouptextchat" in the "URI purposes" sub-registry of the
         http://www.iana.org/assignments/sip-parameters registry as
        follows:</t>
      <figure>
        <artwork><![CDATA[
  Value: grouptextchat
  Description: The URI can be used to join a multi-user chat directly
  associated with the conference
  Document: [this document]
        ]]></artwork>
      </figure>
    </section>

  </middle>

  <back>
    <references title='Normative References'>
      <?rfc include="reference.RFC.4575"?>
    </references>
    <references title='Informative References'>
      <?rfc include="reference.RFC.3261"?>
      <?rfc include="reference.RFC.5122"?>
    </references>
    <section title='Acknowledgements'>
      <t>
        Thanks to Jonathan Lennox, Mary Barnes, Paul Kyzivat, Peter
        Saint-Andre, Rifaat Shekh-Yusef, and Saúl Ibarra Corretgé for
        their input.
      </t>
    </section>
  </back>

</rfc>