GEOPRIV H. Tschofenig Internet-Draft Siemens Intended status: Standards Track H. Schulzrinne Expires: March 21, 2007 Columbia U. September 17, 2006 A Presence-based GEOPRIV Layer 7 Location Configuration Protocol draft-tschofenig-geopriv-l7lcp-presence-00.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 March 21, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Tschofenig & Schulzrinne Expires March 21, 2007 [Page 1] Internet-Draft GEOPRIV-L7 Presence LCP September 2006 Abstract The GEOPRIV Layer 7 Location Configuration Protocol (LCP) is an application layer protocol to allow an end host to create a presence URI by a Location Information Server (LIS) that is located in the access network. This document describes how existing SIP presence work can be utilized. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. High-Level Message Exchange . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Behavior . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Client and Server Protocol Behavior . . . . . . . . . . . 6 3.2. PIDF/PIDF-LO Parameter Setting . . . . . . . . . . . . . . 7 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Applicability Statement . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Tschofenig & Schulzrinne Expires March 21, 2007 [Page 2] Internet-Draft GEOPRIV-L7 Presence LCP September 2006 1. Introduction The GEOPRIV Layer 7 Location Configuration Protocol is an application layer protocol to allow an end host to create a presence URI by a Location Information Server (LIS) that is located in the access network. This presence URI refers to a Presence Information Data Format Location Object (PIDF-LO) [RFC4119] and can be used for a variety of different protocols and purposes. For example, it can be used by the Target to obtain its own location information that subsequently serves as input to the Location-to-Service Translation Protocol (LoST) (see [I-D.ietf-ecrit-lost]) or to convey location within SIP to other entities (see [I-D.ietf-sip-location-conveyance]). 1.1. Assumptions This document makes the following assumptions: o The LIS is located in the access network and a corresponding LIS discovery mechanism is available (for example via a reverse DNS lookup or a DHCP option). o The Target is not assumed to share credentials with the LIS. The Target does not authenticate to the LIS when creating the presence URI. o This document does only create presence URIs that can be resolved into location objects by using the SIP presence mechanisms. o The usage of authorization policies for controlling the access to PIDF-LOs are not envisioned or at least they are not provided by the Target itself. o The LIS discovery procedure makes the domain name required for the SIP URI available to the Target. 1.2. Goals This document aims to provide a protocol that offers the following functionality: o It enables the end host to obtain a reference to a PIDF-LO from a special node, called the Location Information Server (LIS). This LIS is a SIP presence server. The reference is in the form of a presence URI. o The entity that knows the reference can subscribe to it in order to obtain the Location Object in the form of a PIDF-LO. Every Tschofenig & Schulzrinne Expires March 21, 2007 [Page 3] Internet-Draft GEOPRIV-L7 Presence LCP September 2006 entity that is in possession of the presence URI can resolve it. There are no authorization policies that need to be uploaded from the Target (or any other node) to the LIS for access control of a potential Location Recipient. Any node can play the role of a Location Recipient as long as it knows the reference (e.g., the Target, a Public Safety Answering Point (PSAP) or Location/ Presence Server). 1.3. High-Level Message Exchange Figure 1 shows a protocol exchange that allows the Target to obtain a presence URI pointing to a PIDF-LO from the Presence Server / LIS in the access network. Note that the discovery exchange is not known in this figure and it it also not described in this document. First, the Target obtains the IP address of the LIS and sends a SUBSCRIBE with a Request-URI equal to Geopriv-L7. This message is protected using Transport Layer Security, which is also not shown in the figure. The LIS uses the IP address of the Target to determine its current location information and creates a presence URI with a randomized username part. This presence URI is returned to the Target in a 302 status message. The Contact header carries the presence URI that will later be used with the SUBSCRIBE / NOTIFY mechanism to obtain the PIDF-LO. The latter exchange is not shown in the figure. +--------+ +----------+ | | | Presence | | Target | | Server / | | | | LIS | +--------+ +----------+ | | | | | SUBSCRIBE | | (Request-URI = | | Geopriv-L7@example.com) | |--------------------------->| | | | 302 Moved Temporarily | | (Contact header = | 7214148E0433AFE2FA2D48003D31172E@example.com | ) | |<---------------------------| | | Figure 1: Basic Message Exchange Tschofenig & Schulzrinne Expires March 21, 2007 [Page 4] Internet-Draft GEOPRIV-L7 Presence LCP September 2006 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 [RFC2119]. This document furthermore uses terms introduced in [I-D.tschofenig-geopriv-l7-lcp-ps]. We use the term Location Information Server (LIS) and Presence Server interchangable. Tschofenig & Schulzrinne Expires March 21, 2007 [Page 5] Internet-Draft GEOPRIV-L7 Presence LCP September 2006 3. Protocol Behavior 3.1. Client and Server Protocol Behavior Within this document we assume that the Target has already discovered the address of the LIS and the domain name of the access network. The Target MUST target the SUBSCRIBE message to the LIS and thereby bypassing any configured outbound SIP proxies. The resource the Target subscribes to is constructed based on the pre-defined username part 'Geopriv-L7' concatinated with the domain name of the access network as learned through the discovery procedure. The Target SHOULD NOT use its real presence identity but instead uses a randomly constructed identity since the Target SHOULD NOT want to disclose its own presence identity to the access network. The SUBSCRIBE message MUST be secured using Datagram Transport Layer Security (DTLS) when the message is sent via UDP or using Transport Layer Security (TLS) when the message is sent via TCP or SCTP. In any case, the LIS MUST be authenticated by the Target and connection security MUST be applied to prevent various attacks, including denial of service, man- in-the-middle and eavesdropping. Authentication of the Target to the LIS is NOT RECOMMENDED due to the key management difficulty particularly when considering emergency services that do not demand network access authentication. When the Presence Server receives a SUBSCRIBE with a Request-URI set to 'Geopriv-L7' then it needs to use source IP address in the IP header of the incoming SUBSCRIBE message to determine location information. Before performing any action and before allocating state information it is important that the Presence Server ensures that the IP address was not spoofed. A return routability check for the indicated IP address was, for example, performed using the previously executed Transport Layer Security (TLS) handshake or other spoofing prevention techniques are used in the network. The Presence Server stores location information along with the newly created presence URI that will be returned within the Contact header of the 302 message returned to the Target. The state is associated with a specific lifetime selected by the Presence Server. The created presence URI MUST fullfill the following requirements: o The username part of the presence URI MUST be hard to guess, i.e., it MUST contain a cryptographically random component of at least 128 bit length. o The username part of the presence URI MUST NOT contain any information that identifies the user, device or address of record. Tschofenig & Schulzrinne Expires March 21, 2007 [Page 6] Internet-Draft GEOPRIV-L7 Presence LCP September 2006 The duration of the validity of the Contact URI can be indicated through an Expires (see Section 20.19 of [RFC3261]) header field or an expires parameter in the Contact header field. If there is no explicit expiration time, then the returned URI MUST NOT be cached for future transactions. When the Target receives the 302 message it MUST evaluate the Expires header or the expires parameter in the Contact header field to determine how long to store the received presence URI carried in the Contact header. When the presence URI is sent to other entities using SIP then the description provided in [I-D.ietf-sip-location-conveyance] is applicable. For resolving the presence URI to a PIDF-LO the SIP-based mechanisms as described in [RFC3265], [I-D.ietf-simple-event-filter-funct], [I-D.ietf-simple-filter-format] and [I-D.ietf-geopriv-loc-filters] are used and hence they are outside the scope of this document. 3.2. PIDF/PIDF-LO Parameter Setting Since the PIDF-LO itself is created by a node that does not know a number of parameters it needs to be constructed in a way that is privacy safe. The following PIDF-LO parameter layout is mandated: 'usage-rules' Element: retransmission-allowed: This element MUST be set to 'no'. retention-expires: This field specifies an absolute date at which time the Recipient is no longer permitted to possess the location information and its encapsulating Location Object. The value of this field MUST be computed based on the lifetime of the presence URI, i.e., the Location Object and the presence URI MUST have the same lifetime. ruleset-reference: This element SHOULD NOT contain a URI to an external set of privacy rules. Tschofenig & Schulzrinne Expires March 21, 2007 [Page 7] Internet-Draft GEOPRIV-L7 Presence LCP September 2006 note-well: This element SHOULD NOT contain a human readable privacy statement. 'method' Element: This element SHOULD contain information about the way how location information was derived or discovered. 'provided-by' Element: This element might SHOULD contain the entity or organization that supplied this location information. Since the PIDF-LO is not signed it is highly RECOMMMENDED to provide information within this element. 'entity' Attribute of the Element: The value of the 'entity' attribute (see [RFC3863]) MUST be set based on the 'pres' URL of the presentity, i.e., the URI created by the LIS. The PIDF-LO created by the LIS MUST NOT be signed. Tschofenig & Schulzrinne Expires March 21, 2007 [Page 8] Internet-Draft GEOPRIV-L7 Presence LCP September 2006 4. Examples This section provides message flows to illustrate the usage of the proposed mechanism. Figure 2 shows a message flow with a third party acting as the Location Recipient and Figure 2 offers a description of the Target itself acting as a Location Recipient. Note that both message flows present different usage scenarios. Message (1) and (2) are described in Figure 1. The ability to convey a location reference in SIP is described in [I-D.ietf-sip-location-conveyance] and shown in message (3). The mechanism to subscribe to presence information is described in [RFC3265] and shown in message (4-7). UA Alice LIS SIP Proxy UAS-A UAS-B UAS-C | | | | | | | SUBSCRIBE | | | | | (1)|----------->| | | | | |----------------->| | 302 | | | (2)|<-----------| | | | | | | | SIP INVITE | | (3)|---------------------------->|----------------->| | Location (ref./body) | | | | | | | | | SUBSCRIBE | (4)| |<==================================| | | | | | 200 OK | (5)| |==================================>| | | | | | NOTIFY | (6)| |==================================>| | | | | | 200 OK | (7)| |<==================================| | | | | | | Figure 2: Message Flow with SUBSCRIBE by Third Party Subsequently, we depict sample SIP messages based on the exchange shown in Figure 2. Tschofenig & Schulzrinne Expires March 21, 2007 [Page 9] Internet-Draft GEOPRIV-L7 Presence LCP September 2006 (1) SUBSCRIBE Target->LIS SUBSCRIBE sip:Geopriv-L7@example.com SIP/2.0 To: From: ;tag=xfg9 Call-ID: 2010@target.example.com CSeq: 17766 SUBSCRIBE Max-Forwards: 70 Event: presence Accept: application/pidf+xml Contact: Expires: 600 Content-Length: 0 (2) 302 Moved Temporarily example.com LIS->Target SIP/2.0 302 Moved Temporarily Via: SIP/2.0/TCP target.example.com;branch=z9hG4bKnashds7 ;received=192.0.2.1 To: ;tag=ffd2 From: ;tag=xfg9 Call-ID: 2010@target.example.com CSeq: 17766 SUBSCRIBE Expires: 600 Contact: sip:7214148E0433AFE2FA2D48003D31172E@example.com Content-Length: 0 (3) INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP pc33.atlanta.example.com ;branch=z9hG4bK74bf9 Max-Forwards: 70 To: Bob From: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Location: <7214148E0433AFE2FA2D48003D31172E@example.com>, geo-loc Supported: location Accept: application/sdp, application/cpim-pidf+xml CSeq: 31862 INVITE Contact: Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ... --boundary1 Tschofenig & Schulzrinne Expires March 21, 2007 [Page 10] Internet-Draft GEOPRIV-L7 Presence LCP September 2006 Content-Type: application/sdp ...SDP here --boundary1 (4) SUBSCRIBE UAS-B->LIS SUBSCRIBE sip:7214148E0433AFE2FA2D48003D31172E@example.com SIP/2.0 To: From: ;tag=xfg9 Call-ID: 2010@target.example.com CSeq: 17766 SUBSCRIBE Max-Forwards: 70 Event: presence Accept: application/pidf+xml Contact: Expires: 600 Content-Length: 0 (5) 200 OK example.com LIS->UAS-B SIP/2.0 200 OK Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7 ;received=192.0.2.1 To: ;tag=ffd2 From: ;tag=xfg9 Call-ID: 2010@watcherhost.example.com CSeq: 17766 SUBSCRIBE Expires: 600 Contact: sip:server.example.com Content-Length: 0 (6) NOTIFY example.com LIS->UAS-B NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk From: ;tag=ffd2 To: ;tag=xfg9 Call-ID: 2010@watcherhost.example.com Event: presence Tschofenig & Schulzrinne Expires March 21, 2007 [Page 11] Internet-Draft GEOPRIV-L7 Presence LCP September 2006 Subscription-State: active;expires=599 Max-Forwards: 70 CSeq: 8775 NOTIFY Contact: sip:server.example.com Content-Type: application/pidf+xml Content-Length: ... [PIDF Document] (7) 200 OK UAS-B -> example.com LIS SIP/2.0 200 OK Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk ;received=192.0.2.2 From: ;tag=ffd2 To: ;tag=xfg9 Call-ID: 2010@watcherhost.example.com CSeq: 8775 NOTIFY Content-Length: 0 Message (1) and (2) are described in Figure 1. The mechanism to subscribe to presence information is described in [RFC3265] and shown in message (3-6). Subsequently, in this example a LoST findServiceByLocation query is sent to the LoST Server and it responds with the service URI (in this case a PSAP URI). This is shown in message (7) and (8). The corresponding description can be found in [I-D.ietf-ecrit-lost]. The obtained service boundary is then used as input for a subsequent SUBSCRIBE message in order to perform event notification filtering (see [I-D.ietf-simple-event-filter-funct], [I-D.ietf-simple-filter-format] and [I-D.ietf-geopriv-loc-filters]) whereby location filters are uploaded to the LIS to return a NOTIFICATION only when the Target moves outside the service boundary and a new LoST query would be necessary. This exchange is shown in message (9) and (10). In this example the Target does not move outside the service boundary but initiates an emergency call with the previously obtained information (see message (11) and (12)). Note that the Target might obtain most current location information for the emergency call or might use an UPDATE message to subsequently provide a location update. Tschofenig & Schulzrinne Expires March 21, 2007 [Page 12] Internet-Draft GEOPRIV-L7 Presence LCP September 2006 UA Alice LIS LoST Server PSAP | | | | | SUBSCRIBE | | | (1)|----------->| | | | | | | | 302 | | | (2)|<-----------| | | | | | | | SUBSCRIBE | | | (3)|===========>| | | | | | | | 200 OK | | | (4)|<===========| | | | | | | | NOTIFY | | | (5)|<===========| | | | | | | | 200 OK | | | (6)|===========>| | | | | | | | | | | |LoST findServiceByLocation | | (7)|~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | | | | | |LoST Response | | (8)|<~~~~~~~~~~~~~~~~~~~~~~~~~~~~| | | | | | | SUBSCRIBE | | | (9)|===========>| | | | | | | | 200 OK | | | (10)|<===========| | | | | | | | | | INVITE | (11)|----------------------------------------------->| | Location (value/body) | | | | 200 OK | (12)|<-----------------------------------------------| | | | | Figure 4: Message Flow with SUBSCRIBE by Target Tschofenig & Schulzrinne Expires March 21, 2007 [Page 13] Internet-Draft GEOPRIV-L7 Presence LCP September 2006 5. Applicability Statement A future version of this document will provide information regarding its appliability. Tschofenig & Schulzrinne Expires March 21, 2007 [Page 14] Internet-Draft GEOPRIV-L7 Presence LCP September 2006 6. Security Considerations A future version of this document will provide information how the security requirements listed in [I-D.tschofenig-geopriv-l7-lcp-ps] can be met. Tschofenig & Schulzrinne Expires March 21, 2007 [Page 15] Internet-Draft GEOPRIV-L7 Presence LCP September 2006 7. IANA Considerations This document does not require actions by IANA. Tschofenig & Schulzrinne Expires March 21, 2007 [Page 16] Internet-Draft GEOPRIV-L7 Presence LCP September 2006 8. Acknowledgment We would like to thank the Geopriv L7 design team (the members are listed in Section 11 of [I-D.tschofenig-geopriv-l7-lcp-ps]) for their input to this document. We would particuarly like to thank Brian Rosen for suggested some ideas listed in this document. Tschofenig & Schulzrinne Expires March 21, 2007 [Page 17] Internet-Draft GEOPRIV-L7 Presence LCP September 2006 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004. [RFC3261] 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. 9.2. Informative References [I-D.tschofenig-geopriv-l7-lcp-ps] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements", draft-tschofenig-geopriv-l7-lcp-ps-02 (work in progress), August 2006. [I-D.ietf-sip-location-conveyance] Polk, J. and B. Rosen, "Session Initiation Protocol Location Conveyance", draft-ietf-sip-location-conveyance-04 (work in progress), August 2006. [I-D.ietf-ecrit-lost] Hardie, T., "LoST: A Location-to-Service Translation Protocol", draft-ietf-ecrit-lost-01 (work in progress), September 2006. [I-D.ietf-geopriv-loc-filters] Mahy, R., "A Document Format for Filtering and Reporting Location Notications in the Presence Information Document Format Location Object (PIDF-LO)", draft-ietf-geopriv-loc-filters-00 (work in progress), March 2006. [I-D.ietf-simple-event-filter-funct] Khartabil, H., "Functional Description of Event Notification Filtering", Tschofenig & Schulzrinne Expires March 21, 2007 [Page 18] Internet-Draft GEOPRIV-L7 Presence LCP September 2006 draft-ietf-simple-event-filter-funct-05 (work in progress), March 2005. [I-D.ietf-simple-filter-format] Khartabil, H., "An Extensible Markup Language (XML) Based Format for Event Notification Filtering", draft-ietf-simple-filter-format-05 (work in progress), March 2005. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. Tschofenig & Schulzrinne Expires March 21, 2007 [Page 19] Internet-Draft GEOPRIV-L7 Presence LCP September 2006 Authors' Addresses Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Phone: +1 212 939 7004 Email: hgs+ecrit@cs.columbia.edu URI: http://www.cs.columbia.edu Tschofenig & Schulzrinne Expires March 21, 2007 [Page 20] Internet-Draft GEOPRIV-L7 Presence LCP September 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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). Tschofenig & Schulzrinne Expires March 21, 2007 [Page 21]