[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

Dispatch Working Group                                     A. Allen, Ed.
Internet-Draft                                                Blackberry
Intended status: Informational                               May 6, 2013
Expires: November 7, 2013


    Session Initiation Protocol Instance ID usage by the Open Mobile
                  Alliance Push-to-talk over Cellular
              draft-allen-dispatch-poc-instanceid-usage-00

Abstract

   This document describes how SIP Instance ID as defined in RFC 5626
   [1] is used by the Open Mobile Alliance (OMA), for Push-to-talk over
   Cellular (PoC) and addresses security concerns with use of the SIP
   instance ID in non-register requests.

Status of this Memo

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

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents 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 November 7, 2013.

Copyright Notice

   Copyright (c) 2013 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.



Allen                   Expires November 7, 2013                [Page 1]


Internet-Draft            PoC Instance ID usage                 May 2013


Table of Contents

   1.  Overall Applicability . . . . . . . . . . . . . . . . . . . . . 3

   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3

   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3

   4.  Architectural Background  . . . . . . . . . . . . . . . . . . . 4

   5.  Use of SIP Instance ID  . . . . . . . . . . . . . . . . . . . . 5

   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6

   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7

   8.  Informative References  . . . . . . . . . . . . . . . . . . . . 7

   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
































Allen                   Expires November 7, 2013                [Page 2]


Internet-Draft            PoC Instance ID usage                 May 2013


1.  Overall Applicability

   The procedures specified in this document makes certain assumptions
   regarding network topology and the existence of transitive trust.
   These assumptions are generally NOT APPLICABLE in the Internet as a
   whole.  The mechanisms specified here were designed to satisfy the
   requirements specified by the Open Mobile Alliance for Push-to-talk
   over Cellular.


2.  Introduction

   The Open Mobile Alliance(OMA)(http://www.openmobilealliance.org) has
   specified the Push-to-talk Over Cellular (PoC) service where SIP is
   the protocol used to establish half duplex media sessions across
   different participants.  This document describes how SIP Instance ID
   as defined in RFC 5626 [1] is used by the OMA PoC enabler and how
   security concerns with use of the SIP instance ID in non-register
   requests are addressed by this enabler.

   The PoC service allows a user of a PTT Terminal to establish a
   session to one or more PTT Terminals simultaneously, usually
   initiated by the initiating user pushing a button.

   OMA has defined an architecture to enable the support of the PoC
   service based upon the use of PTT Servers within the network.  The
   PoC service cannot function without the support of these PTT Servers
   by the network.


3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [2].

   The term "PTT Server" (Push-to-talk Server), is introduced in this
   document.

   A "PTT Server" as referred to here is a SIP network server that
   performs the network based functions for the Push to Talk service.
   The PTT Server acts as a back-to-back UA (B2BUA) as defined in [3]
   when processing SIP requests and responses for establishing SIP Push
   to Talk sessions.  There can be one or more PTT Servers involved in a
   SIP Push to Talk session.  The PTT Server is called a PoC Server in
   the OMA architecture.

   The term "PTT Terminal" (Push-to-talk Terminal), is introduced in



Allen                   Expires November 7, 2013                [Page 3]


Internet-Draft            PoC Instance ID usage                 May 2013


   this document.

   A "PTT Terminal" as referred to here is a SIP User Agent (UA) in a
   mobile or fixed device used by a user of the Push to Talk service.
   The PTT Terminal is called a PoC Client in the OMA architecture.


4.  Architectural Background

   The OMA PoC Architecture [4] utilizes PTT Servers within the network
   that can perform such roles as a conference focus [5], a real-time
   transport protocol (RTP) translator, floor control, or a network
   policy enforcement server.  There can be more than one PTT server in
   the signaling path for the session, particularly when multiple
   domains are involved in the session.  Section 6.1.3 of the OMA PoC
   Architecture [4] defines the functions of the PTT Servers (known in
   OMA terminology as PoC Servers).  Two roles for the PTT Servers are
   defined, the Participating PoC Function and the Controlling PoC
   Function.  Each PTT Terminal is assigned a PTT Server that performs
   the Participating PoC Function.  When the PTT Terminal originates a
   PTT Session the assigned PTT Server performs the Originating
   Participating PoC Function.  When the PTT Terminal is invited to a
   PTT Session the assigned PTT Server performs the Terminating
   Participating PoC Function.  The Controlling PoC Function performs
   floor control (know as Talk/Media Burst Control) and acts as the
   conference focus for group PTT Sessions.  For 1-1 and adhoc group PTT
   PTT Sessions the Originating Participating PoC Function and the
   Controlling PoC Function roles are always combined within the same
   PTT Server.  For Pre-arranged group and Chat group PTT Sessions the
   Controlling PoC Function is the PTT Server that hosts the Conference
   URI that is used for the Pre-arranged group or Chat group.

   When a PTT Session is established SIP requests are sent by the PTT
   Terminal to the PTT Server performing the Originating Participating
   PoC Function which acts as a B2BUA and then originates a new SIP
   request which is sent to the PTT Server preforming the Controlling
   PoC Function which acting as a B2BUA then originates a new SIP
   request towards each of the PTT Terminal invited to the PTT Session
   which are routed to the PTT Server performing the Terminating
   Participating PoC Function for the invited PTT Terminal(s).  The PTT
   Server performing the Terminating Participating PoC Function also
   acts as B2BUA and originates a new SIP request to the PTT Terminal.

   The PTT Server performing the Participating PoC Function provides
   various features to the PTT Terminal that it serves.  In order to
   support these features the PTT Server performing the Participating
   PoC Function needs to obtain various user configurable settings (e.g
   the current answer mode) from the PTT Terminal.  To do this an event



Allen                   Expires November 7, 2013                [Page 4]


Internet-Draft            PoC Instance ID usage                 May 2013


   package to indicate these PoC Service Settings was defined in [6].
   Immediatly after completing SIP registration the PTT Terminal senda a
   SIP PUBLISH request [7] containig the PoC Service Setttings event
   package to the PTT Server performing the Participating PoC Function.
   As well as delivering the PoC Service Settings to enable and
   configure various features the SIP PUBLISH request acts as a kind of
   implicit registration of the PTT Terminal with the PTT Server
   performing the Participating PoC Function.  The receipt of a 200 OK
   response from the PTT Server informs the PTT Terminal that the PoC
   Service is supported by the network.  If a 200 OK response to the SIP
   PUBLISH request is not received from the PTT Server the PTT Terminal
   will not initiate any PTT Sessions.


5.  Use of SIP Instance ID

   OMA PoC has been developed in phases.  The first phase is OMA PoC 1.0
   and was later enhanced as OMA PoC 2.0.  One of the enhancements in
   OMA PoC 2.0 is the support of multiple PoC Addresses by the PTT
   Terminal and the support of multiple PTT Terminals registering with
   the same PoC Address.  The PoC Address is a Public User Identity that
   is registered as an address of recored (AoR).  The PTT Server
   performing the Participating PoC Function needs to be aware of how
   many PTT Sessions are established with a particular PTT Terminal in
   order for certain features such a simultaneous PoC Sessions to work
   correctly.  Supporting multiple PoC Addresses and multiple PTT
   Terminals registering with the same PoC Address complicates the
   monitoring of how many PTT Sessions are established with a particular
   PTT Terminal by the PTT Server.  Since now the PTT Server needs to
   know which PTT Sessions are established to which PTT Terminal even
   when the PTT Terminal has multiple PTT sessions established to
   different PoC Addresses or when different PTT Terminals sharing the
   same PoC Address are involved in separate PTT Sessions.  Therefore in
   order to support multiple PoC Addresses and multiple PTT Terminals
   registering with the same PoC Address the PTT Server performing the
   Participating PoC Function needs to know which PTT Terminal is
   involved in which PTT Sessions and the relationship between PTT
   Terminals and PoC Addresses.

   To do this the PTT Terminal includes in both the SIP REGISTER request
   and in the PoC Service Settings the SIP Instance ID defined in RFC
   5626 [1].  The PTT Terminal will also send a SIP PUBLISH request
   containing the PoC Service Settings event package for each registered
   PoC Address.  This way the PTT Server performing the Participating
   PoC Function is made aware of the relationship between the instances
   of PTT Terminals and PoC Addresses.  By subscribing to the
   Registration Event Package defined in [8] the PTT Server can also
   determine if multiple PTT Terminals share the same PoC Address and



Allen                   Expires November 7, 2013                [Page 5]


Internet-Draft            PoC Instance ID usage                 May 2013


   the SIP Instance IDs of those PTT Terminals sharing the same PoC
   Address.

   In order for the PTT Server performing the Participating PoC Function
   to be made aware of which PTT Sessions are on which PTT Terminals the
   PTT Terminal includes the SIP Instance ID in the Contact header field
   of SIP request or SIP response related to PTT Sessions.  In order to
   address privacy concerns with providing the SIP Instance ID to other
   parties the PTT Server performing the Participating PoC Function does
   not include the SIP Instance ID in requests and responses that it
   sends towards the remote party.


6.  Security Considerations

   The instance ID is personally identifiable information that can be
   associated with a user and therefore could reveal the identity of a
   caller if included in anonymous requests.  RFC 5626 [1] states "One
   case where a UA could prefer to omit the "sip.instance" media feature
   tag is when it is making an anonymous request or some other privacy
   concern requires that the UA not reveal its identity".  OMA PoC
   depends on 3GPP IP Multimedia Subsystem (IMS) and 3GPP have defined
   use of the International Mobile Equipment Identity (IMEI) as an
   instance ID as defined in
   draft-allen-dispatch-imei-urn-as-instanceid-09 [9] and in
   draft-montemurro-gsma-imei-urn-14 [10].  The same privacy concerns
   apply when using the IMEI URN as an instance ID.

   draft-allen-dispatch-imei-urn-as-instanceid-09 [9] states "A UAC MUST
   NOT include its "sip.instance" media feature tag containing the GSMA
   IMEI URN in the Contact header field of non-register requests or
   responses except when the request or response is related to an
   emergency session when regulatory requirements can require the IMEI
   to be provided to the Public Safety Answering Point (PSAP).  Any
   future exceptions to this prohibition require a RFC that addresses
   how privacy is not violated by such usage".  The OMA PoC usage of the
   instance ID as defined in this doument adds an additional exception
   to the usage of "sip.instance" media feature tag containing the GSMA
   IMEI URN in the Contact header field of non-register requests.  Since
   the PTT Server performing the Participating PoC Function does not
   include the Instance ID in requests and responses that it generates
   and sends towards the remote party the privacy concerns with
   including the Instance ID in in the Contact header field of non-
   register requests and responses are addressed.







Allen                   Expires November 7, 2013                [Page 6]


Internet-Draft            PoC Instance ID usage                 May 2013


7.  Acknowledgements

   The author would like to thank TBD.


8.  Informative References

   [1]   Jennings, C., Mahy, R., and F. Audet, "Managing Client-
         Initiated Connections in the Session Initiation Protocol
         (SIP)", RFC 5626, October 2009.

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [3]   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.

   [4]   OMA, "Push to talk over Cellular - Architecture", OMA-AD-
         PoC V2_0, 20110802 A, August 2011.

   [5]   Rosenberg, J., "A Framework for Conferencing with the Session
         Initiation Protocol (SIP)", RFC 4353, February 2006.

   [6]   Garcia-Martin, M., "A Session Initiation Protocol (SIP) Event
         Package and Data Format for Various Settings in Support for the
         Push-to-Talk over Cellular (PoC) Service", RFC 4354,
         January 2006.

   [7]   Niemi, A., "Session Initiation Protocol (SIP) Extension for
         Event State Publication", RFC 3903, October 2004.

   [8]   Rosenberg, J., "A Session Initiation Protocol (SIP) Event
         Package for Registrations", RFC 3680, March 2004.

   [9]   Allen, A., "Using the International Mobile station Equipment
         Identity(IMEI)URN as an Instance ID, work in progress",
         Internet Draft draft-allen-dispatch-imei-urn-as-instanceid-09,
         May 2013.

   [10]  Montemurro, M., "A Uniform Resource Name Namespace For The GSM
         Association (GSMA) and the International Mobile  station
         Equipment Identity(IMEI), work in progress", Internet
         Draft draft-montemurro-gsma-imei-urn-14, May 2013.







Allen                   Expires November 7, 2013                [Page 7]


Internet-Draft            PoC Instance ID usage                 May 2013


Author's Address

   Andrew Allen (editor)
   Blackberry
   1200 Sawgrass Corporate Parkway
   Sunrise, Florida  33323
   USA

   Phone: unlisted
   Fax:   unlisted
   Email: aallen@blackberry.com








































Allen                   Expires November 7, 2013                [Page 8]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/