One document matched: draft-barnes-geopriv-lo-sec-01.txt
Differences from draft-barnes-geopriv-lo-sec-00.txt
Geopriv R. Barnes
Internet-Draft M. Lepinski
Updates: 3693, 3694 BBN Technologies
(if approved) H. Tschofenig
Intended status: Informational Nokia Siemens Networks
Expires: May 22, 2008 H. Schulzrinne
Columbia University
November 19, 2007
Security Requirements for the Geopriv Location System
draft-barnes-geopriv-lo-sec-01
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 May 22, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Internet protocols that deal with presence-based location objects
support a wide variety of applications. However, the dissemination
of location objects from sources of location to consumers is a common
feature of all location-based applications. In order to enable the
Barnes, et al. Expires May 22, 2008 [Page 1]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007
development of broadly-applicable security and privacy mechanisms for
dissemination of location objects, this document describes an end-to-
end architecture for policy-constrained location distribution. In
this architecture, location distribution is accomplished by a set of
distribute actors. Likewise, we describe the assurances that these
actors require from the architecture, and derive more detailed
security requirements based on these assurances.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. An End-to-end Location Architecture . . . . . . . . . . . . . 4
3.1. Structure of a Location Transmission . . . . . . . . . . . 5
3.2. The End-to-end Model and Global Roles . . . . . . . . . . 7
3.3. Usage Scenarios for this Model . . . . . . . . . . . . . . 8
3.3.1. RFC 3693 model of transmission . . . . . . . . . . . . 8
3.3.2. Location configuration by "pull" . . . . . . . . . . . 9
3.3.3. Location configuration by "push" . . . . . . . . . . . 10
3.3.4. Location conveyance by value . . . . . . . . . . . . . 10
3.3.5. Location conveyance by reference . . . . . . . . . . . 10
3.3.6. Presence server . . . . . . . . . . . . . . . . . . . 10
4. Required Assurances . . . . . . . . . . . . . . . . . . . . . 11
4.1. Location Transmission . . . . . . . . . . . . . . . . . . 11
4.1.1. Location Mover . . . . . . . . . . . . . . . . . . . . 11
4.1.2. Rule Maker . . . . . . . . . . . . . . . . . . . . . . 12
4.1.3. Location Server . . . . . . . . . . . . . . . . . . . 12
4.1.4. Location Recipient . . . . . . . . . . . . . . . . . . 12
4.2. End-to-end distribution . . . . . . . . . . . . . . . . . 13
4.2.1. Location Generator . . . . . . . . . . . . . . . . . . 13
4.2.2. Viewer . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.3. Target . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Security Requirements . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Informative References . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Barnes, et al. Expires May 22, 2008 [Page 2]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007
1. Introduction
Demand for location-based Internet applications, especially location-
based Internet calling [I.D-ietf-ecrit-framework], has driven the
creation of Internet protocols for communicating information about
the location of Internet end hosts or other entities. Of interest,
for example, are protocols for informing hosts of their own location
(location configuration protocols), transmitting location information
from one host to another (location conveyance protocols), and
requesting location information from a server (location dereference
protocols).
The first goal of this document is to describe how location
information is used by these protocols over its entire "life-cycle".
This life-cycle begins when location information is introduced into
an IP network via a location configuration protocol, continues
through one or more transmission by way of location conveyance
protocols (and dereference protocols, when conveyed by reference),
and ultimately ends when the location is delivered to an application
consumer.
A model for the use of Internet protocols to transmit location
information via a store-and-forward network of Location Servers has
been described in RFC 3693 [RFC3693]. Privacy concerns and privacy-
relevant security concerns are described in RFC 3694 [RFC3694]. This
document extends the model of these previous documents to explicitly
take into account the end-to-end properties of the system, and to
address security mechanisms related to concerns other than privacy.
The Location Objects (LO) described in RFC 3693 and RFC 3694 are
usually encoded as XML documents in the Presence Information Data
Format - Location Object (PIDF-LO) schema [RFC4119]. While the
general trend in the IETF is to require that LOs be in this format,
certain protocols do not use PIDF-LO, most notably the DHCP
extensions to carry location in civic [RFC4776] or geospatial
[RFC3825] format. In this document, such formats for location
information are also regarded as LO formats, even though they do not
comply with the requirements for LO formats in RFC 3693.
The remainder of this document is structured as follows: After
relevant terminology is introduced in Section [ref], Section [ref]
describes an architecture for the end-to-end distribution of location
over the Internet. In particular, this architecture describes a set
of entities that work together to move location information from
source to consumer. Based on the roles they play in the
architecture, these entities may require certain assurances, and
these are described in Section [ref]. Finally, the technical
properties and mechanisms required to enable these assurances are
Barnes, et al. Expires May 22, 2008 [Page 3]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007
reflected in a set of requirements for Geopriv security mechanisms.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Most of the terms used in this document are defined in RFC 3693. New
terms, and terms which have a different meaning than in RFC 3693, are
described below.
Location Mover: An entity that causes a location transmission to
occur. It may do so by instructing a Location Server to transmit
location to a Location Recipient (a "push"), or it may provide a
Location Recipient a reference that it can use to request the
location from a Location Server (a "pull").
Location Server: An entity that transmits location according to
privacy policies.
Location Generator: The entity that introduces a Location Object to
the Internet. An LG may perform sighting (i.e., it may determine
the location of a Target), or it may act as a relay from some non-
Internet-connected location resource.
Location by value: Location is represented by value when it is
represented directly, as a data object containing location
information. We say that a location object is represented by
value even if the information it contains is encrypted.
Location by reference: Location is represented by reference when it
is represented indirectly, as a reference to another location
datum (possibly another reference). For example, if a URL returns
a PIDF-LO document when dereferenced, then that URL constitutes a
representation of the PIDF-LO by reference.
3. An End-to-end Location Architecture
In this section, we present an architecture for the end-to-end
communication of location information. The overall pattern of
transmissions involved in this communication is often complex and
thus such systems are modeled as the composition of atomic building
blocks.
In Section 3.1 we describe a single location transmission, and the
Barnes, et al. Expires May 22, 2008 [Page 4]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007
roles played by parties in such a transmission. A location
transmission is an atomic unit that models a single movement of
location information. In Section 3.2 we describe how multiple
location transmissions can fit together within an end-to-end system
and the global roles played by entities in such a composite system.
Finally, in Section 3.3 we demonstrate how this model maps to common
location use-cases such as location configuration and point-to-point
location conveyance.
3.1. Structure of a Location Transmission
Location transmission is the basic building block for policy-
constrained location distribution. A single transmission occurs in
three steps, illustrated in Figure 1:
1. A Rule Maker informs the Location Server about Privacy Rules
governing the distribution of Location Objects.
2. A Location Mover requests that location be moved, either by
directing the LS to transmit the location to the LR or by
providing the LR with a reference by which it can request
location from the LS.
3. The LS determines whether the transmission is permitted by the
rules available to it, and if so, transmits location to the LR
(possibly as the result of a request by the LR).
Note that the location transmitted in step (3) may be represented
directly, as an intelligible LO, or indirectly, as a reference to the
LO. When the LS provides a reference, it is also acting as an LM in
a second transmission, in which the LR uses the reference to obtain
an LO from another LS. In the below, the distinction between these
representations is not significant, and we refer to the transmitted
datum as a Location Object regardless of whether it is directly or
indirectly represented.
Barnes, et al. Expires May 22, 2008 [Page 5]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007
+---------+
| LM |
+---------+
|
+---(2)--either/or-------+
| |
V V
+---------+ +---------+
| LS |------(3)---->| LR |
+---------+ +---------+
^
|
(1)
|
+---------+
| RM |
+---------+
Figure 1: A single location transmission
There are four roles involved in this transaction, a Location Server
(LS), a Location Recipient (LR), a Location Mover (LM) and a Rule
Maker (RM). A single entity will commonly play multiple of these
roles within a single transaction (see Section Section 3.3 for
examples). The only two roles that are necessarily separate are that
of the LS and the LR, for obvious reasons.
Location Mover (LM) The Location Mover is the party who causes the
location transmission to occur. The LM may accomplish this in one
of two ways. Either the LM tells the Location Recipient how to
"pull" the LO, or else it tells the LS how to "push" the LO. In
the former case, the Location Mover would send the Location
Recipient a reference to the Location Server and to the location
information to be retrieved. In the latter case, the Location
Mover would send the Location Server an identifier for the
Location Recipient and an identifier for of the location
information to sent.
Rule Maker The Rule Maker is the party who produces the rules
governing whether a Location Recipient is allowed to receive
location information and what precision of location information a
Location Recipient is allowed to receive. (Such rules are
described in [ref:RFC4745] and [ref:draft-ietf-Geopriv-policy].)
The Rule Maker may send rules directly to the Location Server, or
the Location Server may receive the rules as part of a location
object as per [ref:RFC4119]. Note that some transmissions may
occur without a Rule Maker, in which cases the transmission is
constrained only by policy contained in the LO itself.
Barnes, et al. Expires May 22, 2008 [Page 6]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007
Location Server The Location Server is the party who possesses the
location information at the beginning of the transmission. The
Location Server receives rules governing the location information
as received from the Rule Maker, as part of the location object
containing the location information, or as part of its internal
configuration. The Location Server is responsible for applying
these rules and as such he may need to reduce the precision of the
location information or terminate the location transmission if the
Location Recipient is not authorized to receive the location
information. After applying the appropriate rules, the Location
Server sends the location information to the Location Recipient.
Location Recipient The Location Recipient receives the location from
the Location Server. If the Location Mover indicates that the
location is to be pulled by the Location Recipient, then the
Location Recipient may need to send a message to the Location
Server requesting the location.
3.2. The End-to-end Model and Global Roles
The life-cycle of a Location Object typically consists of multiple
location transmissions. For example, location might first be
acquired via a location configuration protocol (LCP) and then
conveyed via a location conveyance protocol). This end-to-end
distribution process can be described as a "chaining together" of the
individual transmissions described above; different transmissions are
connected by an entity that acts as an LR in one transmission and an
LS in the next. This process is illustrated in Figure 2. Note that
although Figure 2 depicts a single "path", a single LS may transmit
location to multiple LRs over time; grouping these paths together
forms a logical distribution tree, with the LG as the root node and
Viewers as leaf nodes.
. +----+ . +----+ . +----+
. | LM | . | LM | . | LM |
. +----+ . +----+ . +----+
. / \ . / \ . / \
+----+----+ +----+----+ +----+----+ +----+--------+
| LG | LS |--->| LR | LS |--->| LR | LS |--->| LR | Viewer |
+----+----+ +----+----+ +----+----+ +----+--------+
. | . | . |
. +----+ . +----+ . +----+
. | RM | . | RM | . | RM |
. +----+ . +----+ . +----+
Figure 2: End-to-end location distribution
In addition to the roles within a particular location transmission,
there are also three additional global roles within the larger
Barnes, et al. Expires May 22, 2008 [Page 7]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007
composite system. As described in Section 3, a given party may need
particular assurances based on the global role that it plays.
Location Generator The Location Generator is the party who initially
introduces location information into the Internet. The LG may be
(but need not be) the entity that performs the sighting of the
Target. The LG may be the same as the target when mechanisms such
as GPS are used, but in many settings the location generator is a
separate entity within the access network.
Viewer The Viewer is the party who ultimately makes use of the
location information; in particular, the Viewer does not transmit
location further. The Viewer is the Location Recipient in the
final location transmission.
Target The Target is the party whose location is described by the
location information. Although not explicitly included in the
model above, every LO has a Target, and the Target will frequently
play multiple roles in the distribution of related LOs.
It is common for a party to play different roles within the different
transmissions. For example, the Target might be the Location
Recipient during location configuration, then act as Location Server
when transmitting the LO to a presence server, then act as a Rule
Maker by providing the presence server rules for further
dissemination of the LO. In some cases, the Target may be a Location
Generator or a Viewer; obviously, we assume that the roles of the LG
and the Viewer are played by different entities.
3.3. Usage Scenarios for this Model
In order to make the meaning of the above model clearer, this section
desribes how several common use cases can be described using the
model. In addition, we describe how the transmission model described
in RFC 3693 maps into the model described above.
3.3.1. RFC 3693 model of transmission
Section 4 of RFC 3693 depicts the relationships of the primary
Geopriv entities, in which the Location Server acts as a relay
between a Location Generator and a Location Recipient, with rules
provided by a Rule Holder. In this document, we take a more limited
view of three of these roles: Here an Location Server is simply an
entity that transmits location (relying on a separate associated
Location Recipient for input), an Location Generator is simply a
distinguished Location Server, and Rule Holders are omitted from the
discussion because they simply act as intermediaries for Rule Makers.
The omission of Rule Holders is not meant to claim that Rule Holders
Barnes, et al. Expires May 22, 2008 [Page 8]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007
do not exist (for instance, RMs may transmit rules to the LS via a
store-and-forward network, in which the nodes would be RHs); however,
they do not have application-level significance.
In exchange for using these more limited roles, the single "T"-shaped
diagram of RFC 3693 maps onto a chain of two transmissions, as
illustrated in Figure 3 below. The first transmission is from the LG
(in this case, just another LS) to the LR that acts as the receiving
component of the Location Server (as defined in RFC 3693). The
second transmission is from the LS acting as the sending component of
the RFC 3693 Location Server to the LR, as dictated by rules supplied
by the RM. Note that in these transmissions, the role of the LM is
undefined; RFC 3693 starts from the assumption that the given
interfaces exist, without giving explicit consideration to how they
are established.
...... . ......
. LM . . . LM .
...... . ......
+-------------+
| LS |
+----+----+ | +----+----+ | +----+
| LG | LS |--->| LR | LS |--->| LR |
+----+----+ | +----+----+ | +----+
. +--------|----+
. . |
...... . +----+
. RM . . | RM |
...... . +----+
.
Figure 3: The model of RFC 3693, Section 4
3.3.2. Location configuration by "pull"
Location configuration protocols, such as HELD
[I.D-ietf-geopriv-http-location-delivery], that require a device to
specifically "pull" location can be modeled as a location
transmission as follows: The LIS discovery mechanism is the Location
Mover. The LIS discovery mechanism sends the endpoint the identity
of the LIS, e.g. the HELD server. (Note that in this case the
Location Mover need not send the identity of the location information
to the endpoint, because the identity of the location information is
implicit in the identity of the endpoint.) The endpoint is the
Location Recipient and also the Target. Upon receiving the identity
of the LIS, the endpoint makes an LCP query to the LIS requesting
location. The LIS is the Location Server and in this case has
previously been provisioned with rules by the Rule Maker. The LIS
applies the rules and returns a location object to the endpoint.
Barnes, et al. Expires May 22, 2008 [Page 9]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007
3.3.3. Location configuration by "push"
Location configuration protocols, such as DHCP, that push location
information to the endpoint can be modeled as a location transmission
as follows. The network (i.e. a lower layer protocol) tells the LIS,
e.g. the DHCP server, that an endpoint has connected to the network
and provides the LIS with an identifier for the endpoint. (Note that
again in this case the identity of the endpoint is implicitly the
identity of the location information.) The LIS is the Location
Server and in this case has previously been provision with rules by
the Rule Maker. The endpoint is the Location Recipient and also the
target. Upon learning the identity of the endpoint the LIS then
sends the location information to the endpoint.
3.3.4. Location conveyance by value
A protocol, such as SIP, that conveys a location object by value can
be modeled as a location transmission as follows. The calling device
is both the Location Mover and the Location Server. The calling
device possesses a location object that contains the rules governing
the location information. The called device is the Location
Recipient. The calling device applies the rules within the location
object and then sends the location object to the called device (e.g.
in the body of a SIP INVITE).
3.3.5. Location conveyance by reference
A protocol, such as SIP, that conveys a location object by reference
can be modeled as a location transmission as follows. The calling
device is the Location Mover and possesses a reference to location
information stored on an LIS. The calling device sends the location
reference, containing both the identity of the LIS and the identity
of the location information, to the called party (e.g. in the header
of a SIP INVITE). The called party is the Location Recipient. Upon
receiving the location reference, the called party sends a
dereference request, containing the identity of the location
information, to the LIS. The LIS is the Location Server, and has
been previously provisioned with rules by the Rule Maker. The LIS
applies the appropriate rules for the location information and
returns a location object to the called party.
3.3.6. Presence server
The subscription to location information on a presence server can be
modeled as a location transmission as follows. The presence
subscriber is the Location Mover and also the Location Recipient.
Through some out of band mechanism (e.g. a business card) the
presence subscriber learns the identity of a presence server and the
Barnes, et al. Expires May 22, 2008 [Page 10]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007
identity of a target whose presence is stored on the server. The
presence subscriber sends a subscription request, containing the
identity of the target, to the presence server. The presence server
has previously been provisioned with rules by the Rule Maker (in this
case, most likely the target). The presence server applies the rules
and constructs a location object which it then sends to the presence
subscriber.
4. Required Assurances
Each of the entities in the above model has expectations about how
the system works, which may or may not be valid in a given situation.
Depending on the needs of the entities, they may require assurances
that their expectations are valid in a given situation. The goal of
Geopriv security and privacy mechanisms is to provide such
assurances. In order to determine requirements for Geopriv security
mechanisms, then, we need to understand the assurances required by
participants in the architecture.
4.1. Location Transmission
As described above, there are generally four logical roles in a
single location transmission. In some cases, the same entity may
play multiple roles within a transmission. In that case, the set of
assurances required by that entity is the union of the assurances
required by the roles it fulfills.
4.1.1. Location Mover
The goal of the Location Mover is to effect the communication of an
LO from the Location Server to the Location Recipient. Conversely,
the LM may not wish to disclose other LOs, or to disclose any
information to other recipients. Because the LM does not perform the
transmission himself, he cannot receive direct assurances about these
questions; he must trust the LS and the LR to carry out his
instructions. Thus, the only direct assurance of value to the LM is
that his instructions are faithfully communicated to their recipient
(the LS or the LR), and that those instructions unambiguously direct
the recipient to perform the action desired by the LM (including the
application of appropriate security measures on the transmission).
In the "push" scenario, the instructions provided to the LS must
clearly identify the LR, and in the "pull" scenario, the instructions
provided to the LR must clearly identify LS. In both cases, the
instructions must clearly identify the LO to be transmitted and the
manner in which it should be sent. Not all of these indications need
to be explicit in the instructions; for instance, an LS that only
distributes location via HTTPS does not need to be instructed to use
Barnes, et al. Expires May 22, 2008 [Page 11]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007
HTTPS for every transmission.
4.1.2. Rule Maker
The goal of the Rule Maker is tell the LS policies to apply to
transmissions, and to ensure that the rules clearly specify how the
LS should execute them. The first assurance of relevance to the RM
is to assure that rules are faithfully transmitted to the correct
destination: Since policy documents can themselves be sensitive, the
RM must verify that they are delivered only to the LS it intends,
i.e., it must authenticate the identity of the LS and verify that the
authenticated identity belongs to the desired LS. And since changes
to a policy document can affect many subsequent transmissions, the RM
requires assurance that rules are not modified en route to the LS.
Second, in order to assure that policy is correctly executed, the
transmitted rules must define an unambiguous mapping from LOs to
actions that the LS must perform. The RM is further assured that the
rules will be executed when the LS can provide confirmation that it
is able to process the supplied rules at the time that the RM
transmits them.
4.1.3. Location Server
The goal of the Location Server is to transmit location in compliance
with relevant policy. Thus, the primary assurances the LS requires
are related to the question of whether a given transmission is
authorized by policy. The LS must determine whether the LR is
authorized to receive location; when a transmission is by "push", it
must also determine whether the LM is authorized to initiate a
transmission. As a pre-requisite, the LS must also verify that
policy is valid, i.e., that the Rule Maker is authorized to dictate
policy. All of these authorization decisions require that the server
authenticate the identities of the parties requesting access (e.g.,
to move or receive location, or to install policy). Note that the
manner in which these authorization policies are installed on the LS
and applied to specific transmissions is a matter of local
configuration.
4.1.4. Location Recipient
The goal of the Location Recipient is to acquire the LO intended by
the LM. In general, this assurance can be decomposed into assuring
that the LS is the one intended to deliver the LO and that the LO is
faithfully transmitted from the LM to the LR; the LS is trusted by
the LR to deliver the LO specified by the LM. In the "push" case,
the LR may not have information about the LS prior to the
transmission, so it must also trust that the LS delivering location
was properly instructed to do so. In the "pull" scenario, the LM has
Barnes, et al. Expires May 22, 2008 [Page 12]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007
told the LR which LS should be delivering the LO, so the LR can be
assured that the LS that does transmit location is the proper one by
authenticating the identity of the LS. In both cases, the LR
requires assurance that the LO is not modified while en route between
the LS and the LR.
4.2. End-to-end distribution
In addition to the four transmission entities described above, we
also consider three distinguished entities in an end-to-end
distribution scenario. They require assurances about the entire
distribution chain, or the entire distribution tree.
4.2.1. Location Generator
The Location Generator is the Location Server at the root of the
distribution tree. The LG thus offers the valuable service of acting
as an Internet-accessible source of location information, and its
primary interest is in controlling the use of this service,
especially controlling access to it. In terms of the model, the LG
is interested in controlling the set of Viewers that are able to
interpret and use the LO. There are two basic approaches to
acheiving this control: First, the LG may distribute LOs that are
encrypted in such a way that only the Viewers that are authorized to
access the location encoded in the LO. Second, the LG may distribute
LOs in indirect representation, i.e., location references. Because
these references are not valuable by themselves, the LG can give
allow them to be distributed by parties that may not be authorized to
access the location they refer to. In order for the Viewer to obtain
the location referred to, it has to engage in a final transmission,
in which the LG is the LS; as part of this transmission, the LG can
verify that the Viewer is authorized to receive the location.
4.2.2. Viewer
The Viewer is the ultimate consumer of a Location Object. As a
consumer, the Viewer requires assurance that location information is
available to it by value, and that that information be correct, in
the sense that the location information describes the actual location
of the indicated entity at the indicated time. (In some cases, the
entity and time may be implicit). Viewers' access to location
information by value is largely a deployment issue, related to
Viewers' ability to provide authentication credentials to Location
Servers, and to Location Servers' authorization policies. In most
situations, it is not possible to verify the correctness of location
directly. Rather, a Viewer can receive assurance that a location is
correct by virtue of trust in the source of the location information.
That is, Viewer can have more confidence in the correctness of an LO
Barnes, et al. Expires May 22, 2008 [Page 13]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007
when it can verify that the location was provided by a source that
the it trusts to provide correct location. As with LG access
control, this verification can be done either through the object or
through the LS that provides it. If the LO itself provides a
verifiable assertion as to its origin, then the Viewer receives
assurance about its correctness even if it receives the LO via an
untrusted channel. On the other hand, if the LS that provides the LO
is trusted to provide correct location, then the Viewer receives
assurance about the LO's correctness even if the ultimate origin of
the LO (i.e., the LG) remains unknown to the Viewer.
4.2.3. Target
The interests of the Target are discussed at length in RFC 3693 and
RFC 3694. The Target by itself has no technical involvement in the
distribution process; in order to affect how its location is
distributed, it must take on one of the roles described above. For
instance, the Target will commonly act as an LS to explicitly control
how location is transmitted, or as a Rule Maker to control
distribution by a third-party LS. Much like the LG, the main concern
of the Target is controlling access to its location. If the Target
acts as an LS, then the assurances and mechanisms available to it are
essentially the same as those available to the LG.
5. Security Requirements
[RLB] In this section, we will define a taxonomy of location-relevant
protocols, and set security requirements on them. As for the
taxonomy, I tend to classify protocols according to which arrow they
correspond to in Figure 1:
o Policy Handling Protocols go between RMs and LSs (e.g., XCAP,
common-policy)
o Location Control Protocols go between the LM and the LS/LR (to
many to list, we probably can't do much here)
o Location Conveyance Protocols go between the LS and the LR (e.g.,
SIP Geolocation, HELD, Location dereference protocols)
6. Security Considerations
The focus of this document is the security of location objects. As
such, security concerns are discussed throughout.
Barnes, et al. Expires May 22, 2008 [Page 14]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007
7. IANA Considerations
This document makes no request of IANA.
8. Informative References
[I.D-ietf-ecrit-framework]
Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling using Internet
Multimedia", September 2007.
[I.D-ietf-geopriv-http-location-delivery]
Barnes, M., "HTTP Enabled Location Delivery",
September 2007.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", February 2004.
[RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson,
"Threat Analysis of the Geopriv Protocol", February 2004.
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based
Location Configuration Information", July 2004.
[RFC4119] Peterson, J., "A Presence-based Geopriv Location Object
Format", December 2005.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", November 2006.
Authors' Addresses
Richard Barnes
BBN Technologies
9861 Broken Land Pkwy, Suite 400
Columbia, MD 21046
USA
Phone: +1 410 290 6169
Email: rbarnes@bbn.com
Barnes, et al. Expires May 22, 2008 [Page 15]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007
Matt Lepinski
BBN Technologies
10 Moulton St
Cambridge, MA 02138
USA
Phone: +1 617 873 5939
Email: mlepinski@bbn.com
Hannes Tschofenig
Nokia Siemens Networks
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Barnes, et al. Expires May 22, 2008 [Page 16]
Internet-Draft draft-barnes-geopriv-lo-sec-01 November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Barnes, et al. Expires May 22, 2008 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-22 16:56:09 |