Dispatch Working Group A. Allen, Ed. Internet-Draft Blackberry Updates: 7255 (if approved) A. Soloway Intended status: Informational Qualcomm Expires: August 22, 2015 February 18, 2015 Session Initiation Protocol (SIP) Instance ID usage by the Open Mobile Alliance Push-to-talk over Cellular draft-allen-dispatch-poc-instanceid-usage-02 Abstract This document describes how the 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 Push-to-Communicate for Public Safety (PCPS) and addresses security concerns with use of the SIP instance ID in non-register requests and responses. This document updates RFC 7255 [2] to allow the use of the International Mobile Equipment Identity (IMEI) as an instance ID in the Contact header field of non-register requests and responses by the OMA PoC and PCPS enablers for the purposes described in this document. 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 August 22, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Allen & Soloway Expires August 22, 2015 [Page 1] Internet-Draft PoC Instance ID usage February 2015 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. Overall Applicability . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 and Push-to-Communicate for Public Safety. 2. Introduction The Open Mobile Alliance(OMA)(http://www.openmobilealliance.org) has specified the Push-to-talk Over Cellular (PoC) and Push-to- Communicate for Public Safety enablers where the SIP protocol [3] is used to establish half duplex media sessions between different participants. OMA completed the specification of the initial version of the PoC Enabler (OMA PoC 1.0) in 2006. Enhanced versions of this enabler have been defined since then (OMA PoC 2.0 and OMA PoC 2.1) that add additional functionality. Most recently OMA completed another update of the OMA PoC enabler for Push-To-Talk over 3GPP Long Term Evolution (LTE) networks as a baseline for the work now taking place in 3GPP on Mission Critical Push-To-Talk over LTE (MCPTT). The updated version of the OMA PoC Enabler is known as OMA Push-to- Communicate for Public Safety (PCPS). 3GPP MCPTT is part of an initiative from Public Safety communities around the world to define a global standard for Broadband Public Safety networks, based on 3GPP Allen & Soloway Expires August 22, 2015 [Page 2] Internet-Draft PoC Instance ID usage February 2015 LTE and 3GPP Enhanced Packet Core (EPC) technology. Public Safety Agencies in the United States, United Kingdom, several other European nations, as well as South Korea are planning to deploy MCPTT as a supplement to, and ultimately a replacement for, their existing 2nd Generation Push-To-Talk systems such as P25 (see TIA-102 [4]), Terrestrial Trunked Radio (TETRA)(see ETSI EN 300 392-1 [5]) and other 2nd Generation and analog Push-To-Talk systems. The 3GPP MCPTT work is scheduled for completion at the end of 2015 with initial deployments of MCPTT expected in 2016. This document describes how the SIP Instance ID as defined in RFC 5626 [1] is used by the OMA PoC and PCPS enablers and how security concerns with use of the SIP instance ID in non-register requests and responses are addressed by these enablers. The PoC and PCPS enablers allow 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 and PCPS services based upon the use of PTT Servers within the network. The PoC and PCPS enablers 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 [6]. 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 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. Allen & Soloway Expires August 22, 2015 [Page 3] Internet-Draft PoC Instance ID usage February 2015 4. Architectural Background The OMA PoC Architecture [7] utilizes PTT Servers within the network that can perform such roles as a conference focus [8], 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 [7] 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 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 package to indicate these PoC Service Settings was defined in [9]. Immediatly after completing SIP registration the PTT Terminal sends a SIP PUBLISH request [10] containing the PoC Service settings 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 Allen & Soloway Expires August 22, 2015 [Page 4] Internet-Draft PoC Instance ID usage February 2015 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 was OMA PoC 1.0 and was later enhanced as OMA PoC 2.0. Additional enhancements were added as part of OMA PoC 2.1 and then the enabler was updated for use over 3GPP LTE as OMA PCPS. 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 record (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 [11] the PTT Server can also determine if multiple PTT Terminals share the same PoC Address and 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 Allen & Soloway Expires August 22, 2015 [Page 5] Internet-Draft PoC Instance ID usage February 2015 of SIP requests and SIP responses 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 the requests and responses that it sends towards the remote party. In parallel to the development of OMA PoC, 3GPP has continued to enhance the IP Multimedia Subsystem (IMS) which is a SIP based network which can be used to deploy OMA PoC and PCPS for mobile networks. 3GPP TS 24.229 [12] makes using the IMEI URN defined in RFC 7254 [13] as the SIP Instance ID (see RFC 7255 [2]) mandatory for 3GPP mobile terminals from 3GPP release 10. However RFC 7255 [2] does not allow inclusion of the IMEI as the SIP Instance ID in the Contact header field of non-register requests or responses except when the request or response is related to an emergency session. Thus when OMA PoC or PCPS enablers are deployed on 3GPP terminals compliant with 3GPP release 10 or later the use of the SIP Instance ID by OMA PoC and PCPS will not comply with the requirements of RFC 7255 [2]. 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 IMEI as an instance ID as defined in RFC 7255 [2] and in RFC 7254 [13]. The same privacy concerns apply when using the IMEI URN as an instance ID. RFC 7255 [2] 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, except when the request is related to an emergency session. Regulatory requirements can require that the IMEI be provided to the PSAP. Any future exceptions to this prohibition will require the publication of an RFC that addresses how privacy is not violated by such usage". RFC 7255 [2] also makes a similar prohibition on the use of the "sip.instance" media feature tag containing the GSMA IMEI URN in the Contact header field of responses without publication of an RFC that addresses how privacy is not violated by such usage. The OMA PoC usage of the instance ID as defined in this document 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 and responses. Since the PTT Server performing the Participating PoC Function does not Allen & Soloway Expires August 22, 2015 [Page 6] Internet-Draft PoC Instance ID usage February 2015 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 the Contact header field of non-register requests and responses are addressed. 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] Allen, A., "Using the International Mobile station Equipment Identity (IMEI) Uniform Resource Name (URN) as an Instance ID", RFC 7255, May 2014. [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] TIA, , "Project 25 TIA-102: Documentation Suite Overview", TSB 102, Edition B, June 2012. [5] ETSI, , "Terrestrial Trunked Radio (TETRA);Voice plus Data (V+D);Part 1: General network design", EN 300 392-2, v1.4.1 (2009-01), January 2009. [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [7] OMA, , "Push-To-Talk over Cellular - Architecture", OMA- AD-PoC V2_0, 20110802 A, August 2011. [8] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006. [9] 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. [10] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004. Allen & Soloway Expires August 22, 2015 [Page 7] Internet-Draft PoC Instance ID usage February 2015 [11] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004. [12] 3GPP, , "TS 24.229: IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (Release 10)", 3GPP 24.229, December 2014, . [13] Montemurro, M., Allen, A., McDonald, D., and P. Gosden, "A Uniform Resource Name Namespace for the Global System for Mobile Communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI)", RFC 7254, May 2014. Authors' Addresses Andrew Allen (editor) Blackberry 1200 Sawgrass Corporate Parkway Sunrise, Florida 33323 USA Phone: unlisted Fax: unlisted Email: aallen@blackberry.com Alan Soloway Qualcomm 5775 Morehouse Drive San Diego, California 92121 USA Phone: unlisted Fax: unlisted Email: asoloway@qti.qualcomm.com Allen & Soloway Expires August 22, 2015 [Page 8]