SIPPING Working Group Document: draft-sriram-sipping-poc-lip-02.txt Internet-Draft Motorola Expires: February 17, 2006 August 17, 2005 Lawful Intercept procedure via the Session Initiation Protocol (SIP) for the Open Mobile Alliance (OMA) Push to talk over Cellular (PoC) draft-sriram-sipping-poc-lip-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 17, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes the Lawful Intercept Procedure using Session Initiation Protocol (SIP) used by the Open Mobile Alliance (OMA), for S.Sriram Expires - February, 2006 [Page 1] LIR: Lawful Intercept Request May 2005 Push to talk over Cellular (PoC) along with their applicability, which is limited to the OMA PoC application. Table of Contents 1 Overall Applicability ............................... 2 2 Conventions ......................................... 2 3 Overview ............................................ 3 4 Definitions ......................................... 4 5 Lawful Interception Operation in PoC ................ 4 5.1 Procedure at the PoC User to perform Legal Interception ....................................... 4 5.2 Procedures at the PoC Server performing the Lawful Intercept function ................................. 5 5.2.1 PoC Control Plane Procedure ......................... 5 5.2.2 PoC User Plane Procedure ............................ 6 5.3 Procedure at the PoC User to stop Legal Interception ....................................... 7 5.4 Procedure at the PoC Server to stop Legal Interception ....................................... 7 6 Lawful Intercept Request Protocol Syntax ............ 7 6.1 Header Fields ....................................... 8 6.1.1 Mode-of-Tapping ...................................... 8 6.1.2 Direction ........................................... 9 6.1.3 PoC-User-to-be-Tapped ............................... 9 7 Illustrative Examples ............................... 9 8 IANA considerations ................................. 10 8.1 The "application/lir" mime type ..................... 10 9 Formal Syntax ....................................... 10 10 Security Considerations ............................. 11 11 References .......................................... 12 12 Copyright Statement ................................. 13 13 Disclaimer of Validity .............................. 13 14 Acknowledgment ...................................... 13 15 Author's Address .................................... 13 1 Overall Applicability The SIP extensions specified in this document make certain assumptions regarding network topology, and the availability 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 for which either no general-purpose solution was found, where insufficient operational experience was available to understand if a general solution is needed, or where a more general solution is not yet mature. For more details about the assumptions made about these extensions, consult the Applicability subsection for each extension. 2 Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", S.Sriram Expires - February, 2006 [Page 2] LIR: Lawful Intercept Request May 2005 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2]. 3 Overview The Open Mobile Alliance (OMA) (http://www.openmobilealliance.org) is specifying the Push-to-talk Over Cellular (PoC) service where SIP is the protocol used to establish half duplex media sessions across different participants. Push to talk over Cellular (PoC) is intended to provide rapid communications for business and consumer customers of mobile networks. PoC will allow user voice and data communications shared with a single recipient, (1-to-1) or between groups of recipients as in a group chat session, (1-to-many). This document describes the procedure for Lawful Interception of the PoC via SIP signaling. The PoC Server implements the application level network functionality for the PoC service and shall provide centralized PoC Session handling, media distribution and Talk Burst Control functionality. The PoC Service uses a half duplex type of communication and only one PoC User in a PoC Session can send media at the time. The PoC User does not send a continuous stream of RTP Media packets instead the media is sent in bursts, in this document referred to as a Talk Burst. A PoC Server located between the PoC Users communicating with each other acts as an arbitrator and controls the sending of Talk Burst using a Talk Burst Control Protocol (TBCP). PoC Users are located on mobile devices hence the quality of the transmission may vary depending on access network and distance to the base station. All RTP Media packets, RTCP packets and TBCP messages (RTCP APP or other negotiated TBCP) flow through the PoC Server performing the Participating PoC function (if inserted in the transport path) and are terminated in the PoC Server performing the Controlling PoC Function. The transport path between the PoC User and the PoC Server performing the Controlling PoC Function is established on a per PoC Session basis. When the PoC Session is established, the PoC Server performing the Participating PoC Function normally includes itself into the transport path to relay the RTP Media packets, RTCP packets and TBCP messages between the PoC User and the PoC Server performing the Controlling PoC Function and act as a translator according to [RFC3550]. Considering a case where a PoC Server performing the Participating PoC Function has inserted itself in the transport path. When the transport path includes the Participating PoC Function, the PoC Server (performing the Participating PoC Function) forwards RTP Media packets, RTCP packets and TBCP messages between the PoC User and the PoC Server (performing the Controlling PoC Function). This is done when the PoC server is used to support lawful intercept procedures. S.Sriram Expires - February, 2006 [Page 3] LIR: Lawful Intercept Request May 2005 This document proposes the approach to perform the the Lawful Intercept procedure via SIP signaling for OMA PoC. The PoC server processes the Lawful Intercept request information generated in the SIP request received from the PoC user and performs the Lawful Intercept procedure. 4 Definitions The following OMA PoC related definitions are relevant to this document PoC Address: A PoC Address identifies a PoC User. The PoC Address can be used by one PoC User to request communication with other PoC Users. PoC User: A PoC User is a user of the PoC service. PoC Client: A PoC Client is a PoC functional entity that resides on the PoC User Equipment that supports the PoC service. Talk Burst: A Talk Burst is the flow of media from a PoC User while that has the permission to send media. The following definitions are relevant to this document FBI Agent: The FBI Agent is a PoC Client/User who has special access to tap any other PoC user supported by the PoC server. Mode-of-Tapping: The tapping shall be done in split or combined mode. In Split mode, the FBI agent SHALL be able to listen to either SEND or RECEIVE media stream of the PoC user who is tapped. The "Direction" in this context specifies SEND stream or RECEIVE stream. In combined mode, the FBI agent SHALL be able to listen to both the SEND and RECEIVE media streams of the PoC user who is tapped. 5 Lawful Interception Operation in PoC The Lawful Interception request information contains a series of information lines. Each line contains some part of the operation information and follows text based encoding rules and procedures that could be carried in the SIP signaling message. 5.1 Procedure at the PoC User to perform Legal Interception: The FBI Agent, who has the special privileges to listen to any PoC User, is himself a PoC User. The FBI Agent (PoC User) 1. SHALL Set the Request-URI of the SIP INVITE request to the Conference-factory-URI for the PoC service in the Home PoC Network. S.Sriram Expires - February, 2006 [Page 4] LIR: Lawful Intercept Request May 2005 2. SHALL add the Lawful Intercept Message body which carries the information regarding a. PoC User to be tapped. b. The mode in which the tapping should be done.(Split or Combined mode) c. The direction in which the tapping should be done.(Only in case of split mode.(send or receive)) i. If "direction=send", the FBI agent (PoC User) requests for tapping only the media streams sent out by the PoC User who is to be tapped. ii.If "direction=receive", the FBI agent (PoC User) requests for tapping only the media streams that is received the PoC User who is to be tapped. 3. SHALL generate an initial SIP INVITE request according to the rules and procedures of [RFC3261] and the general procedure as in section 6.1.3.1 with the media stream direction as "sendonly" in the session description parameter FBI Agent (PoC User) SHALLL be challenged and authenticated by the PoC Server for authorization credentials and the same shall be sent by the FBI Agent (PoC User) in the second INVITE request towards the PoC Server. If the authentication was successful and if the PoC server was able to successfully extract the Lawful Intercept message and process it successfully, then the FBI Agent (PoC User) SHALL receive a 200 OK from the PoC Server with the media description parameters of the PoC Server. The FBI Agent (PoC User) SHALL send an ACK for 200 OK and listen on the RTP port for media streams sent by the PoC server. 5.2 Procedures at the PoC Server performing the Lawful Intercept function: 5.2.1 PoC Control Plane Procedure 1. Upon receiving an initial SIP INVITE request the PoC Server SHALL check - if it is the Terminating PoC Service Point. - if the SIP URI in the Request-URI of the SIP INVITE request corresponds to the Conference-factory-URI of the PoC service in the network served by the PoC Server. If both the checks are valid, then the PoC Server SHALL check if the SIP message contains the Lawful Intercept Message body. If this message body is present,the PoC server SHALL challenge the authenticity of the FBI agent by sending a 407 SIP response message with the realm, nonce, qop, opaque and algorithm to the FBI Agent (PoC User). S.Sriram Expires - February, 2006 [Page 5] LIR: Lawful Intercept Request May 2005 2. Upon receiving the second INVITE from the FBI Agent (PoC User), the PoC server shall authenticate all the credentials to confirm that the PoC user(FBI Agent) has all the privileges to use the Lawful Intercept Message body. 3. If the credentials supplied by the FBI Agent (PoC User) are valid, then the PoC server SHALL read the Lawful Intercept Message body and get the details of a. PoC User to be tapped. b. The mode in which the tapping should be done.(Split or Combined mode explained below) c. The direction in which the tapping should be done.(Only in case of split mode.(send or receive)) 4. The PoC server shall check if it is the terminating PoC Service Point for the PoC User URI mentioned in the Lawful Intercept Message body. If so, then the PoC Server SHALL send a 200 OK for the INVITE with the SDP answer according to the rules and procedures of [RFC 3264] and [RFC 3267]. 5. The PoC server SHALL interact with the PoC User Plane and instruct the Controlling PoC Function to start the legal intercept procedure by providing the following information: a. FBI Agent's (PoC User's) SDP profile b. The PoC User identification to be tapped. c. The mode of tapping to be followed. 5.2.2 PoC User Plane Procedure The Controlling PoC Function performing the Lawful Intercept function: 1. SHALL receive the identification of the PoC User to be tapped;(RTP port and IP address). 2. SHALL receive the identification of the FBI agent(s)(PoC User(s)); (RTP port and IP address). 3. SHALL receive the mode in which the tapping is to be done on the PoC User;(Combined or Split mode). 4. SHALL perform the tapping functionality via two modes of operation as listed: a. In Combined mode, The Controlling PoC Function takes on additional responsibility: - To transmit the RTCP SR and RTP packets sent by the PoC User that is tapped to the FBI agent (PoC User). S.Sriram Expires - February, 2006 [Page 6] LIR: Lawful Intercept Request May 2005 - To transmit the RTP SR and RTP packets sent by all other PoC Users in the same group call to the FBI agent (PoC User). b. In Split mode, The Controlling PoC Function takes on additional responsibility: - To transmit the RTCP SR and RTP packets sent by the PoC User that is tapped to the FBI agent (PoC User) if the direction requested for the tap creation is onl for 'send' media streams. - To transmit the RTP SR and RTP packets sent by all other PoC Users in the same group call to the FBI agent (PoC User) if the direction requested for the tap creation is only for 'receive' media streams. Note: As the FBI Agent(s) (PoC User(s)) are invisible to all other PoC users in the active group call, the controlling PoC function should not inform the RTCP SR compound packet sent by the FBI Agent(s) (PoC User(s)) to any of the PoC Users in the PoC Session. When the FBI agent (PoC User) wants to release the tap, the same SHALL be informed via the Control Plane and the Controlling PoC Function shall stop sending the multicast RTP packets to the FBI Agent(s) RTP port and shall release the reserved resources. 5.3 Procedure at the PoC User to stop Legal Interception: This procedure is same as the one mentioned in the section 6.1.6 in the PoC Control Plane document [Reference 3]. 5.4 Procedure at the PoC Server to stop Legal Interception: This procedure is same as the one mentioned in the section 7.2.1.9.1 in the PoC Control Plane document [Reference 3]. 6 Lawful Intercept Request Protocol Syntax The media type follows the conventions of the SIP (RFC 3261 [1]) for Lawful intercept request header information formatting. The Lawful intercept request header information contains a series of information headers with each of the information header lines terminated by a CRLF. Lawful-intercept request-info = *info-header info-header = "header-name" HCOLON header-value *(COMMA header value) CRLF S.Sriram Expires - February, 2006 [Page 7] LIR: Lawful Intercept Request May 2005 The basic set of information header fields are defined in this document. However the information elements can be extended adhering to the generic framework of header format defined above. The header field formats strictly adhere to the conventions defined for SIP in section 7.3.1 of RFC 3261. Each header field consists of a field name followed by a colon (":") and the field value. field-name: field-value The header names and the header values are case sensitive. 6.1 Header Fields This section lists the full set of header fields along with notes on syntax, meaning, and usage. The ABNF [8] definitions for the headers follow the notations on the basis of section 25 of SIP(RFC 3261[1]). The conditions for the presence of the header fields in the lawful intercept request information are summarized in Table 1. The following codes are used in the table. c: Conditional; requirements on the header field depend on other fields in the information. m: The header field is mandatory. o: The header field is optional. Header Field presence ____________________________________________________ Mode-of-Tapping m Direction c PoC-User-to-be-Tapped m Table 1: Presence of headers There is a specific requirement for the order in which the information headers should be present in the charging information. It is required that the Mode-of-Tapping header field be present as the first header field. The other header fields following this first header field shall be present in any order. 6.1.1 Mode-of-Tapping The Mode-of-Tapping header field defines the mode in which the tapping shall be done. There are two modes of tapping defined in this document: split mode, combined mode. S.Sriram Expires - February, 2006 [Page 8] LIR: Lawful Intercept Request May 2005 This header field MUST be present one and only once per Lawful intercept information. Mode-of-Tapping = " Mode-of-Tapping" HCOLON Modes-of-Tapping Modes-of-Tapping = "split" | "combined" Example: Mode-of-Tapping: split 6.1.2 Direction The Direction header field defines the direction in which the split mode of tapping is done. This header field shall be present only if the 'Mode-of-Tapping' is 'split' mode. This field can take two values: - 'send' indicating the SEND stream of the PoC user to be tapped, - 'receive'indicating the RECEIVE stream of the PoC user to be tapped. This header field MUST be present one and only once per billing information. Direction = "Direction" HCOLON Directions Directions = "send" | "receive" Example: Direction: send 6.1.3 PoC-User-to-be-Tapped The PoC-User-to-be-Tapped field defines the SIP/TEL URI of the PoC user who is to be tapped. This header field MUST be present one and only once per billing information. PoC-User-to-be-Tapped = "PoC-User-to-be-Tapped" HCOLON SIP-URI or TEL- URI SIP-URI = "sip:" [ userinfo ] hostport uri-parameters [ headers ] Example: PoC-User-to-be-Tapped: sip:sriram@motorola.com 7 Illustrative Examples The Lawful Intercept request information is sent in the INVITE method by the FBI Agent who wants to tap a PoC User listed in his request information. INVITE sip:FBI_Agent@conference-factoryURI.net SIP/2.0 P-Preferred-Identity: "FBI_Agent" Accept-Contact:*;+g.poc.talkburst; require;explicit S.Sriram Expires - February, 2006 [Page 9] LIR: Lawful Intercept Request May 2005 User-Agent: PoC-User/OMA1.0 Acme-Talk5000/v1.01 Authorization: Digest username=" FBI_Agent-private@networkA.net", realm="registrar.networkA.net", nonce="", uri="sip:registrar.networkA.net", response="" Privacy: Id Contact: Supported: Timer Session-Expires: 1800;refresher=uac Allow: INVITE,ACK,CANCEL,BYE,REFER,MESSAGE,SUBSCRIBE, NOTIFY,PUBLISH Content-Type: multipart/mixed; boundary=unique-boundary-1 Content-Length: 407 --unique-boundary-1 Content-Type: application/SDP v=0 o=ezimmerer 2890844526 2890842807 IN IP4 126.16.64.4 c=IN IP4 motds.mot.com m=audio 3456 RTP/AVP 97 a=Rtpmap:97 AMR a=rtcp:5560 m=application 2000 udp TBCP a=recvonly a=fmtp:TBCP queuing=1; tb_priority=2; timestamp=1 --unique-boundary-1 Content-Type: application/lir Mode-of-Tapping: split Direction: send PoC-User-to-be-Tapped: sip:sriram@motorola.com --unique-boundary-1-- 8 IANA considerations 8.1 The "application/lir" mime type This draft registers the "application/lir" MIME media type. The Lawful intercept request (lir) information is text-based. It follows the recommendations of RFC 2045[10] for the usage of text- based data for MIME. This media type is defined by the following information: Media type name: application Media subtype name: lir Required Parameters: None Encoding scheme: ASCII Security considerations: See section 10 S.Sriram Expires - February, 2006 [Page 10] LIR: Lawful Intercept Request May 2005 9 Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [3]. The grammar for this mime-type is mostly derived out of the SIP specification (RFC 3261[1]). The following definitions are derived from the SIP specification (RFC 3261[1]) token DIGIT HCOLON quoted-string Lawful-Intercept-Request-Info = *(Information-Header) Information-Header = (Advice-State / Mode-of-Tapping / Direction / PoC-User-to-be-Tapped) Mode-of-Tapping = " Mode-of-Tapping" HCOLON Modes-of-Tapping Modes- of- Tapping = "split" | "combined" Direction = "Direction" HCOLON Directions Directions = "send" | "receive" PoC-User-to-be-Tapped = "PoC-User-to-be-Tapped" HCOLON SIP-URI or TEL- URI SIP-URI = "sip:" [ userinfo ] hostport uri-parameters [ headers ] 10 Security Considerations The Lawful Intercept request message body contains sensitive information that requires the use of encryption. Lawful Intercept request information should not be trusted until it is ensured that it is received through reliable sources. As a reference, security mechanisms provided in SIP [1] (section 26.1.3) can be used as this is appropriate for both the SIP message and the encapsulated Lawful intercept request information. Encryption of the Lawful intercept request information is also considered a good solution. Some form of cryptographic hashing on the Lawful intercept request information may be used to ensure there is no tampering of the message en-route. MD5 (RFC 1321[14]) is a good choice. However, OMA PoC standards does not mandate any security mechanisms, a cryptographic hash of the Lawful intercept request information along S.Sriram Expires - February, 2006 [Page 11] LIR: Lawful Intercept Request May 2005 with a shared key SHOULD be carried as a part of the Lawful intercept request information. PoC Server SHALL authenticate the FBI Agent (PoC User) credentials and SHALL process the Lawful Intercept Message body only after confirming that the PoC User has the rights to intercept the call of another PoC User. 11 References 1 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. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 OMA PoC Control Plane Candidate Version 1.0 û 17 March 2005, Open Mobile Alliance OMA-TS-POC-ControlPlane-V1_0-20050317-C 4 PoC User Plane Version Candidate Version 1.0 û 17 March 2005, Open Mobile Alliance OMA-TS_PoC-UserPlane-V1_0-20050317-C 5 Push to talk over Cellular (PoC) - Architecture Candidate Version 1.0 û 17 March 2005, Open Mobile Alliance OMA-AD_PoC-V1_0-20050317-C 6 J. Galvin, Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted, RFC:1847, October 1995 7 B. Ramsdell, Editor, S/MIME Version 3 Message Specification, RFC:2633, June 1999 8 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997 9 Freed, N., Klensin, J. and J. Postel, "Multipart Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996. 10 Freed, N. and N. Borenstein, "Multipart Internet Mail Extensions(MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. 11 Freed, N. and N. Borenstein, "Multipart Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. 12 Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. S.Sriram Expires - February, 2006 [Page 12] LIR: Lawful Intercept Request May 2005 13 W. Marshall, Ed., F. Andreasen, Ed Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture, RFC 3603, October 2003 14 IAB, IETF Policy on Wiretapping, RFC 2804,May 2000 12 Copyright Statement This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 13 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 14 Acknowledgment I would like to thank my Manager Mr S Hariprasad for constant support and encouragement for proposing a draft on Lawful intercept procedure in OMA PoC via SIP signaling. 15 Author's Addresses S.Sriram 4-D9-170, Motorola No.66/1, Plot No. 5, Bagmane Techpark CV Raman Nagar Post Bangalore - 560 093 DID phone: 91-80-26014170 Mobile: 91-9886704956 Fax: 91-80-25343100 Email: sriram.s@motorola.com S.Sriram Expires - February, 2006 [Page 13]