draft-ietf-ecrit-trustworthy-location-03.txt   draft-ietf-ecrit-trustworthy-location-04.txt 
ECRIT Working Group H. Tschofenig ECRIT Working Group H. Tschofenig
INTERNET-DRAFT Nokia Siemens Networks INTERNET-DRAFT Nokia Siemens Networks
Category: Informational H. Schulzrinne Category: Informational H. Schulzrinne
Expires: October 4, 2012 Columbia University Expires: April 22, 2013 Columbia University
B. Aboba (ed.) B. Aboba (ed.)
Microsoft Corporation Microsoft Corporation
4 April 2012 22 October 2012
Trustworthy Location Information Trustworthy Location
draft-ietf-ecrit-trustworthy-location-03.txt draft-ietf-ecrit-trustworthy-location-04.txt
Abstract Abstract
For some location-based applications, such as emergency calling or For some location-based applications, such as emergency calling or
roadside assistance, it is important to be able to determine whether roadside assistance, the trustworthiness of location information is
location information is trustworthy. critically important.
This document outlines potential threats to trustworthy location and This document describes the problem of "trustworthy location" as well
analyzes the operational issues with potential solutions. as potential solutions.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 4, 2012. This Internet-Draft will expire on April 22, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Emergency Services Architecture . . . . . . . . . . . . . . . 4
3. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 6 3.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 6
3.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 7 3.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 7
4. Solution Proposals . . . . . . . . . . . . . . . . . . . . . . 8 4. Solution Proposals . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Location Signing . . . . . . . . . . . . . . . . . . . . . 8 4.1. Location Signing . . . . . . . . . . . . . . . . . . . . . 8
4.2. Location by Reference . . . . . . . . . . . . . . . . . . 9 4.2. Location by Reference . . . . . . . . . . . . . . . . . . 10
4.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 11 4.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 11
5. Operational Considerations . . . . . . . . . . . . . . . . . . 11 5. Operational Considerations . . . . . . . . . . . . . . . . . . 12
5.1. Attribution to a Specific Trusted Source . . . . . . . . . 11 5.1. Attribution to a Specific Trusted Source . . . . . . . . . 12
5.2. Application to a Specific Point in Time . . . . . . . . . 16 5.2. Application to a Specific Point in Time . . . . . . . . . 16
5.3. Linkage to a Specific Endpoint . . . . . . . . . . . . . . 16 5.3. Linkage to a Specific Endpoint . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Informative references . . . . . . . . . . . . . . . . . . 18 9.1. Informative references . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The operation of a number of public and commercial services depend Several public and commercial services depend upon location
upon location information in their operations. Emergency services, information in their operations. This includes emergency services
such as fire department, ambulance and police, are among these, as (such as fire, ambulance and police) as well as commercial services
are commercial services such as food delivery and roadside such as food delivery and roadside assistance.
assistance.
Services that depend on accurate location commonly experience
security issues today. While prank calls have been a problem for
emergency services dating back to the time of street corner call
boxes, a recent increase in the frequency and sophistication of the
attacks has lead to the FBI issuing a warning [Swatting]. Since
prank emergency calls can endanger bystanders or emergency services
personnel, or divert resources away from legitimate emergencies, they
can be life threatening.
It should be kept in mind that issues of location trust and
attribution are closely linked. In situations where tracing of an
emergency call back to the originator is more difficult, experience
has shown that the frequency of nuisance calls can rise dramatically.
For example, where emergency calls have been allowed from handsets
lacking a SIM card, or where ownership of the SIM card cannot be
determined, the frequency of nuisance calls has often been
unacceptably high [TASMANIA][UK][SA].
Conversely, where the ability exists enable an investigator to
determine the originator of a prank emergency call after the fact,
the trustworthiness of location is likely to improve, even without
the introduction of measures to limit location spoofing. Under a
court order, an investigator can have access to additional
information beyond the messages conveyed in the emergency call. For
example, in such a situation, audit logs will often be made available
and in addition, information relating to the owner of an unlinked
pseudonym could be provided to investigators, enabling them to
unravel the chain of events that lead to the attack.
This document reviews the emergency services architecture in Section
2, investigates security threats in Section 3, and outlines potential
solutions in Section 4. Operational considerations are provided in
Section 5 and security considerations are discussed in Section 6.
1.1. 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].
This document uses terms from [RFC5012] Section 3.
2. Emergency Services Architecture
Users of the telephone network can summon emergency services such as Users of the telephone network can summon emergency services such as
ambulance, fire and police using a well-known emergency service ambulance, fire and police using a well-known emergency service
number (e.g., 9-1-1 in North America, 1-1-2 in Europe). Location number (e.g., 9-1-1 in North America, 1-1-2 in Europe). Location
information is used to route emergency calls to the appropriate information is used to route emergency calls to the appropriate
regional Public Safety Answering Point (PSAP) that serves the caller regional Public Safety Answering Point (PSAP) that serves the caller
to dispatch first-level responders to the emergency site. to dispatch first-level responders to the emergency site.
Physical security is often based on location. Light switches in
buildings are not typically protected by keycards or passwords, but
are only accessible to those within the perimeter of the building.
Merchants processing credit card payments already use location
information to estimate the risk that a transaction is fraudulent,
based on translation of the HTTP client's IP address to an estimated
location. In these cases, location information can be used to
augment identity or, in some cases, avoid the need for role-based
authorization.
For services that depend on the accuracy of location information in
their operation, the ability to determine the trustworthiness of
location information may be important. Prank calls have been a
problem for emergency services, dating back to the time of street
corner call boxes. Individual prank calls waste emergency services
and possibly endanger bystanders or emergency service personnel as
they rush to the reported scene of a fire or accident. However, a
recent increase in the frequency and sophistication of the attacks
has lead to the FBI issuing a warning [Swatting].
In situations where it is possible to place emergency calls without
accountability, experience has shown that the frequency of nuisance
calls can rise dramatically. For example, where emergency calls have
been allowed from handsets lacking a SIM card, or where ownership of
the SIM card cannot be determined, the frequency of nuisance calls
has often been unacceptably high [TASMANIA][UK][SA].
In emergency services deployments utilizing voice over IP, many of In emergency services deployments utilizing voice over IP, many of
the assumptions of the public switched telephone network (PSTN) and the assumptions of the Plain Old Telephone Service (POTS) and public
public land mobile network (PLMN) no longer hold. While the local land mobile network (PLMN) no longer hold. While both POTS and PLMN
telephone company provides both physical access and the phone service providers often both physical access as well as phone
service, with VoIP there is a split between the role of the Access service, with Voice over IP (VoIP) there is a split between the role
Infrastructure Provider (AIP), and the Application (Voice) Service of the Access Infrastructure Provider (AIP), and the Application
Provider (VSP). The VSP may be located far away from the AIP and may (Voice) Service Provider (VSP). The VSP may be located far away from
either have no business relationship with the AIP or may be a the AIP and may either have no business relationship with the AIP or
competitor. It is also likely that the VSP will have no relationship may be a competitor. It is also likely that the VSP will have no
with the PSAP. relationship with the PSAP.
In some situations it is possible for the end host to determine its In some situations it is possible for the end host to determine its
own location using technology such as the Global Positioning System own location using technology such as the Global Positioning System
(GPS). Where the end host cannot determine location on its own, (GPS). Where the end host cannot determine location on its own,
mechanisms have been standardized to make civic and geodetic location mechanisms have been standardized to make civic and geodetic location
available to the end host, including LLDP-MED [LLDP-MED], DHCP available to the end host, including LLDP-MED [LLDP-MED], DHCP
extensions [RFC4776][RFC6225], HELD [RFC5985], or link-layer extensions [RFC4776][RFC6225], HELD [RFC5985], or link-layer
specifications such as [IEEE-802.11y]. The server offering this specifications such as [IEEE-802.11y]. The server offering this
information is known as a Location Information Server (LIS). The LIS information is known as a Location Information Server (LIS). The LIS
may be deployed by an AIP, or it may be run by a Location Service may be deployed by an AIP, or it may be run by a Location Service
Provider (LSP) which may have no relationship with the AIP, the VSP Provider (LSP) which may have no relationship with the AIP, the VSP
or the PSAP. The location information is then provided, by reference or the PSAP. The location information, provided by reference or by
or value, to the service-providing entities, i.e. location value, is then conveyed to the service-providing entities, i.e.
recipients, via application protocols, such as HTTP, SIP or XMPP. location recipients, via application protocols, such as HTTP, SIP or
XMPP.
This document investigates security threats in Section 3, and
outlines potential solutions in Section 4. Operational
considerations are provided in Section 5 and security considerations
are discussed in Section 6.
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].
This document uses terms from [RFC5012] Section 3. Where the end host does not provide location, or is not trusted to do
so, it is possible for an intermediary to retrieve location
information on behalf of the endpoint.
3. Threats 3. Threats
This document focuses on threats deriving from the introduction of This section focuses on threats deriving from the introduction of
untrustworthy location information by end hosts, regardless of untrustworthy location information, regardless of whether this occurs
whether this occurs intentionally or unintentionally. intentionally or unintentionally.
In addition to threats arising from the intentional forging of In addition to threats arising from the intentional forging of
location information, end hosts may be induced to provide location information, end hosts may be induced to provide
untrustworthy location information. For example, end hosts may untrustworthy location information. For example, end hosts may
obtain location from civilian GPS, which is vulnerable to spoofing obtain location from civilian GPS, which is vulnerable to spoofing
[GPSCounter] or from third party Location Service Providers (LSPs) [GPSCounter] or from third party Location Service Providers (LSPs)
which may be vulnerable to attack or may not warrant the use of their which may be vulnerable to attack or may not warrant the use of their
services for emergency purposes. services for emergency purposes.
Emergency services have three finite resources subject to denial of Emergency services have three finite resources subject to denial of
skipping to change at page 12, line 10 skipping to change at page 12, line 31
5.1. Attribution to a Specific Trusted Source 5.1. Attribution to a Specific Trusted Source
[NENA-i2] Section 3.7 describes some of the aspects of attribution as [NENA-i2] Section 3.7 describes some of the aspects of attribution as
follows: follows:
The i2 solution proposes a Location Information Server (LIS) be The i2 solution proposes a Location Information Server (LIS) be
the source for distributing location information within an access the source for distributing location information within an access
network. Furthermore the validity, integrity and authenticity of network. Furthermore the validity, integrity and authenticity of
this information are directly attributed to the LIS operator. this information are directly attributed to the LIS operator.
Section 6.1.1 describes the issues that arise in ensuring the Section 5.1.1 describes the issues that arise in ensuring the
validity of location information provided by the LIS operator. validity of location information provided by the LIS operator.
Section 6.1.2 and Section 6.1.3 describe operational issues that Section 5.1.2 and Section 5.1.3 describe operational issues that
arise in ensuring the integrity and authenticity of location arise in ensuring the integrity and authenticity of location
information provided by the LIS operator. information provided by the LIS operator.
5.1.1. Validity 5.1.1. Validity
In existing networks where location information is both determined by In existing networks where location information is both determined by
the access/voice service provider as well as communicated by the AIP/ the access/voice service provider as well as communicated by the AIP/
VSP, responsibility for location validity can be attributed entirely VSP, responsibility for location validity can be attributed entirely
to a single party, namely the AIP/VSP. to a single party, namely the AIP/VSP.
skipping to change at page 17, line 34 skipping to change at page 18, line 10
gain fraudulent use of services and to divert emergency calls to non- gain fraudulent use of services and to divert emergency calls to non-
emergency sites. [RFC5069] also describes attacks against emergency sites. [RFC5069] also describes attacks against
individuals, including attempts to prevent an individual from individuals, including attempts to prevent an individual from
receiving aid, or to gain information about an emergency. receiving aid, or to gain information about an emergency.
"Threat Analysis of the Geopriv Protocol" [RFC3694] describes threats "Threat Analysis of the Geopriv Protocol" [RFC3694] describes threats
against geographic location privacy, including protocol threats, against geographic location privacy, including protocol threats,
threats resulting from the storage of geographic location data, and threats resulting from the storage of geographic location data, and
threats posed by the abuse of information. threats posed by the abuse of information.
This document focuses on threats deriving from the introduction of
untrustworthy location information by end hosts, regardless of
whether this occurs intentionally or unintentionally.
Although it is important to ensure that location information cannot Although it is important to ensure that location information cannot
be faked there will be a larger number of GPS-enabled devices out be faked there will be many GPS-enabled devices that will find it
there that will find it difficult to utilize any of the security difficult to utilize any of the security mechanisms described in
mechanisms described in Section 5. It is unlikely that end users Section 5. It is also unlikely that users will be willing to upload
will upload their location information for "verification" to a nearby their location information for "verification" to a nearby location
location server located in the access network. server located in the access network.
Given the practical and operational limitations in the technology, it
may be worthwhile to consider whether the goals of trustworthy
location, as for example defined by NENA i2 [NENA-i2], are
attainable, or whether lesser goals (such as auditability) should be
substituted instead.
The goal of auditability is to enable an investigator to determine While auditability is an important deterrent, it is likely to be of
the source of a rogue emergency call after the fact. Since such an most benefit in situations where attacks on the emergency services
investigation can rely on audit logs provided under court order, the system are likely to be relatively infrequent, since the resources
information available to the investigator could be considerably required to pursue an investigation are likely to be considerable.
greater than that present in messages conveyed in the emergency call.
As a consequence the emergency caller becomes accountable for his
actions. For example, in such a situation, information relating to
the owner of the unlinked pseudonym could be provided to
investigators, enabling them to unravel the chain of events that lead
to the attack. Auditability is likely to be of most benefits in
situations where attacks on the emergency services system are likely
to be relatively infrequent, since the resources required to pursue
an investigation are likely to be considerable.
Where attacks are frequent and continuous, a reliance on non- Where attacks are frequent and continuous, automated mechanisms are
automated mechanisms is unlikely to be satisfactory. As such, required. For example, mechanisms to exchange audit trails
mechanisms to exchange audit trails information in a standardized information in a standardized format between ISPs and PSAPs / VSPs
format between ISPs and PSAPs / VSPs and PSAPs or heuristics to and PSAPs or heuristics to distinguish potentially fraudulent
distinguish potentially fraudulent emergency calls from real emergency calls from real emergencies might be valuable.
emergencies might be valuable for the emergency services community.
7. IANA Considerations 7. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
8. Acknowledgments 8. Acknowledgments
We would like to thank the members of the IETF ECRIT and the IETF We would like to thank the members of the IETF ECRIT and the IETF
GEOPRIV working group for their input to the discussions related to GEOPRIV working group for their input to the discussions related to
this topic. We would also like to thank Andrew Newton, Murugaraj this topic. We would also like to thank Andrew Newton, Murugaraj
skipping to change at page 19, line 6 skipping to change at page 19, line 7
Warner, J. S. and R. G. Johnston, "GPS Spoofing Warner, J. S. and R. G. Johnston, "GPS Spoofing
Countermeasures", Los Alamos research paper LAUR-03-6163, Countermeasures", Los Alamos research paper LAUR-03-6163,
December 2003. December 2003.
[I-D.thomson-geopriv-location-dependability] [I-D.thomson-geopriv-location-dependability]
Thomson, M. and J. Winterbottom, "Digital Signature Methods Thomson, M. and J. Winterbottom, "Digital Signature Methods
for Location Dependability", draft-thomson-geopriv-location- for Location Dependability", draft-thomson-geopriv-location-
dependability-07 (work in progress), March 2011. dependability-07 (work in progress), March 2011.
[I-D.ietf-geopriv-deref-protocol] [I-D.ietf-geopriv-deref-protocol]
Winterbottom, J., Tschofenig, H., Schulzrinne, H., Thomson, Winterbottom, J., Tschofenig, H., Schulzrinne, H. and M.
M., and M. Dawson, "A Location Dereferencing Protocol Using Thomson, "A Location Dereferencing Protocol Using HELD",
HELD", draft-ietf-geopriv-deref-protocol-04 (work in draft-ietf-geopriv-deref-protocol-07 (work in progress), July
progress), October 2011. 2012.
[IEEE-802.11y] [IEEE-802.11y]
Information technology - Telecommunications and information Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area exchange between systems - Local and metropolitan area
networks - Specific requirements - Part 11: Wireless LAN networks - Specific requirements - Part 11: Wireless LAN
Medium Access Control (MAC) and Physical Layer (PHY) Medium Access Control (MAC) and Physical Layer (PHY)
specifications Amendment 3: 3650-3700 MHz Operation in USA, specifications Amendment 3: 3650-3700 MHz Operation in USA,
November 2008. November 2008.
[LLDP-MED] [LLDP-MED]
 End of changes. 23 change blocks. 
113 lines changed or deleted 102 lines changed or added

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