draft-ietf-geopriv-lbyr-requirements-03.txt   draft-ietf-geopriv-lbyr-requirements-04.txt 
GeoPriv R. Marshall, Ed. GeoPriv R. Marshall, Ed.
Internet-Draft TCS Internet-Draft TCS
Intended status: Informational July 9, 2008 Intended status: Informational November 3, 2008
Expires: January 10, 2009 Expires: May 7, 2009
Requirements for a Location-by-Reference Mechanism Requirements for a Location-by-Reference Mechanism
draft-ietf-geopriv-lbyr-requirements-03 draft-ietf-geopriv-lbyr-requirements-04
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 January 10, 2009. This Internet-Draft will expire on May 7, 2009.
Abstract Abstract
This document defines terminology and provides requirements relating This document defines terminology and provides requirements relating
to Location-by-Reference approach using a location URI to handle to Location-by-Reference approach using a location URI to handle
location information 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview of Location-by-Reference . . . . . . . . . . . . . . 6 3. Overview of Location-by-Reference . . . . . . . . . . . . . . 7
4. High-Level Requirements . . . . . . . . . . . . . . . . . . . 9 4. High-Level Requirements . . . . . . . . . . . . . . . . . . . 10
4.1. Requirements for a Location Configuration Protocol . . . 9 4.1. Requirements for a Location Configuration Protocol . . . 10
4.2. Requirements for a Location Dereference Protocol . . . . 11 4.2. Requirements for a Location Dereference Protocol . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 23
1. Introduction 1. Introduction
Location-based services rely on ready access to location information, Since all location-based services rely on ready access to location
which can be through a direct or indirect mechanism. While there are information, this can accomplished through some direct means, or
mechanisms for providing location directly, (e.g., as part of the SIP alternatively, through some indirect means as a pointer to location
signaling protocol), an alternative mechanism has been developed for information. The direct vs. indirect approach we characterize as
handling location indirectly, via a location reference, a pointer to either Location-by-Value (LbyV), or Location-by-Reference (LbyR).
the actual location information. This reference is called a location
URI, and is used by the mechanism we generally call the Location-by-
Reference mechanism, or simply, LbyR.
The use of a location URI is generally applied in one of the While it is the case that within SIP, location can be handled in a
following ways: direct manner, (i.e., passing the actual location information around
in the form of a PIDF-LO*), there are additional location
requirements which apply to certain applications and/or location
architectures that are only satisfied by specifying an indirect
location mechanism. This document puts forth a set of requirements
for such an indirect location approach, namely, the LbyR location
model.
1. Creation/allocation of a location URI, by a location server based As justification for a LbyR model, consider the following. In some
on some request mechanism. mobile networks it is not efficient for the end host to periodically
query the LIS for up-to-date location information. This is
especially the case when power is a constraint or when a location
update is not immediately needed. Furthermore, the end host might
want to delegate the task of retrieving and publishing location
information to a third party, such as to a presence server.
Additionally, in some deployments, the network operator may not want
to make location information widely available. These kinds of
location scenarios, and more, such as whether a Target is mobile and
whether a mobile device needs to be located on demand or according to
some pre-determined interval, together form the basis of motivation
for the LbyR concept.
2. As part of a Location Configuration Protocol, between a target The concept of an LbyR mechanism is simple. It is made up of a
and location server*. pointer which makes reference to the actual location information by
some combination of key value and fully qualified domain name. This
combination of data elements, in the form of a URI, is referred to
specifically as a "location URI".
3. The location dereference process, (between a dereference client The LbyR mechanism itself works according to an information
and dereference server). lifecycle. Within the LbyR mechanism, location URIs are temporary
identifiers, each undergoing the following uses: Creation;
Distribution; Conveyance; Dereference; and Termination. The use of a
location URI according to these various states is generally applied
in one of the following ways:
4. Cancellation/expiration of a location URI, by a location server 1. Creation of a location URI, within a location server, based on
based on either a direct target request or some other action (e.g., some request for its creation.
timer).
*In this document, we make no differentiation between a LS, per 2. Distribution of a location URI, via a Location Configuration
RFC3693, and a LIS, but may refer to either of them as a location Protocol, between a target and a location server**.
server interchangeably.
These four things fall under two general protocol mechanisms, 3. Conveyance, applied to LbyR, in SIP, is the transporting of the
location configuration protocols and location dereference protocols. location URI, in this case, between any successive signaling
nodes***.
A fifth use of location URI is within the context of what is called 4. Dereference of a location URI, a request/response between a
location conveyance. Location conveyance is defined as part of the client having a location URI and a location server holding the
SIP protocol, and is out of scope for this document. (see location information that the location URI references.
[I-D.ietf-sip-location-conveyance] for an explanation of conveyance
of location using a location URI. 5. Termination of a location URI, either due to expiration or
cancellation within a location server, and which is based on a target
cancellation request or some other action, such as timer
expiration.
Location determination, different than location configuration or
dereferencing, often includes topics related to manual provisioning
processes, automated location calculations based on a variety of
measurement techniques, and/or location transformations, (e.g., geo-
coding), and is beyond the scope of this document.
*The standard mechanism for LbyV has been defined around the use of
the PIDF-LO (Presence Information Document Format - Location Object
[RFC4119]]), and is explicitly out of scope in this document.
**This document make no differentiation between a LS, per RFC3693,
and a LIS [ref. draft-ietf-geopriv-l7-lcp-ps], but may refer to
either of them as a location server interchangeably.
***Location Conveyance for either LbyR or LbyV, within SIP signaling
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.)
Except for location conveyance, the above stages in the LbyR
lifecycle fall into one of two general categories of protocols,
either a Location Configuration Protocol or a Location Dereference
Protocol. The stages of LbyR Creation, Distribution, and
Termination, are each found within the set of Location Configuration
Protocols (LCP). The Dereference stage belongs solely to the set of
Location Dereference Protocols.
The issues around location configuration protocols have been The issues around location configuration protocols have been
documented in a location configuration protocol problem statement and documented in a location configuration protocol problem statement and
requirements document [I-D.ietf-geopriv-l7-lcp-ps]. requirements document [I-D.ietf-geopriv-l7-lcp-ps]. There are
currently several examples of a location configuration protocols
There are currently a several examples of a location configuration currently proposed, including, DHCP, LLDP-MED, and HELD
protocol. These include DHCP, LLDP-MED, and HELD
[I-D.ietf-geopriv-http-location-delivery]) protocols. [I-D.ietf-geopriv-http-location-delivery]) protocols.
For dereferencing of a location URI, depending on the type of
reference used, such as a HTTP/HTTPS, or SIP Presence URI, different
operations can be performed. While an 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].
The structure of this document includes terminology, Section 2, The structure of this document includes terminology, Section 2,
followed by a discussion of the basic elements that surround how a followed by a discussion of the basic elements that surround how a
location URI is used. These elements, or actors, are discussed in an location URI is used. These elements, or actors, are discussed in an
overview section, Section 3, accompanied by a graph and associated overview section, Section 3, accompanied by a graph and associated
processing steps. processing steps.
Requirements are outlined accordingly, separated as location Requirements are outlined accordingly, separated as location
configuration requirements, Section 4.1, and location dereference configuration requirements, Section 4.1, and location dereference
requirements, Section 4.2. 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 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].
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:
skipping to change at page 6, line 7 skipping to change at page 7, line 7
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.
3. Overview of Location-by-Reference 3. Overview of Location-by-Reference
In mobile wireless networks it is not efficient for the end host to This section describes the entities and interactions involved in the
periodically query the LIS for up-to-date location information. This LbyR model.
is especially the case when power is a constraint or a location
update is not immediately needed. Furthermore, the end host might
want to delegate the task of retrieving and publishing location
information to a third party, such as to a presence server. Finally,
in some deployments, the network operator may not want to make
location information widely available.
Different location scenarios, such as whether a Target is mobile and
whether a mobile device needs to be located on demand or according to
some pre-determined interval motivated the introduction of the LbyR
concept. Depending on the type of reference, such as HTTP/HTTPS or
SIP Presence URI, different operations can be performed. While an
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].
+-----------+ Geopriv +-----------+ +-----------+ Geopriv +-----------+
| | Location | Location | | | Location | Location |
| LIS +---------------+ Recipient | | LIS +---------------+ Recipient |
| | Dereference | | | | Dereference | |
+-+---+-----+ Protocol (3) +----+------+ +-+---+-----+ Protocol (3) +----+------+
* | -- * | --
Rulemaker * | Geopriv -- Rulemaker * | Geopriv --
Policy * | Location -- Policy * | Location --
Exchange * | Configuration -- Exchange * | Configuration --
skipping to change at page 6, line 48 skipping to change at page 7, line 32
+ - - - -*- - - - - -|- - - -+ -- (e.g., SIP) + - - - -*- - - - - -|- - - -+ -- (e.g., SIP)
|+------+----+ +-----+-----+ |-- (2) |+------+----+ +-----+-----+ |-- (2)
| Rulemaker | | Target / |-- | Rulemaker | | Target / |--
|| / owner | | End Host + | || / owner | | End Host + |
| | | | | | | |
|+-----------+ +-----------+ | |+-----------+ +-----------+ |
| User of Target | | User of Target |
+ - - - - - - - - - - - - - -+ + - - - - - - - - - - - - - -+
Figure 1: Shows the assumed communication model for both a layer 7 Figure 1: Location Reference Entities and Interactions
location configuration protocol and a dereference protocol:
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 location dereference protocol. location configuration protocol and a location dereference protocol.
(1a). Target requests reference from server; and receives back, a (1a). Target requests reference from server; and receives back, a
location URI in server response location URI in server response
(1b). Rulemaker policy is consulted (interface out of scope) (1b). Rulemaker policy is consulted (interface out of scope)
(2). Target conveys reference to recipient (out of scope) (2). Target conveys reference to recipient (out of scope)
(3). Recipient dereferences location URI, by a choice of methods, (3). Recipient dereferences location URI, by a choice of methods,
including a request/response (e.g., HTTP) or publish/subscription including a request/response (e.g., HTTP) or publish/subscription
(e.g., SIP SUBSCRIBE/NOTIFY) (e.g., SIP SUBSCRIBE/NOTIFY)
Note A. There is no requirement for using the same protocol in (1a) Note A. There is no requirement for using the same protocol in (1a)
and (3). and (3).
Note B. Figure 1 includes the interaction between the owner of the Note B. Figure 1 includes the interaction between the owner of the
Target and the LIS to establish Rulemaker policies. This is Target and the LIS to establish Rulemaker policies. This is
communications path (1b). This interaction needs to be done before communications path (1b). This interaction needs to be done before
the LIS will authorize anything of than default policies to a the LIS will authorize anything other than default policies to a
dereference request for location of the Target. dereference request for location of the Target.
Note C. that the Target may take on the role of the Location Note C. The Target may take on the role of the Location Recipient
Recipient whereby it would dereference the location URI to obtain its whereby it would dereference the location URI to obtain its own
own location information. location information.
An example scenario of how this might work, is where the Target An example scenario of how this might work, is where the Target
obtains a location URI in the form of a subscription URI (e.g., a SIP obtains a location URI in the form of a subscription URI (e.g., a SIP
URI) via HELD, (a Geopriv layer 7 location configuration protocol). URI) via HELD (a Geopriv layer 7 location configuration protocol).
Since, in this case the Target equals Recipient, then the Target can In this case, the Target is the same as the Recipient, therefore the
subscribe to the URI in order to be notified of its current location Target can subscribe to the URI in order to be notified of its
based on subscription parameters (see current location based on subscription parameters. In the example,
[I-D.ietf-geopriv-loc-filters]). Additionally, a geospatial boundary parameters are set up for a specific Target/Recipient along with an
can be expressed (ref. [I-D.ietf-geopriv-policy]), so that the expressed geospatial boundary, so that the Target/Recipient receives
Target/Recipient will get its updated location notification once it an updated location notification once the boundary is crossed (see
crosses the specified boundary. [I-D.ietf-geopriv-loc-filters]).
Location URIs may have an expiry associated to them, so that the LIS Location URIs may have an expiry associated with them, primarily for
is able to keep track of the location URIs that have been handed out, security considerations, and generally so that the LIS is able to
to know whether a location URI is still valid once the LIS receives keep track of the location URIs that have been handed out, to know
it in a request, and in order for a recipient of such a URI from whether a location URI is still valid once the LIS receives it in a
being able to (in some cases) permanently track a host. Other request, and in order for a recipient of such a URI from being able
justifications for expiration of location URIs include the ability to (in some cases) permanently track a host. Expiration of a
for a LIS to do garbage collection. location URI limits the time that accidental leaking of a location
URI introduces. Other justifications for expiration of location URIs
include the ability for a LIS to do garbage collection.
Because a location URI is a pointer to the Target's location, it is Because a location URI is a pointer to the Target's location, it is
important that it be constructed in such a way that it does not important that it be constructed in such a way that it does not
unintentionally reveal any usable information about the Target it unintentionally reveal any usable information about the Target it
represents. For example, it is important to prevent adversaries from represents. For example, it is important to prevent adversaries from
obtaining any information that may be revealed about a Target by obtaining any information that may be revealed about a Target by
direct examination of the location URI itself, (e.g., names, direct examination of the location URI itself, (e.g., names,
identifiers, etc.), some determinable pattern or syntax (e.g., identifiers, etc.), some determinable pattern or syntax (e.g.,
sequence of numbers), or guessable codes (e.g., weak encryption). sequence of numbers), or guessable codes (e.g., weak encryption).
Therefore, each location URI must be constructed with security Therefore, each location URI must be constructed with security
safeguards in mind. safeguards in mind.
How a location URI is will ultimately be used within the dereference How a location URI is will ultimately be used within the dereference
step is an important consideration at the time that the location URI step is an important consideration at the time that the location URI
is requested via a location configuration protocol. Since is requested via a location configuration protocol. Since
dereferencing of location URIs could be done according to one of two dereferencing of location URIs could be done according to one of two
models, an "access control" model or a "possession" model (see authorization models, either an "access control authorization model"
below), it is important that location configuration protocols or a "possession authorization model" (see definitions, below), it is
indicate the type of a location URI that is being requested, (and important that location configuration protocols indicate the type of
also which type is returned). Dereference protocols must support a location URI that is being requested, (and also which type is
both types. returned).
1. Access control use type: Access to the location URI is limited by 1. Access control authorization model: Access to the location URI is
policy. This is the case where, for location configuration, the limited by policy. In this case, the Rule Maker (owner/Target) is
LIS applies (server side) authentication and access control at the able to provide authorization policies to the LIS during this
location configuration step, and repeats authentication and stage, or through some other parallel mechanism (e.g., interface
authorization for each dereference operation of that location URI. 1b., Figure 1.). Policies are attached to a location URI through
an (undisclosed) mechanism.
2. Possession use type: The possession use type is described as 2. Possession authorization model: The possession authorization
having no authentication and/or authorization requirement aside model is described as having no authentication and/or
from only possessing the location URI itself (in this case, authorization requirement aside from only possessing the location
possession implies authorization). Access to the location URI is URI itself. In this case, possession implies authorization.
limited by distribution only. Whoever possesses the location URI Access to the location URI is limited by distribution only.
has the ability to dereference it. Possession use types may be Whoever possesses the location URI has the ability to dereference
used within specified domains only, or might be used across wide it. Possession authorization models may be used within specified
open public networks. domains only, or might be used across wide open public networks.
In either of the above cases, a location URI needs to be In either of the above cases, a location URI needs to be constructed
constructed is such a way as to make it difficult to guess. The is such a way as to make it difficult to guess. The form of the URI
form of the URI is constrained by the degree of randomness and is constrained by the degree of randomness and uniqueness applied to
uniqueness applied to it. It is important to protect the actual it. It is important to protect the actual location information from
location information from an intermediate node (despite the fact an intermediate node (despite the fact that in the possession model
that in the possession model there would be nothing to prevent an there would be nothing to prevent an interceptor from seeking to
interceptor from seeking to dereference the location URI). dereference the location URI). Obfuscating the location URI
Obfuscating the location URI safeguards against the undetected safeguards against the undetected stripping off of what would
stripping off of what would otherwise be evident location otherwise be evident location information, since it forces a
information, since it forces a dereference operation by the dereference operation by the location dereference server, an
location dereference server, an important step for the purpose of important step for the purpose of providing statistics, audit trails,
providing statistics, audit trails, and general logging for many and general logging for many different kinds of location based
different kinds of location based services. services.
4. High-Level Requirements 4. High-Level Requirements
This document outlines the requirements for an Location by Reference This document outlines the requirements for an Location by Reference
mechanism which can be used by a number of underlying protocols. mechanism which can be used by a number of underlying protocols.
Requirements here address two general types of such protocols, a Requirements here address two general types of such protocols, a
general location configuration protocol, and a general location general location configuration protocol, and a general location
dereferencing protocol. Each of these two general protocols has dereferencing protocol. Each of these two general protocols has
multiple specific protocol implementations. Location configuration multiple specific protocol implementations. Location configuration
protocols include, HELD, DHCP, and LLDP-MED, whereas current location protocols include, HELD, DHCP, and LLDP-MED, whereas current location
skipping to change at page 9, line 46 skipping to change at page 10, line 46
C2. Location URI expiration: When a location URI has a limited C2. Location URI expiration: When a location URI has a limited
validity interval, its lifetime MUST be indicated. validity interval, its lifetime MUST be indicated.
Motivation: A location URI may not intend 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 MUST 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. Location Information Masking: The location URI form MUST, C4. Location Information Masking: The location URI form MUST,
through randomization and uniqueness, ensure that any location through randomization and uniqueness, ensure that any location
specific information embedded within the location URI itself is specific information embedded within the location URI itself is
skipping to change at page 10, line 30 skipping to change at page 11, line 30
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 only, or control whether a location URI can be resolved once only, or
multiple 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 URI Valid-for: A location URI validity interval, if C7. Validity Interval Indication: A location configuration protocol
used, MUST include the validity time, in seconds, as an indication MUST provide an indication of the location URI validity interval
of how long the client can consider a location URI to be valid. (i.e., expiry time) when present.
Motivation: It is important to be able to determine how long a Motivation: It is important to be able to determine how long a
location URI is to remain useful for, and when it must be location URI is to remain useful for, and when it must be
refreshed. refreshed.
C8. Location URI Anonymous: The location URI MUST NOT point to any C8. Location only: The location URI MUST NOT point to any
information about the Target other than it's location. information about the Target other than it's location.
Motivation: A user should have the option to control how much Motivation: A user should have the option to control how much
information is revealed about them. This provides that control by information is revealed about them. This provides that control by
not forcing the inclusion of other information with location, not forcing the inclusion of other information with location,
(e.g., to not include any identification information in the (e.g., to not include any identification information in the
location URI.) location URI.)
C9. Location URI Not guessable: Where location URIs are used C9. Location URI Not guessable: Where location URIs are used
publicly, any location URI MUST be constructed using properties of publicly, any location URI MUST be constructed using properties of
skipping to change at page 11, line 17 skipping to change at page 12, line 17
C10. Location URI Optional: In the case of user-provided C10. Location URI Optional: In the case of user-provided
authorization policies, where anonymous or non-guessable location authorization policies, where anonymous or non-guessable location
URIs are not warranted, the location configuration protocol MAY URIs are not warranted, the location configuration protocol MAY
support optional location URI forms. support optional location URI forms.
Motivation: Users don't always have such strict privacy Motivation: Users don't always have such strict privacy
requirements, but may opt to specify their own location URI, or requirements, but may opt to specify their own location URI, or
components thereof. components thereof.
C11. Location URI Use Type: The location configuration protocol C11. Location URI Authorization Model: The location configuration
MUST indicate whether the requested location URI conforms to the protocol SHOULD indicate whether the requested location URI
access control model or the possession model. conforms to the access control authorization model or the
possession authorization model.
Motivation: Downstream dereference clients and servers need to Motivation: Downstream dereference clients and servers need to
know whether a location URI provided by the location configuration know whether a location URI provided by the location configuration
protocol conforms to an access control model or a possession protocol conforms to an access control authorization model or a
model. possession authorization model.
C12. Location URI Lifetime: A location URI SHOULD have an
associated expiration lifetime (i.e., validity interval), and MUST
have an validity interval if used with the possession
authorization model.
Motivation: If a location URI is unintentionally leaked, then the
amount of time that the reference can be potentially used by an
unknown attacker (or, casual observer) needs to be limited.
4.2. Requirements for a Location Dereference Protocol 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 indicator: The location dereference D2. Validity Interval Indication: A location dereference protocol
protocol MUST support an indicator showing that, if it is the MUST provide an indication of the location URI validity interval
case, that a location URI is no longer valid due to expiration. (i.e., expiry time) when present.
Motivation: Location URIs are expected to expire, based on Motivation: It is important to be able to determine how long a
location configuration protocol parameters, and it is therefore location URI is to remain useful for, and what time it will no
useful to convey the expired status of the location URI in the longer be usable.
location dereference protocol.
D3. Authentication: The location dereference protocol MUST include D3. Authentication: The location dereference protocol MUST include
mechanisms to authenticate both the client and the server. mechanisms to authenticate both the client and the server.
Motivation: Although the implementations must support Motivation: Although the implementations must support
authentication of both parties, any given transaction has the authentication of both parties, any given transaction has the
option not to authenticate one or both parties. option not to authenticate one or both parties.
D4. Dereferenced Location Form: The value returned by the D4. Dereferenced Location Form: The value returned by the
dereference protocol MUST contain a well-formed PIDF-LO document. dereference protocol MUST contain a well-formed PIDF-LO document.
skipping to change at page 12, line 25 skipping to change at page 13, line 36
D5. Location URI Repeated Use: The location dereference protocol D5. Location URI Repeated Use: The location dereference protocol
MUST support the ability for the same location URI to be resolved MUST support the ability for the same location URI to be resolved
more than once, based on dereference server configuration. more than once, based on dereference server configuration.
Motivation: Through dereference server configuration, for example, Motivation: Through dereference server configuration, for example,
it may be useful to not only allow more than one dereference it may be useful to not only allow more than one dereference
request, but, in some cases, to also limit the number of request, but, in some cases, to also limit the number of
dereferencing attempts by a client. dereferencing attempts by a client.
D6. Location URI Valid-for: A location URI validity interval, if D6. Validity Interval Indication: A dereference protocol MUST
used, MUST include the validity time, in seconds, as an indication provide an indication of the location URI validity interval (i.e.,
of how long the client can consider a location URI to be valid. expiry time) when present.
Motivation: It is important to be able to determine how long a Motivation: It is important to be able to determine how long a
location URI is to remain useful when dereferencing a location location URI is to remain useful for, and when it must be
URI. refreshed.
D7. Location URI anonymized: Any location URI whose dereference will D7. Location URI anonymized: Any location URI whose dereference will
not be subject to authentication and access control MUST be not be subject to authentication and access control MUST be
anonymized. anonymized.
Motivation: The dereference protocol must define an anonymized Motivation: The dereference protocol must define an anonymized
format for location URIs. This format must identify the desired format for location URIs. This format must identify the desired
location information via a random token with at least 128 bits of location information via a random token with at least 128 bits of
entropy (rather than some kind of explicit identifier, such as an entropy (rather than some kind of explicit identifier, such as an
IP address). IP address).
skipping to change at page 13, line 22 skipping to change at page 14, line 31
D10. Location Confidentiality: The dereference protocol MUST D10. Location Confidentiality: The dereference protocol MUST
support encryption of messages sent between the location support encryption of messages sent between the location
dereference client and the location dereference server, and MAY dereference client and the location dereference server, and MAY
alternatively provide messaging unencrypted. alternatively provide messaging unencrypted.
Motivation: Environmental and local configuration policy will Motivation: Environmental and local configuration policy will
guide the requirement for encryption for certain transactions. In guide the requirement for encryption for certain transactions. In
some cases, encryption may be the rule, in others, it may be some cases, encryption may be the rule, in others, it may be
acceptable to send and receive messages without encryption. acceptable to send and receive messages without encryption.
D11. Location URI Use Type: The location dereference protocol MUST D11. Location URI Authorization Model: The location dereference
indicate whether the requested location URI conforms to the access protocol SHOULD indicate whether the requested location URI
control model or the possession model. conforms to the access control authorization model or the
possession authorization model.
Motivation: Downstream dereference clients need to know whether a Motivation: Downstream dereference clients need to know whether a
location URI provided by the location configuration protocol location URI provided by the location configuration protocol
conforms to an access control model or a possession model in order conforms to an access control authorization model or a possession
to save time processing dereference attempts. authorization model in order to save time processing dereference
attempts.
5. Security Considerations 5. Security Considerations
The LbyR mechanism currently addresses security issues as follows. A location URI, regardless of its construction, if public, by itself,
implies no safeguard against anyone being able to dereference and get
the location. The method of constructing the location URI form to
include randomization along with encryption does help prevent some
potential pattern guessing. In the case of one time use location
URIs, (referred to as a pawn ticket), the argument can be made that
possession implies permission, and location URIs that are public are
protected only by privacy rules enforced at the dereference server.
A location URI, regardless of its construction, if public, by Any location URI, by necessity, indicates the server (name) that
itself, implies no safeguard against anyone being able to hosts the location information. Knowledge of the server in some
dereference and get the location. The method of constructing the specific domain could therefore reveal something about the location
location URI form to include randomization along with encryption of the Target. This kind of threat may be mitigated somewhat by
does help prevent some potential pattern guessing. In the case of introducing another layer of indirection: namely the use of a
one time use location URIs, (referred to as a pawn ticket), the (remote) presence server.
argument can be made that possession implies permission, and
location URIs that are public are protected only by privacy rules
enforced at the dereference server.
6. IANA Considerations 6. IANA Considerations
This document does not require actions by the IANA. This document does not require actions by the IANA.
7. Acknowledgements 7. Acknowledgements
We would like to thank the IETF GEOPRIV working group chairs, Andy I would like to thank the present IETF GEOPRIV working group chair
Newton, Allison Mankin and Randall Gellens, for creating the design for their continued support in progressing this document along, as
team which initiated this requirements work. We'd also like to thank well, I wish to thank past chairs, Andy Newton, Allison Mankin and
those design team participants for their inputs, comments, and Randall Gellens, for creating the design team which initiated this
reviews. The design team included the following folks: Richard requirements work. I'd also like to thank those original design team
Barnes; Martin Dawson; Keith Drage; Randall Gellens; Ted Hardie; participants for their inputs, comments, and insightful reviews. The
Cullen Jennings; Marc Linsner; Rohan Mahy; Allison Mankin; Roger design team included the following folks: Richard Barnes; Martin
Marshall; Andrew Newton; Jon Peterson; James M. Polk; Brian Rosen; Dawson; Keith Drage; Randall Gellens; Ted Hardie; Cullen Jennings;
John Schnizlein; Henning Schulzrinne; Barbara Stark; Hannes Marc Linsner; Rohan Mahy; Allison Mankin; Roger Marshall; Andrew
Tschofenig; Martin Thomson; and James Winterbottom. Newton; Jon Peterson; James M. Polk; Brian Rosen; John Schnizlein;
Henning Schulzrinne; Barbara Stark; Hannes Tschofenig; Martin
Thomson; and James Winterbottom.
8. References 8. References
8.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.
8.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-07 (work in draft-ietf-geopriv-http-location-delivery-10 (work in
progress), April 2008. progress), October 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-08 (work in Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in
progress), June 2008. progress), June 2008.
[I-D.ietf-geopriv-loc-filters] [I-D.ietf-geopriv-loc-filters]
Mahy, R., "A Document Format for Filtering and Reporting Mahy, R. and B. Rosen, "A Document Format for Filtering
Location Notications in the Presence Information Document and Reporting Location Notications in the Presence
Format Location Object (PIDF-LO)", Information Document Format Location Object (PIDF-LO)",
draft-ietf-geopriv-loc-filters-01 (work in progress), draft-ietf-geopriv-loc-filters-02 (work in progress),
March 2007. July 2008.
[I-D.ietf-geopriv-policy] [I-D.ietf-geopriv-policy]
Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
and J. Polk, "Geolocation Policy: A Document Format for and J. Polk, "Geolocation Policy: A Document Format for
Expressing Privacy Preferences for Location Information", Expressing Privacy Preferences for Location Information",
draft-ietf-geopriv-policy-17 (work in progress), draft-ietf-geopriv-policy-17 (work in progress),
June 2008. June 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-10 (work in progress), draft-ietf-sip-location-conveyance-11 (work in progress),
February 2008. October 2008.
[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 previous version (-04 vs.
-03):
1. Changed wording of section 1 "Introduction", (Thompson ~ 7/09/08
list comments).
1. Relocated text in section 3 "Overview of Location-by-Reference"
to section 1 (Intro), (Thompson comments).
2. (Sect. 3, con't) Fixed Figure 1. Label, based on (Thompson
comments).
3. Fixed minor spelling errors, incl. Note B., Note C., etc., based
on (Thompson comments).
4. Added some qualifying text (security) around possession model,
based on (Thompson comments).
5. Replaced "use type" labels with "authorization models", "access
authorization model", and "possession authorization model", (Thompson
comments).
6. Changed the entity role of applying security from LIS (Server-
side authentication), to the Rule-Maker (owner/Target) providing
policies to the LIS, (Thompson comments).
7. Changed requirement C3 to a MUST, (Thompson comments).
8. Added new requirement, C12, "C12. Location URI Lifetime:" as a
SHOULD for all, and MUST for possession auth model, (Thompson
comments).
9. Changed name of requirement C8 to "Location Only", (Thompson
comments).
10. Reworded C7 and D6 to be less implementation specific, (Thompson
comments).
11. Changed requirements C11, D11 to SHOULD, (Thompson comments).
12. (Section 5:) Removed lead in sentence for readibility, (Thompson
comments).
13. Remove "pawn ticket" reference - replaced with "possession
authorization model", (Thompson comments).
14. Added new paragraph to the security section (Thompson, 7/09/08
comments).
15. Corrected other minor spelling and wording errors and
deficiencies (refer to diff 04/03) (-Editor).
Changes to this draft in comparison to the previous version (-03 vs. Changes to this draft in comparison to the previous version (-03 vs.
-02): -02):
1. Changed wording of section 3 "Overview of Location-by-Reference" 1. Changed wording of section 3 "Overview of Location-by-Reference"
(Polk, Thomson, Winterbottom ~ 4/1/08 list comments). (Polk, Thomson, Winterbottom ~ 4/1/08 list comments).
2. Added new requirement C4. "Location Information Masking:", based 2. Added new requirement C4. "Location Information Masking:", based
on (Thomson ~4/1/08 list comment). on (Thomson ~4/1/08 list comment).
3. Added new requirement C11. "Location URI Use Type:", based on 3. Added new requirement C11. "Location URI Use Type:", based on
 End of changes. 45 change blocks. 
192 lines changed or deleted 289 lines changed or added

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