Internet DRAFT - draft-winterbottom-location-uri
draft-winterbottom-location-uri
GEOPRIV WG J. Winterbottom
Internet-Draft M. Thomson
Expires: July 24, 2006 Andrew
J. Peterson
NeuStar, Inc.
January 20, 2006
Rationale for Location by Reference
draft-winterbottom-location-uri-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 24, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
An analysis is performed on the advantages and disadvantages for
provision of Location Information (LI) by-reference in the GEOPRIV
architecture. The concept of a Location URI, that is, a URI that
references LI, is introduced. A number of usage patterns for
Location URIs are discussed, particularly with regard to addressing
mobility. Security concerns that are introduced by Location URIs are
Winterbottom, et al. Expires July 24, 2006 [Page 1]
Internet-Draft Location URI January 2006
also considered.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Location By-Value . . . . . . . . . . . . . . . . . . . . 3
1.2. Location By-Reference . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
3. Session Decoupling . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Subscriptions and Presence . . . . . . . . . . . . . . . . 6
3.2. Location Format . . . . . . . . . . . . . . . . . . . . . 6
4. Performance and Optimization . . . . . . . . . . . . . . . . . 7
4.1. Reducing Device Responsibilities . . . . . . . . . . . . . 7
4.2. Open Medium Scenarios . . . . . . . . . . . . . . . . . . 8
5. Device Mobility . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. The Cost of Determining Location Information . . . . . . . 9
5.2. Impact of Mobility on By-Value Location . . . . . . . . . 9
5.3. Addressing Mobility . . . . . . . . . . . . . . . . . . . 10
5.4. Expiry of Location Information . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6.1. Authorizing the Source of Location Information . . . . . . 11
6.2. Assigning a Location URI . . . . . . . . . . . . . . . . . 12
6.3. Location URI Theft . . . . . . . . . . . . . . . . . . . . 12
6.3.1. Protecting the Location URI . . . . . . . . . . . . . 12
6.3.2. Strong Identity Association . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Winterbottom, et al. Expires July 24, 2006 [Page 2]
Internet-Draft Location URI January 2006
1. Introduction
The basic GEOPRIV architecture [RFC3693] concentrates on how Location
Information (LI) is conveyed from creation at a Location Generator
(LG) to consumption at a Location Recipient (LR). Particular
emphasis is placed on ensuring that appropriate privacy constraints
exist to protect the Target.
Two primary usage models have evolved from this basic architecture,
which we shall call _by-value_ and _by-reference_. This document
concentrates on the by-reference method for conveyance of LI. The
strengths and particular vulnerabilities, from implementation,
network architecture, security and privacy perspectives are
discussed.
This document is intended to provide a guide to making a choice
between the two approaches, as well as providing some additional
information on providing LI by-reference.
1.1. Location By-Value
The by-value usage model is based on the concept that the Target, as
the subject of the LI, should also be the owner and controller of the
data. The Target receives LI from the LG and is then responsible for
providing a Location Object (LO) [RFC4119] to LRs. This model places
the control over which LRs gain access to LI directly with the
Target.
+-----------+ +--------+ +-----------+
| Location | | | | Location |
| Generator |---LI/LO-->| Target |----LO--->| Recipient |
| | | | | |
+-----------+ +--------+ +-----------+
Figure 1: Basic By-Value Model
Implicit in this diagram are a number of other entities from the
GEOPRIV architecture. The Target also assumes the roles of Rule
Maker (RM), Rule Holder (RH) and Location Server (LS). The Device is
considered to be acting for the Target.
Two minor variations have evolved from this model, either of the LG
or Target can construct the LO.
1.2. Location By-Reference
When a Location URI is used, a Location Server (LS) is employed to
manage interactions with LRs. The Target either explicitly delegates
Winterbottom, et al. Expires July 24, 2006 [Page 3]
Internet-Draft Location URI January 2006
this task, or the LG arranges for this. The Target then makes a
Location URI available to the LR, which de-references that URI to
acquire the Target's LO.
+-----------+ +-----------+
| Location | | Location |
| Generator |---LI/LO--->| Server |
| | (a) ,->| |
+-----------+ / +---<URI>---+
| / |
LI/LO (b) LI/LO LO
| (b) |
V / V
+-----------+ / +-----------+
| |--' | Location |
| Target |----URI---->| Recipient |
| | | |
+-----------+ +-----------+
Figure 2: Basic By-Reference Model
Two variations are shown in the diagram: (a) shows the LG publishing
LI to the LS directly; (b) shows that the LI is first provided to the
Target, which then publishes LI to the LS. Note: To simplify this
diagram, variations related to privacy and the means by which
authorization rules are made available to the LS are not shown.
Winterbottom, et al. Expires July 24, 2006 [Page 4]
Internet-Draft Location URI January 2006
2. Conventions and Terminology
This document uses the terminology and acronyms defined in RFC 3693
[RFC3693].
The term _Location URI_ is defined as a reference to a Location
Object (LO). A Location URI contains the address of a Location
Server (LS) and provides sufficient additional information for the LS
to be able to retrieve a LO. Location URI is preferred over the term
_location-key_, which is sometimes used in this context.
Winterbottom, et al. Expires July 24, 2006 [Page 5]
Internet-Draft Location URI January 2006
3. Session Decoupling
A Location URI decouples interactions between LR and LS from any
application-specific interactions between Target and LR. This
introduces the possibility of a different protocol, and enables more
sophisticated interactions between LR and LS.
3.1. Subscriptions and Presence
The LR is able to subscribe to the LS for notifications of changes in
a particular Target's location. The LR is also able to provide its
own time and resolution constraints to limit these notifications, see
[I-D.mahy-geopriv-loc-filters]. This subscribe/notify mode of
operation closely matches the general presence model [RFC3859].
Note: In order to support a subscription service for location the LG
must be able to detect changes in location and then communicate these
changes to the LS.
3.2. Location Format
When LI is provided to an LR by-value, the LR is somewhat dependent
on the Target to provide LI in a form that can be used. For
instance, the LR could be unable to make use of a civic address
[I-D.ietf-geopriv-revised-civic-lo]. Therefore, application
protocols that support by-value provision of LI need to support
negotiation for the correct form of LI.
A Location URI enables the retrieval of LI directly from the LS; the
LR can request the necessary form of LI directly. This reduces the
level of support required for LI in application protocols.
Winterbottom, et al. Expires July 24, 2006 [Page 6]
Internet-Draft Location URI January 2006
4. Performance and Optimization
Using a Location URI also introduces a retrieval step that could add
additional delay to a time-critical application. By-value location
can be used in these situations to remove this step; if a Target is
able to acquire LI beforehand, this information can be provided by-
value, thus avoiding adding delays. However, care must be taken to
ensure the validity of LI, particularly when the Target is mobile,
see Section 5.
Note also that if a time-critical operation is started when LI is not
available, by-value location provision is delayed until location
generation has completed.
Using Location URIs places the control over when location is
generated with the LR. Again, in a time-critical application this
also means that the LR may be forced to wait for location generation
to occur.
Several methods can reduce the impact of the location generation
delay when using Location URIs:
o Because the LR interacts with the LS directly, it has some degree
of control over the costs involved. The LR can communicate
urgency to the LS and request that the LI is generated quickly; a
parameter indicating priority, or maximum time to respond could be
used.
o The LS is able to perform caching of LI. Subsequent requests for
LI can use cached values without incurring the costs associated
with generating location.
o The generation or assignment of a Location URI has a minimal cost,
therefore a Location URI can be provided to an LR without adding
additional delays at the start of time-critical operations. The
Target could also initiate a location generation process at this
time; this way some of the delay can occur in parallel to the main
operation, and potentially LI can be pre-cached at the LS in
preparation for a request from the LR.
4.1. Reducing Device Responsibilities
Using a Location URI allows a Device to delegate much of the effort
involved with providing LI. In particular, authentication of LRs can
require processing of encrypted data and interaction with network
servers, for example Online Certification Status Protocol (OCSP)
[RFC2560]. For lightweight devices with limited processing
capabilities, battery dependencies or limited network access, this
Winterbottom, et al. Expires July 24, 2006 [Page 7]
Internet-Draft Location URI January 2006
can be advantageous. Delegating this responsibility can also reduce
the complexity of an end device.
Deciding when LI is required for an application is sometimes
difficult. For instance, it is difficult to determine if certain
telephony services require LI based on dialed digits. Because a
Location URI does not necessarily leak any private information, a
Location URI can be provided in all cases without having to make any
decision. This leaves the receiver the choice of whether LI is
required. A privacy profile at the LS guarantees that only
authorized LRs gain access to LI. If this approach is taken, the
security implications of this approach need to be considered, see
Section 6.3.
4.2. Open Medium Scenarios
Providing LI by-value over a medium that is accessible to multiple
parties presents a particular challenge to the Target. In order to
ensure that only authorized entities have access to LI, the LO must
be individually encrypted for those entities. This also implies that
those entities are known ahead of time. For example, this might
apply for an application where intermediaries are part of a
transaction with another end point.
Using a Location URI on such an open medium allows this authorization
decision to occur at the LS based on a policy. A Location URI can be
provided to all parties with only those who are permitted actually
gaining access to LI, including the other end point if desired.
Section 6.3.1 covers the implications of this approach with regards
to theft.
Winterbottom, et al. Expires July 24, 2006 [Page 8]
Internet-Draft Location URI January 2006
5. Device Mobility
Device mobility, specifically the degree to which devices are able or
expected to move, has an effect on the applicability of by-value and
by-reference location. Some networks have definite mobility
characteristics; for instance, a cellular network is expected to have
highly mobile devices, whereas devices in a residential wired access
network rarely move.
How frequently devices move is the primary way that mobility affects
the validity of LI. LI for a mobile device can become inaccurate in
a very short period of time.
5.1. The Cost of Determining Location Information
One further impact of mobility is the cost of determining location,
in both processing power consumed and time. As mobility increases,
the means of determining a precise location become more complex and
time-consuming.
To take a generic wireless network as an example, a coarse location
estimate based on the location of a transmitter can be provided
relatively quickly, however this estimate may not be sufficiently
precise to be of use to the LR. More accurate wireless location
determination methods incur a greater cost, in processing capacity,
time or both. For instance, generating a location based on signal
propagation delays is relatively processing intensive; similarly, a
significant amount of time can be required to acquire Global
Positioning System (GPS) signals, which then also require processing
to derive location.
Therefore, it can be seen that the usefulness of inexpensive location
estimates is reduced where network mobility is allowed; conversely,
the cost of acquiring a sufficiently precise estimate increases.
5.2. Impact of Mobility on By-Value Location
In order for LI to be current at the time of use in a network that
allows for mobility, the LG must ensure that it provides new LI to
the Target every time it moves. Since location is practically
continuous (Planck length notwithstanding) a moving device can
generate any number of such notifications, limited only by the
ability of the LG to recognise changes in location and any
artificially imposed constraints.
In practice, both time and resolution constraints are used to limit
the rate of polling that occurs. Even with these constraints, there
is still a potential for a substantial proportion of the location
Winterbottom, et al. Expires July 24, 2006 [Page 9]
Internet-Draft Location URI January 2006
determination effort to be wasted.
5.3. Addressing Mobility
In more mobile access networks, a Location URI can reduce this
expenditure of effort. A Location URI grants the LR some control
over how and when LI is determined.
Using a Location URI ensures that the information that the LR
receives is current, and therefore more accurate; it also reduces the
cost of polling.
5.4. Expiry of Location Information
The inclusion of parameters such as expiry time enables better
management of the validity of LI.
For fixed services, expiry times can be moderately lengthy with
little risk of LI actually being inaccurate. Fixed services based on
a wired connection can also detect movement based on detecting the
physical disconnection and connection of a wire or cable.
Expiry of LI becomes more important when the Target is mobile.
Appropriate values for expiry times can limit the chances of LI being
inaccurate due to movement. However, if location is provided by-
value, the Target must provide LI more frequently as expiry times are
shorter. Using a Location URI can reduce the impact of this on the
Target.
Winterbottom, et al. Expires July 24, 2006 [Page 10]
Internet-Draft Location URI January 2006
6. Security Considerations
RFC 3693 [RFC3693] primarily concentrates on protecting the privacy
of the Target. However, much of the security implications of using a
Location URI arise from location fraud. The LR, as a consumer of LI,
requires protection against being provided fraudulent LI, which can
occur in a number of ways.
6.1. Authorizing the Source of Location Information
To protect against fraudulent LI, the LR must be able to authenticate
the identity of the source of LI, then ensure that the LI has not
been modified in transit. In this instance, three potential
_sources_ of LI are considered: the Target, the LG and the LS.
Protection against modification can be assured either by guaranteeing
a secure connection directly between the source and recipient using a
protocol such as TLS [RFC2246], or by the application of a digital
signature. If a secure channel is used, authentication needs to
applied within that channel. A digital signature should include
authentication information for the signer.
Once an authenticated source of LI has been identified, the LR must
also determine if it trusts that entity to provide accurate LI.
o If the Target is the source of LI, as may be the case when
location is provided by-value, the LR must authorize the Target.
Where the LR has a strong need to trust the veracity of the LI,
the effort involved in establishing this level of authorization
for each possible Target could be prohibitive. Situations where
this might not be appropriate are where there are very large
numbers of potential Targets and/or where resources are expended
based on the value of the LI.
o For the LS, it is expected that there are fewer Location Servers
with which an LR needs to establish an adequate trust
relationship. Thus, by-reference LI can be used to avoid the
Target authorization problem. However, the LR must also trust
that the LS is not likely to accept fraudulent LI; if the LS
relies on an LG to generate LI, then the LR must also trust the
LG.
o The LG can also be considered as a part of either LS or Target, in
which case, the guidelines for either of those roles apply.
Winterbottom, et al. Expires July 24, 2006 [Page 11]
Internet-Draft Location URI January 2006
6.2. Assigning a Location URI
A Location URI is an identifier generated by an LS so that an LR can
retrieve LI. The Location URI must not include any information that
could be used to identify the Target or any other entity that might
be associated with the Target, such as the Device. The Location URI
can therefore be considered an _unlinked pseudonym_ as defined in
[RFC3693]. This implies that internal correlation (using a hash-
table or similar) is the only method that the LS can use to associate
a Location URI with a particular Target.
The LS must assign a Location URI and then must maintain a link
between the assigned URI and the specific Target. If this
association can be subverted, an attacker could request a URI using
fake identification information so that subsequent requests to this
URI resulted in the location of another Target being determined and
returned to the LR. The LS must employ measures to prevent this from
occuring.
6.3. Location URI Theft
The lack of identification information means that a recipient of a
Location URI cannot be sure to whom the Location URI belongs. To
this end, two options are presented: protecting the Location URI from
theft, and weak Location URI protection with strong identity
association.
6.3.1. Protecting the Location URI
This is the simpler approach, the Target ensures that the Location
URI is only provided to trusted entities. The Target need only trust
these entities to not retransmit the Location URI, they need not
include all such entities in an authorization policy.
For this reason, a Location URI should always be carried over a
transport that protects against eavesdropping.
6.3.2. Strong Identity Association
One advantage of a Location URI is that it can be used to provide LI
to an LR, even when untrusted intermediaries are involved in a
transaction. The Location URI can be given to these intermediaries,
but they cannot access LI as long as they are not included in the
Target's authorization policy. Note also that because the Location
URI does not include identification information, the Target could
also remain anonymous, depending on the application protocol used.
The disadvantage of using a Location URI in this manner is that it is
Winterbottom, et al. Expires July 24, 2006 [Page 12]
Internet-Draft Location URI January 2006
exposed to theft, whereby the intermediaries (or other parties) can
take the Location URI and use it as if it were their own. The LR,
upon receiving the LI cannot know to whom the Location URI belongs.
To protect against this, the Target can provide the LS with a
presentity identifier that is also known to the LR. When the LR
retrieves the LO from the LS, the LO includes this presentity
identifier. In this way the LR can link the LI with the identity of
the Target.
This approach requires that the LS authenticate the Target when
assigning a Location URI.
7. References
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3859] Peterson, J., "Common Profile for Presence (CPP)",
RFC 3859, August 2004.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[I-D.ietf-geopriv-revised-civic-lo]
Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for PIDF-LO",
draft-ietf-geopriv-revised-civic-lo-01 (work in progress),
January 2006.
[I-D.mahy-geopriv-loc-filters]
Mahy, R., "A Document Format for Filtering and Reporting
Location Notications in PIDF-LO",
draft-mahy-geopriv-loc-filters-00 (work in progress),
October 2005.
Winterbottom, et al. Expires July 24, 2006 [Page 13]
Internet-Draft Location URI January 2006
Authors' Addresses
James Winterbottom
Andrew
PO Box U40
Wollongong University Campus, NSW 2500
AU
Phone: +61 2 4221 2938
Email: james.winterbottom@andrew.com
URI: http://www.andrew.com/
Martin Thomson
Andrew
PO Box U40
Wollongong University Campus, NSW 2500
AU
Phone: +61 2 4221 2915
Email: martin.thomson@andrew.com
URI: http://www.andrew.com/
Jon Peterson
NeuStar, Inc.
1800 Sutter St, Suite 570
Concord, CA 94520
US
Phone: +1 925/363-8720
Email: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Winterbottom, et al. Expires July 24, 2006 [Page 14]
Internet-Draft Location URI January 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Winterbottom, et al. Expires July 24, 2006 [Page 15]