GEOPRIV WG M. Barnes, Ed. Internet-Draft Nortel Intended status: Standards Track Expires: January 10, 2008 July 9, 2007 HTTP Enabled Location Delivery (HELD) draft-ietf-geopriv-http-location-delivery-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 January 10, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract A Layer 7 Location Configuration Protocol (L7 LCP) is described that is used for retrieving location information from a server within an access network. The protocol includes options for retrieving location information either by-value or by-reference. The protocol supports mobile and nomadic devices through Location URIs. The protocol is an application-layer protocol that is independent of Barnes, et al. Expires January 10, 2008 [Page 1] Internet-Draft HELD July 2007 session-layer; an HTTP, web services binding is specified. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 6 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 6. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9 6.1. Protocol Binding . . . . . . . . . . . . . . . . . . . . . 9 6.2. Location Request . . . . . . . . . . . . . . . . . . . . . 10 6.3. Location Response . . . . . . . . . . . . . . . . . . . . 10 6.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10 7. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11 7.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11 7.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12 7.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 12 7.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 13 7.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 13 7.5. "locationURI" Parameter . . . . . . . . . . . . . . . . . 14 7.5.1. "expires" Parameter . . . . . . . . . . . . . . . . . 14 8. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. HTTP Binding WSDL . . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10.1. Return Routability . . . . . . . . . . . . . . . . . . . . 20 10.2. Transaction Layer Security . . . . . . . . . . . . . . . . 21 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1. Simple HTTP Binding Example Messages . . . . . . . . . . . 21 11.2. Simple Location Request Example . . . . . . . . . . . . . 24 11.3. Location Request Example for Multiple Location Types . . . 25 11.4. Sample LCS WSDL Document . . . . . . . . . . . . . . . . 26 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 12.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 27 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 27 12.3. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held:http . . . . . . . . . 27 12.4. MIME Media Type Registration for 'application/held+xml' . 28 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 15. Changes since last Version . . . . . . . . . . . . . . . . . . 29 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 16.1. Normative References . . . . . . . . . . . . . . . . . . . 30 16.2. Informative References . . . . . . . . . . . . . . . . . . 32 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 32 Barnes, et al. Expires January 10, 2008 [Page 2] Internet-Draft HELD July 2007 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 33 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 33 A.3. L7-3: Layer 7 and Layer 2/3 Provider Relationship . . . . 33 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 34 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 34 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 35 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 35 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 35 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . . . 37 Barnes, et al. Expires January 10, 2008 [Page 3] Internet-Draft HELD July 2007 1. Introduction The location of a Device is information that is useful for a number of applications. The L7 LCP problem statement and requirements document [11] provides some scenarios in which a Device might rely on its access network to provide the location information, such as such as fixed environments (e.g., DSL/Cable), mobile networks and wireless access networks. This document describes a protocol that can be used to acquire Location Information (LI) from a service within an access network. The service within an access network is assumed to be provided by a Location Configuration Server (LCS), as introduced in the L7 LCP problem statement and requirements document. This specification identifies two methods for acquiring LI. Location may be retrieved from a Location Configuration Server (LCS) by-value, that is, the Device may acquire a literal location object describing the location of the Device. Alternatively, the Device may request that the LCS provide a location reference in the form of a location URI or set of location URIs, allowing the Device to distribute its LI by-reference. Both of these methods are compatible, and both can be provided concurrently from the same LCS so that application needs can be addressed individually. This specification defines an XML-based protocol that enables the retrieval of LI from a LCS by a Device. This protocol can be bound to any session-layer protocol, particularly those capable of MIME transport; an HTTP binding is included as a minimum requirement. 2. Conventions 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 [1]. 3. Terminology This document uses the terms (and their acronym forms) Access Provider (AP), Location Information (LI), Location Object (LO), Device, Target, Location Server (LS), Location Generator (LG), Location Recipient (LR), Rule Maker (RM) and Rule Holder (RH) as defined in [7]. This document also includes definitions for the terms, Civic Location/Address, Geodetic Location, and Location Configuration Server, used within this document. These definitions may differ slightly from those used in other GEOPRIV documents, but the concepts are the same. Barnes, et al. Expires January 10, 2008 [Page 4] Internet-Draft HELD July 2007 For convenience, abbreviated versions of RFC 3693 [7] definitions are included. Notes are included following some of the definitions to clarify the context in which these terms are used in this document: Access Network Provider: See Access Provider (AP). Access Provider (AP): An organization that provides physical network connectivity to its customers or users, e.g., through digital subscriber lines, cable TV plants, Ethernet, leased lines or radio frequencies. Examples of such organizations include telecommunication carriers, municipal utilities, larger enterprises with their own network infrastructure, and government organizations such as the military. Note: this definition differs from that in [7] by the use of the more generic 'organization' rather than 'domain' - the general concept is the same. This term is used interchangeably with Access Network Provider in this document. Civic Location/Address: A location expressed in a form that is defined by civic demarcations. Civic addresses can be specialized for jurisdictional (general use) or postal (message delivery) purposes, or they can apply to either. Device: The technical device whereby the location is tracked as a proxy for the location of a Target. Geodetic Location: A location expressed in coordinate form. Location Configuration Server (LCS): The entity within the Access Provider's network that provides location information to clients. This term is introduced in [11] and refers to an entity capable of determining the location of an end point and providing that location information via the Location Configuration Protocol (LCP) to the requesting party. The requesting party is the end point itself or an authorized entity that acts on its behalf. Location Generator (LG): The entity that initially determines or gathers the location of the Target and creates Location Objects describing that location. Location Information (LI): The data that describes the location of a Device, either by-value or by-reference. The term LI does not include the representation of this data. Note: this terms is not officially defined in [7], but rather is assumed from the general usage throughout that document and within the GEOPRIV WG. Barnes, et al. Expires January 10, 2008 [Page 5] Internet-Draft HELD July 2007 Location Object (LO): An object conveying Location Information (and possibly privacy rules) to which Geopriv security mechanisms and privacy rules are to be applied. Note: this is a specific by-value representation of Location Information (LI). In this document, LO refers to PIDF-LO [8]. Location Server (LS): The LS is an element that receives publications of Location Objects from Location Generators and may receive subscriptions from Location Recipients. The LS applies the rules (which it learns from the Rule Holder) to LOs it receives from LGs, and then notifies LRs of resulting LOs as necessary. Note: This definition varies from that defined in [7] by defining the roles of the functional elements more explicitly. In some specifications the Location Server is referred to as a Location Information Server or LIS. In this context, the Location Server is distinct from what is alternatively referred to as a Registrar in other contexts. Location Recipient (LR): The entity that receives Location Information (LI). Rule Holder (RH): The entity that provides the rules associated with a particular target for the distribution of Location Information (LI). Rule Maker (RM): The authority that creates rules governing access to location information for a target (typically, this it the Target themselves). Target: A person or other entity whose location is communicated by a GEOPRIV Location Object (LO). 4. Overview and Scope This document describes an interface between a Device and a Location Configuration Server (LCS). The LCS is a service present within the same administrative domain as the Device (the access network). An Access Provider (AP) operates the LCS service so that Devices (and Targets) can retrieve LI. The LCS exists because not all Devices are capable of determining LI, and because, even if a device is able to determine its own LI, it may be more efficient with assistance. This document does not specify how LI is derived. This document is based on the attribution of the LI to a Device and not specifically a person (end user) or Target, based on the premise Barnes, et al. Expires January 10, 2008 [Page 6] Internet-Draft HELD July 2007 that location determination technologies are generally designed to locate a device and not a person. It is expected that, for most applications, LI for the device can be used as an adequate substitute for the end user's LI. Since revealing the location of the device almost invariably reveals some information about the location of the user of the device, the same level of privacy protection demanded by a user is required for the device. This approach may require either some additional assurances about the link between device and target, or an acceptance of the limitation that unless the device requires active user authentication, there is no guarantee that any particular individual is using the device at that instant. This document identifies two methods for acquiring LI. Location may be retrieved from a Location Configuration Server (LCS) by-value, that is, the Device may acquire a literal location in ther form of a PIDF-LO. Alternatively, the Device may request that the LCS provide a location reference in the form of a location URI or set of location URIs, allowing the Device to distribute its LI by-reference. Providing LI by-reference implies that a server is able to provide the Device with a public, globally-addressable URI. The following diagram shows the logical configuration of some of the functional elements identified in [7] and the LCS defined in [11] and where this protocol applies, with the Rule Maker and Target represented by the role of the Device. +---------------------------------------------+ | Access Network Provider | | | | +--------------------------------------+ | | | Location Configuration Server | | | | | | | | | | | | | | | | | | | +------|---------------------'---------+ | +----------|---------------------'------------+ | ' | ' HELD APP | ' Rule Maker - _ +-----------+ +-----------+ o - - | Device | | Location | and as specified in [8] MUST be applied. A default value of "no" SHALL be used for the element. A default value of 24 hours SHALL be used for value of any generated PIDF-LO documents. An LCS MAY provide a shorter value for but MUST NOT provide a value longer than 24 hours. Requesting location directly does not always address the requirements of an application. A Device can request a location URI instead of literal location. A Location URI is a URI [23] of any scheme, which a Location Recipient (LR) can use to retrieve LI. A location URI provided by an LCS can be assumed to be globally-addressable; that is, anyone in possession of the URI can access the LCS. This does not in any way suggest that the LCS is bound to reveal the location associated with the location URI. This issue is deemed out of scope Barnes, et al. Expires January 10, 2008 [Page 8] Internet-Draft HELD July 2007 for this document. The merits and drawbacks of using a Location URI approach are discussed in [16]. 6. Protocol Description As discussed in Section 5, this protocol provides for the retrieval of a Location or a Location URI from an LCS. Three messages are defined to support the location retrieval: locationRequest, locationResponse and error. Messages are defined as XML documents. The Location Request (locationRequest) message is described in Section 6.2. A Location Request from a Device indicates whether a Location (and the specific type of location) and/or a Location URI should be returned. The LCS replies with a response (locationResponse), including a PIDF-LO document and/or one or more Location URIs in case of success, or an error message in case of an error. A MIME type "application/held+xml" is registered in Section 12.4 to distinguish HELD messages from other XML document bodies. This specification follows the recommendations and conventions described in [20], including the naming convention of the type ('+xml' suffix) and the usage of the 'charset' parameter. Section 7 contains a more thorough description of the protocol parameters, valid values, and how each should be handled. Section 8 contains a more specific definition of the structure of these messages in the form of an XML Schema [12]. 6.1. Protocol Binding The HELD protocol is an application-layer protocol that is defined independently of any lower layers. This means that any protocol can be used to transport this protocol providing that it can provide a few basic features: o The protocol must have acknowledged delivery. o The protocol must be able to correlate a response with a request. o The protocol must provide authentication, privacy and protection against modification. Candidate protocols that could be used to address these purposes include: TCP [17], TLS [2], SASL [18], HTTP [3], SIP [22], BEEP [21] and SOAP [25] [26]. This document includes a binding that uses a combination of HTTP, TLS and TCP in Section 9. Barnes, et al. Expires January 10, 2008 [Page 9] Internet-Draft HELD July 2007 6.2. Location Request A location request is sent from the Device to the LCS when it requires LI. This request MUST include the type of location being requested such as civic location, location URI, etc. The type of LI that a Device requests is determined by the type of LI that is included in the "locationType" element. The location request is made by sending a document formed of a "locationRequest" element. The LCS uses the source IP address of the location request message as the primary source of identity for the requesting device or target. It is anticipated that other Device identities MAY be provided through schema extensions. The successful response to a location request is a document formed of a "locationResponse" element, unless the request fails, in which case the LCS SHOULD provide an error indication document. 6.3. Location Response The response to a Location request MUST contain either a PIDF-LO and/or Location URI(s), depending upon the requested "locationType". The "locationResponse" element MUST include a "code" attribute with a value of "success". A set of predefined error codes are included in Section 7.3. The response is in error if there is a value other than "success", since those MUST be sent using the error message Section 6.4. A Location URI MUST NOT contain any information that could be used to identify the Device or Target. It is RECOMMENDED that a Location URI contain a public address for the LCS and an anonymous identifier, such as a local identifer or unlinked pseudonym. 6.4. Indicating Errors In the event of an error, the LCS SHOULD respond to the Device with an error document. The error response applies to all request types and SHOULD also be sent in response to any unrecognized request. An error indication document consists of an "error" element. The "error" element MUST include a "code" attribute that indicates the type of error. A set of predefined error codes are included in Section 7.3. A code of "success" MUST NOT be used in an "error" element. Error responses MAY also include a "message" attribute that can include additional information. This information SHOULD be for diagnostic purposes only, and MAY be in any language. The language of the message SHOULD be indicated with an "xml:lang" attribute. Barnes, et al. Expires January 10, 2008 [Page 10] Internet-Draft HELD July 2007 7. Protocol Parameters This section describes, in detail the parameters that are used for this protocol. Table 1 lists the top-level components used within the protocol and where they are mandatory or optional for each of the messages. +------------------------+----------------+-----------------+-------+ | Parameter | Location | Location | Error | | | Request | Response | | +------------------------+----------------+-----------------+-------+ | responseTime | o | | | | (Section 7.1) | | | | | locationType | m | | | | (Section 7.2) | | | | | exact (Section 7.2.1) | o | | | | code (Section 7.3) | | m | m | | message (Section 7.4) | | o | o | | locationURI | | o | | | (Section 7.5) | | | | | expires | | m | | | (Section 7.5.1) | | | | +------------------------+----------------+-----------------+-------+ Table 1: Message Parameter Usage 7.1. "responseTime" Parameter The "responseTime" attribute indicates to the LCS how long the Device is prepared to wait for a response. This attribute MAY be added to a Location request message. The value of this attribute is indicative only, the LCS is under no obligation to strictly adhere to the time limit implied; any enforcement of the time limit is left to the requesting Device. This attribute is expressed with a decimal seconds value, which may include a decimal point. It is RECOMMENDED that systems support millisecond precision for this parameter. The LCS MUST provide the most accurate LI that can be determined within the specified interval. This parameter could be used as input when selecting the method of location determination, where multiple such methods exist. If this parameter is absent, then the LCS MUST return the most precise LI it is capable of determining. Barnes, et al. Expires January 10, 2008 [Page 11] Internet-Draft HELD July 2007 7.2. "locationType" Parameter The "locationType" element is included in a location request. It contains a list of LI types that are requested by the Device. The following list describes the possible values: any: The LCS SHOULD attempt to provide LI in all forms available to it. This value MUST be assumed as the default if no "locationType" is specified. The LCS SHOULD return location information in a form that is suited for routing and responding to an emergency call in its jurisdiction. The LCS MAY alternatively or additionally return a location URI. geodetic: The LCS SHOULD return a geodetic location for the Target. civic: The LCS SHOULD return a civic address for the Target. Any type of civic address may be returned. The LCS SHOULD ignore this value if a request for jurisdictional or postal civic address has been made and can be satisfied. jurisdictionalCivic: The LCS SHOULD return a jurisdictional civic address for the Target. postalCivic: The LCS SHOULD return a postal civic address for the Target. locationURI: The LCS SHOULD return a location URI for the Target. The LCS SHOULD return the requested location type or types. The LCS MAY provide additional location types, or it MAY provide alternative types if the request cannot be satisfied for a requested location type. If the "exact" attribute is present and set to "true" in a location request, then a successful LCS response MUST provide the requested location type only, with no additional location information. The "exact" attribute has no effect when this element is set to "any". The "SHOULD"-strength requirement on this parameter is included to allow for soft-failover. This enables a fixed client configuration that prefers a specific location type without causing location requests to fail when that location type is unavailable. Unless the "exact" attribute is set, the LCS MUST provide LI in any available form if it is unable to comply with the request. For example, a notebook computer could be configured to retrieve civic addresses, which is usually available from typical home or work situations. However, when using a wireless modem, the LCS might be unable to provide a civic address. 7.2.1. "exact" Attribute When the "exact" attribute is set to "true", it indicates to the LCS that the contents of the "locationType" parameter MUST be strictly followed. The default value of "false" allows the LCS the option of Barnes, et al. Expires January 10, 2008 [Page 12] Internet-Draft HELD July 2007 returning something beyond what is specified, such as a location URI when only a civic location was requested. A value of "true" indicates that the LCS MUST provide a location of the requested type or types or MUST provide an error. The LCS MUST provide the requested types only and these types SHOULD be specified in the same order as they were requested. The LCS SHOULD handle an exact request that includes a "locationType" element set to "any" as if the "exact" attribute were set to "false". 7.3. "code" Parameter All responses MUST contain a response code. The "code" attribute applies to the "error" and "locationResponse" messages. All errors are application-level errors, and MUST only be provided in successfully processed transport-level responses. For example where HTTP is used as the transport, HELD error messages MUST be accompanied by a 200 OK HTTP response. HELD error responses may be one of the following tokens: success: This code indicates that the request was successful. This code MUST not be used for an error response. requestError: This code indicates that the request was badly formed in some fashion. xmlError: This code indicates that the XML content of the request was either badly formed or invalid. generalLcsError: This code indicates that an unspecified error occurred at the LCS. locationUnknown: This code indicates that the LCS could not determine the location of the Device. unsupportedMessage: This code indicates that the request was not supported or understood by the LCS. timeout: This code indicates that the LCS could not satisfy the request within the time specified in the "responseTime" parameter. cannotProvideLiType: This code indicates that the LCS was unable to provide LI of the type or types requested. This code is used when the "exact" attribute on the "locationType" parameter is set to "true". 7.4. "message" Parameter The "locationResponse" and "error" messages MAY include a "message" attribute to convey some additional, human-readable information about the result of the request. This message MAY be included in any language, which SHOULD be indicated by the "xml:lang", attribute. The default language is assumed to be English. Barnes, et al. Expires January 10, 2008 [Page 13] Internet-Draft HELD July 2007 7.5. "locationURI" Parameter The "locationURI" element includes a single Location URI. Each Location URI that is allocated by the LCS is unique to the device that is requesting it. A "locationResponse" message MAY contain any number of "locationURI" elements. It is RECOMMENDED that the LCS allocate a Location URI for each scheme that it supports and that each scheme is present only once. URI schemes and their secure variants such as http and https should be regarded as two separate schemes. 7.5.1. "expires" Parameter The "expires" attribute indicates the time at which the Location URI provided by the LCS will expire. This attribute is included in the "locationResponse" message only. Responses to Locations requests for Location URIs MUST include the expiry time of the Location URI. 8. XML Schema This section gives the XML Schema Definition [12] of the "application/held+xml" format. This is presented as a formal definition of the "application/held+xml" format. Note that the XML Schema definition is not intended to be used with on-the-fly validation of the presence XML document. This document defines HELD messages. Barnes, et al. Expires January 10, 2008 [Page 14] Internet-Draft HELD July 2007 Barnes, et al. Expires January 10, 2008 [Page 15] Internet-Draft HELD July 2007 Barnes, et al. Expires January 10, 2008 [Page 16] Internet-Draft HELD July 2007 locationRequest message requests a location and/or a location URI. locationType being requested is specified as an element. A locationURI is explicitly requested by setting the locationURI attribute to true. Barnes, et al. Expires January 10, 2008 [Page 17] Internet-Draft HELD July 2007 9. HTTP Binding This section defines an HTTP [3] binding for this protocol, which all conforming implementations MUST support. This binding takes the form of a Web Service (WS) that can be described by the Web Services Description Language (WSDL) document in Section 9.1. The request is carried in this binding as the body of an HTTP POST request. The MIME type of both request and response bodies should be "application/held+xml". The LCS populates the HTTP headers so that they are consistent with the contents of the message. In particular, the "expires" and cache control headers are used to control the caching of any PIDF-LO document or Location URIs. The HTTP status code SHOULD have the same first digit as any "locationResponse" or "error" body included, and it SHOULD indicate a 2xx series response when a PIDF-LO document or Location URI is included. This binding also includes a default behaviour, which is triggered by a GET request, or a POST with no request body. If either of these queries are received, the LCS MUST attempt to provide either a PIDF-LO document or a Location URI, as if the request was a location request. This binding MUST use TLS as described in [4]. TLS provides message integrity and privacy between Device and LCS. The LCS MUST use the server authentication method described in [4]; the Device MUST fail a request if server authentication fails, except in the event of an emergency. Barnes, et al. Expires January 10, 2008 [Page 18] Internet-Draft HELD July 2007 9.1. HTTP Binding WSDL The following WSDL 2.0 [27] document describes the HTTP binding for this protocol. Actual service instances MUST provide a "service" with at least one "endpoint" that implements the "heldHTTP" binding. A service description document MAY include this schema directly or by using the "import" or "include" directives. This document describes the basic HELD sighting web service. Please refer to RFCXXXX for details. [[NOTE TO RFC-EDITOR: Please replace XXXX with the RFC number for this specification and remove this note.]] Barnes, et al. Expires January 10, 2008 [Page 19] Internet-Draft HELD July 2007 10. Security Considerations The threat model for this protocol assumes that the LCS exists within the same administrative domain as the Device. The LCS requires access to network information so that it can determine Location. Therefore, the LCS can use network information to protect against a number of the possible attacks. Specific requirements and security considerations for location acquisition protocols are provided in [11] including that the LCP MUST NOT assume prior network access authentication, which is addressed in Section 10.2 An in-depth discussion of the security considerations applicable to the use of Location URIs and by-reference provision of LI is included in [16]. 10.1. Return Routability It is RECOMMENDED that Location Configuration Servers use return routability rather than requiring Device authentication. Device authentication SHOULD NOT be required due to the administrative challenge of issuing and managing of client credentials, particularly when networks allow visiting users to attach devices. However, the LCS MAY require any form of authentication as long as these factors are considered. Addressing information used in a request to the LCS is used to determine the identity of the Device, and to address a response. This ensures that a Device can only request its own LI. Barnes, et al. Expires January 10, 2008 [Page 20] Internet-Draft HELD July 2007 A temporary spoofing of IP address could mean that a device could request a Location URI that would result in another Device's location. One or more of the follow approaches are RECOMMENDED to limit this exposure: o Location URIs SHOULD have a limited lifetime, as reflected by the value for the expires element (Section 7.5.1). o The network SHOULD have mechanisms that protect against IP address spoofing. o The LCS SHOULD ensure that requests can only originate from within its administrative domain. o The LCS and network SHOULD be configured so that the LCS is made aware of Device movement within the network and addressing changes. If the LCS detects a change in the network, then all location URIs MUST be invalidated. The above measures are dependent on network configuration and SHOULD be considered with circumstances in mind. For instance, in a fixed internet access, providers may be able to restrict the allocation of IP addresses to a single physical line, ensuring that spoofing is not possible; in such an environment, other measures may not be necessary. 10.2. Transaction Layer Security All bindings for this protocol MUST ensure that messages are adequately protected against eavesdropping and modification. Bindings MUST also provide a means of authenticating the LCS. It is RECOMMENDED that all bindings also use TLS [2]. For the HTTP binding, TLS MUST be used. TLS provides protection against eavesdropping and modification. The server authentication methods described in HTTP on TLS [4] MUST be used. 11. Examples 11.1. Simple HTTP Binding Example Messages The examples in this section show a complete HTTP message that includes the HELD request or response document. Barnes, et al. Expires January 10, 2008 [Page 21] Internet-Draft HELD July 2007 This example shows the most basic request for a LO. This uses the GET feature described by the HTTP binding. This example assumes that the LCS service exists at the URL "https://lcs.example.com/location". GET /location HTTP/1.1 Host: lcs.example.com Accept:application/held+xml, application/xml;q=0.8, text/xml;q=0.7 Accept-Charset: UTF-8,* The GET request is exactly identical to a minimal POST request that includes an empty "locationRequest" element. POST /location HTTP/1.1 Host: lcs.example.com Accept: application/held+xml, application/xml;q=0.8, text/xml;q=0.7 Accept-Charset: UTF-8,* Content-Type: application/held+xml Content-Length: 87 Barnes, et al. Expires January 10, 2008 [Page 22] Internet-Draft HELD July 2007 The successful response to either of these requests is a PIDF-LO document. The following response shows a minimal PIDF-LO response. HTTP/1.x 200 OK Server: Example LCS Date: Tue, 10 Jan 2006 03:42:29 GMT Expires: Tue, 10 Jan 2006 03:42:29 GMT Cache-control: private Content-Type: application/held+xml Content-Length: 594 -34.407 150.88001 2006-01-11T03:42:28+00:00 2006-01-10T03:42:28+00:00 Barnes, et al. Expires January 10, 2008 [Page 23] Internet-Draft HELD July 2007 The error response to either of these requests is an error document. The following response shows an example error response. HTTP/1.x 200 OK Server: Example LCS Expires: Tue, 10 Jan 2006 03:49:20 GMT Cache-control: private Content-Type: application/held+xml Content-Length: 135 Note: To focus on important portions of messages, all examples following this note do not show HTTP headers or the XML prologue. In addition, sections of XML not relevant to the example are replaced with comments. 11.2. Simple Location Request Example The location request shown below doesn't specify any location types or response time. The response to this location request is a list of Location URIs. https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com An error response to this location request is shown below: Barnes, et al. Expires January 10, 2008 [Page 24] Internet-Draft HELD July 2007 11.3. Location Request Example for Multiple Location Types The following Location Request message includes a request for geodetic, jurisdictional civic and any Location URIs. geodetic jurisdictionalCivic locationURI The corresponding Location Response message includes the requested location information, including two location URIs. https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com: -34.407242 150.882518 30 AU NSW Wollongong Gwynneville Barnes, et al. Expires January 10, 2008 [Page 25] Internet-Draft HELD July 2007 Northfield Avenue University of Wollongong 2 Andrew Corporation 2500 39 WS-183 U40 false 2007-05-25T12:35:02+10:00 Wiremap 2007-05-24T12:35:02+10:00 11.4. Sample LCS WSDL Document The following WSDL document demonstrates how a WSDL document can be created for a specific service, in this case, a service at the URI "https://lcs.example.com/location". Barnes, et al. Expires January 10, 2008 [Page 26] Internet-Draft HELD July 2007 12. IANA Considerations This document registers an XML namespace and schema and the "application/held+xml" MIME type. 12.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:held", as per the guidelines in [6]. URI: urn:ietf:params:xml:ns:geopriv:held Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com). XML: BEGIN HELD Messages

