GEOPRIV J. Winterbottom
Internet-Draft M. Dawson
Expires: April 24, 2006 M. Thomson
Andrew
B. Stark
BellSouth
October 21, 2005
HTTP Enabled Location Delivery (HELD)
draft-winterbottom-http-location-delivery-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 24, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a means by which a Target may request
location from a Location Server using HTTP as a GEOPRIV 'using
protocol'. The protocol uses standard HTTP request methods with
parameters encoded as form data. Methods for discovering accessible
servers are also described.
Winterbottom, et al. Expires April 24, 2006 [Page 1]
Internet-Draft HELD October 2005
Table of Contents
1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 4
1.2. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Access Network . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Device or User . . . . . . . . . . . . . . . . . . . . . . 7
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Location Server Discovery . . . . . . . . . . . . . . . . . . 11
5.1. SLP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4. DNS Service Record . . . . . . . . . . . . . . . . . . . . 12
6. Protocol Specifics . . . . . . . . . . . . . . . . . . . . . . 13
6.1. HELD Protocol Stack . . . . . . . . . . . . . . . . . . . 13
6.2. HELD Tasks . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Location Information Request Parameters . . . . . . . . . 14
6.3.1. locationURI . . . . . . . . . . . . . . . . . . . . . 15
6.3.2. locationType . . . . . . . . . . . . . . . . . . . . . 15
6.3.3. pidf-lo . . . . . . . . . . . . . . . . . . . . . . . 16
6.3.4. exact . . . . . . . . . . . . . . . . . . . . . . . . 17
6.3.5. updateURI . . . . . . . . . . . . . . . . . . . . . . 17
6.3.6. updateResponseTime . . . . . . . . . . . . . . . . . . 18
6.3.7. rulesetURI . . . . . . . . . . . . . . . . . . . . . . 18
6.3.8. ruleset . . . . . . . . . . . . . . . . . . . . . . . 19
6.3.9. retentionInterval . . . . . . . . . . . . . . . . . . 19
6.3.10. responseTime . . . . . . . . . . . . . . . . . . . . . 20
6.3.11. lero . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.3.12. signed . . . . . . . . . . . . . . . . . . . . . . . . 21
6.3.13. Identity Parameters . . . . . . . . . . . . . . . . . 21
6.3.14. Extension parameters . . . . . . . . . . . . . . . . . 22
7. Location Information Response . . . . . . . . . . . . . . . . 23
7.1. Location Assertion . . . . . . . . . . . . . . . . . . . . 24
7.2. URI Generation and Identity Protection . . . . . . . . . . 24
7.2.1. Location URI . . . . . . . . . . . . . . . . . . . . . 24
7.2.2. Presentity URI . . . . . . . . . . . . . . . . . . . . 24
8. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Location Server and Location Generator Authentication . . 26
8.2. Target Authentication . . . . . . . . . . . . . . . . . . 26
8.3. Location Recipient Authentication . . . . . . . . . . . . 27
8.4. Authentication for Location Update . . . . . . . . . . . . 27
9. Persistent State at the Location Server . . . . . . . . . . . 28
9.1. Initiating Contexts . . . . . . . . . . . . . . . . . . . 29
9.2. Terminating Contexts . . . . . . . . . . . . . . . . . . . 29
10. Location Server Interactions . . . . . . . . . . . . . . . . . 31
10.1. Delegating Location URI Allocation . . . . . . . . . . . . 31
Winterbottom, et al. Expires April 24, 2006 [Page 2]
Internet-Draft HELD October 2005
10.2. Delegating Location Determination . . . . . . . . . . . . 32
10.3. Network Address Translation . . . . . . . . . . . . . . . 32
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Simple Location Request . . . . . . . . . . . . . . . . . 33
11.1.1. Request for Any Location . . . . . . . . . . . . . . . 33
11.1.2. Request for Civic Location . . . . . . . . . . . . . . 34
11.2. Location URI Request . . . . . . . . . . . . . . . . . . . 35
11.2.1. Request Location URI Specifying rulesetURI . . . . . . 36
11.2.2. Requesting locationURI Specifying ruleset . . . . . . 39
11.2.3. Location Recipient Using locationURI . . . . . . . . . 40
11.3. Location Assertion . . . . . . . . . . . . . . . . . . . . 41
11.4. Requests Using Update and Location URIs . . . . . . . . . 45
11.5. Location Server to Location Generator . . . . . . . . . . 46
11.6. Location Server to Location Server . . . . . . . . . . . . 47
12. Addresssing Using-Protocol Requirements . . . . . . . . . . . 51
13. Security Considerations . . . . . . . . . . . . . . . . . . . 53
13.1. Identity Assurance and Location Fraud . . . . . . . . . . 53
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
14.1. DHCP Option Code Registration . . . . . . . . . . . . . . 55
14.2. SLP Service Template Registration . . . . . . . . . . . . 55
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
16.1. Normative references . . . . . . . . . . . . . . . . . . . 58
16.2. Informative references . . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61
Intellectual Property and Copyright Statements . . . . . . . . . . 62
Winterbottom, et al. Expires April 24, 2006 [Page 3]
Internet-Draft HELD October 2005
1. Change Log
This section is intended for removal before publication.
1.1. Changes from -01 to -02
Changes based on feedback and further work (in no particular order):
o Used GEOPRIV terminology, as in [RFC3693].
o Added SLP as a discovery option.
o Added concept of using HELD to communicate with a Location
Generator.
o Added short section on LS-LS communication using HELD, which also
covers LS-LG and the NAT problem.
o Added common tasks and the associated parameters that are used to
complete those tasks.
o Added LERO.
o Changed location URI request to use the Content-Location header.
Location information is now always provided (except when a LERO is
requested).
o Moved examples section.
o Corrected examples based on text and added more examples.
o Updated reference to RFC2388.
o Made identity parameters (ip address, hardware address) more
explicit and identifiable, added extension parameters.
o Expanded security considerations.
o Added notes about IP spoofing in target authentication section.
o Removed "on behalf of".
o Expanded sessions section, used less overloaded word "context"
instead of "session", included better guidance on when contexts
should be established and when they should be purged.
o Miscellaneous clarifications, rewordings and reformatting.
Winterbottom, et al. Expires April 24, 2006 [Page 4]
Internet-Draft HELD October 2005
1.2. Changes from -00 to -01
This was a major revision - very little content was retained.
Winterbottom, et al. Expires April 24, 2006 [Page 5]
Internet-Draft HELD October 2005
2. Introduction
This document describes a protocol that employs secure HTTP as a
GEOPRIV 'using protocol' to deliver location information relating to
a Target from a Location Server. The Target discovers or is informed
of the Location Server and establishes a context with the server.
The Location Server constructs a PIDF-LO document and returns this to
the Target. 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 network environments due to its independence from the
link layer. 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.
Many residential broadband services, for example, do not use DHCP to
deliver host configuration data. Even where DHCP is employed the
access is made up of a number of segments maintained and controlled
by different organizations and business entities. The operator of
the DHCP server might have no direct knowledge of where physical
access points terminate, as the equipment is outside their control.
This makes it difficult for the provider of the IP address to provide
a logical address to physical location mapping. HELD overcomes this
problem by allowing Location Server to Location Server and Location
Server to Location Generator communications to occur in a common way
so that the node most able to provide location is ultimately the
source of the location information. A second drawback is that binary
protocols are less able to accommodate new features and data that are
introduced as the XML representation evolves.
2.1. Access Network
Providing a location service is the responsibility of an access
network. This is primarily because the access network must be
physically located in some fashion near an endpoint, either though
hardware, such as cabling, or through electromagnetic transmission.
In addition, in able for location to be made available for all
endpoints, the endpoint cannot be relied upon for location
information, due to lack of appropriate methods for sourcing this
Winterbottom, et al. Expires April 24, 2006 [Page 6]
Internet-Draft HELD October 2005
information. Therefore, the access network must provide a means for
determining the location of endpoints within the access network.
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.
2.2. Device or User
Location information provided for a device is often represented as
the location of a user. However, in this document location
information is attributed to a device and not a person. Primarily,
this is because location determination technologies are generally
designed to locate a device and not a person. In addition to this,
unless the device requires user authentication, there can be no level
of assurance that any particular individual is using the device at
that instance. Thus, if any claim is to be made with regards to the
veracity of location information, the distinction between user and
device must be made explicit.
This distinction should not lead to the impression that the location
of a device does not impact the privacy constraints required by this
protocol. Revealing the location of a device almost invariably
reveals some information about the location of the user of that
device, therefore the same level of privacy protection demanded by a
user is required for their device.
It is expected that, for most applications, the location of a device
will be used interchangably for the location of the user of that
device. This requires either some additional assurances about the
link between device and user, or an acceptance of the aforementioned
limitations.
Winterbottom, et al. Expires April 24, 2006 [Page 7]
Internet-Draft HELD October 2005
3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This document reuses the terms Target, Location Server, Location
Generator, Location Recipient and Using-Protocol as defined in
[RFC3693]. In some specifications the Location Server is referred to
as a Location Information Server or LIS. Note that in this context,
the Location Server is distinct from what is alternatively referred
to as a Registrar in other contexts.
This document also introduces a new acronym, the Local Emergency
Routing Option (LERO), which is a locality-specific option that may
be provided by a Location Server to a Target to assist with emergency
services contact.
Winterbottom, et al. Expires April 24, 2006 [Page 8]
Internet-Draft HELD October 2005
4. Overview
This document describes how a Target requests location information
from a Location Server, including how a Location Server is
discovered.
Location Server discovery is achieved through the use of a new DHCP
option, a new DNS SRV record [RFC2782], Service Location Protocol
(SLP) [RFC2608] 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 Target initiates an HTTP connection with the Location Server. If
the Target 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 Target based on its IP address.
The Location Server then identifies a Location Generator for the
Target, which determines the location of the Target. The Location
Server will take the generated location and produce a PIDF-LO
document that is subsequently returned to the requesting Target. The
PIDF-LO document can contain geodetic information [GML3] and/or civic
address information [I-D.thomson-revised-civic-lo], [I-D.ietf-
geopriv-pidf-lo].
In addition to returning a location to a Target requesting its own
location, the protocol provides support for a location URI, which
enables by-reference distribution of location information by the
Target. This has a number of benefits which are described in more
detail by [I-D.winterbottom-location-uri].
The following figure shows the relationship between the Location
Server and the Target, Location Generator and Location Recipient:
Location Location
+--------+ Request +------------+ Request +-----------+
| Target |--------------->| Location |<-------------| Location |
| |<---------------| Server |------------->| Recipient |
+--------+ Location/URI +------------+ Location +-----------+
^
|
Location
|
+-----------+
| Location |
| Generator |
+-----------+
Winterbottom, et al. Expires April 24, 2006 [Page 9]
Internet-Draft HELD October 2005
HELD is not restricted to serving as a protocol for the acquisition
of location information, it can be used by a Location Server to gain
access to particular functions that it may not have locally. A
Location Server can use HELD to request location information from a
Location Generator, or a Location Server can request certain
information from another Location Server. See Section 10 for
details.
Winterbottom, et al. Expires April 24, 2006 [Page 10]
Internet-Draft HELD October 2005
5. Location Server Discovery
Location Server discovery MAY occur using SLP service discovery, a
DHCP option, a DNS SRV record, or a preconfigured URL; these methods
SHOULD be attempted in the given order where available.
5.1. SLP
This document registers a service type for SLP that describes a
location service. The abstract service prefix "service:locserv:" is
defined as the base for discovering a location server. A client that
requires HELD SHOULD use the URL "service:locserv:https", but this
registration also allows for schemes other than "https".
The template in Section 14.2 includes a number of optional attributes
that may indicate the capabilities of a Location Server. These
specifically apply to HELD, but they could apply to any Location
Server with a similar feature set. An SLP UA MAY use these
attributes to assist in selecting a location service. In the absence
of desired characteristics a service SHOULD still be selected.
5.2. 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 Target with location
information. Where multiple URIs are provided with different
schemes, a client SHOULD use the first scheme that it supports.
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
5.3. DHCPv6
The DHCPv6 option is similarly formatted to the DHCPv4 option.
Winterbottom, et al. Expires April 24, 2006 [Page 11]
Internet-Draft HELD October 2005
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
5.4. 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 could therefore look similar to:
_locserv+http._tcp SRV 1 0 10001 location-server.example.com.
A host determines the search suffix based on local configuration,
which MAY be static, or determined from an automatic configuration
source. For example, DHCP options 15 and 119 can indicate possible
domain suffixes.
The DNS response indicates a fully qualified domain name for the
Location Server, as well as a TCP port. In order to derive a URI
from this FQDN, the "https" scheme MUST be used with the root path
("/"). For the above example, the client constructs a URL as
follows:
https://location-server.example.com:10001/
Winterbottom, et al. Expires April 24, 2006 [Page 12]
Internet-Draft HELD October 2005
6. Protocol Specifics
6.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 against interception and
modification. A detailed treatment of requirements, including how
TLS addresses these is included in Section 12.
6.2. HELD Tasks
This section describes common tasks and how HELD may be used to
accomplish these tasks. Specifically, which parameters are required
in request messages to complete those tasks.
+---------------------------+-----------------+---------------------+
| Task | Applicable | Applicable |
| | Parameters | References |
+---------------------------+-----------------+---------------------+
| Request own location | locationType | Section 6.3, |
| | | Section 6.3.2 |
| | | |
| Request Target's location | locationType | Section 6.3, |
| from location URI | | Section 6.3.2 |
| | | |
| Request location URI | locationURI and | Section 6.3.1, |
| | ruleset or | Section 6.3.7, |
| | rulsetURI | Section 6.3.8 |
| | | |
Winterbottom, et al. Expires April 24, 2006 [Page 13]
Internet-Draft HELD October 2005
| Provide own location to | locationURI and | Section 6.3.3 |
| be retrieved by Location | pidf-lo | |
| Recipients | | |
| | | |
| Update authorization | locationURI and | Section 6.3.1, |
| policy | ruleset or | Section 9 |
| | rulesetURI | |
| | | |
| Cancel a location URI | locationURI | Section 6.3.1, |
| | (0d) | Section 9 |
+---------------------------+-----------------+---------------------+
6.3. 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: a Target
requesting its own location of a Location Server, a Location
Recipient requesting the location of a Target from a Location server,
or a Location Server querying a Location Generator. Request
parameters are included in the body of a POST request using either
URL-encoding or the "multipart/form-data" encoding defined in
[RFC2388]. The same type of request is made from the Target, a
Location Recipient, or a Location Server, the only difference being
the URI to which the requests are posted.
It is RECOMMENDED that URL-encoded parameters be indicated by the
"application/x-www-form-urlencoded" MIME type, however the following
MIME types MUST also be recognized as including URL-encoded data:
"application/x-url-urlencoded", "application/x-www-form-urlencoded".
The Location Server identifies the Target by a different means for
each request source. For requests from the Target, the source IP
address of the connection is used. Requests from the Location
Recipient SHOULD be to a globally unique URI that includes
information that the Location Server can use to identify a particular
Target. Where an Location Server requests the location of a Target
from a Location Generator, the IP address of the Target is included
as a parameter and additional identity 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
Winterbottom, et al. Expires April 24, 2006 [Page 14]
Internet-Draft HELD October 2005
of location functions across servers.
The following sub-sections describe each of the parameters in detail.
6.3.1. locationURI
The "locationURI" parameter indicates if a location URI is required
by the Target.
The value space of this parameter is the superset of the "duration"
type specified in [W3C.REC-xmlschema-2-20041028], plus the boolean
type. A value of "true" implies that a location URI is requested
with no set time limit; a value of "false" indicates that no location
URI is requested. The default value for this parameter is "false".
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.
A location URI is provided in the "Content-Location:" header of the
response message.
A Location Server MUST create a context in response to a location URI
request. The creation of a context is indicated to the Target by the
presence of a "Set-Cookie2" header [RFC2965]; the value of the
"Max-Age" parameter of this header indicates when the context
expires. See Section 9 for more details on contexts.
If a cookie is provided in the request, a value of "false", or a zero
or negative duration for this parameter indicates that the Target
wishes to cancel a location URI that was already issued. See
Section 9.2 for details on terminating contexts.
6.3.2. locationType
A form parameter that may have multiple values. The valid values
are:
any: The Location Server SHOULD attempt to provide location
information in all available forms, however it MAY return any
location information it has available. This value SHOULD be
assumed as the default if no "locationType" is specified.
geodetic: The Location Server SHOULD return a geodetic location for
the Target.
Winterbottom, et al. Expires April 24, 2006 [Page 15]
Internet-Draft HELD October 2005
jurisdictionalCivic: The Location Server SHOULD return a
jurisdictional civic address for the Target.
postalCivic: The Location Server SHOULD return a postal civic address
for the Target.
civic: The Location Server SHOULD return a civic address for the
Target. 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.
6.3.3. pidf-lo
A file describing a location provided by a Target, and the general
format of PIDF-LO documents that the Target wishes the Location
Server use when providing location information.
The "pidf-lo" parameter is transferred to the location server using
the multipart file transfer, with the MIME type of
"application/pidf+xml".
The Location Server SHOULD validate 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 fills in the values of the following elements in
any provided PIDF-LO document with values that it derives or
determines:
o "presentity"
o "timestamp"
o "retention-expiry"
o "method"
Winterbottom, et al. Expires April 24, 2006 [Page 16]
Internet-Draft HELD October 2005
o "provided-by"
A Location Server MAY retain published location information when it
is providing a location URI for a Target. A Location Server SHOULD
place time limits on published location information to prevent stale
information from being provided. The amount of time that location
information can be retained depends on a number of factors such as
the type of network access and the degree of mobility afforded the
device, therefore local policy should limit how long location
information is retained.
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.
PIDF-LO documents SHOULD contain a "method" element if location
information is included.
If the Target wishes authorization policy rules to be included in any
PIDF-LO documents containing its location, then it MUST include them
in the "pidf-lo" parameter 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.
6.3.4. exact
The "exact" parameter may have a value of "true" or "false". If not
included the default value is "false".
When set to "true" the "exact" parameter affects the way that the
"locationType" and "pidf-lo" parameters are interpreted. See
Section 6.3.2 and Section 6.3.3 for details.
6.3.5. updateURI
The "updateURI" parameter MAY be provided by a Target that is capable
of determining its own location. This provides the Location Server
with a means of interrogating a Target to determine the Target's
current location.
A location update URI SHOULD use the "https" scheme so that HELD may
be employed to request information.
When requesting location information from a location update URI, the
following constraints apply:
Winterbottom, et al. Expires April 24, 2006 [Page 17]
Internet-Draft HELD October 2005
o The Location Server MUST NOT request a location URI, or signed
location information.
o The Location Server MUST NOT include a location update URI, a
ruleset or ruleset URI.
o The Target (or other serving entity) MAY disregard any PIDF-LO
document provided.
6.3.6. updateResponseTime
A form parameter provided to the Location Server in conjunction with
an "updateURI" as an indication of how long a Target could take to
respond to a request for location information.
The "updateResponseTime" is indicative only and is a positive decimal
value, which may include a decimal point, 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, that is, up
to three decimal places.
6.3.7. rulesetURI
A form parameter that defines a URI to a set of policies and rules
describing how and to whom a Target's location may be provided.
The "rulesetURI" is the preferred means by which a Target informs the
Location Server to whom the Target'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.
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 Target does not provide an authorization policy, using the
"rulesetURI" or "ruleset" parameters, then the Location Server MUST
NOT provide location information to any requester. Note that in
certain jurisdictions a Location Server MAY include specific third-
parties as mandated by local regulations, for example emergency
services.
If the Target 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
Winterbottom, et al. Expires April 24, 2006 [Page 18]
Internet-Draft HELD October 2005
error. Note that this implies that a Location Server SHOULD attempt
to retrieve the ruleset at the time of a request, however a Location
Server MAY choose not to do this where the requested response time
might be exceeded.
It is anticipated that, to improve responsiveness and reduce network
usage, a Location Server may cache an authorization policy,
consistent with the rules specified by the Rule Holder. For
instance, the Rule Holder may specify retention times using the
"Expires" header in HTTP [RFC2616]. The impact of changes to
authorization policies are addressed in Section 9.1.
Section 11.2.1 demonstrates how a ruleset is associated with a
location URI. The ruleset indicated in a request (either by value or
reference) is bound to the location URI provided in the response.
6.3.8. ruleset
A file containing policies and rules describing how and to whom a
Target'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"
take precedence. Rules documents MUST comply with [I-D.ietf-geopriv-
common-policy] and [I-D.ietf-geopriv-policy].
If the Target does not provide an authorization policy, using the
"ruleset" or "rulesetURI" parameters, then the Location Server MUST
NOT provide location information to any requester. Note that in
certain jurisdictions a Location Server MAY include specific third-
parties as mandated by local regulations, for example, emergency
services.
If the Target provides a "ruleset" that is invalid, or cannot be
parsed by the Location Server then the request MUST be rejected and
an error returned.
6.3.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 in the PIDF-LO document that SHOULD be applied to all
locations provided for this Target.
The "retentionInterval" is an positive decimal value, which may
Winterbottom, et al. Expires April 24, 2006 [Page 19]
Internet-Draft HELD October 2005
include a decimal point, specifying a 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, but MUST NOT use a larger value than that
requested; for example, where the access network supports mobility,
this value can be reduced.
6.3.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, which may include a
decimal point, 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, that is, up to three decimal places.
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
provide any default value, which may be arbitrarily large. 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.
6.3.11. lero
The Local Emergency Routing Option, or "lero", parameter requests
that the Location Server provide the requester with routing
information specific to their locality. The LERO is represented as a
set of URNs, that either contain routing information, or can be
dereferenced to acquire this information.
"lero" is a form parameter that MAY have a value of "true" or
"false". The default value of this parameter is "false".
When present and set to "true", the Location Server MUST NOT provide
Winterbottom, et al. Expires April 24, 2006 [Page 20]
Internet-Draft HELD October 2005
a PIDF-LO document in the response. Instead, the LERO is provided as
a text document with a MIME type of "text/plain".
A LERO document includes one or more URNs, each on a different line,
that is, separated by CRLF. For example, a LERO could include URNs
such as: a contact URI for the local Public Safety Answering Point
(PSAP), an Emergency Location Identification Number (ELIN), or any
other local information applicable to the routing of an emergency
call.
6.3.12. signed
A form parameter that may have a value of "true" or "false". If not
included the default value is "false".
When the "signed" parameter is set to "true", the Location Server
MUST provide a signed location object as defined in [I-D.thomson-
domain-auth], or return an error. If not present a value of "false"
MUST be assumed. Location information MUST NOT be signed unless
explicitly requested.
6.3.13. Identity Parameters
When a Location Server requests location information from a Location
Generator, it might need to provide some information that identifies
the Target to the Location Generator. Identity parameters SHOULD
begin with the string "id-" to indicate the nature of the parameter
and enable appropriate treatment.
A Location Generator MUST NOT use identity parameters unless it has
successfully authenticated the identity of an authorized Location
Server. Identity parameters are inputs that could affect the output
of the location determination process performed by a Location
Generator; if incorrect values are used, fraudulent location
information could be acquired.
Two identity parameters are described in this document, others MAY be
defined by extension:
id-ip: The IP address of the Target. Either a dotted decimal IPv4
address, or a valid IPv6 address [RFC2373].
id-hwaddr: The hardware address of the Target as a sequence of
hexadecimal digits.
Winterbottom, et al. Expires April 24, 2006 [Page 21]
Internet-Draft HELD October 2005
6.3.14. Extension parameters
Parameter names that contain the period character (".") are defined
as extension parameters. Extensions SHOULD be given names of the
form "parameter.company.com". Using a domain name registered to the
person or organization creating the extension parameter limits the
opportunity for collisions in parameter definitions.
Extension parameters that are not recognized SHOULD be ignored. If a
Location Server forwards a request to another Location Server, it
SHOULD include all received extension parameters.
Winterbottom, et al. Expires April 24, 2006 [Page 22]
Internet-Draft HELD October 2005
7. Location Information Response
The location information response message contains either a
"application/pidf+xml" body containing a valid PIDF-LO document or a
"text/plain" body containing the LERO. 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.
403 Forbidden: The Location Server MAY return this code if a Location
Recipient 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 Recipient 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 information MUST include an
"Accept" header that includes "text/xml",
"application/xml""application/pidf+xml", or "*".
410 Gone: The Location Server MAY return this code if a request
arrives to an expired location URI.
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 April 24, 2006 [Page 23]
Internet-Draft HELD October 2005
7.1. Location Assertion
Location assertion is most applicable where a Target 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 Target to tell the Location Server where it
thinks it is.
If the Location Server decides not to use the location information
provided by the Target then the Location Server MUST do one of two
things depending on the value of the "exact" parameter:
o If "exact" parameter is set to "true" then the Location Server
MUST return an error to the Target.
o If the "exact" parameter is set to "false", then the Location
Server MUST return the location provided by the Location
Generator.
7.2. URI Generation and Identity Protection
7.2.1. Location URI
The location URI is an identifier generated by the Location Server so
that the Target's location may be retrieved by-reference. Location
URIs are discussed in more detail in Section 11.2.2.
The Location Server MUST be able to correlate a location URI with a
Target context in order to provide location information, therefore a
location URI MUST be globally unique. The Location Server MUST also
ensure that no private information is leaked in the location URI;
that is, the location URI MUST NOT indicate either identity or
location information in any way. This implies that internal
correlation is the only means available to match a location URI to a
particular Target.
To this end, it is RECOMMENDED that a location URI be, at a minimum,
composed of a public address for the Location Server and a random
sequence of characters that uniquely identifies a context within the
Location Server.
7.2.2. Presentity URI
There is no requirement for the Location Server to know the identity
of the user of a Target. The unlinked pseudonym that is used for a
presentity URI ensures that this identity can be protected.
Winterbottom, et al. Expires April 24, 2006 [Page 24]
Internet-Draft HELD October 2005
It is RECOMMENDED that Location Server be able to identify a Target
context based on the presentity URI. Therefore presentity URIs
SHOULD be globally unique. Where requests include a PIDF-LO
document, the Location Server SHOULD use that presentity URI to limit
the effectiveness of the attack described in Section 13.1. A
Location Server MAY append URI parameters to ensure that the URI is
globally unique.
A Location Server MUST generate a presentity URI when one is not
provided. A Location Server MAY also generate a presentity URI, even
where one is provided. Generating a presentity URI ensures that it
is globally unique, however this might provide a Location Recipient
no means of attributing location information to a particular Target,
as described in Section 13.1.
Winterbottom, et al. Expires April 24, 2006 [Page 25]
Internet-Draft HELD October 2005
8. Authentication
Identification of clients to a Location Server may be achieved
through any of the means available to HTTP/TLS implementations.
Selection of authentication method is left to specific administrative
domains. The HTTP authentication methods described in [RFC2616] MAY
be used, or any of the authentication methods available for TLS
[RFC2246]. Authentication using X.509v3 certificates is RECOMMENDED.
Regardless of the following recommendations, a Location Server MAY
require any form of authentication from Targets as dictated by local
policy.
8.1. Location Server and Location Generator Authentication
This document RECOMMENDS that Location Servers and Location
Generators support X.509v3 certificate-based authentication for
server authentication. If a Location Server uses either another
Location Server or a Location Generator, an X.509v3 certificate to
provide client authentication.
8.2. Target Authentication
The Location Server identifies that a request comes from a Target by
the incoming URI and the accompanying HELD parameters. For these
requests, the source IP address of the request message is used to
determine the location of the device. The response to this request
is returned to the IP address where the request came from.
A Location Server MAY require any reasonable form of authentication
for Targets. However, using return routability might prove
sufficient protection against providing location information to the
wrong entity. Note that a Location Server provides location
information to the device that currently uses the IP address.
Using return routability can reduce the administrative effort
required to manage device authentication, however care should be
taken to reduce the impact of location theft. Network administrators
that rely on return routability should ensure that IP spoofing cannot
be used to obtain a location URI for some other device. Measures to
mitigate this problem include:
o Limit the interval over which a location URI is valid, as
suggested in Section 6.3.1.
o Ensure that requests to a Location Server can only originate from
the served access network.
Winterbottom, et al. Expires April 24, 2006 [Page 26]
Internet-Draft HELD October 2005
o Provide a means for the Location Server (perhaps through a
Location Generator) to be notified of changes in network
connectivity and address allocation. This ensures that location
information can be cancelled.
o Associate location information with other identifiers that can be
independently verified, such as device hardware addresses.
These measures are dependent on network deployments and should each
be considered as appropriate, keeping in mind existing constraints on
a network. For instance, fixed access providers may be able to
restrict the allocation of IP addresses to a single physical line,
negating the need for any of these measures.
8.3. Location Recipient Authentication
Authentication of Location Recipients requesting the location of a
Target 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 Target. If the
Location Recipient request fails authentication then a "404 Not
Found" status code SHOULD be returned.
8.4. Authentication for Location Update
A Location Server SHOULD should have one X.509v3 certificate that is
used for all HELD-based communication. That is, it SHOULD provide
the same certificates to Targets regardless of if the request is from
the Target, or to the location update URI provided by the Target. If
a Target provides a location update URI, it is RECOMMENDED that the
Target retain the certificate provided by the Location Server to
later authenticate the Location Server.
Winterbottom, et al. Expires April 24, 2006 [Page 27]
Internet-Draft HELD October 2005
9. Persistent State at the Location Server
When a client requests a location URI from a Location Server, the
Location Server MUST maintain sufficient state information to be able
to serve requests to the provided URI. The term _context_ avoids
confusion with the term _session_, which is often used in the HTTP
concept with regards to a persistent relationship between a
particular client and a server.
When a location URI is requested, the Location Server MUST create a
context that stores the following state information, where it is
provided by the Target:
o Any PIDF-LO document format provided as a "pidf-lo" parameter.
o The authorization policy (the "rulesetURI" or "ruleset"
parameters).
o The location update URI and associated response time.
o Any Target identification information necessary to be able to
determine location information, or sufficient to provide to a
Location Generator.
The following diagram shows how a context is referenced by Targets
and Location Recipients.
+--------+
| Target |
+--------+
|
(HTTP Cookie)
|
v
.-----------------------------.
| Location Server Context |
| (PIDF-LO, Auth. Policy, ...) |
| |
| +-------------------------+ |
| | Location URI | |
`-+-------------------------+-'
^ ^
| |
+-----------+ +-----------+
| Location | ... | Location |
| Recipient | | Recipient |
+-----------+ +-----------+
Winterbottom, et al. Expires April 24, 2006 [Page 28]
Internet-Draft HELD October 2005
Although they reference the same context through the location URI,
Location Recipients MUST NOT be able to update the information stored
in the context. Note also that a location URI ensures that the
location retrieved from the Location Server always contains the
location of the Target.
9.1. Initiating Contexts
A Location Server MUST issue an HTTP cookie to a Target that requests
a location URI so that the Target can update the information stored
in the context. Cookies are set using the "Set-Cookie2" header, as
defined in [RFC2965].
The Target updates stored information by providing a request that
includes the updated information and the cookie information (using
the "Cookie" header). The Location Server MAY retain only latest
provided value for any of these data. Changes to authorization
policy MUST be immediate; in particular, if a rulesetURI is provided
the Location Server MUST assume that any cached rules are no longer
valid.
A Location Server MAY issue HTTP cookies to a Target for other
requests. Such a cookie can be used for correlating requests.
However, if a Target receives a cookie the Location Server MUST store
the listed state information. A Target that makes a request from a
Location Server using a cookie MAY assume that the Location Server
has created a context that includes any query information that was
previously provided. A Target MAY therefore omit parameters that
haven't changed in subsequent requests.
A Location Server MAY also issue HTTP cookies to Location Recipients.
Since Location Recipients do not initiate a context, they do not need
to make any assumptions about the nature of stored data.
A Location Server MUST NOT use an existing context for a request from
a Target that does not contain an issued cookie. This ensures that
hosts that appear to originate from the same network address cannot
affect each other. This particularly applies where Network Address
Translation (NAT) is employed. To protect against denial of service
type attacks, a Location Server SHOULD limit the number of contexts
that it maintains for any one logical location.
9.2. Terminating Contexts
The Location Server SHOULD expire contexts based on the value of the
"locationURI" parameter, see Section 6.3.1. The expiration time of a
context SHOULD be indicated through the "Max-Age" parameter of the
"Set-Cookie" header.
Winterbottom, et al. Expires April 24, 2006 [Page 29]
Internet-Draft HELD October 2005
The Location Server MAY terminate a context at any time to react to
changes in the access network. For example, the Location Server
could detect when the IP address allocated to the Target is
reassigned to another device, or when the device is no longer
attached to the network. If a Target subsequently uses a cookie to
attempt to refer to a context that has been removed in this fashion,
the Location Server SHOULD treat the request as if the cookie were
not present.
Targets SHOULD be able to extend the expiry time of a context by
requesting a location URI with a new duration, providing that the
context has not already expired.
When a request to terminate a context is received (see
Section 6.3.1), the Location Server MUST remove any stored state
information relating to identified context. The Location Server MUST
indicate this expiry by providing a response message that indicates
that the context identifying cookie has expired. A response message
can indicate that cookie has expired by including a "Set-Cookie"
header with the "Max-Age" parameter set to "0".
Winterbottom, et al. Expires April 24, 2006 [Page 30]
Internet-Draft HELD October 2005
10. Location Server Interactions
Differences in network configurations can mean that location
information cannot be provided by a single service that houses a
Location Server and Location Generator function. Typical scenarios
include segmented networks operated by different organizations; a
network "core" that is hidden from its users; and, networks employing
network address translation (NAT). To address these scenarios, it is
often desirable to segment the Location Server and Location Generator
functions in a fashion that suits the specific network.
HELD supports this division of functions by providing a means for a
Location Server to delegate specific responsibilities to another
entity, using HELD. Typical functions that may be delegated are:
location determination (Location Generator), allocation of location
URIs, and signing of location information. If the Location Server is
unable to serve a request it MAY forward a HELD request to an entity
that is able to service that request.
10.1. Delegating Location URI Allocation
A Location Server MAY delegate the allocation of location URIs to
another Location Server using the HELD protocol. For instance, a
Location Server that is behind a firewall may delegate the allocation
of location URIs to another Location Server that is more accessible
from the wider network.
Location Servers that delegate the allocation of a location URIs MAY
not need to maintain a context. When location URIs are provided by
another Location Server, the Location Server does not have to
understand or enforce authorization policy rules. A Location Server
that provides a location URI MUST enforce the authorization policy
rules specified by the Target. Therefore, a Location Server that
delegates the allocation of location URIs MUST forward any request
that contains either the "rulesetURI" or "ruleset" parameters
immediately.
To delegate the allocation of location URIs a Location Server either
publishes a PIDF-LO document, or provides a location update URI. A
location update URI SHOULD be used to enable the retrieval of current
location information when requests are made to the location URI. A
location update URI MAY be omitted only when a location update URI
cannot be provided. If a location update URI is not provided the
Location Server MUST provide location information in the request.
For instance, the Location Server might be unreachable externally due
to firewalls or Network Address Translation (NAT).
Winterbottom, et al. Expires April 24, 2006 [Page 31]
Internet-Draft HELD October 2005
10.2. Delegating Location Determination
If the Location Generator function is not a part of the Location
Server, the Location Server may forward a HELD request to an
appropriate Location Generator to retrieve location information.
For these instances, the Location Server includes the IP address of
the Target, and any additional identification information it has
available in a request message. In this case, the Location Generator
uses this IP address as an input to its location determination
function, rather than the source IP address of the request message.
10.3. Network Address Translation
When session border controllers, for instance, NAT devices, are
employed, a Location Server is unable to distinguish between
individual hosts behind the NAT; all hosts appear as a single host -
the NAT device. This limits the ability of a Location Generator that
is external to the translated network to determine locations for each
individual host behind the NAT device.
In some cases, particularly where only a small number of hosts exist
in a small area, this limitation is not of great concern. For
example, many households employ a modem/router with NAT for internet
access; the location of the residence is considered ample for a large
range of applications.
However, this limitation is unacceptable where the network on the
other side of a NAT device covers a larger space or multiple sites.
In the most extreme cases, intranets that span multiple continents
employ a NAT, which means that an externally determined location
could not possibly be accurate.
It is RECOMMENDED that where sufficient area is covered, a Location
Server be provided for the network behind the NAT device. This
Location Server MAY provide a limited service and use HELD to request
other features from external Location Servers.
Winterbottom, et al. Expires April 24, 2006 [Page 32]
Internet-Draft HELD October 2005
11. Examples
The following subsections represent a few examples of location
requests and subsequent responses.
11.1. Simple Location Request
In this example a Target makes a request for any location from the
Location Server.
The Location Server determines the location and subsequently returns
it to the Target, which may then communicate its location to other
entities.
+--------+ +-----------+ +-----------+
| Target | | Location | | Location |
| | | Server | | Recipient |
+----+---+ +-----+-----+ +-----+-----+
| | |
| LocReq(ANY) | |
|------------------>| |
| | |
| Determine |
| Location |
| | |
| Location | |
|<------------------| |
| | |
| |
| Conveyance |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >|
| |
11.1.1. Request for Any Location
In this example the Target 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 April 24, 2006 [Page 33]
Internet-Draft HELD October 2005
A positive response from the Location Server to the Target would look
similar to:
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
Cache-control: private
Content-Type: application/pidf+xml
Content-Length: 648
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:3650n87934c@lis.example.com">
<tuple id="3b650sf789nd">
<status>
<gp:geopriv>
<gp:location-info>
<gml:position>
<gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4326">
<gml:pos>-34.407 150.88001</gml:pos>
</gml:Point>
</gml:position>
</gp:location-info>
<gp:usage-rules/>
</gp:geopriv>
</status>
<timestamp>2005-07-13T01:59:45+00:00</timestamp>
</tuple>
</presence>
11.1.2. Request for Civic Location
In this example the Target 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
locationType=civic
Winterbottom, et al. Expires April 24, 2006 [Page 34]
Internet-Draft HELD October 2005
A civic location response from the Location Server follows:
HTTP/1.x 200 OK
Server: Example LIS
Date: Wed, 13 Jul 2005 01:54:47 GMT
Expires: Wed, 13 Jul 2005 07:54:47 GMT
Cache-control: private
Content-Type: application/pidf+xml
Content-Length: 1131
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
entity="pres:Rvi46wB4fd345@lis.example.com">
<tuple id="38mvwfq54">
<status>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>AU</cl:country>
<cl:A1>NSW</cl:A1>
<cl:A3>Wollongong</cl:A3>
<cl:A4>North Wollongong</cl:A4>
<cl:A6>Northfields</cl:A6>
<cl:STS>Avenue</cl:STS>
<cl:LMK>University of Wollongong</cl:LMK>
<cl:LOC>Building 3</cl:LOC>
</cl:civilAddress>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>
2005-07-13T07:54:47Z
</gp:retention-expiry>
</gp:usage-rules>
<gp:method>DHCP</gp:method>
</gp:geopriv>
</status>
<timestamp>2005-07-13T01:54:47Z</timestamp>
</tuple>
</presence>
11.2. Location URI Request
In these examples the Target requests a location URI from the
Location Server. Two examples show the way in which a Target may
Winterbottom, et al. Expires April 24, 2006 [Page 35]
Internet-Draft HELD October 2005
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 Recipient can request the location of a Target
using a location URI.
+--------+ +-----------+ +-----------+
| Target | | Location | | Location |
| | | Server | | Recipient |
+----+---+ +-----+-----+ +-----+-----+
| | |
| LocReq(URI,rules) | |
|------------------>| |
| | |
| Generate |
| LocationURI |
| | |
| LocationURI | |
|<------------------| |
| | |
| |
| Conveyance(locationURI) |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >|
| |
| | LocReq(ANY) |
| |<-------------------|
| | |
| Authenticate |
| | |
| Determine |
| Location |
| | |
| | location |
| |------------------->|
| | |
11.2.1. Request Location URI Specifying rulesetURI
In this example the Target specifies a "rulesetURI" when requesting a
"locationURI".
Winterbottom, et al. Expires April 24, 2006 [Page 36]
Internet-Draft HELD October 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: application/x-www-form-urlencoded
Content-Length: 61
locationURI=true&rulesetURI=https://10.2.3.4:9974/ruleset.xml
Winterbottom, et al. Expires April 24, 2006 [Page 37]
Internet-Draft HELD October 2005
The Location Server responds with a PIDF-LO document, except that a
location URI is included in the "Content-Location" header and a
cookie is set to indicate that a session has been created.
HTTP/1.x 200 OK
Server: Example LIS
Set-Cookie2: httplocationID="F168jiwdjw92jds09";
Version="1"; Max-Age: 86400; Secure
Date: Wed, 13 Jul 2005 01:54:47 GMT
Expires: Wed, 13 Jul 2005 07:54:47 GMT
Cache-control: private
Content-Type: application/pidf+xml
Content-Location: https://lis.example.com/362b0e75du908n1
Content-Length: 1131
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
entity="pres:Rvi46wB4fd345@lis.example.com">
<tuple id="38mvwfq54">
<status>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>AU</cl:country>
<cl:A1>NSW</cl:A1>
<cl:A3>Wollongong</cl:A3>
<cl:A4>North Wollongong</cl:A4>
<cl:A6>Northfields</cl:A6>
<cl:STS>Avenue</cl:STS>
<cl:LMK>University of Wollongong</cl:LMK>
<cl:LOC>Building 3</cl:LOC>
</cl:civilAddress>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>
2005-07-13T07:54:47Z
</gp:retention-expiry>
</gp:usage-rules>
<gp:method>DHCP</gp:method>
</gp:geopriv>
</status>
<timestamp>2005-07-13T01:54:47Z</timestamp>
</tuple>
</presence>
Winterbottom, et al. Expires April 24, 2006 [Page 38]
Internet-Draft HELD October 2005
11.2.2. Requesting locationURI Specifying ruleset
In this example the Target provides an explicit "ruleset" in a
request for a location URI.
Note that the location request contains a cookie identifying the
session created from a previous request. [[NOTE: The authorization
policy here is incorrect, however the common policy document is still
undergoing changes. This should be updated once that document
becomes stable.]]
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: $Version="1"; httplocationID="F168jiwdjw92jds09"
Content-Type: multipart/form-data; boundary=-29733
Content-Length: 472
---29733
Content-Disposition: form-data; name="locationURI"
true
---29733
Content-Disposition: form-data; name="ruleset"
Content-Type: application/auth-policy+xml
<?xml version="1.0"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="rul123">
<conditions>
<identity>
<id>helpme@roadside.assistance.com</id>
</identity>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
---29733--
The Location Server accepts the request and responds with a
"locationURI". Requests to this URI will result in the Location
Server providing location information to the requester based on the
rules in the provided ruleset. Note that the PIDF-LO returned in
this example is identical to the one shown in Section 11.2.1, so it
is omitted.
Winterbottom, et al. Expires April 24, 2006 [Page 39]
Internet-Draft HELD October 2005
HTTP/1.x 200 OK
Server: Example LIS
Set-Cookie2: httplocationID="F168jiwdjw92jds09";
Version="1"; Max-Age: 86400; Secure
Date: Wed, 13 Jul 2005 01:54:47 GMT
Expires: Wed, 13 Jul 2005 07:54:47 GMT
Cache-control: private
Content-Type: application/pidf+xml
Content-Location: https://lis.example.com/362b0e75du908n1
Content-Length: 1131
... PIDF-LO contents omitted for brevity ...
11.2.3. Location Recipient Using locationURI
This example shows how a Location Recipient 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 GET request shows how a Location Recipient can request
arbitrary location information. A POST to the "locationURI" with
parameters is also allowed where specific location formats are
required.
Winterbottom, et al. Expires April 24, 2006 [Page 40]
Internet-Draft HELD October 2005
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
Cache-control: private
Content-Type: application/pidf+xml
Content-Length: 692
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:3650n87934c@lis.example.com">
<tuple id="3b650sf789nd">
<status>
<gp:geopriv>
<gp:location-info>
<gml:position>
<gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4326">
<gml:pos>-34.407 150.88001</gml:pos>
</gml:Point>
</gml:position>
</gp:location-info>
<gp:usage-rules/>
</gp:geopriv>
</status>
<timestamp>2005-07-13T01:59:45+00:00</timestamp>
</tuple>
</presence>
11.3. Location Assertion
In the example the Target contains an on-board GPS so that the device
can accurately determine where it is. The Target asserts its
location to the Location Server to obtain a valid PIDF-LO document.
Winterbottom, et al. Expires April 24, 2006 [Page 41]
Internet-Draft HELD October 2005
+--------+ +-----------+
| Target | | Location |
| | | Server |
+----+---+ +-----+-----+
| |
| LocReq(Assert) |
|------------------>|
| |
| Validate
| Location
| |
| Location |
|<------------------|
| |
Winterbottom, et al. Expires April 24, 2006 [Page 42]
Internet-Draft HELD October 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: 971
---29733
Content-Disposition: form-data; name="locationType"
geodetic
---29733
Content-Disposition: form-data; name="pidf-lo"
Content-Type: application/pidf+xml
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.org/gml"
entity="pres:user@example.com">
<tuple id="38mvwfq54">
<status>
<gp:geopriv>
<gp:location-info>
<gml:position>
<gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4326">
<gml:pos>-34.407 150.88001</gml:pos>
</gml:Point>
</gml:position>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
</gp:usage-rules>
<gp:method>GPS</gp:method>
</gp:geopriv>
</status>
<timestamp>2005-07-13T01:54:32Z</timestamp>
</tuple>
</presence>
---29733--
If the Location Server is able to validate the location information
then a "200 OK" status is returned to the Target along with the
PIDF-LO document providing the location.
Winterbottom, et al. Expires April 24, 2006 [Page 43]
Internet-Draft HELD October 2005
HTTP/1.x 200 OK
Server: Example LIS
Date: Wed, 13 Jul 2005 01:54:47 GMT
Expires: Wed, 13 Jul 2005 02:04:47 GMT
Cache-control: private
Content-Type: application/pidf+xml
Content-Length: 1242
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.org/gml"
entity="pres:vw46sny894G9@lis.example.com">
<tuple id="38mvwfq54">
<status>
<gp:geopriv>
<gp:location-info>
<gml:position>
<gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4326">
<gml:pos>-34.407 150.88001</gml:pos>
</gml:Point>
</gml:position>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2005-07-13T02:04:32Z</gp:retention-expiry>
</gp:usage-rules>
<gp:method>GPS</gp:method>
<gp:provided-by>
<mydp:myProvidedBy
xmlns:dp="urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider"
xmlns:mydp="http://www.example.org/schema/myDataProvider">
<dp:DataProviderID>99999</dp:DataProviderID>
<dp:TelURI>tel:555-99</dp:TelURI>
<dp:URL>https://www.example.com/</dp:DataProviderID>
</mydp:myProvidedBy>
</gp:provided-by>
</gp:geopriv>
</status>
<timestamp>2005-07-13T01:54:32Z</timestamp>
</tuple>
</presence>
Note that the "provided-by" element has also been populated.
If the location assertion had failed in the above example then the
Location Server would return the location that the Location Generator
Winterbottom, et al. Expires April 24, 2006 [Page 44]
Internet-Draft HELD October 2005
generated for the Target. If the "exact" parameter was set to "true"
then the request would fail.
11.4. Requests Using Update and Location URIs
In this example the Target requests a location URI from the Location
Server that includes a "rulesetURI" and an "updateURI". The Location
Server assigns a location URI and returns it to the Target.
+--------+ +-----------+ +-----------+
| Target | | Location | | Location |
| | | Server | | Recipient |
+----+---+ +-----+-----+ +-----+-----+
| | |
| LocReq(URI,upURI,rules) | |
|------------------------>| |
| | |
| Generate |
| LocationURI |
| LocationURI | |
|<------------------------| |
| | |
| Conveyance(locationURI) |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~>|
| | LocReq(ANY) |
| |<----------------|
| | |
| Authenticate |
| LocReq | |
|<------------------------| |
Determine | |
Location | |
| Location | |
|------------------------>| |
| Validate |
| Location |
| | Location |
| |---------------->|
| | |
The Target sends the location URI to the Location Recipient. The
Location Recipient uses the location URI to request a location from
the Location Server.
The Location Server uses the update URI to request location
information from the Target. The Target determines its own location
and responds to the Location Server.
Winterbottom, et al. Expires April 24, 2006 [Page 45]
Internet-Draft HELD October 2005
The Location Server validates the provided location information and
then returns a PIDF-LO document to the Location Recipient.
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: 63
locationURI=true&updateURI=https://10.2.3.4:9974/locationUpdate
The Location-Server response and subsequent Location Recipient
request are the same as shown in Section 11.2.2 and are not repeated
here. The Location Server request to the Target using the update URI
is shown below. The response from the Target is either a PIDF-LO
document or an error.
GET /locationUpdate HTTP/1.1
Host: 10.2.3.4
Accept: application/pidf+xml,text/xml;q=0.8,application/xml;q=0.8
Accept-Charset: UTF-8,*
11.5. Location Server to Location Generator
This example demonstrates how a Location Server might delegate
location determination to a Location Generator.
+--------+ +------------+ +------------+
| Target | | Location | | Location |
| | | Server | | Generator |
+----+---+ +-----+------+ +-----+------+
| Location Request | |
|--------------------->| |
| | Location Request |
| |--------------------->|
| | |
| Allocate Determine
| Location URI Location
| | |
| | Location Information |
| |<---------------------|
| Location Information | |
|<---------------------| |
| | |
Winterbottom, et al. Expires April 24, 2006 [Page 46]
Internet-Draft HELD October 2005
From the perspective of the Target, the Location Server interaction
is no different to that shown in previous examples. That is, the
fact that a Location Generator interaction is required is not visible
to the Target. Similarly the Location Recipient is also unaware of
the existence of a separate Location Generator.
For the purposes of this example, assume that the request and
response messages are identical to those in Section 11.2.2. However,
the response is sourced from both the Location Server and Location
Generator.
The following request message is sent from the Location Server to the
Location Generator. The Location Server indicates the identity of
the target using the "id-ip" parameter. Note that the request does
not need to include either of the "locationURI" or "ruleset"
parameters.
POST / HTTP/1.1
Host: location-generator.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: 14
id-ip=10.2.3.4
The response from the Location Generator includes a PIDF-LO document
and the associated expiry information.
HTTP/1.x 200 OK
Server: Example Location Generator
Date: Wed, 13 Jul 2005 01:54:47 GMT
Expires: Wed, 13 Jul 2005 07:54:47 GMT
Cache-control: private
Content-Type: application/pidf+xml
Content-Length: 1131
... PIDF-LO contents omitted for brevity ...
11.6. Location Server to Location Server
This example demonstrates how a Location Server might delegate the
allocation of location URIs to another Location Server.
Winterbottom, et al. Expires April 24, 2006 [Page 47]
Internet-Draft HELD October 2005
+--------+ +------------+ +------------+
| Target | | Location | | Location |
| | | Server A | | Server B |
+----+---+ +-----+------+ +-----+------+
| | |
| Location Request | |
|--------------------->| |
| | |
| Determine |
| Location |
| | Location Request |
| |--------------------->|
| | |
| | Allocate
| | Location URI
| | |
| | Location Information |
| |<---------------------|
| Location Information | |
|<---------------------| |
| | |
Similar to the example in Section 11.5, the interaction between the
Target and the Location Server is identical to that in
Section 11.2.2, except that the location URI indicates a different
Location Server than the one that the Target directly interacts with.
Winterbottom, et al. Expires April 24, 2006 [Page 48]
Internet-Draft HELD October 2005
The request message is identical to that in Section 11.2.2. Upon
receipt of this request, Location Server A determines the location of
the Target and sends a request to Location Server B as follows:
POST / HTTP/1.1
Host: lis-b.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: 1803
---29733
Content-Disposition: form-data; name="locationURI"
true
---29733
Content-Disposition: form-data; name="updateURI"
https://lis.example.com/F168jiwdjw92jds09
---29733
Content-Disposition: form-data; name="ruleset"
Content-Type: application/auth-policy+xml
... authorization policy document included here (omitted) ...
---29733
Content-Disposition: form-data; name="pidf-lo"
Content-Type: application/pidf+xml
... PIDF-LO document included here (omitted) ...
---29733--
Note that this request message does not include identity parameters,
instead it includes a location update URI. Location Server B does
not perform the role of Location Generator, therefore it does not
need to receive any identity information.
Winterbottom, et al. Expires April 24, 2006 [Page 49]
Internet-Draft HELD October 2005
The response from Location Server B includes the same PIDF-LO body
that was included in the request from Location Server A, but now
includes a "Content-Location" header with a Location URI.
HTTP/1.x 200 OK
Server: Example LIS
Set-Cookie2: locURInumber="vyIh39sS843sil3mr";
Version="1"; Max-Age: 86400; Secure
Date: Wed, 13 Jul 2005 01:54:47 GMT
Expires: Wed, 13 Jul 2005 07:54:47 GMT
Cache-control: private
Content-Type: application/pidf+xml
Content-Location: https://lis-b.example.com/362b0e75du908n1
Content-Length: 1131
... PIDF-LO document omitted for brevity ...
Upon receipt of this response, Location Server A stores the cookie
and issues another. Location Server A now maintains state that
correlates between cookie received from Location Server B and the one
that it issues. Location Server A also needs to maintain enough
information to be able to service the location update URI that it
issued.
The response from Location Server A is shown below:
HTTP/1.x 200 OK
Server: Example LIS
Set-Cookie2: httplocationID="F168jiwdjw92jds09";
Version="1"; Max-Age: 86400; Secure
Date: Wed, 13 Jul 2005 01:54:47 GMT
Expires: Wed, 13 Jul 2005 07:54:47 GMT
Cache-control: private
Content-Type: application/pidf+xml
Content-Location: https://lis-b.example.com/362b0e75du908n1
Content-Length: 1131
... PIDF-LO document omitted for brevity ...
Winterbottom, et al. Expires April 24, 2006 [Page 50]
Internet-Draft HELD October 2005
12. Addresssing Using-Protocol Requirements
The following list individually addresses the requirements from
[RFC3693]:
Req 1-3: These requirements are addressed by the formatting in
[I-D.ietf-geopriv-pidf-lo], and subsequently [I-D.ietf-geopriv-
pdif-lo-profile].
Req 4: This protocol defines an out-of-band method for conveying
rulesets to a Location Server, which controls privacy and security
for the Location Object and associated rules. A Location Server
cannot distribute location information unless expressly given
permission. A Location Server cannot disseminate rulesets and may
only provide rulesets that are explicitly provided for that
purpose by a user.
Req 5: Key establishment is acheived by using TLS [RFC2246].
Req 6: This protocol does not add to the size of the Location Object,
but is constrained by [I-D.ietf-geopriv-pidf-lo] in its encoding.
HTTP [RFC2616] supports content compression, which may be employed
to reduce the size of message contents.
Req 7: This document makes it mandatory to follow provided rules and
specifies that where rules are not provided the Location Server
MUST prohibit access to data.
Req 8: The interactions between a Location Generator and other
entities are not defined by this document.
Req 9: This document specifies that Rules, or authorization policy
documents, are stored separately to the Location Object and that a
Viewer does not receive these rules. A Rule Maker may specify a
set of rules that are visible to a Viewer by including this
information in a template PIDF-LO document.
Req 10: This requirement is addressed by [I-D.ietf-geopriv-common-
policy] and [I-D.ietf-geopriv-policy].
Req 11: This requirement is addressed by [I-D.ietf-geopriv-pidf-lo].
Req 12: Section 7.2 includes rules that ensure that a location URI
does not include information that reveals any information about
the Target. In addition to this, this section also specifies that
the presentity URI provided in Location Objects be an Unlinked
Pseodonym, which offers the protections described in [RFC3694].
Winterbottom, et al. Expires April 24, 2006 [Page 51]
Internet-Draft HELD October 2005
Req 13: This document recommends that the authentication schemes
adopted in [I-D.ietf-geopriv-common-policy] are used.
Req 14:
Req 14.1: TLS provides a number of schemes that enable mutual end-
point authentication. Section 8.1 addresses this requirement
in more detail.
Req 14.2: TLS provides protection against in-transit modification
of information.
Req 14.3: TLS provides data confidentiality.
Req 14.4: TLS provides protection against replay attacks.
Req 15:
Req 15.1: This document makes TLS a MUST implement component of
the defined protocol stack. Other aspects, including the
provision of a digital signature on location information are
outside the scope of this document; for instance, [I-D.thomson-
domain-auth] defines a digital signature scheme.
Req 15.2: No further security measures are identified as
mandatory.
Req 15.3: The Location Server does not have any means of ensuring
that any request is as a result of an emergency call. However,
see Section 8.2 for details on how Target authentication MAY be
avoided.
Where HELD is used between a Location Server and Location Generator,
TLS can provide identity assurance, data confidentiality, in-transit
modification and replay protection. This protection is sufficient to
ensure that only the Location Server and Generator have access to the
location information.
Winterbottom, et al. Expires April 24, 2006 [Page 52]
Internet-Draft HELD October 2005
13. Security Considerations
All requests for location and subsequent location responses MUST be
done using secure HTTP (https). Target authentication MAY be avoided
in preference for return routability, see Section 8.2. The Location
Server MUST be authenticated; using the method described in [RFC2818]
is RECOMMENDED.
Exactly how validation and authentication of Location Recipients
using client-side certificates or SAML assertions is implemented is
beyond the scope of this document but consideration should be given
to employing best current practices.
State information associated with a context at the Location Server
MUST be purged when the context expires.
Identity parameters, such as Target IP address, MUST NOT be accepted
by a Location Server, see Section 6.3.13 for details. A Location
Generator MUST only accept identity parameters from an authenticated,
authorized Location Server.
13.1. Identity Assurance and Location Fraud
Unlinked pseudonyms are favoured by the GEOPRIV architecture so that
users can provide location information without necessarily revealing
identity information at the same time. However, this characteristic
of unlinked pseudonyms can make it difficult to associate PIDF-LO
documents with a particular Target. This applies with all PIDF-LO
documents.
Even if a PIDF-LO document is provided directly from a Location
Server that the Location Recipient can rely on to provide accurate
information, there may be no way to associate the presentity URI with
a particular Target. This effect is somewhat less applicable when
providing location information directly from Target to Location
Recipient, since the link between Target and location information is
made implicitly. When receiving location information directly, the
Location Recipient needs to only trust the Target's assurances, which
may be backed by a digital signature.
For a location URI, if an attacker were able to obtain a location URI
that belongs to another entity, that attacker could use that location
URI as if it were their own. Location Recipients that receive this
location URI might not be able to determine the true owner of the
location information. If the original owner allowed access to the
Location Recipient, then the Location Recipient might be granted
location information with no indication of the actual identity
associated with the location information. This enables an attacker
Winterbottom, et al. Expires April 24, 2006 [Page 53]
Internet-Draft HELD October 2005
to provide fradulent location information.
To protect against location fraud in this fashion two methods are
applicable: protecting the location URI from theft, and providing a
link between a presentity URI and some other information that a
Location Recipient can use to associate with a Target. Note that to
provide this link, the Location Recipient need only be assured that
the location information does not belong to someone else, it does not
necessarily need to obtain identity information.
Recommendations that reduce the potential for location URI theft are
described in Section 8.2. In addition to these, a Target MUST NOT
convey a location URI on an unsecure communication channel.
To provide a link between Target and location information, it is
RECOMMENDED that a Target be able to provide a presentity URI to the
Location Server. The Location Recipient can use the presentity URI
to link location information with some known information. This
approach limits the potential for location fraud. Note that the
presentity URI remains an unlinked pseudonym that protects a users
identity information, a user may still limit the amount of
information that is revealed to the Location Recipient.
If a presentity URI is provided by the Target, anonymity might not be
possible depending on whether the Location Recipient is able to link
the provided presentity URI to other identify information. A Rule
Maker needs to be aware of this factor when creating authorization
policies.
If a Location Server generates a presentity URI, a layer of identity
protection can be added. However, this limits the ability of a
Location Recipient to associate location information with the
Target's identity.
Winterbottom, et al. Expires April 24, 2006 [Page 54]
Internet-Draft HELD October 2005
14. IANA Considerations
14.1. DHCP Option Code Registration
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.
14.2. SLP Service Template Registration
[NOTE: This template has not been sent to svrloc-list@iana.org for
submission.]
Name of submitter: "Martin Thomson" <martin.thomson@andrew.com>
Language of service template: en
Security Considerations:
A service that implements this protocol needs to conform with the
requirements of a GEOPRIV using protocol, as defined in RFC 3693.
Connection security and authentication are described in RFC XXXX.
Template Text:
-------------------------template begins here-----------------------
template-type=service:locserv
template-version=0.0
template-description=
A location service provides network devices with their location
and enables the dissemination of that location information to
selected hosts.
template-url-syntax=
url-path = absoluteURI ; as defined in RFC 3986
; For example:
; service:locserv:https://lis.example.com:54462/locserv
locserv-domain = STRING O M L
# The name of the domain or domains served.
locserv-target-auth = STRING O M L
none
# Specifies what authentication options are required by the server
# for targets that request their own location:
# - none - return routability is considered adequate
# - basic - HTTP basic authentication RFC 2617 (not recommended)
Winterbottom, et al. Expires April 24, 2006 [Page 55]
Internet-Draft HELD October 2005
# - digest - HTTP digest authentication RFC 2617/3310
# - x509 - an X.509 certificate attached to the TLS session
# Multiple values indicate a choice.
none,basic,digest,x509
locserv-recipient-auth = STRING O M L
x509
# The authentication that is required for location recipients.
# The same as locserv-target-auth, except with X.509 as default.
none,basic,digest,x509
locserv-response-times = INTEGER O M L
# A set of response times (in milliseconds) that location
# generators available to the location service are capable of.
# These values provide a hint to a SLP UA only.
# - A value of 0 indicates that the service caches location.
# - A negative value indicates the timeliness of a location
# generator is unknown.
locserv-pidf-lo-accepted = STRING O L
no
# Indicates if the location service accepts user-provided PIDF-LO
# documents.
# - no indicates that the pidf-lo parameter is ignored.
# - template-only indicates that only the template is used.
# - loc-only indicates that only the location information is used.
# - yes indicates that the pidf-lo parameters is fully supported.
no,template-only,loc-only,yes
locserv-locuri-supported = BOOLEAN O L
# Indicates if the location service can provide a location URI.
locserv-update-supported = BOOLEAN O L
# Indicates if the location service can query for updates.
locserv-ruleset-supported = BOOLEAN O L
# Indicates if the location service applies user-provided
# authorization policies.
locserv-dsig-supported = BOOLEAN O L
# Indicates if the location service supports the application of
# digital signatures to provided location information.
locserv-lero-supported = BOOLEAN O L
# Indicates if the location service can provide Local
# Emergency Routing Option information
Winterbottom, et al. Expires April 24, 2006 [Page 56]
Internet-Draft HELD October 2005
15. Acknowledgements
The authors wish to thank Hannes Tschofenig and John Schnizlein for
their early comments and guidance.
Winterbottom, et al. Expires April 24, 2006 [Page 57]
Internet-Draft HELD October 2005
16. References
16.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
"Service Location Protocol, Version 2", RFC 2608,
June 1999.
[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.
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2965, October 2000.
[RFC2388] Masinter, L., "Returning Values from Forms: multipart/
form-data", RFC 2388, August 1998.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[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.
[I-D.ietf-geopriv-common-policy]
Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences", draft-ietf-geopriv-common-policy-05 (work in
progress), July 2005.
[I-D.ietf-geopriv-policy]
Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences for Location Information",
draft-ietf-geopriv-policy-06 (work in progress),
July 2005.
Winterbottom, et al. Expires April 24, 2006 [Page 58]
Internet-Draft HELD October 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.
16.2. Informative references
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based
Location Configuration Information", RFC 3825, July 2004.
[RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson,
"Threat Analysis of the Geopriv Protocol", RFC 3694,
February 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-07 (work in progress),
September 2005.
[I-D.ietf-geopriv-pdif-lo-profile]
Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification,
Considerations and Recommendations",
draft-ietf-geopriv-pdif-lo-profile-01 (work in progress),
July 2005.
[I-D.thomson-revised-civic-lo]
Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for PIDF-LO", draft-thomson-revised-civic-lo-01
(work in progress), October 2005.
[GML3] Cox, S., Lake, R., Portele, C., and A. Whiteside,
"Geographic information - Geography Markup Language
Winterbottom, et al. Expires April 24, 2006 [Page 59]
Internet-Draft HELD October 2005
(GML)", OpenGIS d02-023r4, January 2003.
Winterbottom, et al. Expires April 24, 2006 [Page 60]
Internet-Draft HELD October 2005
Authors' Addresses
James Winterbottom
Andrew
PO Box U40
Wollongong University Campus, NSW 2500
AU
Email: james.winterbottom@andrew.com
Martin Dawson
Andrew
PO Box U40
Wollongong University Campus, NSW 2500
AU
Email: martin.dawson@andrew.com
Martin Thomson
Andrew
PO Box U40
Wollongong University Campus, NSW 2500
AU
Email: martin.thomson@andrew.com
Barbara Stark
BellSouth
Room 7A41
725 W Peachtree St.
Atlanta, GA 30308
US
Email: barbara.stark@bellsouth.com
Winterbottom, et al. Expires April 24, 2006 [Page 61]
Internet-Draft HELD October 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 April 24, 2006 [Page 62]