SIPPING Working Group J. Hautakorpi Internet-Draft G. Camarillo Expires: July 5, 2007 Ericsson Jan 2007 The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header) draft-hautakorpi-sipping-uri-list-handling-refused-01.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 July 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document specifies the Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header). This P-Header is used in the Open Mobile Alliance's (OMA) Push to talk over Cellular (PoC) system. It enables URI-list servers to refuse the handling of an incoming URI-list, which has an embedded URI-list inside it. This P-Header also makes it possible for the URI-list server to inform the client about the embedded URI-list that caused the rejection and the Hautakorpi & Camarillo Expires July 5, 2007 [Page 1] Internet-Draft The P-Refused-URI-List P-Header Jan 2007 individual URIs that form such a URI-list. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 5. Syntax of P-Refused-URI-List Header Field . . . . . . . . . . 6 6. Response Generation . . . . . . . . . . . . . . . . . . . . . 6 7. Message Sequence Example . . . . . . . . . . . . . . . . . . . 7 8. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Hautakorpi & Camarillo Expires July 5, 2007 [Page 2] Internet-Draft The P-Refused-URI-List P-Header Jan 2007 1. Introduction The Open Mobile Alliance (OMA) has specified the Push to talk over Cellular (PoC) service, which uses the Session Initiation Protocol (SIP) [3] and Uniform Resource Identifier (URI)-list services [5] (more information about OMA PoC can be found at [8]). OMA PoC needs a mechanism for servers to refuse the handling of incoming URI-lists when these have embedded URI-lists inside them. Such a mechanism is intended to be used to establish a particular type of PoC session called ad-hoc PoC group. The remainder of this document is organized as follows. Section 3 describes the scenario where the mechanism will be used. Section 4 provides an overview of the mechanism, which includes a new P-Header called P-Refused-URI-List. Section 5 defines the syntax of this new P-Header. Section 6 specifies how to use the P-Header. Section 7 provides a usage example. Section 8 describes the applicability of the P-Header. Security considerations are discussed in Section 9 and finally the IANA consideration are stated in Section 10. 2. 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 RFC 2119 [1]. 3. Usage Scenario An ad-hoc PoC group is a type of multi-party PoC session. The originator or a particular ad-hoc PoC group chooses in an ad-hoc manner (e.g., selecting them from an address book) the set of participants in the ad-hoc PoC group. In order to establish the ad- hoc PoC group, the originator sends an INVITE request with a URI list, which contains the URIs of those participants. The PoC network, following the procedures defined in [6], receives such an INVITE request and generates an individual INVITE request towards each of the URIs in the URI list. In previous versions of the OMA PoC service, the originator of an ad- hoc PoC group was only allowed to populate the initial URI list with URIs identifying individual users. Later versions of the service allow the originator to also include entries that do not represent individual users, but also represent URI lists themselves. That is, the initial URI list would carry entries that are URI lists Hautakorpi & Camarillo Expires July 5, 2007 [Page 3] Internet-Draft The P-Refused-URI-List P-Header Jan 2007 themselves. The expected service behavior in such a case is that all the members of the embedded URI lists are also invited to join the ad-hoc PoC group. Figure 1 illustrates this point. The originator places the URI list friends@example.org in inside its initial URI list. The PoC network resolves friends@example.org into its members, which are bob@example.org and carol@example.net, and sends INVITE requests to all the recipients. 2. INVITE +------------------> | alice@example.com | | +-------------+ | | 1. INVITE | | 3. INVITE ------------------>| PoC Network |----------------> alice@example.com | | bob@example.org friends@example.org | | +-------------+ | | | | 4. INVITE +------------------> carol@example.net Figure 1: PoC Expected Behavior The PoC network in Figure 1 consists of PoC servers, which are SIP entities that can behave as proxies or B2BUAs (Back-to-back User Agents). There are two types of PoC servers: controlling and participating. In an ad-hoc PoC group, there is always exactly one controlling PoC server. However, there can be any number of participating PoC servers. The controlling PoC server of an ad-hoc PoC group is the only PoC server that can resolve an incoming URI list and send INVITEs to its members. Every participant in an ad-hoc PoC group has an associated participating PoC server. Figure 2 shows how the PoC network behaves in the scenario shown in Figure 1. A PoC user agent sends an INVITE request (1) with URI list in its body to its PoC server. The PoC server receives the INVITE request becomes the controlling PoC server for the ad-hoc PoC group Hautakorpi & Camarillo Expires July 5, 2007 [Page 4] Internet-Draft The P-Refused-URI-List P-Header Jan 2007 and sends an INVITE request to each of the URIs in the URI list. +-------------+ 2. INVITE | Particip. | +------------------>| PoC server |-> | alice@example.com | example.com | | +-------------+ | +-------------+ 3. INVITE +-------------+ | |-------------------->| | 1. INVITE | Controlling | friends@example.org | Particip. | ---------------->| PoC server | | PoC server |-> alice@example.com | | 4. 403 Forbidden | example.org | friends@example.org| |<--------------------| | +-------------+ bob@example.org +-------------+ | | carol@example.net ^ | | | | | 5. INVITE | | +--------------------------------+ | bob@example.org | | +------------+ | 6. INVITE | Particip. | +------------------>| PoC server |-> carol@example.net | example.net| +------------+ Figure 2: PoC Network Behavior The first URI, alice@example.com, identifies a single user. However, the second URI in the URI list, friends@example.org, identifies a URI list. In PoC terminology, the URI identifies a pre-arranged PoC group. The PoC server at example.org cannot send INVITE requests to the member of friends@example.org because it is not the controlling PoC server for the ad-hoc PoC group. Instead, it informs the controlling PoC server that friends@example.org is a list whose members are bob@example.org and carol@example.net. On receiving this information, the controlling PoC server generates INVITE requests towards the members of the list. At present, there is no mechanism for a participating PoC server to inform a controlling PoC server about the fact that a URI identifies a list and about the members of that list. This document defines such a mechanism: the P-Refused-URI-List P-Header. Hautakorpi & Camarillo Expires July 5, 2007 [Page 5] Internet-Draft The P-Refused-URI-List P-Header Jan 2007 4. Overview of Operation When a URI-list server receives an INVITE request with a URI list, some of which entries are URI lists themselves that the server cannot handle, it returns a 403 (Forbidden) response with a P-Refused-URI- List P-Header, as shown in Figure 3. The P-Refused-URI P-Header contains the members of the URI list or lists that caused the rejection of the request. This way, the client can send requests directly to those member URIs. +---------+ INVITE request +----------+ | |------------------------------>| | | | [URI-list in a URI-list] | URI-list | | Client | | server | | | 403 Forbidden | | | |<------------------------------| | | | [Content of refused URI-list] | | +---------+ +----------+ Figure 3: Operational Overview 5. Syntax of P-Refused-URI-List Header Field The following is the augmented Backus-Naur Form (BNF) [4] syntax of the P-Refused-URI-List P-Header: P-Refused-URI-List = "P-Refused-URI-List" HCOLON uri-list-entry *(COMMA uri-list-entry) uri-list-entry = ( name-addr / addr-spec ) *( SEMI refused-param ) refused-param = members-param / generic-param members-param = "members" EQUAL LDQUOT *( qdtext / quoted-pair ) RDQUOT The members P-Header parameter MUST contain a cid-url, which is defined in RFC 2392 [2]. The HCOLON, SEMI, EQUAL, LDQUOT, RDQUOT, and generic-param are defined in [3]. 6. Response Generation A 403 (Forbidden) response can contain more than one P-Refused-URI- List entries. The P-Refused-URI-List header field MUST NOT be used with any other response. The P-Refused-URI-List P-Header contains Hautakorpi & Camarillo Expires July 5, 2007 [Page 6] Internet-Draft The P-Refused-URI-List P-Header Jan 2007 one or more URIs, which were present in the URI-list in the incoming request and could not be handled by the server. Additionally, the P-Refused-URI-List can optionally carry the members of the URI lists identified by those URIs. The 403 (Forbidden) response MAY contain body parts which contain URI-lists. Those body parts can be referenced by the P-Refused-URI- List entries through their Content-IDs [2]. If there is a Content-ID defined in the P-Refused-URI-List, one of the body parts MUST have an equivalent Content-ID. The format of a URI-list is service specific. This kind of message structure enables clients to determine which URI relates to which URI-list, if the URI-list server is willing to disclose that information. Furthermore, the information enclosed in the URI lists enable clients to take further actions to remedy the rejection situation (e.g., send individual requests to the members of the URI list). 7. Message Sequence Example In the following message sequence example, a controlling PoC server sends an INVITE request to a participating PoC server. The participating PoC server rejects the request with a 403 (Forbidden) response. The 403 response has a P-Refused-URI-List P-Header that carries the members of the rejected URI-lists in the body of the message. Controlling PoC server Participating PoC server example.com example.net | | | INVITE | |-------------------------------->| | | | 403 Forbidden | |<--------------------------------| | | Figure 4: Message Sequence Example The INVITE request shown in Figure 4 is the following (Via header fields are not shown for simplicity): Hautakorpi & Camarillo Expires July 5, 2007 [Page 7] Internet-Draft The P-Refused-URI-List P-Header Jan 2007 INVITE sip:poc-service@example.net SIP/2.0 Max-Forwards: 70 From: PoC service ;tag=4fxaed73sl To: PoC service Call-ID: 7xTn9vxNit65XU7p4@example.com CSeq: 1 INVITE Contact: Require: recipient-list-invite Content-Type: multipart/mixed;boundary="boundary1" Content-Length: 538 --boundary1 Content-Type: application/sdp (SDP not shown) --boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list --boundary1-- The URIs sip:friends-list@example.net and sip:colleagues-list@example.net in the example above are actually references to URI lists (i.e., pre-arranged PoC groups). In the following response, the URI lists are in the XML resource list format [7]. The content of the 403 (Forbidden) response in Figure 4 is the following (Via header fields are not shown for simplicity): Hautakorpi & Camarillo Expires July 5, 2007 [Page 8] Internet-Draft The P-Refused-URI-List P-Header Jan 2007 SIP/2.0 403 Forbidden From: PoC service ;tag=4fxaed73sl To: PoC service ;tag=814254 Call-ID: 7xTn9vxNit65XU7p4@example.com CSeq: 1 INVITE P-Refused-URI-List: sip:friends-list@example.net; members= P-Refused-URI-List: sip:colleagues-list@example.net; members= Conten-Type: multipart/mixed;boundary="boundary1" Content-Length: 745 --boundary1 Content-Type: application/resource-lists+xml Content-Disposition: uri-list Content-ID: --boundary1 Content-Type: application/resource-lists+xml Content-Disposition: uri-list Content-ID: --boundary1-- From the 403 (Forbidden) response above controlling PoC server can determine the members of sip:friend-list@example.net and sip:colleagues-list@example.net from the message body. Furthermore, the controlling PoC server can deduce that the participating PoC server has not sent any outgoing requests, per regular URI-list server procedures. Hautakorpi & Camarillo Expires July 5, 2007 [Page 9] Internet-Draft The P-Refused-URI-List P-Header Jan 2007 8. Applicability The P-Refused-URI-list header field is intended to be used in OMA PoC networks. This header field is used between PoC servers and carries information about those URI-lists that were rejected by the server receiving the request. The OMA PoC services is designed so that, in a given session, only one server can resolve incoming URI lists and send INVITEs to its members. This restriction is not present on services developed to be used on the public Internet. Therefore, the P-Refused-URI-List P-Header does not seem to have general applicability outside the OMA PoC service. Additionally, the use of the P-Refused-URI-List P-Header requires special trust relationships between servers that do not typically exist on the public Internet. It is important to note that the P-Refused-URI-List is optional and does not change the basic behavior of a SIP URI-list service. The P-Refused-URI-List only provides clients with additional information about the refusal of the request. 9. Security Considerations It is assumed that the network elements handling the P-Refused-URI- List P-Header are trusted. Also, attackers are not supposed to have access to the protocol messages between those elements. This is because the P-Refused-URI-List is intended to be used in the OMA PoC environment, which is implemented in the operators' core network. Traffic protection between network elements is achieved by using IP Security (IPsec) and sometimes by physically protecting the network. However, implementors and administrators should be aware of two special security consideration related to the use of P-Refused-URI- List: Eavesdropping: 403 (Forbidden) responses may contain information about the members of a given URI list. Eavesdroppers can acquire this information if the 403 (Forbidden) responses are not encrypted. Therefore it is RECOMMENDED that either hop-by-hop or end-to-end encryption is used. Hautakorpi & Camarillo Expires July 5, 2007 [Page 10] Internet-Draft The P-Refused-URI-List P-Header Jan 2007 Disclosing information: A rogue entity may be able to acquire information about the members of a given URI list if the URI-list server sends information about those URI-lists also to unauthorized users. Therefore, it is RECOMMENDED that URI-list server discloses the content of URI-list only to authorized clients. 10. IANA Considerations The IANA is requested to make two additions to the Session Initiation Protocol (SIP) Parameters registry. The first addition is to add the following header field to the already existing Header Fields sub- registry Header Name compact Reference ----------------- ------- --------- P-Refused-URI-List [RFCxxxx] The second addition is to add the following header field parameter to the already existing Header Field Parameters and Parameter Values sub-registry. Predefined Header Field Parameter Name Values Reference ---------------------------- --------------- --------- --------- P-Refused-URI-List members No [RFCxxxx] Note for the RFC Editor: The two occurrences of 'RFCxxxx' in the above should be a reference to the coming RFC number of this draft. 11. References 11.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998. [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] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. Hautakorpi & Camarillo Expires July 5, 2007 [Page 11] Internet-Draft The P-Refused-URI-List P-Header Jan 2007 [5] Camarillo, G. and A. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services", draft-ietf-sipping-uri-services-05 (work in progress), January 2006. [6] Camarillo, G. and A. Johnston, "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", draft-ietf-sip-uri-list-conferencing-00 (work in progress), September 2006. 11.2. Informative References [7] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", draft-ietf-simple-xcap-list-usage-05 (work in progress), February 2005. [8] "OMA PoC System Description: Draft Version 2.0", April 2006. Authors' Addresses Jani Hautakorpi Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Jani.Hautakorpi@ericsson.com Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Gonzalo.Camarillo@ericsson.com Hautakorpi & Camarillo Expires July 5, 2007 [Page 12] Internet-Draft The P-Refused-URI-List P-Header Jan 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Hautakorpi & Camarillo Expires July 5, 2007 [Page 13]