Namespace for HELD Messages

urn:ietf:params:xml:ns:geopriv:held

[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX with the RFC number for this specification.]]

See RFCXXXX.

END 12.2. XML Schema Registration This section registers an XML schema as per the guidelines in [6]. URI: urn:ietf:params:xml:schema:geopriv:held Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com). Schema: The XML for this schema can be found as the entirety of Section 8 of this document. 12.3. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held:http This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:held:http", as per the guidelines in [6]. Barnes, et al. Expires January 10, 2008 [Page 27] Internet-Draft HELD July 2007 URI: urn:ietf:params:xml:ns:geopriv:held:http Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com). XML: BEGIN HELD HTTP Binding WS

Namespace for HELD HTTP Binding WS

urn:ietf:params:xml:ns:geopriv:held:http

[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX with the RFC number for this specification.]]

See RFCXXXX.

END 12.4. MIME Media Type Registration for 'application/held+xml' This section registers the "application/held+xml" MIME type. To: ietf-types@iana.org Subject: Registration of MIME media type application/held+xml MIME media type name: application MIME subtype name: held+xml Required parameters: (none) Optional parameters: charset Indicates the character encoding of enclosed XML. Default is UTF-8. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [20], section 3.2. Security considerations: This content type is designed to carry protocol data related to the location of an entity, which could include information that is considered private. Appropriate precautions should be taken to limit disclosure of this information. Interoperability considerations: This content type provides a basis for a protocol Barnes, et al. Expires January 10, 2008 [Page 28] Internet-Draft HELD July 2007 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this specification.]] Applications which use this media type: Location information providers and consumers. Additional Information: Magic Number(s): (none) File extension(s): .xml Macintosh File Type Code(s): (none) Person & email address to contact for further information: Mary Barnes Intended usage: LIMITED USE Author/Change controller: This specification is TBD Other information: This media type is a specialization of application/xml [20], and many of the considerations described there also apply to application/held+xml. 13. Contributors James Winterbottom, Martin Thomson and Barbara Stark are the authors of the original document, from which this WG document was derived. Their contact information is included in the Author's address section. James Winterbottom also contributed to the WG document. 14. Acknowledgements The author/contributors would like to thank the following people for their constructive input to this document (in alphabetical order): Nadine Abbott, Eric Arolick, Guy Caron, Martin Dawson, Jerome Grenier, Neil Justusson, Tat Lam, Patti McCalmont, Perry Prozeniuk, John Schnizlein, Henning Schulzrinne, Ed Shrum, and Hannes Tschofenig. 15. Changes since last Version NOTE TO THE RFC-Editor: Please remove this section prior to publication as an RFC. Changes from WG 00 to 01: 1) heldResponse renamed to locationResponse. 2) Changed namespace references for the PIDF-LO geoShape in the schema to match the agreed GML PIDF-LO Geometry Shape Application Schema. 3) Removed "options" element - leaving optionality/extensibility to Barnes, et al. Expires January 10, 2008 [Page 29] Internet-Draft HELD July 2007 XML mechanisms. 4) Changed error codes to be enumerations and not redefinitions of HTTP response codes. 5) Updated schema/examples for the above and removed some remnants of the context element. 6) Clarified the definition of "Location Information (LI)" to include a reference to the location (to match the XML schema and provide consistency of usage throughout the document). Added an additional statement in section 7.2 (locationType) to clarify that LCS MAY also return a Location URI. 7) Modifed the definition of "Location Configuration Server (LCS)" to be consistent with the current definiton in the requirements document. 8) Updated Location Response (section 6.3) to remove reference to context and discuss the used of a local identifier or unlinked pseudonym in providing privacy/security. 9) Clarified that the source IP address in the request is used as the identifier for the target/device for the HELD protocol as defined in this document. 10) Miscellaneous editorial clarifications. 16. References 16.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [5] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002. Barnes, et al. Expires January 10, 2008 [Page 30] Internet-Draft HELD July 2007 [6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [7] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [8] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [9] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in progress), February 2007. [10] Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations", draft-ietf-geopriv-pdif-lo-profile-08 (work in progress), July 2007. [11] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements", draft-ietf-geopriv-l7-lcp-ps-02 (work in progress), April 2007. [12] Thompson, H., Mendelsohn, N., Maloney, M., and D. Beech, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, . [13] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC- xmlschema-2-20041028, October 2004, . [14] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, "Geographic information - Geography Markup Language (GML)", OpenGIS 03-105r1, April 2004, . [15] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", draft-thomson-geopriv-lis-discovery-00 (work in progress), February 2007. [16] Marshall, R., "Requirements for a Location-by-Reference Mechanism used in Location Configuration and Conveyance", draft-marshall-geopriv-lbyr-requirements-01 (work in progress), March 2007. Barnes, et al. Expires January 10, 2008 [Page 31] Internet-Draft HELD July 2007 16.2. Informative References [17] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [18] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. [19] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [20] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [21] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [22] 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. [23] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [24] Polk, J. and B. Rosen, "Session Initiation Protocol Location Conveyance", draft-ietf-sip-location-conveyance-07 (work in progress), February 2007. [25] Gudgin, M., Mendelsohn, N., Nielsen, H., Moreau, J., and M. Hadley, "SOAP Version 1.2 Part 1: Messaging Framework", World Wide Web Consortium FirstEdition REC-soap12-part1-20030624, June 2003, . [26] Mendelsohn, N., Nielsen, H., Hadley, M., Gudgin, M., and J. Moreau, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Web Consortium FirstEdition REC-soap12-part2-20030624, June 2003, . [27] Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language", W3C CR CR-wsdl20-20060106, January 2006. Appendix A. HELD Compliance to IETF LCP requirements This appendix describes HELD's compliance to the requirements Barnes, et al. Expires January 10, 2008 [Page 32] Internet-Draft HELD July 2007 specified in the [11]. A.1. L7-1: Identifier Choice "The LIS MUST be presented with a unique identifier of its own addressing realm associated in some way with the physical location of the end host." COMPLY HELD uses the IP address of the location request message as the primary source of identity for the requesting device or target. This identity can be used with other contextual network information to provide a physical location for the Target for many network deployments. There may be network deployments where an IP address alone is insufficient to identify a Target in a network. However, any necessary identity extensions for these networks is beyond the scope of this document. A.2. L7-2: Mobility Support "The GEOPRIV Layer 7 Location Configuration Protocol MUST support a broad range of mobility from devices that can only move between reboots, to devices that can change attachment points with the impact that their IP address is changed, to devices that do not change their IP address while roaming, to devices that continuously move by being attached to the same network attachment point." COMPLY Mobility support is inherently a characteristic of the access network technology and HELD is designed to be access network agnostic. Consequently HELD complies with this requirement. In addition HELD provides specific support for mobile environments by providing an optional responseTime attribute in location request messages. Wireless networks often have several different mechanisms at their disposal for position determination (e.g. Assisted GPS versus location based on serving base station identity), each providing different degrees of accuracy and taking different amounts of time to yield a result. The responseTime parameter provides the LIS with a criterion which it can use to select a location determination technique. A.3. L7-3: Layer 7 and Layer 2/3 Provider Relationship "The design of the GEOPRIV Layer 7 Location Configuration Protocol MUST NOT assume a business or trust relationship between the provider of application layer (e.g., SIP, XMPP, H.323) provider and the access Barnes, et al. Expires January 10, 2008 [Page 33] Internet-Draft HELD July 2007 network provider operating the LIS." COMPLY HELD describes a location acquisition protocol and has no dependencies on how location is used once it has been acquired. Location acquisition using HELD is subject to the restrictions described in Section 10. A.4. L7-4: Layer 2 and Layer 3 Provider Relationship "The design of the GEOPRIV Layer 7 Location Configuration Protocol MUST assume that there is a trust and business relationship between the L2 and the L3 provider. The L3 provider operates the LIS and needs to obtain location information from the L2 provider since this one is closest to the end host. If the L2 and L3 provider for the same host are different entities, they cooperate for the purposes needed to determine end system locations." COMPLY HELD was specifically designed with this model in mind and readily allows itself to chaining requests between operators without a change in protocol being required. HELD is a webservices protocol it can be bound to transports other than HTTP, such as BEEP. Using a transport like BEEP for HELD offers the option of high request throughput over a dedicated connection between an L3 provider and an L2 provider without incurring the serial restriction imposed by HTTP. This is less easy to do with protocols that do not decouple themselves from the transport. A.5. L7-5: Legacy Device Considerations "The design of the GEOPRIV Layer 7 Location Configuration Protocol MUST consider legacy residential NAT devices and NTEs in an DSL environment that cannot be upgraded to support additional protocols, for example to pass additional information through DHCP." COMPLY HELD is an application protocol and operates on top of IP. A HELD request from a host behind a residential NAT will traverse the NAT acquiring the external address of the home router. The location provided to the host therefore will be the address of the home router in this circumstance. No changes are required to the home router in order to support this function, HELD was designed specifically to address this deployment scenario. Barnes, et al. Expires January 10, 2008 [Page 34] Internet-Draft HELD July 2007 A.6. L7-6: VPN Awareness "The design of the GEOPRIV Layer 7 Location Configuration Protocol MUST assume that at least one end of a VPN is aware of the VPN functionality. In an enterprise scenario, the enterprise side will provide the LIS used by the client and can thereby detect whether the LIS request was initiated through a VPN tunnel." COMPLY HELD does not preclude a LIS on the far end of a VPN tunnel being aware that the client request is occurring over that tunnel. It also does not preclude a client device from accessing a LIS serving the local physical network and subsequently using the location information with an application that is accessed over a VPN tunnel. A.7. L7-7: Network Access Authentication "The design of the GEOPRIV Layer 7 Location Configuration Protocol MUST NOT assume prior network access authentication." COMPLY HELD makes no assumptions about prior network access authentication. HELD strongly recommends the use of TLS with server-side certificates for communication between the end-point and the LIS. There is no requirement for the end-point to authenticate with the LIS. A.8. L7-8: Network Topology Unawareness "The design of the GEOPRIV Layer 7 Location Configuration Protocol MUST NOT assume end systems being aware of the access network topology. End systems are, however, able to determine their public IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP." COMPLY HELD makes no assumption about the network topology. HELD doesn't require that the device know its external IP address, except where that is required for discovery of the LCS. A.9. L7-9: Discovery Mechanism "The L7 LCP MUST define a single mandatory to implement discovery mechanism." COMPLY Barnes, et al. Expires January 10, 2008 [Page 35] Internet-Draft HELD July 2007 HELD uses the discovery mechanism in [15]. Authors' Addresses Mary Barnes (editor) Nortel 2201 Lakeside Blvd Richardson, TX Email: mary.barnes@nortel.com James Winterbottom Andrew PO Box U40 Wollongong University Campus, NSW 2500 AU Phone: +61 2 4221 2938 Email: james.winterbottom@andrew.com URI: http://www.andrew.com/ Martin Thomson Andrew PO Box U40 Wollongong University Campus, NSW 2500 AU Phone: +61 2 4221 2915 Email: martin.thomson@andrew.com URI: http://www.andrew.com/ Barbara Stark BellSouth Room 7A41 725 W Peachtree St. Atlanta, GA 30308 US Email: barbara.stark@bellsouth.com Barnes, et al. Expires January 10, 2008 [Page 36] Internet-Draft HELD July 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). Barnes, et al. Expires January 10, 2008 [Page 37]