< draft-ietf-geopriv-lbyr-requirements-01.txt   draft-ietf-geopriv-lbyr-requirements-02.txt >
GeoPriv R. Marshall, Ed. GeoPriv R. Marshall, Ed.
Internet-Draft TCS Internet-Draft TCS
Intended status: Informational October 11, 2007 Intended status: Informational February 25, 2008
Expires: April 13, 2008 Expires: August 28, 2008
Requirements for a Location-by-Reference Mechanism Requirements for a Location-by-Reference Mechanism
draft-ietf-geopriv-lbyr-requirements-01 draft-ietf-geopriv-lbyr-requirements-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 13, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines terminology and provides requirements relating This document defines terminology and provides requirements relating
to Location-by-Reference approach to handling location information to Location-by-Reference approach using a location URI to handle
within signaling and other Internet messaging. location information within signaling and other Internet messaging.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview of Location-by-Reference . . . . . . . . . . . . . . 6
3.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. High-Level Requirements . . . . . . . . . . . . . . . . . . . 9
4. Basic Actors . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Requirements for a Location Configuration Protocol . . . 9
5. High-Level Requirements . . . . . . . . . . . . . . . . . . . 8 4.2. Requirements for a Location Dereference Protocol . . . . 11
5.1. Requirements for a Location Configuration Protocol . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5.2. Requirements for a Location Dereference Protocol . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
Location-based services rely on ready access to location information, Location-based services rely on ready access to location information,
which can be through a direct or indirect mechanism. While there is which can be through a direct or indirect mechanism. While there are
already a direct mechanism which exists to provide location as part mechanisms for providing location directly, (e.g., as part of the SIP
of the SIP signaling protocol, an alternative mechanism has been signaling protocol), an alternative mechanism has been developed for
developed for handling location indirectly, via a location reference, handling location indirectly, via a location reference, a pointer to
a reference which points to the actual location information. This the actual location information. This reference is called a location
reference is called the location URI, and is used by the mechanism we URI, and is used by the mechanism we generally call the Location-by-
call Location-by-Reference, or LbyR. Reference mechanism, or simply, LbyR.
Each of the actions by which a location URI can be used is The use of a location URI is generally applied in one of the
represented by specific individual protocol. For example, a Location following ways:
Configuration Protocol, is used by a device or middlebox to acquire a
location which already exists (examples of this protocol include
DHCP, LLDP-MED, and HELD [I-D.ietf-geopriv-http-location-delivery]).
The location configuration protocol problem statement and
requirements document can be found in [I-D.ietf-geopriv-l7-lcp-ps].
The action of conveying a location URI along from node to node
according to specific rules in SIP, for example, is known as a
conveyance protocol. A location dereferencing protocol, is used by a
client to resolve a location URI in exchange for location information
from a dereference server (e.g., a LIS).
The structure of this document first defines terminology, or points 1. Creation/allocation of a location URI, by a location server based
to the appropriate draft where defined, in Section 3. Then a short on some request mechanism.
discussion on the basic elements which show LbyR. This section on
actors, Section 4 includes a basic model, and describes the steps
which the LbyR mechanism takes.
Requirements are outlined separately for location configuration, 2. As part of a Location Configuration Protocol, between a target
Section 5.1, followed by those for a dereferencing protocol, and location server*.
Section 5.2.
Location-by-Value, called LbyV, in contrast to LbyR, is a direct 3. The location dereference process, (between a dereference client
location conveyance approach and includes the location object, e.g., and dereference server).
a PIDF-LO [RFC4119] in the SIP signaling. Location conveyance is out
of scope for this document (see [I-D.ietf-sip-location-conveyance]
for an explanation of conveyance of location including both LbyR and
LbyV scenarios.
Location determination, which may include the processes of manual 4. Cancellation/expiration of a location URI, by a location server
provisioning, automated measurements, or location transformations, based on either a direct target request or some other action (e.g.,
(e.g., geo-coding), are beyond the scope of this document. timer).
A detailed discussion of Identity information related to the caller, *In this document, we make no differentiation between a LS, per
subscriber, or device, as associated to location or location URI, is RFC3693, and a LIS, but may refer to either of them as a location
also out of scope. server interchangeably.
2. Requirements Terminology These four things fall under two general protocol mechanisms,
location configuration protocols and location dereference protocols.
A fifth use of location URI is within the context of what is called
location conveyance. Location conveyance is defined as part of the
SIP protocol, and is out of scope for this document. (see
[I-D.ietf-sip-location-conveyance] for an explanation of conveyance
of location using a location URI.
The issues around location configuration protocols have been
documented in a location configuration protocol problem statement and
requirements document [I-D.ietf-geopriv-l7-lcp-ps].
There are currently a several examples of a location configuration
protocol. These include DHCP, LLDP-MED, and HELD
[I-D.ietf-geopriv-http-location-delivery]) protocols.
The structure of this document includes terminology, Section 2,
followed by a discussion of the basic elements that surround how a
location URI is used. These elements, or actors, are discussed in an
overview section, Section 3, accompanied by a graph and associated
processing steps.
Requirements are outlined accordingly, separated as location
configuration requirements, Section 4.1, and location dereference
requirements, Section 4.2.
In contrast to using a location URI as the mechanism to support a
Location-by-Reference model, it may be worth mentioning the common
alternative model, that of Location-by-Value (LbyV), which provides
location directly. LbyV uses a location object, (e.g., a PIDF-LO,
[RFC4119]) within SIP signaling. Using the LbyV model for location
configuration is considered out of scope for this document (see
[I-D.ietf-sip-location-conveyance] for an explanation of location
conveyance for either LbyR or LbyV scenarios.
Location determination, different than location configuration or
dereferencing, often includes topics related to manual provisioning
processes, automated measurements, and/or location transformations,
(e.g., geo-coding), and are beyond the scope of this document.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Terminology
This document reuses the terminology of [RFC3693], such as Location This document reuses the terminology of [RFC3693], such as Location
Server (LS), Location Recipient (LR), Rule Maker (RM), Target, Server (LS), Location Recipient (LR), Rule Maker (RM), Target,
Location Generator (LG), Location Object (LO), and Using Protocol: Location Generator (LG), Location Object (LO), and Using Protocol:
3.1. Terms
Location-by-Value (LbyV): The mechanism of representing location Location-by-Value (LbyV): The mechanism of representing location
either in configuration or conveyance protocols, (i.e., the actual either in configuration or conveyance protocols, (i.e., the actual
included location value). included location value).
Location-by-Reference (LbyR): The mechanism of representing location Location-by-Reference (LbyR): The mechanism of representing location
either in configuration, conveyance, or in dereferencing protocols by means of a location URI for use in either a location
as an identifier which refers to a fully specified location, configuration, conveyance, or dereferencing protocol, and which
(i.e., a pointer to the actual location value). refers to a fully specified location.
Location Configuration Protocol: A protocol which is used by a Location Configuration Protocol: A protocol which is used by a
client to acquire either location or a location URI from a client to acquire either location or a location URI from a
location configuration server, based on information unique to the location configuration server, based on information unique to the
client. client.
Location Dereference Protocol: A protocol which is used by a client Location Dereference Protocol: A protocol which is used by a client
to query a location dereference server, based on location URI to query a location dereference server, based on location URI
input and which returns location information. input and which returns location information.
Location URI: An identifier which serves as a pointer to a location Location URI: An identifier which serves as a pointer to a location
record on a remote host (e.g., LIS). Used within an Location-by- record on a remote host (e.g., LIS). Used within an Location-by-
Reference mechanism, a location URI is provided by a location Reference mechanism, a location URI is provided by a location
configuration server, and is used as input by a dereference configuration server, and is used as input by a dereference
protocol to retrieve location from a dereference server. protocol to retrieve location from a dereference server.
4. Basic Actors 3. Overview of Location-by-Reference
In mobile wireless networks it is not efficient for the end host to In mobile wireless networks it is not efficient for the end host to
periodically query the LIS for up-to-date location information. This periodically query the LIS for up-to-date location information. This
is especially the case when power is a constraint or a location is especially the case when power is a constraint or a location
update is not immediately needed. Furthermore, the end host might update is not immediately needed. Furthermore, the end host might
want to delegate the task of retrieving and publishing location want to delegate the task of retrieving and publishing location
information to a third party, such as to a presence server. Finally, information to a third party, such as to a presence server. Finally,
in some deployments, the network operator may not want to make in some deployments, the network operator may not want to make
location information widely available. location information widely available.
These use scenarios motivated the introduction of the LbyR concept. Different location scenarios, such as whether a Target is mobile and
Depending on the type of reference, such as HTTP/HTTPS or SIP whether a mobile device needs to be located on demand or according to
Presence URI, different operations can be performed. While an HTTP/ some pre-determined interval motivated the introduction of the LbyR
HTTPS URI can be resolved to location information, a SIP Presence URI concept. Depending on the type of reference, such as HTTP/HTTPS or
provides further benefits from the SUBSCRIBE/NOTIFY concept that can SIP Presence URI, different operations can be performed. While an
additionally be combined with location filters HTTP/HTTPS URI can be resolved to location information, a SIP
Presence URI provides further benefits from the SUBSCRIBE/NOTIFY
concept that can additionally be combined with location filters
[I-D.ietf-geopriv-loc-filters]. [I-D.ietf-geopriv-loc-filters].
+-----------+ Geopriv +-----------+ +-----------+ Geopriv +-----------+
| | Location | Location | | | Location | Location |
| LIS +---------------+ Recipient | | LIS +---------------+ Recipient |
| | Dereference | | | | Dereference | |
+-----+-----+ Protocol (3) +----+------+ +-+---+-----+ Protocol (3) +----+------+
| -- * | --
| Geopriv -- Rulemaker * | Geopriv --
| Location -- Policy * | Location --
| Configuration -- Exchange * | Configuration --
| Protocol -- (1b) * | Protocol --
| (1) -- Geopriv * | (1a) -- Geopriv
| -- Using Protocol * | -- Using Protocol
| -- (e.g., SIP) + - - - -*- - - - - -|- - - -+ -- (e.g., SIP)
+-----+-----+ -- (2) |+------+----+ +-----+-----+ |-- (2)
| Target / |-- | Rulemaker | | Target / |--
| End Host + || / owner | | End Host + |
| | | | | |
+-----------+ |+-----------+ +-----------+ |
| User of Target |
+ - - - - - - - - - - - - - -+
Figure 1: Shows the assumed communication model for both a layer 7 Figure 1: Shows the assumed communication model for both a layer 7
location configuration protocol and a dereference protocol: location configuration protocol and a dereference protocol:
Note that there is no requirement for using the same protocol in (1) Figure 1: Shows the assumed communication model for both a layer 7
and (3). location configuration protocol and a location dereference protocol.
The following list describes the location subscription approach: (1a). Target requests reference from server; and receives back, a
location URI in server response
1. The end host discovers the LIS. (1b). Rulemaker policy is consulted (interface out of scope)
2. The target (end host) sends a request to the LIS asking for a (2). Target conveys reference to recipient (out of scope)
location URI, as shown in (1) of Figure 1.
3. The LIS responds to the request and includes a location object (3). Recipient dereferences location URI, by a choice of methods,
along with a subscription URI. including a request/response (e.g., HTTP) or publish/subscription
(e.g., SIP SUBSCRIBE/NOTIFY)
4. The Target puts the subscription URI into a SIP message and Note A. There is no requirement for using the same protocol in (1a)
forwards it to a Location Recipient via a using protocol, as shown in and (3).
(2) of Figure 1. The Location Recipient subscribes to the obtained
subscription URI (see (3) of Figure 1) and potentially uses a
location filter (see [I-D.ietf-geopriv-loc-filters]) to limit the
notification rate.
5. If the Target moves outside a certain area, indicated by a Note B. Figure 1 includes the interaction between the owner of the
location filter, the Location Recipient will receive a notification. Target and the LIS to establish Rulemaker policies. This is
communications path (1b). This interaction needs to be done before
the LIS will authorize anything of than default policies to a
dereference request for location of the Target.
Note that the Target may also act in the role of the Location Note C. that the Target may take on the role of the Location
Recipient whereby it would subscribe to its own location information. Recipient whereby it would dereference the location URI to obtain its
For example, the Target obtains a subscription URI from the Geopriv own location information.
L7 Location Configuration Protocol. It subscribes to the URI in
order to obtain its current location information. A service boundary
indicates the bounded extent up to which the device can move without
the need to have an updated location, since a re-query with any
location within the boundary would result in the same answer returned
from a location-based service.
For LbyR, the LIS needs to maintain a list of randomized location An example scenario of how this might work, is where the Target
URIs for each host, timing out each of these URIs after the reference obtains a location URI in the form of a subscription URI (e.g., a SIP
expires. Location URIs need to expire to prevent the recipient of URI) via HELD, (a Geopriv layer 7 location configuration protocol).
such a URI from being able to (in some cases) permanently track a Since, in this case the Target equals Recipient, then the Target can
host. Furthermore, an expiration mechanism also offers garbage subscribe to the URI in order to be notified of its current location
collection capability for the LIS. based on subscription parameters (see
[I-D.ietf-geopriv-loc-filters]). Additionally, a geospatial boundary
can be expressed (ref. [I-D.ietf-geopriv-policy]), so that the
Target/Recipient will get its updated location notification once it
crosses the specified boundary.
Location URIs must be designed to prevent adversaries from obtaining Location URIs may have an life expiration associated to them, so the
a known Target's location. There are at least two approaches: The LIS needs to be able to keep track of the location URIs that have
location URI contains a random component which helps obscure been handed out, in addition, to also know about validity information
sequential updates to location, yet still allows any holder of the for each location URI. Location URIs need to expire to prevent the
location URI to obtain location information. Alternatively, the recipient of such a URI from being able to (in some cases)
location URI can remain public and the LIS performs access control permanently track a host. Another example of the usefulness of an
via a separate authentication mechanism, such as HTTP digest or TLS expiration mechanism is to offer garbage collection capabilities to
client side authentication, when resolving the reference to a the LIS.
location object.
5. High-Level Requirements It is important to prevent adversaries from obtaining any information
about a Target through the location URI itself, or even a Target's
location if the owner of the Target wants to protect it. Therefore,
each location URI must be constructed with security safeguards in
mind. There are two general cases assumed, both having to do with
the form of the location URI when it is created.
This document outlines only requirements for an LbyR mechanism which Case 1. Where access to the location URI is limited by policy: This
is used by two different protocols, a location configuration is the case where the LIS applies authentication and access
protocol, and a location dereferencing protocol. Each of these control at location configuration step and again at the
protocols has its own unique client and server interactions, and the dereference step. In this case, the URI can be of any form chosen
requirements here are not intended to state what a client or server by the LIS.
is expected to do, but rather which requirements must be met by
either the configuration or dereferencing protocol itself.
5.1. Requirements for a Location Configuration Protocol Case 2. Access limited by distribution: The LIS does not apply
authentication and access control at the time that the location
URI is dereferenced. In this case, the location URI must be
difficult to guess (so that possession can be used to imply
authorization).
4. High-Level Requirements
This document outlines the requirements for an Location by Reference
mechanism which can be used by a number of underlying protocols.
Requirements here address two general types of such protocols, a
general location configuration protocol, and a general location
dereferencing protocol. Given that either of these two general
protocols can take the form of different protocols implementations
for either location configuration vs. location dereference, (e.g.,
HELD/DHCP/LLDP-MED, vs. HTTP GET/SIP SUBSCRIBE/NOTIFY, respectively).
Because each of these specific protocol implementations has its own
unique client and server interactions, the requirements here are not
intended to state what a client or server is expected to do, but
rather which requirements must be met separately by either a location
configuration protocol, or a location dereference protocol, for the
purposes of using a location URI.
The requirements are broken into two sections.
4.1. Requirements for a Location Configuration Protocol
Below, we summarize high-level design requirements needed for a Below, we summarize high-level design requirements needed for a
location-by-reference mechanism as used within the location location-by-reference mechanism as used within the location
configuration protocol. configuration protocol.
C1. Location URI support: The configuration protocol MUST support a C1. Location URI support: The configuration protocol MUST support a
location reference in URI form. location reference in URI form.
Motivation: It is helpful to have a consistent form of key for the Motivation: It is helpful to have a consistent form of key for the
LbyR mechanism. LbyR mechanism.
C2. Location URI expiration: The lifetime of a location URI SHOULD C2. Location URI expiration: When a location URI has a limited
be indicated. validity interval, its lifetime MUST be indicated.
Motivation: Location URIs are not intended to represent a location Motivation: A location URI may not intend to represent a location
forever, and the identifier eventually may need to be recycled, or forever, and the identifier eventually may need to be recycled, or
may be subject to a specific window of validity, after which the may be subject to a specific window of validity, after which the
location reference fails to yield a location, or the location is location reference fails to yield a location, or the location is
determined to be kept confidential. determined to be kept confidential.
C3. Location URI cancellation: The location configuration protocol C3. Location URI cancellation: The location configuration protocol
SHOULD support the ability to request a cancellation of a specific SHOULD support the ability to request a cancellation of a specific
location URI. location URI.
Motivation: If the client determines that in its best interest to Motivation: If the client determines that in its best interest to
destroy the ability for a location URI to effectively be used to destroy the ability for a location URI to effectively be used to
dereference a location, then there should be a way to nullify the dereference a location, then there should be a way to nullify the
location URI. location URI.
C4. Random Generated: The location URI MUST be hard to guess, i.e., C4. [Deleted, replaced by C8,C9,C10]:
it MUST contain a cryptographically random component.
Motivation: There is some benefit to the client if the location
URI is generated in an obscured manner so that its sequence, for
example in the case of a client's location update, can't be easy
guessed.
C5. Identity Protection: The location URI MUST NOT contain any C5. User Identity Protection: The location URI MUST NOT contain any
information that identifies the user, device or address of record user identifying information that identifies the user, device or
within the URI form. address of record, (e.g., which includes phone extensions, badge
numbers, first or last names, etc.), within the URI form.
Motivation: It is important to protect caller identity or contact Motivation: It is important to protect caller identity or contact
address from being included in the form of the location URI itself address from being included in the form of the location URI itself
when it is generated. when it is generated.
C6. Reuse indicator: There SHOULD be a way to allow a client to C6. Reuse indicator: There SHOULD be a way to allow a client to
control whether a location URI can be resolved once or multiple control whether a location URI can be resolved once only, or
times. multiple times.
Motivation: The client requesting a location URI may request a Motivation: The client requesting a location URI may request a
location URI which has a 'one-time-use' only characteristic, as location URI which has a 'one-time-use' only characteristic, as
opposed to a location URI having multiple reuse capability. opposed to a location URI having multiple reuse capability.
C7. Location timestamp: There SHOULD be a way to allow a client to C7. Location URI Valid-for: A location URI validity interval, if
determine whether the dereferenced location information refers to used, MUST include the validity time, in seconds, as an indication
the location of the Target at the time when the location URI was of how long the client can consider a location URI to be valid.
created or when it was dereferenced.
Motivation: It is important to distinguish between an original and Motivation: It is important to be able to determine how long a
an updated location. location URI is to remain useful for, and when it must be
refreshed.
5.2. Requirements for a Location Dereference Protocol C8. Location URI Anonymous: The location URI MUST NOT reveal any
information about the Target other than it's location.
Motivation: A user should have the option to control how much
information is revealed about them. This provides that control by
not forcing the inclusion of other information with location,
(e.g., to not include any identification information in the
location URI.)
C9. Location URI Not guessable: Location URIs that do not require
authentication and authorization MUST NOT be guessable, based on
the use of a cryptographically random sequence somewhere within
the URI. (Note that the number of bits depends to some extent on
the number of active location URIs that might exist at the one
time; 128-bit is most likely enough for the short term.)
Motivation: Location URIs without access control reveal private
information, and a guessable location URI could be easily
exploited to obtain private information.
C10. Location URI Optional: In the case of user-provided
authorization policies, where anonymous or non-guessable location
URIs are not warranted, the location configuration protocol MAY
support optional location URI forms.
Motivation: Users don't always have such strict privacy
requirements, but may opt to specify their own location URI, or
components thereof.
4.2. Requirements for a Location Dereference Protocol
Below, we summarize high-level design requirements needed for a Below, we summarize high-level design requirements needed for a
location-by-reference mechanism as used within the location location-by-reference mechanism as used within the location
dereference protocol. dereference protocol.
D1. Location URI support: The location dereference protocol MUST D1. Location URI support: The location dereference protocol MUST
support a location reference in URI form. support a location reference in URI form.
Motivation: It is required that there be consistency of use Motivation: It is required that there be consistency of use
between location URI formats used in an configuration protocol and between location URI formats used in an configuration protocol and
those used by a dereference protocol. those used by a dereference protocol.
D2. Location URI expiration status: The location dereference D2. Location URI expiration indicator: The location dereference
protocol MUST support a message indicating that for a location URI protocol MUST support an indicator showing that, if it is the
which is no longer valid, that the location URI has expired. case, that a location URI is no longer valid due to expiration.
Motivation: Location URIs are expected to expire, based on Motivation: Location URIs are expected to expire, based on
location configuration protocol parameters, and it is therefore location configuration protocol parameters, and it is therefore
useful to convey the expired status of the location URI in the useful to convey the expired status of the location URI in the
location dereference protocol. location dereference protocol.
D3. Authentication: The location dereference protocol MUST support D3. Authentication: The location dereference protocol MUST include
either client-side and server-side authentication. mechanisms to authenticate both the client and the server.
Motivation: It is reasonable to expect implementations of Motivation: Although the implementations must support
authentication to vary. Some implementations may choose to authentication of both parties, any given transaction has the
implement both client-side and server-side authentication, might option not to authenticate one or both parties.
implement one only, or may implement neither.
D4. Dereferenced Location Form: The dereferenced location MUST D4. Dereferenced Location Form: The value returned by the
result in a well-formed PIDF-LO. dereference protocol MUST contain a well-formed PIDF-LO document.
Motivation: This is in order to ensure that adequate privacy rules Motivation: This is in order to ensure that adequate privacy rules
can be adhered to, since the PIDF-LO format comprises the can be adhered to, since the PIDF-LO format comprises the
necessary structures to maintain location privacy. necessary structures to maintain location privacy.
D5. Repeated use: The location dereference protocol MUST support the D5. Location URI Repeated Use: The location dereference protocol
ability for the same location URI to be resolved more than once, MUST support the ability for the same location URI to be resolved
based on server settings and configuration server parameters. more than once, based on dereference server configuration.
Motivation: According to configuration server parameters, it may Motivation: Through dereference server configuration, for example,
be necessary to have a limit on the number of dereferencing it may be useful to not only allow more than one dereference
attempts. request, but, in some cases, to also limit the number of
dereferencing attempts by a client.
6. Security Considerations D6. Location URI Valid-for: A location URI validity interval, if
used, MUST include the validity time, in seconds, as an indication
of how long the client can consider a location URI to be valid.
The LbyR mechanism currently addresses security issues as follows. Motivation: It is important to be able to determine how long a
location URI is to remain useful when dereferencing a location
URI.
A location URI, regardless of its randomized construction, if D7. Location URI anonymized: Any location URI whose dereference will
public, implies no safeguard against anyone being able to not be subject to authentication and access control MUST be
dereference and get the location. The randomization of a location anonymized.
URI in its naming does help prevent some potential guessing,
according to some defined pattern. In the instance of one-time-
use location URIs, which function similarly to a pawn ticket, the
argument can be made that with a pawn ticket, possession implies
permission, and location URIs which are public are protected only
by privacy rules enforced at the dereference server.
Additional security issues will be discussed in the geopriv draft, Motivation: The dereference protocol must define an anonymized
draft-barnes-geopriv-lo-sec-00.txt. format for location URIs. This format must identify the desired
location information via a random token with at least 128 bits of
entropy (rather than some kind of explicit identifier, such as an
IP address).
7. IANA Considerations D8. Location URI non-anonymized: The dereference protocol MAY define
a more general, non-anonymized URI format.
Motivation: Only location URIs for which dereference is subject to
access-control policy by the LIS may use this format.
D9. Location Privacy: The location dereference protocol MUST support
the application of privacy rules to the dissemination of a
requested location object.
Motivation: The dereference server must obey all provisioned
privacy rules that apply to a requested location object.
D10. Location Confidentiality: The dereference protocol MUST
support encryption of messages sent between the location
dereference client and the location dereference server, and MAY
alternatively provide messaging unencrypted.
Motivation: Environmental and local configuration policy will
guide the requirement for encryption for certain transactions. In
some cases, encryption may be the rule, in others, it may be
acceptable to send and receive messages without encryption.
5. Security Considerations
The LbyR mechanism currently addresses security issues as follows.
A location URI, regardless of its construction, if public, implies
no safeguard against anyone being able to dereference and get the
location. The method of constructing a location URI in its naming
does help prevent some potential guessing, according to some
defined pattern. In the instance of one-time-use location URIs,
which function similarly to a pawn ticket, the argument can be
made that with a pawn ticket, possession implies permission, and
location URIs which are public are protected only by privacy rules
enforced at the dereference server.
6. IANA Considerations
This document does not require actions by the IANA. This document does not require actions by the IANA.
8. Acknowledgements 7. Acknowledgements
We would like to thank the IETF GEOPRIV working group chairs, Andy We would like to thank the IETF GEOPRIV working group chairs, Andy
Newton, Allison Mankin and Randall Gellens, for creating the design Newton, Allison Mankin and Randall Gellens, for creating the design
team which initiated this requirements work. We'd also like to thank team which initiated this requirements work. We'd also like to thank
those design team participants for their inputs, comments, and those design team participants for their inputs, comments, and
reviews. The design team included the following folks: Richard reviews. The design team included the following folks: Richard
Barnes; Martin Dawson; Keith Drage; Randall Gellens; Ted Hardie; Barnes; Martin Dawson; Keith Drage; Randall Gellens; Ted Hardie;
Cullen Jennings; Marc Linsner; Rohan Mahy; Allison Mankin; Roger Cullen Jennings; Marc Linsner; Rohan Mahy; Allison Mankin; Roger
Marshall; Andrew Newton; Jon Peterson; James M. Polk; Brian Rosen; Marshall; Andrew Newton; Jon Peterson; James M. Polk; Brian Rosen;
John Schnizlein; Henning Schulzrinne; Barbara Stark; Hannes John Schnizlein; Henning Schulzrinne; Barbara Stark; Hannes
Tschofenig; Martin Thomson; and James Winterbottom. Tschofenig; Martin Thomson; and James Winterbottom.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References 8.2. Informative References
[I-D.ietf-geopriv-http-location-delivery] [I-D.ietf-geopriv-http-location-delivery]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)", "HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-02 (work in draft-ietf-geopriv-http-location-delivery-05 (work in
progress), September 2007. progress), February 2008.
[I-D.ietf-geopriv-l7-lcp-ps] [I-D.ietf-geopriv-l7-lcp-ps]
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol; Problem Statement and Location Configuration Protocol; Problem Statement and
Requirements", draft-ietf-geopriv-l7-lcp-ps-05 (work in Requirements", draft-ietf-geopriv-l7-lcp-ps-06 (work in
progress), September 2007. progress), November 2007.
[I-D.ietf-geopriv-loc-filters] [I-D.ietf-geopriv-loc-filters]
Mahy, R., "A Document Format for Filtering and Reporting Mahy, R., "A Document Format for Filtering and Reporting
Location Notications in the Presence Information Document Location Notications in the Presence Information Document
Format Location Object (PIDF-LO)", Format Location Object (PIDF-LO)",
draft-ietf-geopriv-loc-filters-01 (work in progress), draft-ietf-geopriv-loc-filters-01 (work in progress),
March 2007. March 2007.
[I-D.ietf-geopriv-policy]
Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
and J. Polk, "Geolocation Policy: A Document Format for
Expressing Privacy Preferences for Location Information",
draft-ietf-geopriv-policy-14 (work in progress),
February 2008.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", Session Initiation Protocol",
draft-ietf-sip-location-conveyance-08 (work in progress), draft-ietf-sip-location-conveyance-09 (work in progress),
July 2007. November 2007.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
Appendix A. Change log Appendix A. Change log
Changes to this draft in comparison to the -00 version: Changes to this draft in comparison to the previous version (-02 vs.
-01):
1. Shortened Abstract and Introduction. 1. Reworded Introduction (Barnes 12/6 list comments).
2. LDP term gone. Expansion of Location Dereferencing Protocol, 2. Changed name of "Basic Actors" section to "Overview of Location
deletion of "LDP" acronym throughout, since LDP stands for Label by Reference" (Barnes).
Distribution Protocol elsewhere in the IETF.
3. LCP term is also gone. LCP is used as Link Control Protocol 3. Keeping the LCP term away (for now) since it is used as Link
elsewhere (IETF). Control Protocol elsewhere (IETF).
4. Reduced the number of terms in the doc. Referenced other drafts 4. Changed formatting of Terminology section (Barnes).
or RFCs for repeated terms.
5. Requirement C2. changed to indicate that the URI has a lifetime. 5. Requirement C2. changed to indicate that if the URI has a
lifetime, it has to have an expiry (Barnes)
6. C3. Softened by changing from a MUST to a SHOULD. 6. C7. Changed title and wording based on suggested text and dhcp-
uri-option example (Polk).
7. C6. Reworded for clarity. 7. The new C2 req. describing valid-for, was also added into the
deref section, as D6
8. C7. Changed the MUST to a SHOULD to reflect a more appropriate 8. Changed C4 based on much list discussion - replaced by 3 new
level. requirements...
9. D6. Replaced the text to make it clearer. 9. Reworded C5 based on the follow-on C4 thread/discussion on list
(~2/18).
10. D7. Deleted the requirement since it wasn't an appropriate task 10. Changed wording of D3 based on suggestion (Barnes).
for the protocol.
11. Referenced Richard's security document 11. Reworded D4 per suggestion (Barnes).
12. Cleaned up some text. 12. Changed D5 based on comment (Barnes), and additional title and
text changes for clarity.
13. Added D9 and D10 per Richard Barnes suggestions - something
needed in addition to his own security doc.
14. Deleted reference to individual Barnes-loc-sec draft per wg list
suggestion (Barnes), but need more text for this draft's security
section.
Author's Address Author's Address
Roger Marshall (editor) Roger Marshall (editor)
TeleCommunication Systems, Inc. TeleCommunication Systems, Inc.
2401 Elliott Avenue 2401 Elliott Avenue
2nd Floor 2nd Floor
Seattle, WA 98121 Seattle, WA 98121
US US
Phone: +1 206 792 2424 Phone: +1 206 792 2424
Email: rmarshall@telecomsys.com Email: rmarshall@telecomsys.com
URI: http://www.telecomsys.com URI: http://www.telecomsys.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 74 change blocks. 
227 lines changed or deleted 353 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/