Geopriv J. Winterbottom Internet-Draft M. Dawson Expires: January 19, 2006 M. Thomson Nortel July 18, 2005 HTTP Enabled Location Delivery (HELD) draft-winterbottom-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 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes a means by which a IP-device may request location from a Location Server using HTTP as a GeoPriv 'using protocol'. Winterbottom, et al. Expires January 19, 2006 [Page 1] Internet-Draft HELD July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Paradigm . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Location Server Discovery . . . . . . . . . . . . . . . . . 8 4.1 DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2 DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3 DNS Service Record . . . . . . . . . . . . . . . . . . . . 9 5. Protocol Specifics . . . . . . . . . . . . . . . . . . . . . 10 5.1 HELD Protocol Stack . . . . . . . . . . . . . . . . . . . 10 5.2 Location Information Request Parameters . . . . . . . . . 10 5.2.1 exact . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2.2 locationURI . . . . . . . . . . . . . . . . . . . . . 12 5.2.3 locationType . . . . . . . . . . . . . . . . . . . . . 12 5.2.4 updateURI . . . . . . . . . . . . . . . . . . . . . . 13 5.2.5 updateResponseTime . . . . . . . . . . . . . . . . . . 13 5.2.6 pidf-lo . . . . . . . . . . . . . . . . . . . . . . . 13 5.2.7 rulesetURI . . . . . . . . . . . . . . . . . . . . . . 14 5.2.8 ruleset . . . . . . . . . . . . . . . . . . . . . . . 15 5.2.9 retentionInterval . . . . . . . . . . . . . . . . . . 15 5.2.10 responseTime . . . . . . . . . . . . . . . . . . . . 16 5.2.11 signed . . . . . . . . . . . . . . . . . . . . . . . 16 5.2.12 ip . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2.13 hwaddr . . . . . . . . . . . . . . . . . . . . . . . 17 6. IP-device References . . . . . . . . . . . . . . . . . . . . 18 7. Location Assertion . . . . . . . . . . . . . . . . . . . . . 19 8. Location Information Response Message . . . . . . . . . . . 20 9. Authentication . . . . . . . . . . . . . . . . . . . . . . . 21 9.1 IP-device Authentication . . . . . . . . . . . . . . . . . 21 9.2 OBO Authentication . . . . . . . . . . . . . . . . . . . . 21 9.3 Location Client Authentication . . . . . . . . . . . . . . 21 10. Session Management . . . . . . . . . . . . . . . . . . . . . 22 11. Security Considerations . . . . . . . . . . . . . . . . . . 23 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 14. Normative references . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26 A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 28 A.1 Simple Location Request . . . . . . . . . . . . . . . . . 28 A.1.1 Request for Any Location . . . . . . . . . . . . . . . 28 A.1.2 Request for Civic Location . . . . . . . . . . . . . . 29 A.2 Location URI Request . . . . . . . . . . . . . . . . . . . 31 A.2.1 Request locationURI Specifying rulesetURI . . . . . . 31 A.2.2 Requesting locationURI Specifying ruleset . . . . . . 32 A.2.3 Location-Client Using locationURI . . . . . . . . . . 34 A.3 Location Assertion . . . . . . . . . . . . . . . . . . . . 35 Winterbottom, et al. Expires January 19, 2006 [Page 2] Internet-Draft HELD July 2005 A.4 Requests Using Update and Location URIs . . . . . . . . . 38 A.5 OBO Location Request Examples . . . . . . . . . . . . . . 39 Intellectual Property and Copyright Statements . . . . . . . 42 Winterbottom, et al. Expires January 19, 2006 [Page 3] Internet-Draft HELD July 2005 1. Introduction This document describes a protocol that employs secure HTTP as a GeoPriv 'using protocol' to deliver location information relating to a IP-device from a Location Server. The IP-device discovers or is informed of the Location Server and establishes a session with the server. The Location Server constructs a PIDF-LO document and returns this to the IP-device. This protocol facilitates requesting specific forms of location including geodetic, postal civic, jurisdictional civic and that the Location Server sign the location as specified in [I-D.thomson-domain-auth]. This document concentrates solely on the provision of location information, it does not describe how location may be generated. The advantage of this is that this enables the use of this protocol in many different networks. This aligns this document with the model described in [RFC3693] by separating the Location Server and Location Generator functions and focussing on only the Location Server. Currently proposed location delivery mechanisms, such as those defined in [RFC3825] and [I-D.ietf-geopriv-dhcp-civil], tightly couple location determination (generation) and location acquisition. While this coupling offers some benefits, it also has drawbacks, particularly where DHCP is not employed to any great degree, or if the form of location or its container evolve to encompass additional information, for example signatures as proposed in [I-D.thomson- domain-auth] or the existing provided-by field, where support for these will necessitate changes to the base protocol. 1.1 Paradigm The philosophical approach for requesting a location on which this document is based, is that the network does not know the identity of a user requesting a location, but it can have some assurances as to which access point the location request is coming from. That is, location is a resource or an attribute being used in a network and the network can identify the resource being used. This is somewhat analogous to an IP address being allocated via DHCP, that is to say that the DHCP server does not know the identity of the user requesting the address, but it can be sure that it has allocated an address in response to a request from an entity physically present in the access network it serves. The Location Server is assumed to have the facilities of a Location Generator as part of its own implementation or available in the access networks serviced by the Location Server. The form and nature of the Location Generator are not discussed in this document. Winterbottom, et al. Expires January 19, 2006 [Page 4] Internet-Draft HELD July 2005 2. Terminology The key conventions and terminology used in this document are defined as follows: This document reuses the terms Location Server, Location Generator and Using-Protocol as defined in [RFC3693]. In some specification the Location Server is referred to as a Location Information Server or LIS. Target The device that the location is attributed to. IP-device Used interchangeably with Target. OBO On-Behalf-Of. A network node that is able to request location on-behalf-of an IP-device. Location-Client A third-party requesting the location of an IP-device using a locationURI. 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]. Winterbottom, et al. Expires January 19, 2006 [Page 5] Internet-Draft HELD July 2005 3. Overview This document describes how an IP-device requests location information from a Location Server, including how a Location Server is identified. Location Server discovery is achieved through the use of a new DHCP option, a new DNS SRV record or static configuration. A Location Server is identified by a URI that identifies the Location Server as an HTTP service using the "https" scheme. The IP-device initiates an HTTP connection with the Location Server. If the IP-device only requires location information with no particular constraints it uses the HTTP GET method, otherwise it includes request parameters using the HTTP POST method. The Location Server identifies the IP-device based on its IP address. The Location Server then identifies a Location Generator for the IP- device, which determines the location of the IP-device. The Location Server will take the generated location and produce a PIDF-LO that is subsequently returned to the requesting IP-device. In addition to returning a location to an IP-device requesting its own location, the protocol provides support for a location URI, which enables by-reference distribution of location information by the IP- device. This has a number of benefits which are described in more detail by [I-D.winterbottom-location-uri]. An option exists for specially authorized entities to request location on-behalf-of (OBO) an IP-device. In this situation the requester includes the IP address of the target IP-device; the Location Server uses this IP address to determine location, rather than the source IP address of the request message. The Location Server in this circumstance must have a pre-arranged trust relationship with the requester otherwise the request MUST fail. Winterbottom, et al. Expires January 19, 2006 [Page 6] Internet-Draft HELD July 2005 Location Location +--------+ Request +-------------+ Request +----------+ | IP |--------------->| Location |<-------------| Location | | Device |<---------------| Server |------------->| Client | +--------+ Location/URI +-------------+ Location +----------+ ^ | | | Location | Request | | Location | | | V +--------------+ | OBO | +--------------+ Winterbottom, et al. Expires January 19, 2006 [Page 7] Internet-Draft HELD July 2005 4. Location Server Discovery Location Server discovery MAY occur using a DHCP option, a DNS SVC record, or a preconfigured URL; in order of preference. 4.1 DHCPv4 The DHCPv4 option includes a list of URIs; the first URI must be attempted first and subsequent URIs contacted only in the event of a problem in retrieving location information. Each URI must reference a service that is able to provide the IP-device with location information. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LOCSERV_URI | Length | URI List ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code LOCSERV_URI (TBD) Length The length of the URI list in octets URI List A list of one or more URIs separated by the space character 4.2 DHCPv6 The DHCPv6 option is similarly formatted to the DHCPv4 option. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_LOCSERV_URI | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | URI List ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_LOCSERV_URI (TBD) option-len The length of the URI list in octets URI List A list of one or more URIs separated by the space character Winterbottom, et al. Expires January 19, 2006 [Page 8] Internet-Draft HELD July 2005 4.3 DNS Service Record A new service is to be created "locserv+http" such that the querying entity can recover the FQDN for the local Location Server. This service MUST be configured such that an HTTP POST to this address will result in the Location Server application being invoked. The DNS server entry will therefore look similar to: _locserv+http_.tcp SRV 1 0 0 location-server.example.com. The new service record needs to be registered with IANA, see Section 12 for more details. The DNS response indicates a fully qualified domain name for the Location Server. In order to derive a URI from this FQDN, the "https" scheme SHOULD be used with the root path ("/"). This allows the corresponding client to construct a URL as follows: https://location-server.example.com/ Winterbottom, et al. Expires January 19, 2006 [Page 9] Internet-Draft HELD July 2005 5. Protocol Specifics 5.1 HELD Protocol Stack HELD is a web services application that uses the POST and GET methods of HTTP. TLS is used a secure transport layer to ensure that HELD meets the requirements of a GEOPRIV 'using protocol'. TLS for transporting HTTP is defined [RFC2818]. +------------+ | HELD | +------------+ | HTTP | +------------+ | TLS | +------------+ | TCP | +------------+ | IP | +------------+ HELD relies on the security features of TLS to ensure that location information is properly protected. Specifically, the encryption and authentication provided by TLS must be enabled. 5.2 Location Information Request Parameters A HELD location information request is either an HTTP GET or POST [RFC2616] to the discovered Location Server URI. Where the requesting entity needs to request specific information from, or provide specific information to the Location Server the POST method MUST be used. A request may be made by one of three types of entity: an IP-device wishing to determine its own location, a location-client requesting the location of a IP-device, or a element requesting location on- behalf-of (OBO) an IP-device. Request parameters are included in the body of a POST request using either URL-encoding or the "multipart/ form-data" encoding defined in [RFC1867]. The same type of request is made from the IP-device, an OBO and a location-client, the only difference being the URI to which the requests are posted. The Location Server identifies the IP-device by a different means for each request source. For requests from the IP-device, the source IP address of the connection is used. Requests from the location-client SHOULD be to a unique URI that includes information that the Location Server can use to identify a particular IP-device. Where an OBO Winterbottom, et al. Expires January 19, 2006 [Page 10] Internet-Draft HELD July 2005 requests the location of an IP-device, the IP address of the IP- device is included as a parameter and additional information MAY be included as necessary. The protocol structure of HELD suitably lends itself to support the cascading of location information requests between Location Servers. This accommodates complex network structures by enabling distribution of location functions across servers. HELD does not explicitly prohibit any parameter from being included in any request, however the practical applications of the parameters dictate their suitability more to specific request types. The following table lists the parameters that may have practically meaning to the Location Server when passed from the requesting node types: +-------------+-------+-------------------+ | IP-device | OBO | Location-Client | ---------------------+-------------+-------+-------------------+ exact | X | X | X | ---------------------+-------------+-------+-------------------+ locationURI | X | X | | ---------------------+-------------+-------+-------------------+ locationType | X | X | X | ---------------------+-------------+-------+-------------------+ updateURI | X | | | ---------------------+-------------+-------+-------------------+ updateResponseTime | X | | | ---------------------+-------------+-------+-------------------+ responseTime | X | X | X | ---------------------+-------------+-------+-------------------+ pidf-lo (multipart) | X | | | ---------------------+-------------+-------+-------------------+ ruleset (multipart) | X | | | ---------------------+-------------+-------+-------------------+ rulesetURI | X | | | ---------------------+-------------+-------+-------------------+ retentionInterval | X | | | ---------------------+-------------+-------+-------------------+ ip | | X | | ---------------------+-------------+-------+-------------------+ hwaddr | | X | | ---------------------+-------------+-------+-------------------+ signed | X | X | X | ---------------------+-------------+-------+-------------------+ The following sub-sections describe each of the parameters in detail. Winterbottom, et al. Expires January 19, 2006 [Page 11] Internet-Draft HELD July 2005 5.2.1 exact The "exact" parameter may have a value of "true" or "false". If not included the default value is "false". When set to "true" all parameters included in the location request MUST be satisfied by the Location Server, or the response from the Location Server MUST indicate failure. 5.2.2 locationURI The "locationURI" parameter indicates if a location URI is required. The value space of this parameter is the superset of the duration type specified in [W3C.REC-xmlschema-2-20041028], plus the string "unbounded". When omitted, or set to a zero or negative duration, no location URI SHALL be generated or returned. When a location URI is requested the Location Server provides a URI that references the location of the IP-device. Uses and reasons for location by-reference are described in [I-D.winterbottom-location- uri]. A location URI is provided in the body of the response using the "text/plain" MIME type. If a "locationURI" is requested then the Location Server MUST return a "locationURI" or fail. The value of this parameter indicates the maximum amount of time that the requester wishes the location URI to be valid for; a Location Server MAY specify a shorter duration, but MUST NOT provide a longer duration than that requested. The inclusion of a "locationURI" parameter overrides the inclusion of the "locationType" and "exact" parameters. The response MUST yield a "locationURI" or an error. 5.2.3 locationType A form parameter that may have multiple values. The valid values are: any The Location Server may return any information it has available. This value is assumed as the default if no "locationType" is specified. geodetic The Location Server SHOULD return a geodetic location for the IP-device. Winterbottom, et al. Expires January 19, 2006 [Page 12] Internet-Draft HELD July 2005 jurisdictionalCivic The Location Server SHOULD return a jurisdictional civic address for the IP-device. postalCivic The Location Server SHOULD return a postal civic address for the IP-device. civic The Location Server SHOULD return a civic address for the IP- device. Any type of civic address may be returned. The location server SHOULD ignore this value if a request for "jurisdictionalCivic" or "postalCivic" has been made and can be satisfied. The Location Server SHOULD attempt to provide the location in the requested form unless the request cannot be properly satisfied. If the "exact" parameter is set to "true" then the Location Server MUST provide the location in the requested form or fail. The Location Server SHOULD provide location-information types in the same order in which they are requested. 5.2.4 updateURI The "updateURI" parameter MAY be provided by an IP-device that is capable of determining its own location. This provides the Location Server with a means of interrogating an IP-device to determine the IP-device's current location. A location update URI SHOULD use the "https" scheme so that HELD may be employed to request information. 5.2.5 updateResponseTime A form parameter provided to the Location Server in conjunction with an "updateURI" as an indication of how long an IP-device could take to respond to a request for location information. The "updateResponseTime" is indicative only and is a positive decimal value representing the approximate number of seconds that it could take to obtain a response. The Location Server MUST ignore this value if no corresponding "updateURI" is provided. It is RECOMMENDED that systems support millisecond precision for this parameter. 5.2.6 pidf-lo A file describing a location provided by an IP-device, and the general format of PIDF-LOs that the IP-device wishes the Location Server use when providing location information. Winterbottom, et al. Expires January 19, 2006 [Page 13] Internet-Draft HELD July 2005 The "pidf-lo" is transferred to the location server using the multipart file transfer, with the MIME type of "application/ pidf+xml". The Location Server SHOULD perform a location assertion against ALL locations provided in the PIDF-LO document. The Location Server MUST only include location information that has been successfully asserted. If the "exact" parameter is set to "true" then ANY location failing an assertion test results in the entire request failing. The Location Server will replace the following entities in any provided PIDF-LO with values that it derives or determines: "presentity" "timestamp" "retention-expiry" "method" "provided-by" If the "exact" parameter is set to "true", then these values MAY be changed, but the Location Server MUST NOT insert new elements if they are not already present. The "pidf-lo" SHOULD contain a "method" element. If the IP-device wishes explicit rules to be included in any PIDF-LO documents containing its location, then it MUST include them in the "pidf-lo" sent to the Location Server. The Location Server will preserve, but not adhere to, any of these rules. The Location Server will adhere to rules provided in either the "rulesetURI" or "ruleset" parameters discussed in subsequent sections. 5.2.7 rulesetURI A form parameter that defines a URI to a set of policies and rules describing how and to whom an IP-device's location may be provided. The "rulesetURI" is the preferred means by which an IP-device informs the Location Server to whom the IP-device's location may be divulged. If a "rulesetURI" is provided to the Location Server then the Location Server MUST adhere to the rules referenced. If a "rulesetURI" and a "ruleset" are both provided then ONLY the "rulesetURI" MUST be used. Winterbottom, et al. Expires January 19, 2006 [Page 14] Internet-Draft HELD July 2005 Rules documents MUST comply with [I-D.ietf-geopriv-common-policy] and [I-D.ietf-geopriv-policy]. It is RECOMMENDED that a ruleset URI use an "https" scheme. If the IP-device does not provide a "rulesetURI", or a "ruleset" then the Location Server MUST apply a default ruleset. The default "ruleset" SHALL prohibit the Location Server from providing location information to any unauthorized location-client. The default "ruleset" MAY include specific third-parties as mandated by local regulations, for example emergency services. If the IP-device provides a "rulesetURI" that is not accessible, contains invalid rules, or cannot be parsed by the Location Server then the Location Server SHOULD reject the request and return an error. 5.2.8 ruleset A file containing policies and rules describing how and to whom an IP-device's location may be provided. It is transferred to the Location Server using multipart file transfer, with a MIME type of "application/auth-policy+xml". If a "ruleset" is provided to the Location Server then the Location Server MUST adhere to the rules, unless it is also provided with a "rulesetURI", in which case the rules referenced by the "rulesetURI" are used. Rules documents MUST comply with [I-D.ietf-geopriv-common- policy] and [I-D.ietf-geopriv-policy]. If the IP-device does not provide a "rulesetURI", or a "ruleset" then the Location Server MUST apply a default ruleset. The default "ruleset" SHALL prohibit the Location Server from providing location information to any unauthorized location-client. The default "ruleset" MAY include specific third-parties as mandated by local regulations, for example emergency services. If the IP-device provides a "ruleset" that is invalid, or cannot be parsed by the Location Server then the request MUST be rejected and an error returned. 5.2.9 retentionInterval A form parameter provided to the Location Server to specify the length of time that should be allowed for the "retention-expiry" element that SHOULD be applied to all locations provided for this IP- device. The "retentionInterval" is an positive decimal value specifying a Winterbottom, et al. Expires January 19, 2006 [Page 15] Internet-Draft HELD July 2005 duration in seconds. When a Location Server serves a request for location, the resulting PIDF-LO document will have a "retention- expiry" element set to the specified number of seconds after the issue of the location information. If no "retentionInterval" is specified the Location Server SHOULD provide a default value for the "retention-expiry" element in all PIDF-LO documents. Nominally this default SHOULD be 24 hours from the receipt of the location request as specified in [I-D.ietf- geopriv-pidf-lo]. The Location Server MAY use a different value as circumstances dictate; for example, where the access network supports mobility, this value can be reduced. 5.2.10 responseTime A form parameter that is sent to the Location Server indicating how long a requester is prepared to wait for location information. The " responseTime" is a positive decimal value representing the time in seconds that a client is prepared to wait for a location response from the Location Server. It is RECOMMENDED that systems support millisecond precision for this parameter. The Location Server SHOULD provide the most accurate location that it can within the response time requested. The Location Server may use this parameter to aid it in making decisions about which location determination method it will invoke if more than one is supported. If this parameter is not provided then the Location Server may use any mechanism for location determination at its disposal. The value used in this parameter is indicative to the Location Server only, and the Location Server is under no obligation to strictly adhere to it, any strict enforcement of behaviour around this time is left to the requester. 5.2.11 signed A form parameter that may have a value of "true" or "false". If not included the default value is "false". The "signed" parameter allows the device to request a signed location object as defined in [I-D.thomson-domain-auth]. A value of "true" indicates a request for a signed location. If not present a value of "false" MUST be assumed, and the location MUST NOT be signed. 5.2.12 ip A form parameter used by an OBO to specify the IP address of the IP- device for which it is requesting location information. Winterbottom, et al. Expires January 19, 2006 [Page 16] Internet-Draft HELD July 2005 Any entity including this parameter in a location request MUST have an explicit trust relationship with the Location Server. Any request from a node not meeting these requirements MUST fail. 5.2.13 hwaddr A form parameter used by an OBO to specify the hardware address of an IP-device for which it is requesting location information. Any entity including this parameter in a location request MUST have an explicit trust relationship with the Location Server. Any request from a node not meeting these requirements MUST fail. Winterbottom, et al. Expires January 19, 2006 [Page 17] Internet-Draft HELD July 2005 6. IP-device References The location URI is an identifier generated by the Location Server so that the IP-device's location may be retrieved by-reference. Location URIs are discussed in more detail in Appendix A.2.2. There is no requirement for the Location Server to know the identity of the user of an IP-device. However the Location Server is responsible for providing assurances that location information is attributed to a specific IP-device at a given point in time. To satisfy these requirements, the Location Server MUST generate a pseudonym for the presentity URI associated with the IP-device. Any pseudonym created by the Location Server SHOULD NOT reveal the true identity of the IP-device or user. The Location Server MUST be able to uniquely identify the IP-device based on a location URI or presentity pseudonym. Identity matching SHOULD occur through internal correlation only; it SHOULD NOT be possible to perform a computational transform on these data to identify the IP-device. Winterbottom, et al. Expires January 19, 2006 [Page 18] Internet-Draft HELD July 2005 7. Location Assertion Location assertion is most applicable where an IP-device can determine its own location. In this situation the device may be able to provide additional or more precise information than the Location Generator available to the Location Server. The location assertion mechanism allows the IP-device to tell the Location Server where it thinks it is and by comparing this location against that provided by a Location Generator, the Location Server may assert that the location provided by the IP-device is better, or more precise. Conversely if the location provided by the IP-device is significantly different to that provided by the Location Generator then the Location Server SHOULD fail the assertion. If the Location Server is unable to assert the location provided by the IP-device as being valid then the Location Server MUST do one of two things depending on the value of the "exact" parameter. If "exact" parameter is set to "true" then the Location Server MUST return an error to the IP-device. If the "exact" parameter is set to "false", then the Location Server MUST return the location provided by the Location Generator. Winterbottom, et al. Expires January 19, 2006 [Page 19] Internet-Draft HELD July 2005 8. Location Information Response Message The location information response message contains either a "text/ plain" body containing a location URI or a "application/pidf+xml" body containing a valid PIDF-LO document. HTTP features SHOULD be used to provide additional information, including the "Content-Type", "Expires" and "Date" headers. The following HTTP status codes MAY be used to convey additional information about the request: 200 OK The Location Server MAY return this code if the request was processed successfully; the body of the response contains the requested data. 400 Bad request The Location Server MAY return this code if the request was badly formatted, or required parameters were incorrect, out of range or missing. This code MAY be returned if any data type does not correctly parse, including any XML content. 401 Unauthorized The Location Server MAY return this code if a requester is not authorized to access the requested service. For example, a Location Server may return this if a requester uses client identification parameters without the required permissions. 403 Forbidden The Location Server MAY return this code if a location client does not meet the criteria specified in the authorization policy. A Location Server SHOULD use the 404 code instead of 403 to prevent a location client from discovering that a location URI is in use. 404 Not Found The Location Server MAY return this code when the Location Server URI or location URI is not correct. A Location Server MAY also use this return code when location information cannot be determined, or a session has expired. 406 Not Acceptable The Location Server MAY return this code where the client uses "Accept" header that does not allow for the content characteristics that the Location Server is capable of providing. A request for location URI MUST include an "Accept" header that includes "text/plain", or "*". A request for location information MUST include an "Accept" header that includes "text/xml", "application/xml""application/pidf+xml", or "*". 501 Not Implemented The Location Server MAY return this code if it does not support a requested function. The body of the response should include some indication about the feature that is not implemented. Winterbottom, et al. Expires January 19, 2006 [Page 20] Internet-Draft HELD July 2005 9. Authentication 9.1 IP-device Authentication The Location Server identifies that a request is comes from an IP- device by the incoming URI and the accompanying HELD parameters. For these requests, the source IP address of the request message is used to identify the IP-device. The location determined is for the device that is using the IP address. Location information is also returned to this device. Therefore there is no explicit requirement for an IP-device to authenticate itself with in the access network, over and above what is needed to gain access to the network in the first place. 9.2 OBO Authentication OBOs require an explicit trust relationship with the Location Server. How this trust relationship is managed with in a specific installation is implementation dependent, but may be implemented with white lists or other such mechanisms. 9.3 Location Client Authentication Authentication of location-clients requesting the location of an IP- device through a location URI MAY be achieved either through the use of client-side certificates attached to the TLS session, or through the use of Security Assertion Markup Language (SAML). When client- side X.509 certificates are used the corresponding common name SHOULD be lifted from the certificate and used to match against the identity components in the usage ruleset provided by the IP-device. If the location-client request fails authentication then a "404 Not Found" status code SHOULD be returned. Winterbottom, et al. Expires January 19, 2006 [Page 21] Internet-Draft HELD July 2005 10. Session Management The protocol described thus far implies in some instances where a session or state is maintained by the Location Server. A Location Server may issue HTTP cookies to provide a persistent session between subsequent requests. When a cookie is used, certain information MUST be maintained by the Location Server. All clients of the Location Server MAY assume that the following information is retained: Any PIDF-LO format provided as a "pidf-lo" parameter. The authorization policy. The location update URI and associated response time. Any client identification information provided by the OBO, including IP address. Only the latest value of any of these data need be maintained. Session duration MAY be increased by the IP-device re-requesting location information from the Location Server. The Location Server SHOULD maintain IP-device session data until a cookie expires, at which time session data MUST be purged. An IP-device MAY change its authorization policy at any time. It does this by providing the Location Server with a new "rulesetURI" or "ruleset". Changes to authorization policy are immediate. Where a policy excludes access to location information from a location-client in an existing session, that session MUST be terminated. Winterbottom, et al. Expires January 19, 2006 [Page 22] Internet-Draft HELD July 2005 11. Security Considerations All requests for location and subsequent location responses MUST be done using secure HTTP (https). Exactly how validation and authentication of location-clients using client-side certificates and SAML identity session is implemented is beyond the scope of this document but consideration should be given to employing best current practices. State information associated with a session at the Location Server MUST be purged when a session expires. Lengthy expiry times SHOULD be avoided. Mechanisms for protection of location URIs to minimize the likelihood and impact of theft are described in Appendix A.2.2. The creation of a location update URI by a IP-device SHOULD be done using a randomly selected port. Winterbottom, et al. Expires January 19, 2006 [Page 23] Internet-Draft HELD July 2005 12. IANA Considerations IANA has assigned a DHCPv4 option code of TBD for the Location Server URI (LOCSERV_URI) option defined in this document. IANA has assigned a DHCPv6 option code of TBD for the Location Server URI (OPTION_LOCSERV_URI) option defined in this document. A new DNS services (SVR) field type of LOCSERV+HTTP with a protocol type of TCP is required in order for a IP-device to discover the Location Server in the access network. Winterbottom, et al. Expires January 19, 2006 [Page 24] Internet-Draft HELD July 2005 13. Acknowledgements The authors wish to thank Rohan Mahy and Hannes Tschofenig for their early comments and guidance. 14. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC1867] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC 1867, November 1995. [RFC2616] 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. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [I-D.ietf-geopriv-pidf-lo] Peterson, J., "A Presence-based GEOPRIV Location Object Format", draft-ietf-geopriv-pidf-lo-03 (work in progress), September 2004. [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004. [I-D.ietf-geopriv-dhcp-civil] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", draft-ietf-geopriv-dhcp-civil-06 (work in progress), May 2005. [I-D.ietf-geopriv-common-policy] Schulzrinne, H., "A Document Format for Expressing Privacy Preferences", draft-ietf-geopriv-common-policy-04 (work in progress), February 2005. [I-D.ietf-geopriv-policy] Schulzrinne, H., "A Document Format for Expressing Privacy Preferences for Location Information", draft-ietf-geopriv-policy-05 (work in progress), November 2004. Winterbottom, et al. Expires January 19, 2006 [Page 25] Internet-Draft HELD July 2005 [I-D.ietf-geopriv-pdif-lo-profile] Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations", draft-ietf-geopriv-pdif-lo-profile-00 (work in progress), July 2005. [I-D.thomson-domain-auth] Thomson, M. and J. Winterbottom, "Domain Authorization for PIDF-LO", draft-thomson-domain-auth-01 (work in progress), June 2005. [I-D.winterbottom-location-uri] Winterbottom, J., "Rationale for Location by Reference", draft-winterbottom-location-uri-00 (work in progress), July 2005. [W3C.REC-xmlschema-2-20041028] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", W3C REC REC-xmlschema-2-20041028, October 2004. Authors' Addresses James Winterbottom Nortel PO Box U87 University of Wollongong, NSW 2500 AU Email: winterb@nortel.com Martin Dawson Nortel PO Box U87 University of Wollongong, NSW 2500 AU Email: mdawson@nortel.com Winterbottom, et al. Expires January 19, 2006 [Page 26] Internet-Draft HELD July 2005 Martin Thomson Nortel PO Box U87 University of Wollongong, NSW 2500 AU Email: martin.thomson@nortel.com Winterbottom, et al. Expires January 19, 2006 [Page 27] Internet-Draft HELD July 2005 Appendix A. Examples The following subsections represent a few examples of location requests and subsequent responses. A.1 Simple Location Request In this example an IP-device makes a request for any location from the Location Server. The Location Server determines the location and subsequently returns it to the IP-device, which may then communicate its location to other entities. +--------+ +-----------+ +----------+ | IP | | Location | | Location | | Device | | Server | | Client | +----+---+ +-----+-----+ +----+-----+ | | | | LocReq(ANY) | | |------------------>| | | | | | Generate | | Location | | | | | Location | | |<------------------| | | | | | | | Conveyance | | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >| | | A.1.1 Request for Any Location In this example the IP-device sends a GET to the Location Server URL. GET / HTTP/1.1 Host: lis.example.com Accept: application/pidf+xml,text/xml;q=0.8,application/xml;q=0.8 Accept-Charset: UTF-8,* Winterbottom, et al. Expires January 19, 2006 [Page 28] Internet-Draft HELD July 2005 A positive response from the Location Server to the IP-device would look similar to: HTTP/1.x 200 OK Server: Example LIS Set-Cookie: httplocationID=dhf2W6hfx53; expires: Wed, 13 Jul 2005 02:54:47 GMT;secure Date: Wed, 13 Jul 2005 01:54:47 GMT Expires: Wed, 13 Jul 2005 01:59:47 GMT Content-Type: application/pidf+xml Content-Length: 745 -34.407 150.88001 2005-07-13T01:59:45+00:00 A.1.2 Request for Civic Location In this example the IP-device specifically wants a civic location, so it posts a "locationType" of "civic" to the Location Server. POST / HTTP/1.1 Host: lis.example.com Accept: application/pidf+xml,text/xml;q=0.8,application/xml;q=0.8 Accept-Charset: UTF-8,* Content-Type: application/x-www-form-urlencoded Content-Length: 18 Winterbottom, et al. Expires January 19, 2006 [Page 29] Internet-Draft HELD July 2005 locationType=civic A civic location response from the Location Server follows: HTTP/1.x 200 OK Server: Example LIS Set-Cookie: httplocationID=789pnLw36T489cse; expires: Wed, 13 Jul 2005 02:54:47 GMT;secure Date: Wed, 13 Jul 2005 01:54:47 GMT Expires: Wed, 14 Jul 2005 01:54:47 GMT Content-Type: application/pidf+xml Content-Length: 809 AU NSW Wollongong North Wollongong Northfields Avenue University of Wollongong Building 3 no 2005-07-14T01:54:47Z DHCP 2005-07-13T01:54:47Z Winterbottom, et al. Expires January 19, 2006 [Page 30] Internet-Draft HELD July 2005 A.2 Location URI Request In these examples the IP-device requests a location URI from the Location Server. Two examples show the way in which an IP-device may specify either a "rulesetURI" or a "ruleset" to control to whom the Location Server divulges their location information. A third example shows how a location-client may request the location of an IP-device using a location URI. +--------+ +-----------+ +----------+ | IP | | Location | | Location | | Device | | Server | | Client | +----+---+ +-----+-----+ +----+-----+ | | | | LocReq(URI,rules) | | |------------------>| | | | | | Generate | | LocationURI | | | | | LocationURI | | |<------------------| | | | | | | | Conveyance(locationURI) | | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >| | | | | LocReq(ANY) | | |<-------------------| | | | | Authenticate | | | | | Generate | | Location | | | | | | location | | |------------------->| | | | A.2.1 Request locationURI Specifying rulesetURI In this example the IP-device specifies a "rulesetURI" when requesting a "locationURI". Winterbottom, et al. Expires January 19, 2006 [Page 31] Internet-Draft HELD July 2005 POST / HTTP/1.1 Host: lis.example.com Accept: text/plain Accept-Charset: UTF-8,* Content-Type: application/x-www-form-urlencoded Content-Length: 17 locationURI=unbounded&rulesetURI=https://1.2.3.4:9974/ruleset.xml The Location Server responds with a "locationURI" HTTP/1.x 200 OK Server: Example LIS Set-Cookie: httplocationID=F168jiwdjw92jds09; expires: Wed, 13 Jul 2005 02:54:47 GMT;secure Date: Wed, 13 Jul 2005 01:54:47 GMT Expires: Wed, 14 Jul 2005 01:54:47 GMT Content-Type: text/plain Content-Length: 41 https://lis.example.com/362b0e75du908n1 A.2.2 Requesting locationURI Specifying ruleset In this example the IP-device provides an explicit "ruleset" in a request for a "locationURI" in the request. Winterbottom, et al. Expires January 19, 2006 [Page 32] Internet-Draft HELD July 2005 Note that the location request contains a cookie identifying the session created from a previous request. POST / HTTP/1.1 Host: lis.example.com Accept: application/pidf+xml,text/xml;q=0.8,application/xml;q=0.8 Accept-Charset: UTF-8,* Cookie: httplocationID=F168jiwdjw92jds09 Content-Type: multipart/form-data; boundary=-29733 Content-Length: 1866 ---29733 Content-Disposition: form-data; name="locationURI" unbounded ---29733 Content-Disposition: form-data; name="ruleset"; filename="rules.xml" Content-Type: application/auth-policy+xml helpme@roadside.assistance.com ---29733-- The Location Server accepts the request and responds with a "locationURI". HTTP/1.x 200 OK Server: Example LIS Date: Wed, 13 Jul 2005 01:54:47 GMT Expires: Wed, 14 Jul 2005 01:54:47 GMT Content-Type: text/plain Content-Length: 41 https://lis.example.com/362b0e75du908n1 Winterbottom, et al. Expires January 19, 2006 [Page 33] Internet-Draft HELD July 2005 A.2.3 Location-Client Using locationURI This example shows how a location-client makes a request to a "locationURI", and the subsequent response. GET /362b0e75du908n1 HTTP/1.1 Host: lis.example.com Accept: application/pidf+xml,text/xml;q=0.8,application/xml;q=0.8 Accept-Charset: UTF-8,* The example illustrates a request for arbitrary information. A POST to the "locationURI" with parameters is also allowed where specific location formats are required. HTTP/1.x 200 OK Server: Example LIS Date: Wed, 13 Jul 2005 01:54:47 GMT Expires: Wed, 13 Jul 2005 01:59:47 GMT Content-Type: application/pidf+xml Content-Length: 745 -34.407 150.88001 2005-07-13T01:59:45+00:00 Winterbottom, et al. Expires January 19, 2006 [Page 34] Internet-Draft HELD July 2005 A.3 Location Assertion In the example the IP-device contains an on-board GPS so that the device can accurately determine where it is. The IP-device asserts its location to the Location Server to obtain a valid PIDF-LO. +--------+ +-----------+ | IP | | Location | | Device | | Server | +----+---+ +-----+-----+ | | | LocReq(Assert) | |------------------>| | | | Assert | Location | | | Location | |<------------------| | | Winterbottom, et al. Expires January 19, 2006 [Page 35] Internet-Draft HELD July 2005 POST / HTTP/1.1 Host: lis.example.com Accept: application/pidf+xml,text/xml;q=0.8,application/xml;q=0.8 Accept-Charset: UTF-8,* Content-Type: multipart/form-data; boundary=-29733 Content-Length: 1866 ---29733 Content-Disposition: form-data; name="locationType" geodetic ---29733 Content-Disposition: form-data; name="pidf-lo"; filename="gpsloc.xml" Content-Type: application/pidf+xml -34.407 150.88001 no GPS 2005-07-13T01:54:32Z ---29733-- If the Location Server is able to satisfy the assertion request then a "200 OK" status is returned to the IP-device along with the PIDF-LO providing the location. Winterbottom, et al. Expires January 19, 2006 [Page 36] Internet-Draft HELD July 2005 HTTP/1.x 200 OK Server: Example LIS Set-Cookie: httplocationID=789pnLw36T489cse; expires: Wed, 13 Jul 2005 02:54:47 GMT;secure Date: Wed, 13 Jul 2005 01:54:47 GMT Expires: Wed, 14 Jul 2005 01:54:47 GMT Content-Type: application/pidf+xml Content-Length: 745 -34.407 150.88001 no 2005-07-14T01:54:32Z GPS 99999 tel:555-99 https://www.example.com/ 2005-07-13T01:54:32Z Note that the "provided-by" element has also been populated. Winterbottom, et al. Expires January 19, 2006 [Page 37] Internet-Draft HELD July 2005 If the location assertion had failed in the above example then the Location Server would return the location that the Location Generator generated for the IP-device. If the "exact" parameter was set to "true" then the request would fail. A.4 Requests Using Update and Location URIs In this example the IP-device requests a location URI from the Location Server that includes a "rulesetURI" and an "updateURI". The Location Server generates a location URI and returns it to the IP- device. +--------+ +-----------+ +----------+ | IP | | Location | | Location | | Device | | Server | | Client | +----+---+ +-----+-----+ +----+-----+ | | | | LocReq(URI,upURI,rules) | | |------------------------>| | | | | | Generate | | LocationURI | | LocationURI | | |<------------------------| | | | | | Conveyance(locationURI) | | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~>| | | LocReq(ANY) | | |<----------------| | | | | Authenticate | | LocReq | | |<------------------------| | Generate | | Location | | | location | | |------------------------>| | | Assert | | Location | | | location | | |---------------->| | | | The IP-device sends the location URI to the location-client. The location-client uses the location URI to request a location from the Location Server. Winterbottom, et al. Expires January 19, 2006 [Page 38] Internet-Draft HELD July 2005 The Location Server uses the update URI to request location information from the IP-device. The IP-device determines its location and responds to the Location Server The Location Server asserts that the provided location information is valid and then returns a PIDF-LO to the location-client. POST / HTTP/1.1 Host: lis.example.com Accept: text/plain Accept-Charset: UTF-8,* Content-Type: application/x-www-form-urlencoded Content-Length: 17 locationURI=unbounded&updateURI=https://1.2.3.4:9974/locationUpdate The Location-Server response and subsequent location-client request are the same as shown in Appendix A.2.2 and are not repeated here. The Location Server request to the IP-device using the update URI is shown below. The response from the IP-device will be a PIDF-LO or an error. GET /locationUpdate HTTP/1.1 Host: 1.2.3.4 Accept: application/pidf+xml,text/xml;q=0.8,application/xml;q=0.8 Accept-Charset: UTF-8,* A.5 OBO Location Request Examples The example shows an OBO requesting location on-behalf-of an IP- device. While not directly shown, the OBO is expected to be in a communication path between the IP-device and the location-client. Winterbottom, et al. Expires January 19, 2006 [Page 39] Internet-Draft HELD July 2005 +--------+ +-----------+ +----------+ | OBO | | Location | | Location | | | | Server | | Client | +----+---+ +-----+-----+ +----+-----+ | | | | LocReq(ip,hwaddr,ANY) | | |---------------------->| | | | | | Generate | | LocationURI | | | | | LocationURI | | |<----------------------| | | | | | | | Conveyance(locationURI) | | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >| | | | | LocReq(ANY) | | |<-------------------| | | | | Authenticate | | | | | Generate | | Location | | | | | | location | | |------------------->| | | | The OBO requests a location URI from the Location Server. It uses the "ip" and "hwaddr" parameters in the request to identify the IP- device. POST / HTTP/1.1 Host: lis.example.com Accept: text/plain Accept-Charset: UTF-8,* Content-Type: application/x-www-form-urlencoded Content-Length: 46 ip=1.2.3.4&hwaddr=abcdef012345&locationURI=true The Location Server generates a location URI and returns this to the OBO. The response is not shown here but similar to examples in Winterbottom, et al. Expires January 19, 2006 [Page 40] Internet-Draft HELD July 2005 Appendix A.2.2. The OBO includes the location URI in the IP-device's communications to the location-client, which is not shown here but similar to examples in Appendix A.2.2. The location-client uses the location URI to request location from the Location Server, which is not shown here but similar to examples in Appendix A.2.2. If the location-client satisfies the default ruleset imposed by the Location Server, then a location is returned, which is not shown here but similar to examples in Appendix A.2.2. Winterbottom, et al. Expires January 19, 2006 [Page 41] Internet-Draft HELD July 2005 Intellectual Property Statement 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. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Winterbottom, et al. Expires January 19, 2006 [Page 42]