One document matched: draft-barnes-geopriv-secure-location-object-00.txt
Network Working Group R. Barnes
Internet-Draft M. Lepinski
Intended status: Informational R. Watro
Expires: April 27, 2007 BBN Technologies
October 24, 2006
Secure Location Objects
draft-barnes-geopriv-secure-location-object-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 27, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Protection of location information is an essential requirement of the
GEOPRIV architecture. Since using protocols cannot be relied upon to
provide adequate protections to the location objects they carry, the
location objects themselves must be secured. This document examines
several candidates for a Secure Location Object format in the context
of GEOPRIV and ECRIT security requirements, including both locations
by value and by reference.
Barnes, et al. Expires April 27, 2007 [Page 1]
Internet-Draft Secure Location Objects October 2006
Requirements Language
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 RFC 2119 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Security Threats . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Disclosure of Location Information . . . . . . . . . . . . 4
2.2. Use of Fake Location Information . . . . . . . . . . . . . 4
2.3. Denial of Location-based Services . . . . . . . . . . . . 5
3. Design Considerations . . . . . . . . . . . . . . . . . . . . 6
3.1. Integration with LoST . . . . . . . . . . . . . . . . . . 6
3.2. GEOPRIV Considerations . . . . . . . . . . . . . . . . . . 7
3.3. ECRIT Considerations . . . . . . . . . . . . . . . . . . . 7
3.4. Technical Considerations . . . . . . . . . . . . . . . . . 7
4. Candidate Secure Location Object Formats . . . . . . . . . . . 7
4.1. Location By Value . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Signed Location . . . . . . . . . . . . . . . . . . . 8
4.1.2. Encrypted Location . . . . . . . . . . . . . . . . . . 9
4.2. Location By Reference . . . . . . . . . . . . . . . . . . 11
4.3. Trust Models . . . . . . . . . . . . . . . . . . . . . . . 12
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Barnes, et al. Expires April 27, 2007 [Page 2]
Internet-Draft Secure Location Objects October 2006
1. Introduction
The security of location objects as they are stored and transmitted
over the Internet is an essential enabler of the GEOPRIV
architecture. Without the ability to guarantee the confidentiality
of transmitted location information, an eavesdropper can circumvent
GEOPRIV privacy rules; without authenticity and integrity, a third
party can forge location information and degrade the reliability of
the entire architecture. Even though such security guarantees may at
times need to be relaxed -- for instance, in an emergency calling --
it is essential that the components of the GEOPRIV architecture make
available a suite of security services.
The fundamental unit of location information in the GEOPRIV
architecture is the Location Object (LO): Location Objects are
constructed by Location Generators; stored, transformed, and
forwarded by Location Servers; and consumed by Location Recipients.
In practice, these different entities are often under separate
administrative domains, joined by various relationships and separated
by diverse networks. The sensitive location information contained in
these LOs is thus stored and transmitted in a wide variety of
circumstances, and faces the risk of unauthorized access at several
points, even in the presence of privacy rules.
While the GEOPRIV architecture does make certain requirements of
"using protocols" -- protocols that read or modify LI -- it
explicitly makes no specifications with regard to protocols used only
for transport of LOs. There are several transport mechanisms
currently defined for conveying LOs from one point to another:
Extensions have been defined for SIP, DHCP, and RADIUS, and others
are being developed. Of these, only SIP has any claim of secure
transport, and even the mechanisms that SIP offers are either seldom
implemented (S/MIME) or widely regarded as ineffective (SIPS).
The security of LOs used in GEOPRIV thus cannot rely on the security
of the underlying transport, but must instead by enforced by security
features inherent in the location object itself. We call location
objects with such features Secure Location Objects, or SLOs. Below,
we summarize the threats to location information that have been
identified by the ECRIT and GEOPRIV working groups to date, identify
some additional design constraints that must be taken into account by
an SLO design, and examine the feasibility of several possible SLO
formats in light of these conditions.
2. Security Threats
Prior work by both the ECRIT and GEOPRIV working groups has
Barnes, et al. Expires April 27, 2007 [Page 3]
Internet-Draft Secure Location Objects October 2006
identified a set of risks facing location information, which are
summarized here as the risks of unauthorized disclosure, forgery, and
denial of location-based services. While these risks have special
importance in the context of emergency calling, they apply broadly to
the GEOPRIV architecture as a whole.
2.1. Disclosure of Location Information
The most immediate threat to location information is the disclosure
of sensitive location information to unauthorized parties. In
particular, this allows an eavesdropper to circumvent any privacy
rules that are supposed to govern the use of a LO. Such disclosure
could occur in either of the following ways:
o An attacker located on the path of communication to a legitimate
location recipient may intercept a LO and extract sensitive
location information. For example, an attacker could be a
compromised router on the public internet who scans incoming
packets for insecure LOs. Alternatively, such an attacker could
be a compromised proxy server for some location-using protocol
such as SIP
o An attacker may impersonate a legitimate location recipient in
order to obtain a LO from location server. For example, an
attacker could attack the LoST service to cause legitimate users
to send LOs to an attacker-controlled URI. Alternatively, an
attacker could supply forged credentials to a location server to
request a LO stored on the server.
This threat is discussed in [Geopriv-Threats], Section 4.1.1 as well
as [Geopriv-L7], Section 10.2. In the setting of emergency services,
this threat is especially pertinent because the requester of
emergency services is often in a vulnerable position and hence
location information is particularly sensitive. For example, a
motorist injured in an accident on a deserted highway is an easy
target for robbery. The disclosure of location information in the
event of an emergency is discussed in Security Threats and
Requirements for Emergency Call Marking and Mapping [Ecrit-Threats]
Section 5.2.3.
2.2. Use of Fake Location Information
A second threat to location information is the ability of an attacker
to create LOs that contain false location information, i.e., a
location that does not correspond to a target's true location. There
are several scenarios in which this might be accomplished:
Barnes, et al. Expires April 27, 2007 [Page 4]
Internet-Draft Secure Location Objects October 2006
o An attacker could replay location information corresponding to the
attacker's true location at an earlier point in time. For
example, an attacker who visits New York City in January could
obtain a legitimate LO indicating his location in New York. The
attacker could then use this previously obtained LO to claim he is
in New York the following summer.
o An attacker could replay location information corresponding to
another target's location at an earlier point in time. For
example, an attacker who has never been to New York City may
obtain a legitimate LO that indicates that Alice is in New York
City. The attacker could then later use this LO to claim that he
is in New York. Note that this attack may or not require the
attacker to be able to extract information from the LO.
o An attacker could from scratch generate a forged LO corresponding
to an arbitrary location. For example, an attacker could forge a
LO indicating that he is in New York City. The attacker could
then pass this LO off as legitimate and claim he is in New York
even though he doesn't know of anyone who has been there.
An extensive discussion of this threat appears in [Geopriv-L7],
Section 8. The threat is also discussed in also discussed in
[Geopriv-Threats] Section 4.1.2. In the setting of emergency
services, this threat is especially pertinent because fake location
information can be used to force scarce emergency-response resources
to be improperly allocated. For example, in the event of a disaster,
when the demand for emergency services exceeds supply, an attacker
using a fake location could cause an ambulance to be sent to a
location where no one is present. Even worse, an attacker could
generate huge numbers of emergency phone calls from all over the
world that all claim to be from a particular city. Such an attack
could easily overwhelm the public safety access point and deny
emergency services to legitimate residents of the city. The use of
fake location information as it pertains to emergency services is
discussed briefly in [Ecrit-Threats] Section 5.2.3.
2.3. Denial of Location-based Services
In a similar vein, an attacker could deny location-based services to
an individual with legitimate need for these services. In the
current, unsecured architecture, this could occur in several ways:
o As discussed in Section 2.2, an attacker can deny access to
location-based services by using forged location information to
overwhelm location-based services for a particular location.
Barnes, et al. Expires April 27, 2007 [Page 5]
Internet-Draft Secure Location Objects October 2006
o An attacker could alter a location object to indicate an incorrect
location of a target. For example, when a legitimate user
attempts to access a location-based service, an attacker on the
path of communication may alter the location object to cause the
request to be routed to the wrong service provider.
o An attacker could prevent a location recipient from obtaining a
location information. For example, an attacker might prevent a
service provider from dereferencing a reference to a location
object making it difficult for the user to receive location-
appropriate services.
This threat is discussed in the context of emergency services in
[Ecrit-Threats] Section 5.2.2, but is equally applicable to other
uses of the GEOPRIV architecture.
3. Design Considerations
In addition to the security objectives discussed in Section 2 above,
there are several other constraints on the design of SLOs. In
general, use of SLOs must be compatible with other GEOPRIV and ECRIT
protocols and architectures, with minimal modifications to either.
One particular issue that is likely to arise is that in several
possible SLO designs, the user (e.g., a UAC in the SIP model) may not
have access to his own location (by value).
3.1. Integration with LoST
Currently, many of the proposed use cases for the Location-to-Service
Translation Protocol (LoST [LoST]) assume that the UAC has access to
its own location. For instance:
o As currently defined, a LoST query includes the location of the
target in GML. In the case that the UAC is both the target of the
query and the originator of the query, this means that the UAC
must have access to its own location.
o LoST responses typically contain a service boundary so that a UAC
can determine when it has left the region in which its current
PSAP URI is valid, and thus must query the LoST server again.
Such a boundary is useful only if the UAC is aware of its own
location.
A security architecture in which a UAC may not know its own location,
may necessitate revisions to the way that LoST is used. For
instance, access networks or VoIP providers may need to provide LoST
proxies that have access to location information.
Barnes, et al. Expires April 27, 2007 [Page 6]
Internet-Draft Secure Location Objects October 2006
3.2. GEOPRIV Considerations
It is as yet unclear which communications in the GEOPRIV architecture
can or should make use of SLOs when exchanging location data. The
areas of application likely will be determined by the number of each
GEOPRIV entity and the contractual, regulatory, or other trust
relationships among them; these considerations also will affect the
trust model underlying a SLO design. In addition, the functions
required of each entity in the GEOPRIV architecture will dictate
certain levels of access, and SLOs must accommodate these
requirements. For instance, since the GEOPRIV architecture specifies
that privacy rules are applied by a Location Server, use of SLOs must
not preclude the Location Server from having sufficient knowledge of
location information to apply these rules.
3.3. ECRIT Considerations
A critical usage of GEOPRIV location objects is in emergency
services, both for routing emergency calls to the correct PSAP and
for directing emergency services to the location of the emergency.
In such situations, it is essential that all relevant location
information be available to all emergency responders that require it.
When adding confidentiality features to a location object, therefore,
appropriate failover mechanisms must be available.
3.4. Technical Considerations
User devices that are expected to handle location objects are
becoming increasingly mobile. In the context of SIP, this will be
especially true as SIP is applied within cellular wireless networks.
In order to facilitate the use of SLOs by these devices, an SLO
design should be adaptable for use in an environment where there are
constraints on both the processing power and bandwidth available to
user devices. SLOs are generally amenable to such environments,
since they require no cryptographic operations to be performed in
order to store or transmit them securely, and, at least when
expressed as locations by reference, can consume very little
bandwidth and storage space.
4. Candidate Secure Location Object Formats
Following the convention of SIP Location Conveyance [SIPLocation], we
broadly divide the category of SLOs (objects that can be transmitted
while still maintaining certain security properties) into those based
on location by value and those based on location by reference. We
then discuss candidate SLOs in both categories and discuss the
properties of a trust model relied upon by any SLO. Note, however,
Barnes, et al. Expires April 27, 2007 [Page 7]
Internet-Draft Secure Location Objects October 2006
that in spite of this division, these two types of SLO can be
naturally combined, for instance multi-layer access control could be
achieved by using a secured location reference to refer to a secured
location value.
4.1. Location By Value
Conveyance of location by value is the act of transmitting an entire
LO, rather than a reference to it. Security properties can be added
to such a location object by either signing the location object,
encrypting it, or both, using a technology such as S/MIME or XMLDsig.
Each type of object -- signed, encrypted, or both -- has a different
set of security properties, discussed below.
Although we separately discuss the signing and encrypting of LOs, it
is natural to consider combining the two approaches. This raises the
question of whether a LO should be first signed and then encrypted,
or vice-versa. We therefore briefly discuss the advantages of both
approaches.
o In settings where denial of service attacks are likely, signing an
already encrypted LO is advantageous because a recipient of such
LOs can quickly discard LOs with invalid signatures without
needing to spend resources decrypting the object. Additionally,
in settings where some fields of the LO should be encrypted and
other fields should be left unencrypted, it is advantageous to
sign the entire LO after the private fields have been encrypted.
o The use of objects that are first signed and then encrypted
requires less work on the part of the location producer. Indeed,
a location producer may produce a single signed object which can
then be encrypted, by a separate party, for delivery to multiple
recipients. Similarly, the recipient of such an LO can re-encrypt
the signed object for delivery to a new recipient without the
involvement of the location producer. Additionally, in settings
where different portions of an LO should be signed by different
entities, it is advantageous to first sign and then encrypt the
LO.
4.1.1. Signed Location
A "signed location" SLO consists of a LO together with a signature of
some or all of the LO by a recognized authority, likely a Location
Server or Location Generator. Use of a signed location SLO has the
following security implications:
o Perhaps most importantly, use of a signed location SLO mitigates
all of the threats in Section 2.2 arising from the use of forged
Barnes, et al. Expires April 27, 2007 [Page 8]
Internet-Draft Secure Location Objects October 2006
location information. An attacker who is not an authorized signer
in the underlying trust model is unable to create fake location
objects. In particular, this prevents an attacker from claiming
he is at a distant location. Additionally, if a timestamp is
included in the signed object, an attacker cannot replay a
previously obtained location object (either his own or someone
else's).
o Use of a signed location SLO partially mitigates the threats in
Section 2.3 regarding denial of service. An attacker on the
communication path between a user and a location-based service
provider cannot alter the location object in transit to make it
appear that the user is at a distant location. Obviously, certain
attackers on the communication path can always deny service to an
individual by dropping the individual's request. However, an
attack that drops the entire request is simpler to detect and
respond to an attack that alters the location, since when a
request is dropped the user finds out immediately (as soon as the
time-out fails) but if a location is altered it is unclear how
long it will take to determine that a problem has occurred.
Naturally, the security properties granted by use of signed location
SLOs fundamentally rely on a suitable trust model; as discussed in
section 4.3, development of this trust model is a nontrivial but
tractable problem. In order for signed location to be useful, it
must be difficult for an attacker to compromise an authorized signer
of location information. When signed location SLOs are used, it is
the responsibility of the using protocol to take appropriate action
when the signature fails to verify. For example, in most cases, a
signed SLO with an invalid signature might be discarded altogether,
but in the special case of emergency services, a call with a location
signature that fails to verify might be answered but given lower
priority than calls with valid SLOs.
4.1.2. Encrypted Location
An "encrypted location" SLO is a LO encrypted in such a way that it
is readable only by its intended recipient(s). Use of an encrypted
location SLO has the following security implications:
o Use of an encrypted location SLO mitigates all of the threats in
Section 2.1 arising from improper disclosure of location
information. Unless the attacker is able to compromise the secret
decryption key of the intended location recipient, it is
infeasible for him to extract information from any encrypted
location SLO he might obtain. Therefore, even if the attacker is
able, for example, to compromise a proxy on the communication path
to a location recipient the sensitive location information
Barnes, et al. Expires April 27, 2007 [Page 9]
Internet-Draft Secure Location Objects October 2006
contained in the SLO remains private.
o Use of an encrypted location SLO only partially mitigates the
threats in Section 2.2 regarding forgery of location information.
Depending on the key distribution architecture, it may be possible
for an attacker to obtain the encryption key of a legitimate
location recipient and forge an encrypted location SLO. Of
course, these threats can be mitigated (as described in Section
4.1.1) by combining signing and encrypting of location objects.
On the other hand, because an eavesdropper does not have access to
the information contained in an encrypted location SLO, it is very
difficult for him to modify the location in transit.
o Use of an encrypted location SLO can pose additional risks
regarding the denial of service threats discussed in Section 2.3.
In particular, use of an encrypted location SLO introduces the
possibility that a user is denied a service because the service
provider cannot decrypt the SLO to extract LI. This could occur
because of a key-management error, or because of an attack on the
mechanism used to distribute public keys.
The use of encrypted location SLOs relies fundamentally on a reliable
mechanism to distribute the keys belonging to legitimate service
providers; the difficulty of this task will derive from the
underlying trust model. In the context of emergency services, for
example, one might use the LoST protocol to return a certificate for
a PSAP in addition to the PSAP's URI. This reduces the incremental
risk of using encryption, since an attacker who is able to use LoST
to distribute incorrect public keys can surely disrupt emergency
services in other ways.
One often-mentioned advantage of location-by-reference is that the
required dereference operation creates an opportunity for location
providers to enforce a scheme in which the party dereferencing the
URL pays the provider for the location. A secondary advantage of
encrypted location SLOs is that they can be used to extend this model
to location by value: The encrypted location object can be
transmitted to the location recipient, but encrypted in such a way
that the SLO cannot be used by the recipient until he performs a
second decryption or key exchange transaction with the location
provider. However, just as the by-reference payment scheme is viable
only if a user cannot dereference a URL to obtain his own location,
this model forces a transaction only if a user cannot decrypt an
encrypted location SLO containing his location. While this may force
some adaptation of existing protocols (as discussed in Section 3), it
seems that use of encrypted location SLOs for this purpose is still
consistent with broader usage. For example, LoST servers could be
operated by entities that maintain business relationships with
Barnes, et al. Expires April 27, 2007 [Page 10]
Internet-Draft Secure Location Objects October 2006
location providers, so that encrypted location SLOs included in LoST
queries could be decrypted.
4.2. Location By Reference
Conveyance of location by reference is the act of transmitting not an
object containing LI, but rather a URL (or other pointer) that can be
dereferenced to obtain a LO. Location URLs have several important
security implications:
o Perhaps most importantly, use of location by reference forces a
location recipient to conduct a separate transaction in order to
obtain the desired LI, which has the effect of allowing any
security decisions to be delayed until the time when a location
URL is dereferenced. This property allows much more complicated
security and privacy policies to be enforced at the location
server (such as rules about location expiration and
retransmission), rather than delegating trust to using protocols.
At the same time, however, it also lends itself very naturally to
failover, since the location server can make a decision to grant
access to parties that can demonstrate a need and authority for
access, such as emergency service providers.
o Because a location URL references a resource held by a third party
(commonly, a location server), not by the location target or
location recipient, location references cannot be constructed by a
user, but rather must be obtained from an location server. This
yields very powerful anti-forgery (hence anti-spam) properties,
since a user cannot forge a location URL that references LI
indicating that he is elsewhere than he is, and likewise, a third
party (e.g., a man in the middle) cannot modify a URL to deny
location-based services.
We call a location reference that employs one or more security
protocols in its dereference a secured location reference. Any
security protocols used in conjunction with location references will
be reliant on a suitable trust model; as discussed in section 4.3,
development of this trust model seems to be a nontrivial, but
tractable problem. In order for secured location references to be
suitable for use in emergency services, the dereferencing protocol
and any security protocols employed between the recipient and the
location server must be made sufficiently reliable for use in an
emergency. As is the case with normal, unsecured location
references, the most significant risk is introduced by the
dereferencing protocol, since the location server is capable of
granting access to LI independent of security policies and protocols.
Barnes, et al. Expires April 27, 2007 [Page 11]
Internet-Draft Secure Location Objects October 2006
4.3. Trust Models
Any SLO system will be based on an underlying trust model. The
structure of this model deeply influences the nature of the security
guarantees that the SLO system can provide. Such guarantees include:
o Authentication of location recipients: Use of SLOs offers another
mechanism for authenticating identities referenced by privacy
rules. Using secure location by value, objects can be encrypted
for a specific recipient, and using secure location by reference,
a location server can interpret a cryptographic credential to
grant or deny access to specific recipients. In particular,
emergency service providers could be unambiguously identified by
their credentials to be assured access to the LI they require.
o Authentication and integrity of location information: In the PSTN,
location information is provided by wireline or wireless
operators, and thus assumed by all using parties to be reliable.
Use of location signing in secure location objects provides a
mechanism to translate these assurances to IP-based telephony and
other location-based Internet services.
o Non-repudiation of location information: By the same token as
above, the current PSTN architecture allows failures of the
location architecture to be clearly attributed to the provider of
faulty LI, for purposes of determining regulatory or civil
liability. For location-based services over IP, particularly
emergency services, this is an important function that can be
enabled by secure location objects.
These features require the identification and issuance of credentials
for two classes of entities: Location producers and location
consumers. The case of location consumers seems to be the simpler,
if we envision two major use cases, (1) emergency services calling,
and (2) client-server style location-based services. In the former
case, the set of PSAPs and emergency service providers is small and
stable enough to be manageable. In some cases, even further
simplification will be possible: In the NENA i3 architecture, for
example, one might need to manage credentials only for gateways
between emergency services networks and the Internet. For other
client-server location-based services, there are several current
trust models that could be adapted, such as the broad, flat PKI model
used by HTTPS or the more flexible model used in DNSSEC.
Constructing a system for authenticating location producers is more
difficult. For example, an organization that administers a corporate
network of SIP-based desk phones might provision these phones with
fine-grained location information, such as their floor and room
Barnes, et al. Expires April 27, 2007 [Page 12]
Internet-Draft Secure Location Objects October 2006
number. By some calculations [ref:Henning], in New York City alone
there are thousands of organizations that might be expected to do
become location producers in this way, several of which appear and
disappear each day. On the other hand, such location producers need
only be included in a trust model if the goal of this trust model is
to provide guarantees stronger than are offered by the PSTN. An
initial capability to provide PSTN-equivalent security would require
only the inclusion of telecommunications and internet service
providers; construction of a PKI on the scale of the former is
already being under taken by the SIDR working group and the Regional
Internet Registries. In addition, many VoIP providers currently
outsource location determination functions to other entities, which
further consolidates the set of location producers. Note also that
although we have treated here the specific example of location for
VoIP, the same access networks that provide location for these
services will be used to access other location-based services, so a
trust model for location producers in a VoIP setting would be
extensible to a model for more general location-based services.
5. Conclusions
The purpose of this document is to start a discussion about the
requirements of GEOPRIV and ECRIT for security in location objects.
Clearly, it is tempting to push responsibility for security onto the
protocols that carry LOs and the using protocols that process them.
Currently, however, these protocols are unable to provide the end-to-
end security guarantees necessary to mitigate threats to the privacy
of location information and the integrity of location-based services.
Without securing the location object itself, entities that generate
LOs have no assurances that the LOs will not be misused, and critical
applications such as emergency services have no assurances that the
LOs they receive have not been forged or otherwise tampered with.
In this document, we considered three approaches to securing LOs.
Signing a location object can prevent forgery and mitigate resulting
denial of service attacks. Encrypting location objects can prevent
the improper disclosure of location information, but encryption
results in an opaque location object that may require adaptation of
using protocols. Using location by reference in conjunction with a
secure dereferencing transaction can prevent both forgery and
improper disclosure of location information. However, obtaining
location information from a location-by-reference object requires an
additional transaction that could introduce additional risk in time-
critical applications such as emergency services. Naturally, these
techniques for securing location objects can be combined to obtain
stronger security guarantees or increased robustness. For example, a
location reference could be appended to a signed and encrypted
Barnes, et al. Expires April 27, 2007 [Page 13]
Internet-Draft Secure Location Objects October 2006
location object to obtain the security guarantees of location-by-
reference and yet require a separate de-referencing transaction only
in the event that decryption fails. Achieving security through any
of these mechanisms will require an appropriate trust model.
6. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
7. Security Considerations
The focus of this document is security; hence security considerations
permeate this specification.
8. Acknowledgements
9. References
9.1. Normative References
[RFC2119] "", 2005.
9.2. Informative References
[Ecrit-Threats]
Nortel, Siemens, Columbia University, and Siemens,
"Security Threats and Requirements for Emergency Call
Marking and Mapping", July 2006.
[Geopriv-L7]
Siemens Networks and Columbia University, "Geopriv Layer 7
Location Configuration Protocol; Problem Statement and
Requirements", October 2006.
[Geopriv-Threats]
Technology and Public Policy Clinic, Technology and Public
Policy Clinic, Center for Democracy and Technology, and
NeuStar, "Threat Analysis of the Geopriv Protocol",
February 2004.
[LoST] Qualcomm, Inc., SunRocket, Columbia University, and
Barnes, et al. Expires April 27, 2007 [Page 14]
Internet-Draft Secure Location Objects October 2006
Siemens, "LoST: A Location-to-Service Translation
Protocol", September 2006.
[RFC3693] Siemens AG, Center for Democracy and Technology,
Technology and Public Policy Clinic, NeuStar, and Cisco,
"Geopriv Requirements", February 2004.
[SIPLocation]
Qualcomm, Inc. and SunRocket, "Session Initiation Protocol
Location Conveyance", October 2006.
Authors' Addresses
Richard Barnes
BBN Technologies
9861 Broken Land Pkwy
Columbia, Maryland 21046
USA
Phone: +1-410-290-6169
Email: rbarnes@bbn.com
Matt Lepinski
BBN Technologies
10 Moulton St.
Cambridge, Massachusetts 02138
USA
Phone: +1-617-873-5939
Email: mlepinsk@bbn.com
Ron Watro
BBN Technologies
10 Moulton St.
Cambridge, Massachusetts 02138
USA
Phone: +1-617-873-2551
Email: rwatro@bbn.com
Barnes, et al. Expires April 27, 2007 [Page 15]
Internet-Draft Secure Location Objects October 2006
Full 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.
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.
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 April 27, 2007 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 04:09:42 |