< draft-ietf-ecrit-trustworthy-location-09.txt   draft-ietf-ecrit-trustworthy-location-10.txt >
ECRIT Working Group H. Tschofenig ECRIT Working Group H. Tschofenig
INTERNET-DRAFT ARM Ltd. INTERNET-DRAFT ARM Ltd.
Category: Informational H. Schulzrinne Category: Informational H. Schulzrinne
Expires: September 24, 2014 Columbia University Expires: December 1, 2014 Columbia University
B. Aboba (ed.) B. Aboba (ed.)
Microsoft Corporation Microsoft Corporation
17 March 2014 31 May 2014
Trustworthy Location Trustworthy Location
draft-ietf-ecrit-trustworthy-location-09.txt draft-ietf-ecrit-trustworthy-location-10.txt
Abstract Abstract
For some location-based applications, such as emergency calling or The trustworthiness of location information is critically important
roadside assistance, the trustworthiness of location information is for some location-based applications, such as emergency calling or
critically important. roadside assistance.
This document describes how to convey location in a manner that is This document focuses on the security issues arising from conveyance
inherently secure and reliable. It also provides guidelines for of location within an emergency call, and describes mechanisms
assessing the trustworthiness of location information. availble to convey location in a manner that is inherently secure and
reliable. It also provides guidelines for assessing the
trustworthiness of location information.
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 September 24, 2014. This Internet-Draft will expire on December 1, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 Literature review . . . . . . . . . . . . . . . . . . . . 5
2.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 6 2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 7 2.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 8
3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 9
3.1. Signed Location by Value . . . . . . . . . . . . . . . . . 8 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Location by Reference . . . . . . . . . . . . . . . . . . 11 3.1. Signed Location by Value . . . . . . . . . . . . . . . . . 10
3.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 14 3.2. Location by Reference . . . . . . . . . . . . . . . . . . 14
4. Location Trust Assessment . . . . . . . . . . . . . . . . . . 16 3.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 4. Location Trust Assessment . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7.1. Informative references . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.1. Informative references . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
Several public and commercial services depend upon location Several public and commercial services depend upon location
information in their operations. This includes emergency services information in their operations. This includes emergency services
(such as fire, ambulance and police) as well as commercial services (such as fire, ambulance and police) as well as commercial services
such as food delivery and roadside assistance. such as food delivery and roadside assistance.
Services that depend on location commonly experience security issues For circuit-switched calls from landlines, as well as for Voice over
today. While prank calls have been a problem for emergency services IP (VoIP) services only supporting emergency service calls from
dating back to the time of street corner call boxes, with the move to stationary devices, location provided to the Public Safety Answering
IP-based emergency services, the ability to launch automated attacks Point (PSAP) is determined from a lookup using the calling telephone
has increased. As the European Emergency Number Association (EENA) number. As a result, for landlines or stationary VoIP, spoofing of
has noted [EENA]: "False emergency calls divert emergency services caller identification can result in the PSAP incorrectly determining
away from people who may be in life-threatening situations and who the caller's location. Problems relating to calling party number and
need urgent help. This can mean the difference between life and Caller ID assurance have been analyzed by the "Secure Telephone
death for someone in trouble." Identity Revisited" [STIR] Working Group as described in "Secure
Telephone Identity Problem Statement and Requirements" [I-D.ietf-
EENA [EENA] has attempted to define terminology and describe best stir-problem-statement]. In addition to the work underway in STIR,
current practices for dealing with false emergency calls, which in other mechanisms exist for validating caller identification. For
certain European countries can constitute as much as 70% of all example, as noted in [EENA], one mechanism for validating caller
emergency calls. Reducing the number of prank calls represents a identification information (as well as the existence of an emergency)
challenge, since emergency services authorities in most countries are is for the PSAP to call the user back, as described in [RFC7090].
required to answer every call (whenever possible). Where the caller
cannot be identified, the ability to prosecute is limited.
Since prank emergency calls can endanger bystanders or emergency
services personnel, or divert resources away from legitimate
emergencies, they can be life threatening. A particularly dangerous
form of prank call is "swatting" - a prank emergency call that draws
a response from law enforcement (e.g. a fake hostage situation that
results in dispatching of a "Special Weapons And Tactics" (SWAT)
team). In 2008 the Federal Bureau of Investigation (FBI) issued a
warning [Swatting] about an increase in the frequency and
sophistication of these attacks.
Many documented cases of "swatting" involve not only the faking of an
emergency, but also the absence of accurate caller identification and
the delivery of misleading location data. Today these attacks are
often carried out by providing false caller identification, since for
circuit-switched calls from landlines, location provided to the
Public Safety Answering Point (PSAP) is determined from a lookup
using the calling telephone number. With IP-based emergency
services, in addition to the potential for false caller
identification, it is also possible to attach misleading location
information to the emergency call.
Ideally, a call taker at a PSAP should be put in the position to Given the existing work on caller identification, this document
assess, in real-time, the level of trust that can be placed on the focuses on the additional threats that are introduced by the support
information provided within a call. This includes automated location of IP-based emergency services in nomadic and mobile devices, in
conveyed along with the call and location information communicated by which location may be conveyed to the PSAP within the emergency call.
the caller, as well as identity information about the caller. Where Ideally, a call taker at a PSAP should be able to assess, in real-
real-time assessment is not possible, it is important to be able to time, the level of trust that can be placed on the information
determine the source of the call in a post-mortem, so as to be able provided within a call. This includes automated location conveyed
to enforce accountability. along with the call and location information communicated by the
caller, as well as identity information relating to the caller or the
device initiating the call. Where real-time assessment is not
possible, it is important to be able to determine the source of the
call after the fact, so as to be able to enforce accountability.
This document defines terminology (including the meaning of This document defines terminology (including the meaning of
"trustworthy location") in Section 1.1, investigates security threats "trustworthy location") in Section 1.1, reviews existing work in
in Section 2, outlines potential solutions in Section 3, covers trust Section 1.2, describes the threat model in Section 2, outlines
assessment in Section 4 and discusses security considerations in potential solutions in Section 3, covers trust assessment in Section
Section 5. 4 and discusses security considerations in Section 5.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The definition for "Target" is taken from "Geopriv Requirements" The definitions of "Internet Access Provider (IAP)", "Internet
[RFC3693]. Service Provider (ISP)" and "Voice Service Provider (VSP)" are taken
from "Requirements for Emergency Context Resolution with Internet
Technologies" [RFC5012].
The definition of a "hoax call" is taken from "False Emergency Calls"
[EENA].
The definition of "Target" and "Device" is taken from "An
Architecture for Location and Location Privacy in Internet
Applications" [RFC6280].
The term "location determination method" refers to the mechanism used The term "location determination method" refers to the mechanism used
to determine the location of a Target. This may be something to determine the location of a Target. This may be something
employed by a location information server (LIS), or by the Target employed by a location information server (LIS), or by the Target
itself. It specifically does not refer to the location configuration itself. It specifically does not refer to the location configuration
protocol (LCP) used to deliver location information either to the protocol (LCP) used to deliver location information either to the
Target or the Recipient. This term is re-used from "GEOPRIV PIDF-LO Target or the Recipient. This term is re-used from "GEOPRIV PIDF-LO
Usage Clarification, Considerations, and Recommendations" [RFC5491]. Usage Clarification, Considerations, and Recommendations" [RFC5491].
The term "source" is used to refer to the LIS, node, or device from The term "source" is used to refer to the LIS, node, or device from
skipping to change at page 5, line 7 skipping to change at page 4, line 45
"Trustworthy Location" is defined as location information that can be "Trustworthy Location" is defined as location information that can be
attributed to a trusted source, has been protected against attributed to a trusted source, has been protected against
modification in transmit, and has been assessed as trustworthy. modification in transmit, and has been assessed as trustworthy.
"Location Trust Assessment" refers to the process by which the "Location Trust Assessment" refers to the process by which the
reliability of location information can be assessed. This topic is reliability of location information can be assessed. This topic is
discussed in Section 4. discussed in Section 4.
The following additional terms apply to location spoofing: The following additional terms apply to location spoofing:
"Place Shifting" is where the attacker constructs a PIDF-LO for a "Place Shifting" is where the attacker constructs a Presence
location other than where they are currently located. In some cases, Information Data Format Location Object (PIDF-LO) for a location
place shifting can be limited in range (e.g., within the coverage other than where they are currently located. In some cases, place
area of a particular cell tower). shifting can be limited in range (e.g., within the coverage area of a
particular cell tower).
"Time Shifting" is where the attacker uses or re-uses location "Time Shifting" is where the attacker uses or re-uses location
information that was valid in the past, but is no longer valid information that was valid in the past, but is no longer valid
because the attacker has moved. because the attacker has moved.
"Location Theft" is where the attacker captures a Target's location "Location Theft" is where the attacker captures a Target's location
information and presents it as their own. Location theft can occur information and presents it as their own. Location theft can occur
in a single instance, or may be continuous (e.g., where the attacker in a single instance, or may be continuous (e.g., where the attacker
has gained control over the victim's device). Location theft may has gained control over the victim's device). Location theft may
also be combined with time shifting to present someone else's also be combined with time shifting to present someone else's
location information after the original Target has moved. Where the location information after the original Target has moved.
Target and attacker collude, the term "location swapping" is used.
2. Threats "Identity Spoofing" is where the attacker forges or obscures their
identity so as to prevent themselves from being identified as the
source of the attack. One class of identity spoofing attack involves
the forging of call origin identification.
While previous IETF documents have analyzed aspects of the security 1.2. Literature Review
of emergency services or threats to geographic location privacy,
those documents do not cover the threats arising from unreliable
location information.
A threat analysis of the emergency services system is provided in There is existing work on the problem of hoax calls, as well as
"Security Threats and Requirements for Emergency Call Marking and analyses of aspects of the security of emergency services, threats to
Mapping" [RFC5069]. RFC 5069 describes attacks on the emergency geographic location privacy, threats relating to spoofing of caller
services system, such as attempting to deny system services to all identification and modification of location information in transit.
users in a given area, to gain fraudulent use of services and to This section reviews the literature.
divert emergency calls to non-emergency sites. [RFC5069] also
describes attacks against individuals, including attempts to prevent
an individual from receiving aid, or to gain information about an
emergency. "Threat Analysis of the Geopriv Protocol" [RFC3694]
describes threats against geographic location privacy, including
protocol threats, threats resulting from the storage of geographic
location data, and threats posed by the abuse of information.
This document focuses on threats from attackers providing false 1.2.1. Hoax Calls
location information within emergency calls. Since we do not focus
on attackers gaining control of infrastructure elements (e.g.,
location servers, call route servers) or the emergency services IP
network, the threats arise from end hosts. In addition to threats
arising from the intentional forging of caller identification or
location information, end hosts may be induced to provide
untrustworthy location information. For example, end hosts may
obtain location from civilian GPS, which is vulnerable to spoofing
[GPSCounter] or from third party Location Service Providers (LSPs) Hoax calls have been a problem for emergency services dating back to
which may be vulnerable to attack or may not provide location the time of street corner call boxes. The European Emergency Number
accuracy suitable for emergency purposes. Association (EENA) has noted [EENA]: "False emergency calls divert
emergency services away from people who may be in life-threatening
situations and who need urgent help. This can mean the difference
between life and death for someone in trouble." As a result,
considerable attention has been focused on the problem.
EENA [EENA] has attempted to define terminology and describe best
current practices for dealing with false emergency calls. Reducing
the number of hoax calls represents a challenge, since emergency
services authorities in most countries are required to answer every
call (whenever possible). Where the caller cannot be identified, the
ability to prosecute is limited.
A particularly dangerous form of hoax call is "swatting" - a hoax
emergency call that draws a response from law enforcement prepared
for a violent confrontation (e.g. a fake hostage situation that
results in dispatching of a "Special Weapons And Tactics" (SWAT)
team). In 2008 the Federal Bureau of Investigation (FBI) issued a
warning [Swatting] about an increase in the frequency and
sophistication of these attacks.
As noted in [EENA], many documented cases of "swatting" involve not
only the faking of an emergency, but also falsification or
obfuscation of identity. In general, the ability to identify the
caller also appears to influence the incidence of hoax calls. Where
a Voice Service Provider enables setting of the outbound caller
identification without checking it against the authenticated
identity, forging caller identification is trivial. Similarly where
an attacker can gain entry to a Private Branch Exchange (PBX), they
can then subsequently use that access to launch a denial of service
attack against the PSAP, or to make fraudulent emergency calls.
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 hoax calls has often been unacceptably high
[TASMANIA][UK][SA].
However, to date there have been few documented cases of hoax calls
that have arisen from conveyance of untrustworthy location
information within an emergency call, which is the focus of this
document.
1.2.2. Existing IETF Work
The Internet architecture for emergency calling is described in
"Framework for Emergency Calling Using Internet Multimedia" [RFC6443]
and "Best Current Practice for Communications Services in Support of
Emergency Calling" [RFC6881]. The conveyance of location information
within the Session Initiation Protocol (SIP) is described in
"Location Conveyance for the Session Initiation Protocol" [RFC6442],
which in the Security Considerations (Section 7) includes discussion
of privacy, authentication and integrity concerns relating to
conveyed location. Note that while [RFC6442] does not prohibit the
conveyance of location within non-emergency calls, in practice,
location conveyance requires additional infrastructure as described
in [RFC6443]. As a result, privacy issues inherent in conveyance of
location within non-emergency calls are not considered within
[RFC6442].
"Secure Telephone Identity Threat Model" [I-D.ietf-stir-threats]
analyzes threats relating to impersonation and obscuring of calling
party numbers, reviewing the capabilities available to attackers, and
the scenarios in which attacks are launched.
"An Architecture for Location and Location Privacy in Internet
Applications" [RFC6280] describes an architecture for privacy-
preserving location-based services in the Internet, focusing on
authorization, security and privacy requirements for the data formats
and protocols used by these services. Within the Security
Considerations (Section 5), mechanisms for ensuring the security of
the location distribution chain are discussed; these include
mechanisms for hop-by-hop confidentiality and integrity protection as
well as end-to-end assurance. As noted in Section 6.3:
"there are three critical steps in the placement of an emergency
call, each involving location information:
1. Determine the location of the caller.
2. Determine the proper Public Safety Answering Point (PSAP) for the
caller's location.
3. Send a SIP INVITE message, including the caller's location, to the
PSAP."
"Geopriv Requirements" [RFC3693] focuses on the authorization,
security and privacy requirements of location-dependent services,
including emergency services. Within the Security Considerations
(Section 8), this includes discussion of emergency services
authentication (Section 8.3), and issues relating to identity and
anonymity (Section 8.4).
"Threat Analysis of the Geopriv Protocol" [RFC3694] describes threats
against geographic location privacy, including protocol threats,
threats resulting from the storage of geographic location data, and
threats posed by the abuse of information.
"Security Threats and Requirements for Emergency Call Marking and
Mapping" [RFC5069] reviews security threats associated with the
marking of signalling messages and the process of mapping locations
to Universal Resource Identifiers (URIs) that point to PSAPs. RFC
5069 describes attacks on the emergency services system, such as
attempting to deny system services to all users in a given area, to
gain fraudulent use of services and to divert emergency calls to non-
emergency sites. In addition, it describes attacks against
individuals, including attempts to prevent an individual from
receiving aid, or to gain information about an emergency, as well as
attacks on emergency services infrastructure elements, such as
mapping discovery and mapping servers.
2. Threat Model
To provide a structured analysis we distinguish between three To provide a structured analysis we distinguish between three
adversary models: adversary models:
External adversary model: The end host, e.g., an emergency caller External adversary model: The end host, e.g., an emergency caller
whose location is going to be communicated, is honest and the whose location is going to be communicated, is honest and the
adversary may be located between the end host and the location adversary may be located between the end host and the location
server or between the end host and the PSAP. None of the server or between the end host and the PSAP. None of the
emergency service intrastructure elements act maliciously. emergency service infrastructure elements act maliciously.
Malicious infrastructure adversary model: The emergency call routing Malicious infrastructure adversary model: The emergency call routing
elements, such as the Location Information Server (LIS), the elements, such as the Location Information Server (LIS), the
Location-to-Service Translation (LoST) infrastructure, used for Location-to-Service Translation (LoST) infrastructure, used for
mapping locations to PSAP address, or call routing elements, may mapping locations to PSAP address, or call routing elements, may
act maliciously. act maliciously.
Malicious end host adversary model: The end host itself acts Malicious end host adversary model: The end host itself acts
maliciously, whether the owner is aware of this or whether it is maliciously, whether the owner is aware of this or whether it is
acting under the control of a third party. acting under the control of a third party.
In this document, we focus only on the malicious end host adversary Since previous work describes attacks against infrastructure elements
model. (e.g. location servers, call route servers, mapping servers) or the
emergency services IP network, as well as threats from attackers
2.1. Location Spoofing attempting to snoop location in transit, this document focuses on the
threats arising from end hosts providing false location information
An adversary can provide false location information in an emergency within emergency calls (the malicious end host adversary model).
call in order to misdirect emergency resources. For calls
originating within the Public Switched Telephone Network (PSTN) or
via a fixed Voice over Internet Protocol (VoIP) service, this attack
can be carried out via caller-id spoofing. For example, where a
Voice Service Provider enables setting of the outbound caller
identification without checking it against the authenticated
identity, forging caller identification is trivial. Where an
attacker can gain entry to a Private Branch Exchange (PBX), they can
then subsequently use that access to launch a denial of service
attack against the PSAP, or to make fraudulent emergency calls.
Where location is attached to the emergency call by an end host,
several avenues are available to provide false location information:
1. The end host could fabricate a Presence Information Data Since the focus is on malicious hosts, we do not cover threats that
Format Location Object (PIDF-LO) and convey it within an emergency may arise from attacks on infrastructure that hosts depend on to
call; obtain location. For example, end hosts may obtain location from
civilian GPS, which is vulnerable to spoofing [GPSCounter] or from
third party Location Service Providers (LSPs) which may be vulnerable
to attack or may not provide location accuracy suitable for emergency
purposes.
2. The Voice Service Provider (VSP) (and indirectly a LIS) could Also, we do not cover threats arising from inadequate location
be fooled into using the wrong identity (such as an IP address) infrastructure. For example, a stale wiremap or an inaccurate access
for location lookup, thereby providing the end host with point location database could be utilized by the Location Information
misleading location information; Server (LIS) or the end host in its location determination, thereby
leading to an inaccurate determination of location. Similarly, a
Voice Service Provider (VSP) (and indirectly a LIS) could utilize the
wrong identity (such as an IP address) for location lookup, thereby
providing the end host with misleading location information.
3. Inaccurate or out-of-date information (such as spoofed Global 2.1. Location Spoofing
Positioning System (GPS) signals, a stale wiremap or an inaccurate
access point location database) could be utilized by the LIS or
the end host in its location determination, thereby leading to an
inaccurate determination of location.
The following represent examples of location spoofing: Where location is attached to the emergency call by an end host, the
end host can fabricate a PIDF-LO and convey it within an emergency
call. The following represent examples of location spoofing:
Place shifting: Trudy, the adversary, pretends to be at an Place shifting: Trudy, the adversary, pretends to be at an
arbitrary location. arbitrary location.
Time shifting: Trudy pretends to be at a location she was a Time shifting: Trudy pretends to be at a location she was a
while ago. while ago.
Location theft: Trudy observes Alice's location and replays Location theft: Trudy observes or obtains Alice's location and
it as her own. replays it as her own.
Location swapping: Trudy and Malory collude and swap location
information, pretending to be in each other's location.
2.2. Identity Spoofing 2.2. Identity Spoofing
While this document does not focus on the problems created by
determination of location based on spoofed caller identification, the
ability to ascertain identity is important, since the threat of
punishment reduces hoax calls. As an example, calls from pay phones
are subject to greater scrutiny by the call taker.
With calls originating on an IP network, at least two forms of With calls originating on an IP network, at least two forms of
identity are relevant, with the distinction created by the split identity are relevant, with the distinction created by the split
between the Internet Access Provider (IAP) and the VSP: between the IAP and the VSP:
(a) network access identity such as might be determined via (a) network access identity such as might be determined via
authentication (e.g., using the Extensible Authentication Protocol authentication (e.g., using the Extensible Authentication Protocol
(EAP) [RFC3748]); (EAP) [RFC3748]);
(b) caller identity, such as might be determined from authentication (b) caller identity, such as might be determined from authentication
of the emergency caller at the VoIP application layer. of the emergency caller at the VoIP application layer.
If the adversary did not authenticate itself to the VSP, then If the adversary did not authenticate itself to the VSP, then
accountability may depend on verification of the network access accountability may depend on verification of the network access
identity. However, this also may not have been authenticated, such identity. However, this also may not have been authenticated, such
as in the case where an open IEEE 802.11 Access Point is used to as in the case where an open IEEE 802.11 Access Point is used to
initiate a prank emergency call. Although endpoint information such initiate a hoax emergency call. Although endpoint information such
as the IP or MAC address may have been logged, tying this back to the as the IP or MAC address may have been logged, tying this back to the
device owner may be challenging. device owner may be challenging.
Unlike the existing telephone system, VoIP emergency calls can Unlike the existing telephone system, VoIP emergency calls can
provide a strong identity that need not necessarily be coupled to a provide an identity that need not necessarily be coupled to a
business relationship with the IAP, Internet Service Provider (ISP) business relationship with the IAP, ISP or VSP. However, due to the
or VSP. However, due to the time-critical nature of emergency calls, time-critical nature of emergency calls, multi-layer authentication
multi-layer authentication is undesirable, so that in most cases, is undesirable, so that in most cases, only the device placing the
only the device placing the call will be able to be identified, call will be able to be identified. Furthermore, deploying
making the system vulnerable to bot-net attacks. Furthermore, additional credentials for emergency service purposes (such as
deploying additional credentials for emergency service purposes (such certificates) increases costs, introduces a significant
as certificates) increases costs, introduces a significant
administrative overhead and is only useful if widely deployed. administrative overhead and is only useful if widely deployed.
3. Solutions 3. Solutions
This section presents three mechanisms which can be used to convey This section presents two mechanisms which can be used to enable
location securely: signed location by value (Section 3.1), location location to be authenticated: signed location by value (Section 3.1),
by reference (Section 3.2) and proxy added location (Section 3.3). which provides for authentication and integrity protection of the
PIDF-LO, and location-by-reference (Section 3.2), which enables
location to be obtained by the PSAP via direct contact with the
location server. In addition, a mechanism is presented which
protects against location forgery by the end host: proxy added
location (Section 3.3). Since at the time of this writing there is
no completed specification for signed location by value, only an
expired straw-man proposal, it should be understood that only the
location-by-reference and proxy added location mechanisms are
suitable for deployment.
In order to provide authentication and integrity protection for the In order to provide authentication and integrity protection for the
Session Initiation Protocol (SIP) messages conveying location, Session Initiation Protocol (SIP) messages conveying location,
several security approaches are available. It is possible to ensure several security approaches are available. It is possible to ensure
that modification of the identity and location in transit can be that modification of the identity and location in transit can be
detected by the location recipient (e.g., the PSAP), using detected by the location recipient (e.g., the PSAP), using
cryptographic mechanisms, as described in "Enhancements for cryptographic mechanisms, as described in "Enhancements for
Authenticated Identity Management in the Session Initiation Protocol" Authenticated Identity Management in the Session Initiation Protocol"
[RFC4474]. However, compatibility with Session Border Controllers [RFC4474]. However, compatibility with Session Border Controllers
(SBCs) that modify integrity-protected headers has proven to be an (SBCs) that modify integrity-protected headers has proven to be an
issue in practice. As a result, SIP over Transport Layer Security issue in practice. As a result, SIP over Transport Layer Security
(TLS) is currently a more deployable mechanism to provide per-message (TLS) is currently a more deployable mechanism to provide per-message
authentication and integrity protection hop-by-hop. authentication and integrity protection hop-by-hop.
3.1. Signed Location by Value 3.1. Signed Location by Value
With location signing, a location server signs the location With location signing, a location server signs the location
information before it is sent to the end host, (the entity subject to information before it is sent to the Target. The signed location
the location determination process). The signed location information information is then sent to the location recipient, who verifies it.
is then verified by the location recipient and not by the target. A
straw-man proposal for location signing is provided in "Digital
Signature Methods for Location Dependability" [I-D.thomson-geopriv-
location-dependability].
Figure 1 shows the communication model with the target requesting Figure 1 shows the communication model with the target requesting
signed location in step (a), the location server returns it in step signed location in step (a), the location server returns it in step
(b) and it is then conveyed to the location recipient in step (c) who (b) and it is then conveyed to the location recipient in step (c) who
verifies it. For SIP, the procedures described in "Location verifies it. For SIP, the procedures described in "Location
Conveyance for the Session Initiation Protocol" [RFC6442] are Conveyance for the Session Initiation Protocol" [RFC6442] are
applicable for location conveyance. applicable for location conveyance.
+-----------+ +-----------+ +-----------+ +-----------+
| | | Location | | | | Location |
| LIS | | Recipient | | LIS | | Recipient |
| | | | | | | |
+-+-------+-+ +----+------+ +-+-------+-+ +----+------+
^ | --^ ^ | --^
| | -- | | --
Geopriv |Req. | -- Geopriv |Req. | --
Location |Signed |Signed -- Geopriv Location |Signed |Signed -- Protocol Conveying
Configuration |Loc. |Loc. -- Using Protocol Configuration |Loc. |Loc. -- Location (e.g. SIP)
Protocol |(a) |(b) -- (e.g., SIP) Protocol |(a) |(b) -- (c)
| v -- (c) | v --
+-+-------+-+ -- +-+-------+-+ --
| Target / | -- | Target / | --
| End Host + | End Host +
| | | |
+-----------+ +-----------+
Figure 1: Location Signing Figure 1: Location Signing
In order to limit replay attacks, [I.D.thomson-geopriv-location- A straw-man proposal for location signing is provided in "Digital
dependability] proposes the addition of a "validity" element to the Signature Methods for Location Dependability" [I-D.thomson-geopriv-
PIDF-LO, including a "from" sub-element containing the time that location-dependability]. Note that since this document is no longer
location information was validated by the signer, as well as an under development, location signing cannot be considered deployable
"until" sub-element containing the last time that the signature can at the time of this writing.
be considered valid.
In order to limit replay attacks, this document proposes the addition
of a "validity" element to the PIDF-LO, including a "from" sub-
element containing the time that location information was validated
by the signer, as well as an "until" sub-element containing the last
time that the signature can be considered valid.
One of the consequences of including an "until" element is that even One of the consequences of including an "until" element is that even
a stationary target would need to periodically obtain a fresh PIDF- a stationary target would need to periodically obtain a fresh PIDF-
LO, or incur the additional delay of querying during an emergency LO, or incur the additional delay of querying during an emergency
call. call.
Although privacy-preserving procedures may be disabled for emergency Although privacy-preserving procedures may be disabled for emergency
calls, by design, PIDF-LO objects limit the information available for calls, by design, PIDF-LO objects limit the information available for
real-time attribution. As noted in [RFC5985] Section 6.6: real-time attribution. As noted in [RFC5985] Section 6.6:
skipping to change at page 9, line 48 skipping to change at page 12, line 4
calls, by design, PIDF-LO objects limit the information available for calls, by design, PIDF-LO objects limit the information available for
real-time attribution. As noted in [RFC5985] Section 6.6: real-time attribution. As noted in [RFC5985] Section 6.6:
The LIS MUST NOT include any means of identifying the Device in The LIS MUST NOT include any means of identifying the Device in
the PIDF-LO unless it is able to verify that the identifier is the PIDF-LO unless it is able to verify that the identifier is
correct and inclusion of identity is expressly permitted by a Rule correct and inclusion of identity is expressly permitted by a Rule
Maker. Therefore, PIDF parameters that contain identity are Maker. Therefore, PIDF parameters that contain identity are
either omitted or contain unlinked pseudonyms [RFC3693]. A either omitted or contain unlinked pseudonyms [RFC3693]. A
unique, unlinked presentity URI SHOULD be generated by the LIS for unique, unlinked presentity URI SHOULD be generated by the LIS for
the mandatory presence "entity" attribute of the PIDF document. the mandatory presence "entity" attribute of the PIDF document.
Optional parameters such as the "contact" and "deviceID" elements Optional parameters such as the "contact" and "deviceID" elements
[RFC4479] are not used. [RFC4479] are not used.
Also, the device referred to in the PIDF-LO may not necessarily be Also, the device referred to in the PIDF-LO may not necessarily be
the same entity conveying the PIDF-LO to the PSAP. As noted in the same entity conveying the PIDF-LO to the PSAP. As noted in
[RFC6442] Section 1: [RFC6442] Section 1:
In no way does this document assume that the SIP user agent client In no way does this document assume that the SIP user agent client
that sends a request containing a location object is necessarily that sends a request containing a location object is necessarily
the Target. The location of a Target conveyed within SIP the Target. The location of a Target conveyed within SIP
typically corresponds to that of a device controlled by the typically corresponds to that of a device controlled by the
Target, for example, a mobile phone, but such devices can be Target, for example, a mobile phone, but such devices can be
separated from their owners, and moreover, in some cases, the user separated from their owners, and moreover, in some cases, the user
agent may not know its own location. agent may not know its own location.
Without the ability to tie the target identity to the identity Without the ability to tie the target identity to the identity
asserted in the SIP message, it is possible for an attacker to cut asserted in the SIP message, it is possible for an attacker to cut
and paste a PIDF-LO obtained by a different device or user into a SIP and paste a PIDF-LO obtained by a different device or user into a SIP
INVITE and send this to the PSAP. This cut and paste attack could INVITE and send this to the PSAP. This cut and paste attack could
succeed even when a PIDF-LO is signed, or [RFC4474] is implemented. succeed even when a PIDF-LO is signed, or [RFC4474] is implemented.
To address location-swapping attacks, [I-D.thomson-geopriv-location- To address location-spoofing attacks, [I-D.thomson-geopriv-location-
dependability] proposes addition of an "identity" element which could dependability] proposes addition of an "identity" element which could
include a SIP URI (enabling comparison against the identity asserted include a SIP URI (enabling comparison against the identity asserted
in the SIP headers) or an X.509v3 certificate. If the target was in the SIP headers) or an X.509v3 certificate. If the target was
authenticated by the LIS, an "authenticated" attribute is added. authenticated by the LIS, an "authenticated" attribute is added.
However, inclusion of an "identity" attribute could enable location However, inclusion of an "identity" attribute could enable location
tracking, so that a "hash" element is also proposed which could tracking, so that a "hash" element is also proposed which could
contain a hash of the content of the "identity" element instead. In contain a hash of the content of the "identity" element instead. In
practice, such a hash would not be much better for real-time practice, such a hash would not be much better for real-time
validation than a pseudonym. validation than a pseudonym.
Location signing is unlikely to deter attacks launched by bot-nets, Location signing cannot deter attacks in which valid location
since the work required to verify the location signature is information is provided. For example, an attacker in control of
considerable. However, while bot-nets are unlikely to be deterred by compromised hosts could launch a denial-of-service attack on the PSAP
location signing, accurate location information would limit the by initiating a large number of emergency calls, each containing
subset of the bot-net that could be used for an attack, as only hosts valid signed location information. Since the work required to verify
the location signature is considerable, this could overwhelm the PSAP
infrastructure.
However, while DDOS attacks are unlikely to be deterred by location
signing, accurate location information would limit the subset of
compromised hosts that could be used for an attack, as only hosts
within the PSAP serving area would be useful in placing emergency within the PSAP serving area would be useful in placing emergency
calls. calls.
Location signing is also difficult when the host obtains location via Location signing is also difficult when the host obtains location via
mechanisms such as GPS, unless trusted computing approaches, with mechanisms such as GPS, unless trusted computing approaches, with
tamper-proof GPS modules, can be applied. Otherwise, an end host can tamper-proof GPS modules, can be applied. Otherwise, an end host can
pretend to have a GPS device, and the recipient will need to rely on pretend to have a GPS device, and the recipient will need to rely on
its ability to assess the level of trust that should be placed in the its ability to assess the level of trust that should be placed in the
end host location claim. end host location claim.
skipping to change at page 11, line 43 skipping to change at page 14, line 8
preferable. However, this raises the question of who would operate preferable. However, this raises the question of who would operate
the intermediate CAs and what the expectations would be. the intermediate CAs and what the expectations would be.
In particular, the question arises as to the requirements for LIS In particular, the question arises as to the requirements for LIS
certificate issuance, and how they would compare to requirements for certificate issuance, and how they would compare to requirements for
issuance of other certificates such as an SSL/TLS web certificate. issuance of other certificates such as an SSL/TLS web certificate.
3.2. Location by Reference 3.2. Location by Reference
Location-by-reference was developed so that end hosts can avoid Location-by-reference was developed so that end hosts can avoid
having to periodically query the location server for up- to-date having to periodically query the location server for up-to-date
location information in a mobile environment. Additionally, if location information in a mobile environment. Additionally, if
operators do not want to disclose location information to the end operators do not want to disclose location information to the end
host without charging them, location-by-reference provides a host without charging them, location-by-reference provides a
reasonable alternative. As noted in "A Location Dereference Protocol reasonable alternative. Also, since location-by-reference enables
Using HTTP-Enabled Location Delivery (HELD)" [RFC6753], a location the PSAP to directly contact the location server, it avoids potential
reference can be obtained via HTTP-Enabled Location Delivery (HELD) attacks by intermediaries. As noted in "A Location Dereference
[RFC5985] or the Dynamic Host Configuration Protocol (DHCP) location Protocol Using HTTP-Enabled Location Delivery (HELD)" [RFC6753], a
URI option [DHCP-URI-OPT]. location reference can be obtained via HTTP-Enabled Location Delivery
(HELD) [RFC5985].
Figure 2 shows the communication model with the target requesting a Figure 2 shows the communication model with the target requesting a
location reference in step (a), the location server returns the location reference in step (a), the location server returns the
reference in step (b), and it is then conveyed to the location reference in step (b), and it is then conveyed to the location
recipient in step (c). The location recipient needs to resolve the recipient in step (c). The location recipient needs to resolve the
reference with a request in step (d). Finally, location information reference with a request in step (d). Finally, location information
is returned to the Location Recipient afterwards. For location is returned to the Location Recipient afterwards. For location
conveyance in SIP, the procedures described in [RFC6442] are conveyance in SIP, the procedures described in [RFC6442] are
applicable. applicable.
+-----------+ Geopriv +-----------+ +-----------+ Geopriv +-----------+
| | Location | Location | | | Location | Location |
| LIS +<------------->+ Recipient | | LIS +<------------->+ Recipient |
| | Dereferencing | | | | Dereferencing | |
+-+-------+-+ Protocol (d) +----+------+ +-+-------+-+ Protocol (d) +----+------+
^ | --^ ^ | --^
| | -- | | --
Geopriv |Req. | -- Geopriv |Req. | --
Location |LbyR |LbyR -- Geopriv Location |LbyR |LbyR -- Protocol Conveying
Configuration |(a) |(b) -- Using Protocol Configuration |(a) |(b) -- Location (e.g. SIP)
Protocol | | -- (e.g., SIP) Protocol | | -- (c)
| V -- (c) | V --
+-+-------+-+ -- +-+-------+-+ --
| Target / | -- | Target / | --
| End Host + | End Host +
| | | |
+-----------+ +-----------+
Figure 2: Location by Reference Figure 2: Location by Reference
Where location by reference is provided, the recipient needs to Where location by reference is provided, the recipient needs to
deference the LbyR in order to obtain location. The details for the deference the LbyR in order to obtain location. The details for the
skipping to change at page 12, line 51 skipping to change at page 15, line 17
certain amount of time. References need to expire to prevent the certain amount of time. References need to expire to prevent the
recipient of such a Uniform Resource Locator (URL) from being able to recipient of such a Uniform Resource Locator (URL) from being able to
permanently track a host and to offer garbage collection permanently track a host and to offer garbage collection
functionality for the location server. functionality for the location server.
Off-path adversaries must be prevented from obtaining the target's Off-path adversaries must be prevented from obtaining the target's
location. The reference contains a randomized component that location. The reference contains a randomized component that
prevents third parties from guessing it. When the location recipient prevents third parties from guessing it. When the location recipient
fetches up-to-date location information from the location server, it fetches up-to-date location information from the location server, it
can also be assured that the location information is fresh and not can also be assured that the location information is fresh and not
replayed. However, this does not address location swapping. replayed. However, this does not address location theft.
With respect to the security of the de-reference operation, [RFC6753] With respect to the security of the de-reference operation, [RFC6753]
Section 6 states: Section 6 states:
TLS MUST be used for dereferencing location URIs unless TLS MUST be used for dereferencing location URIs unless
confidentiality and integrity are provided by some other confidentiality and integrity are provided by some other
mechanism, as discussed in Section 3. Location Recipients MUST mechanism, as discussed in Section 3. Location Recipients MUST
authenticate the host identity using the domain name included in authenticate the host identity using the domain name included in
the location URI, using the procedure described in Section 3.1 of the location URI, using the procedure described in Section 3.1 of
[RFC2818]. Local policy determines what a Location Recipient does [RFC2818]. Local policy determines what a Location Recipient does
skipping to change at page 16, line 20 skipping to change at page 18, line 33
typically a fall-back would be provided where no emergency caller typically a fall-back would be provided where no emergency caller
identity information is made available to the PSAP and the emergency identity information is made available to the PSAP and the emergency
call still has to be completed. call still has to be completed.
4. Location Trust Assessment 4. Location Trust Assessment
The ability to assess the level of trustworthiness of conveyed The ability to assess the level of trustworthiness of conveyed
location information is important, since this makes it possible to location information is important, since this makes it possible to
understand how much value should be placed on location information, understand how much value should be placed on location information,
as part of the decision making process. As an example, if automated as part of the decision making process. As an example, if automated
location information is understood to be highly suspect, a call taker location information is understood to be highly suspect or is absent,
can put more effort into obtaining location information from the a call taker can put more effort into verifying the authenticity of
caller. the call and to obtaining location information from the caller.
Location trust assessment has value regardless of whether the Location trust assessment has value regardless of whether the
location has been conveyed securely (via signed location, location- location itself is authenticated (e.g. signed location) or is
by-reference or proxy-added location) or not (via location-by-value obtained directly from the location server (e.g. location-by-
without location signing), since secure conveyance does not provide reference) over security transport, since these mechanisms do not
assurance relating to the validity or provenance of location data. provide assurance of the validity or provenance of location data.
To prevent location-swapping attacks, the "entity" element of the To prevent location-theft attacks, the "entity" element of the PIDF-
PIDF-LO is of limited value if an unlinked pseudonym is provided in LO is of limited value if an unlinked pseudonym is provided in this
this field. However, if the LIS authenticates the target, then the field. However, if the LIS authenticates the target, then the
linkage between the pseudonym and the target identity can be linkage between the pseudonym and the target identity can be
recovered post-mortem. recovered after the fact.
As noted in [I.D.thomson-geopriv-location-dependability], if the As noted in [I.D.thomson-geopriv-location-dependability], if the
location object was signed, the location recipient has additional location object was signed, the location recipient has additional
information on which to base their trust assessment, such as the information on which to base their trust assessment, such as the
validity of the signature, the identity of the target, the identity validity of the signature, the identity of the target, the identity
of the LIS, whether the LIS authenticated the target, and the of the LIS, whether the LIS authenticated the target, and the
identifier included in the "entity" field. identifier included in the "entity" field.
Caller accountability is also an important aspect of trust Caller accountability is also an important aspect of trust
assessment. Can the individual purchasing the device or activating assessment. Can the individual purchasing the device or activating
service be identified or did the call originate from a non-service service be identified or did the call originate from a non-service
initialized (NSI) device whose owner cannot be determined? Prior to initialized (NSI) device whose owner cannot be determined? Prior to
the call, was the caller authenticated at the network or application the call, was the caller authenticated at the network or application
layer? In the event of a prank call, can audit logs be made layer? In the event of a hoax call, can audit logs be made available
available to an investigator, or can information relating to the to an investigator, or can information relating to the owner of an
owner of an unlinked pseudonym be provided, enabling investigators to unlinked pseudonym be provided, enabling investigators to unravel the
unravel the chain of events that lead to the attack? In practice, chain of events that lead to the attack?
the ability to identify a caller may decrease the likelihood of
caller misbehavior. 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 practice, the source of the location data is important for In practice, the source of the location data is important for
location trust assessment. For example, location provided by a location trust assessment. For example, location provided by a
Location Information Server (LIS) whose administrator has an Location Information Server (LIS) whose administrator has an
established history of meeting emergency location accuracy established history of meeting emergency location accuracy
requirements (e.g. Phase II) may be considered more reliable than requirements (e.g. Phase II) may be considered more reliable than
location information provided by a third party Location Service location information provided by a third party Location Service
Provider (LSP) that disclaims use of location information for Provider (LSP) that disclaims use of location information for
emergency purposes. emergency purposes.
skipping to change at page 18, line 4 skipping to change at page 20, line 12
element of the PIDF-LO, defined in [RFC3863], can be examined and element of the PIDF-LO, defined in [RFC3863], can be examined and
compared against timestamps included within the enclosing SIP compared against timestamps included within the enclosing SIP
message, to determine whether the location data is sufficiently message, to determine whether the location data is sufficiently
fresh. However, the timestamp only represents an assertion by the fresh. However, the timestamp only represents an assertion by the
LIS, which may or may not be trustworthy. For example, the recipient LIS, which may or may not be trustworthy. For example, the recipient
of the signed PIDF-LO may not know whether the LIS supports time of the signed PIDF-LO may not know whether the LIS supports time
synchronization, or whether it is possible to reset the LIS clock synchronization, or whether it is possible to reset the LIS clock
manually without detection. Even if the timestamp was valid at the manually without detection. Even if the timestamp was valid at the
time location was determined, a time period may elapse between when time location was determined, a time period may elapse between when
the PIDF-LO was provided and when it is conveyed to the recipient. the PIDF-LO was provided and when it is conveyed to the recipient.
Periodically refreshing location information to renew the timestamp Periodically refreshing location information to renew the timestamp
even though the location information itself is unchanged puts even though the location information itself is unchanged puts
additional load on LISes. As a result, recipients need to validate additional load on LISes. As a result, recipients need to validate
the timestamp in order to determine whether it is credible. the timestamp in order to determine whether it is credible.
While this document focuses on the discussion of real-time While this document focuses on the discussion of real-time
determination of suspicious emergency calls, the use of audit logs determination of suspicious emergency calls, the use of audit logs
may help in enforcing accountability among emergency callers. For may help in enforcing accountability among emergency callers. For
example, in the event of a prank call, information relating to the example, in the event of a hoax call, information relating to the
owner of the unlinked pseudonym could be provided to investigators, owner of the unlinked pseudonym could be provided to investigators,
enabling them to unravel the chain of events that lead to the attack. enabling them to unravel the chain of events that lead to the attack.
However, while auditability is an important deterrent, it is likely However, while auditability is an important deterrent, it is likely
to be of most benefit in situations where attacks on the emergency to be of most benefit in situations where attacks on the emergency
services system are likely to be relatively infrequent, since the services system are likely to be relatively infrequent, since the
resources required to pursue an investigation are likely to be resources required to pursue an investigation are likely to be
considerable. However, although real-time validation based on PIDF- considerable. However, although real-time validation based on PIDF-
LO elements is challenging, where LIS audit logs are available (such LO elements is challenging, where LIS audit logs are available (such
as where a law enforcement agency can present a subpoena), linking of as where a law enforcement agency can present a subpoena), linking of
a pseudonym to the device obtaining location can be accomplished in a a pseudonym to the device obtaining location can be accomplished in a
post-mortem. post-mortem.
Where attacks are frequent and continuous, automated mechanisms are Where attacks are frequent and continuous, automated mechanisms are
required. For example, it might be valuable to develop mechanisms to required. For example, it might be valuable to develop mechanisms to
exchange audit trails information in a standardized format between exchange audit trails information in a standardized format between
ISPs and PSAPs / VSPs and PSAPs or heuristics to distinguish ISPs and PSAPs / VSPs and PSAPs or heuristics to distinguish
potentially fraudulent emergency calls from real emergencies. While potentially fraudulent emergency calls from real emergencies. While
a Completely Automated Public Touring test to tell Computers and a Completely Automated Public Turing test to tell Computers and
Humans Apart (CAPTCHA) may be applied to suspicious calls to lower Humans Apart (CAPTCHA) may be applied to suspicious calls to lower
the risk from bot-nets, this is quite controversial for emergency the risk from bot-nets, this is quite controversial for emergency
services, due to the risk of delaying or rejecting valid calls. services, due to the risk of delaying or rejecting valid calls.
5. Security Considerations 5. Security Considerations
IP-based emergency services face a number of security threats that do IP-based emergency services face a number of security threats that do
not exist within the legacy system. In order to limit prank calls, not exist within the legacy system. Mechanically placing a large
legacy emergency services rely on the ability to identify callers, as number of emergency calls that appear to come from different
well as on the difficulty of location spoofing for normal users. The locations is difficult in a legacy environment. Also, in the current
ability to ascertain identity is important, since the threat of system, it would be very difficult for an attacker from country 'Foo'
punishment reduces prank calls; as an example, calls from pay phones to attack the emergency services infrastructure located in country
are subject to greater scrutiny by the call taker. 'Bar'.
Mechanically placing a large number of emergency calls that appear to
come from different locations is difficult in a legacy environment.
Also, in the current system, it would be very difficult for an
attacker from country 'Foo' to attack the emergency services
infrastructure located in country 'Bar'.
However, within an IP-based emergency services a number of these However, within an IP-based emergency services a number of these
attacks become much easier to mount. Emergency services have three attacks become much easier to mount. Emergency services have three
finite resources subject to denial of service attacks: the network finite resources subject to denial of service attacks: the network
and server infrastructure, call takers and dispatchers, and the first and server infrastructure, call takers and dispatchers, and the first
responders, such as fire fighters and police officers. Protecting responders, such as fire fighters and police officers. Protecting
the network infrastructure is similar to protecting other high-value the network infrastructure is similar to protecting other high-value
service providers, except that location information may be used to service providers, except that location information may be used to
filter call setup requests, to weed out requests that are out of filter call setup requests, to weed out requests that are out of
area. PSAPs even for large cities may only have a handful of PSAP area. Even for large cities PSAPs may only have a handful of call
call takers on duty, so even if they can, by questioning the caller, takers on duty. So even if call takers can, by questioning the
eliminate a lot of prank calls, they are quickly overwhelmed by even caller, eliminate many hoax calls, PSAPs can be overwhelmed even by a
a small-scale attack. Finally, first responder resources are scarce, small-scale attack. Finally, first responder resources are scarce,
particularly during mass-casualty events. particularly during mass-casualty events.
Attackers may want to modify, prevent or delay emergency calls. In Attackers may want to modify, prevent or delay emergency calls. In
some cases, this will lead the PSAP to dispatch emergency personnel some cases, this will lead the PSAP to dispatch emergency personnel
to an emergency that does not exist and, hence, the personnel might to an emergency that does not exist and, hence, the personnel might
not be available to other callers. It might also be possible for an not be available to other callers. It might also be possible for an
attacker to impede the users from reaching an appropriate PSAP by attacker to impede the users from reaching an appropriate PSAP by
modifying the location of an end host or the information returned modifying the location of an end host or the information returned
from the mapping protocol. In some countries, regulators may not from the mapping protocol. In some countries, regulators may not
require the authenticated identity of the emergency caller (e.g. require the authenticated identity of the emergency caller (e.g.
emergency calls placed from PSTN pay phones or SIM-less cell phones). emergency calls placed from PSTN pay phones or SIM-less cell phones).
Furthermore, if identities can easily be crafted (as it is the case Furthermore, if identities can easily be crafted (as it is the case
with many VoIP offerings today), then the value of emergency caller with many VoIP offerings today), then the value of emergency caller
authentication itself might be limited. As a consequence, an authentication itself might be limited. As a result, attackers can
attacker can forge emergency call information without the chance of forge emergency call information with a lower risk of being held
being held accountable for its own actions. accountable.
The above-mentioned attacks are mostly targeting individual emergency The above-mentioned attacks are mostly targeting individual emergency
callers or a very small fraction of them. If attacks are, however, callers or a very small fraction of them. If attacks are, however,
launched against the mapping architecture (see "Location-URL Mapping launched against the mapping architecture (see "Location-URL Mapping
Architecture and Framework" [RFC5582] or against the emergency Architecture and Framework" [RFC5582] or against the emergency
services IP network (including PSAPs), a larger region and a large services IP network (including PSAPs), a larger region and a large
number of potential emergency callers are affected. The call takers number of potential emergency callers are affected. The call takers
themselves are a particularly scarce resource and if human themselves are a particularly scarce resource and if human
interaction by these call takers is required then this can very interaction by these call takers is required then this can very
quickly have severe consequences. quickly have severe consequences.
skipping to change at page 20, line 4 skipping to change at page 22, line 5
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 many GPS-enabled devices that will find it be faked there will be many GPS-enabled devices that will find it
difficult to utilize any of the solutions described in Section 3. It difficult to utilize any of the solutions described in Section 3. It
is also unlikely that users will be willing to upload their location is also unlikely that users will be willing to upload their location
information for "verification" to a nearby location server located in information for "verification" to a nearby location server located in
the access network. the access network.
Nevertheless, it should be understood that mounting several of the Nevertheless, it should be understood that mounting several of the
attacks described in this document is non-trivial. Location theft attacks described in this document is non-trivial. Location theft
requires the attacker to be in proximity to the location being requires the attacker to be in proximity to the location being
spoofed, and location swapping requires the attacker to collude with spoofed, or to either collude with another endhost or gain control of
someone who was at the spoofed location. Time shifting attacks an endhost so as to obtain its location. Time shifting attacks
require that the attacker visit the location and submit it before the require that the attacker visit the location and submit it before the
location information is considered stale, while travelling rapidly location information is considered stale, while travelling rapidly
away from that location to avoid apprehension. Obtaining a PIDF-LO away from that location to avoid apprehension. Obtaining a PIDF-LO
from a spoofed IP address requires that the attacker be on the path from a spoofed IP address requires that the attacker be on the path
between the HELD requester and the LIS. between the HELD requester and the LIS.
6. IANA Considerations 6. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
7. References 7. References
7.1. Informative References 7.1. Informative References
[DHCP-URI-OPT] [I-D.ietf-stir-problem-statement]
Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 and Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
IPv6 Option for a Location Uniform Resource Identifier (URI)", Telephone Identity Problem Statement", Internet draft (work in
Internet draft (work in progress), draft-ietf-geopriv-dhcp- progress), draft-ietf-stir-problem-statement-05.txt, May 2014.
lbyr-uri-option-19, February 2013.
[I-D.ietf-stir-threats]
Peterson, J., "Secure Telephone Identity Threat Model",
Internet draft (work in progress), draft-ietf-stir-
threats-02.txt, February 2014.
[EENA] EENA, "False Emergency Calls", EENA Operations Document, [EENA] EENA, "False Emergency Calls", EENA Operations Document,
Version 1.0, March 2011, Version 1.1, May 2011, http://www.eena.org/ressource/static/
http://www.eena.org/ressource/static/files/ files/2012_05_04-3.1.2.fc_v1.1.pdf
2011_03_15_3.1.2.fc_v1.0.pdf
[GPSCounter] [GPSCounter]
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.
[NENA-i2] "08-001 NENA Interim VoIP Architecture for Enhanced 9-1-1 [NENA-i2] "08-001 NENA Interim VoIP Architecture for Enhanced 9-1-1
Services (i2)", December 2005. Services (i2)", December 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 21, line 21 skipping to change at page 23, line 27
Identity Management in the Session Initiation Protocol (SIP)", Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006. RFC 4474, August 2006.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July
2006. 2006.
[RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales- [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales-
Valenzuela, C., and K. Tammi, "Diameter Session Initiation Valenzuela, C., and K. Tammi, "Diameter Session Initiation
Protocol (SIP) Application", RFC 4740, November 2006. Protocol (SIP) Application", RFC 4740, November 2006.
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Context Resolution with Internet Technologies", RFC 5012,
January 2008.
[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H. and M. Shanmugam, [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H. and M. Shanmugam,
"Security Threats and Requirements for Emergency Call Marking "Security Threats and Requirements for Emergency Call Marking
and Mapping", RFC 5069, January 2008. and Mapping", RFC 5069, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Level Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Level Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5491] Winterbottom, J., Thomson, M. and H. Tschofenig, "GEOPRIV [RFC5491] Winterbottom, J., Thomson, M. and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", RFC Usage Clarification, Considerations, and Recommendations", RFC
skipping to change at page 22, line 5 skipping to change at page 24, line 14
[RFC5985] Barnes, M., "HTTP Enabled Location Delivery (HELD)", RFC 5985, [RFC5985] Barnes, M., "HTTP Enabled Location Delivery (HELD)", RFC 5985,
September 2010. September 2010.
[RFC6280] Barnes, R., et. al, "An Architecture for Location and Location [RFC6280] Barnes, R., et. al, "An Architecture for Location and Location
Privacy in Internet Applications", RFC 6280, July 2011. Privacy in Internet Applications", RFC 6280, July 2011.
[RFC6442] Polk, J., Rosen, B. and J. Peterson, "Location Conveyance for [RFC6442] Polk, J., Rosen, B. and J. Peterson, "Location Conveyance for
the Session Initiation Protocol", RFC 6442, December 2011. the Session Initiation Protocol", RFC 6442, December 2011.
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling Using Internet Multimedia",
RFC 6443, December 2011.
[RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A. [RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A.
Kuett, "Location Hiding: Problem Statement and Requirements", Kuett, "Location Hiding: Problem Statement and Requirements",
RFC 6444, January 2012. RFC 6444, January 2012.
[RFC6753] Winterbottom, J., Tschofenig. H., Schulzrinne, H. and M. [RFC6753] Winterbottom, J., Tschofenig. H., Schulzrinne, H. and M.
Thomson, "A Location Dereference Protocol Using HTTP-Enabled Thomson, "A Location Dereference Protocol Using HTTP-Enabled
Location Delivery (HELD)", RFC 6753, October 2012. Location Delivery (HELD)", RFC 6753, October 2012.
[SA] "Saudi Arabia - Illegal sale of SIMs blamed for surge in prank [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in Support of Emergency Calling", BCP
181, RFC 6881, March 2013.
[RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C. and M. Patel,
"Public Safety Answering Point (PSAP) Callback", RFC 7090,
April 2014.
[SA] "Saudi Arabia - Illegal sale of SIMs blamed for surge in hoax
calls", Arab News, May 4, 2010, calls", Arab News, May 4, 2010,
http://www.menafn.com/qn_news_story_s.asp?StoryId=1093319384 http://www.menafn.com/qn_news_story_s.asp?StoryId=1093319384
[STIR] IETF, "Secure Telephone Identity Revisited (stir) Working
Group", http://datatracker.ietf.org/wg/stir/charter/, October
2013.
[Swatting] [Swatting]
"Don't Make the Call: The New Phenomenon of 'Swatting', "Don't Make the Call: The New Phenomenon of 'Swatting',
Federal Bureau of Investigation, February 4, 2008, Federal Bureau of Investigation, February 4, 2008,
http://www.fbi.gov/news/stories/2008/february/swatting020408 http://www.fbi.gov/news/stories/2008/february/swatting020408
[TASMANIA] [TASMANIA]
"Emergency services seek SIM-less calls block", ABC News "Emergency services seek SIM-less calls block", ABC News
Online, August 18, 2006, Online, August 18, 2006,
http://www.abc.net.au/elections/tas/2006/news/stories/ http://www.abc.net.au/elections/tas/2006/news/stories/
1717956.htm?elections/tas/2006/ 1717956.htm?elections/tas/2006/
[UK] "Rapper makes thousands of prank 999 emergency calls to UK [UK] "Rapper makes thousands of prank 999 emergency calls to UK
police", Digital Journal, June 24, 2010, police", Digital Journal, June 24, 2010,
http://www.digitaljournal.com/article/293796?tp=1 http://www.digitaljournal.com/article/293796?tp=1
Acknowledgments Acknowledgments
We would like to thank the members of the IETF ECRIT working group, We would like to thank the members of the IETF ECRIT working group,
including Marc Linsner, Henning Schulzrinne and Brian Rosen, for including Marc Linsner and Brian Rosen, for their input at IETF 85
their input at IETF 85 that helped get this documented pointed in the that helped get this documented pointed in the right direction. We
right direction. We would also like to thank members of the IETF would also like to thank members of the IETF GEOPRIV WG, including
GEOPRIV WG, including Andrew Newton, Murugaraj Shanmugam, Martin Andrew Newton, Murugaraj Shanmugam, Martin Thomson, Richard Barnes
Thomson, Richard Barnes and Matt Lepinski for their feedback to and Matt Lepinski for their feedback to previous versions of this
previous versions of this document. Thanks also to Bert Wijnen and document. Thanks also to Pete Resnick, Adrian Farrel, Alissa Cooper,
Meral Shirazipour who provided review comments in IETF last call. Bert Wijnen and Meral Shirazipour who provided review comments in
IETF last call.
Authors' Addresses Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
ARM Ltd. ARM Ltd.
110 Fulbourn Rd 110 Fulbourn Rd
Cambridge CB1 9NJ Cambridge CB1 9NJ
Great Britain Great Britain
Email: Hannes.tschofenig@gmx.net Email: Hannes.tschofenig@gmx.net
 End of changes. 60 change blocks. 
257 lines changed or deleted 368 lines changed or added

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