draft-ietf-ecrit-trustworthy-location-14.txt   rfc7378.txt 
ECRIT Working Group H. Tschofenig Internet Engineering Task Force (IETF) H. Tschofenig
INTERNET-DRAFT Independent Request for Comments: 7378 Independent
Category: Informational H. Schulzrinne Category: Informational H. Schulzrinne
Expires: January 5, 2015 Columbia University ISSN: 2070-1721 Columbia University
B. Aboba (ed.) B. Aboba, Ed.
Microsoft Corporation Microsoft Corporation
28 July 2014 December 2014
Trustworthy Location Trustworthy Location
draft-ietf-ecrit-trustworthy-location-14.txt
Abstract Abstract
The trustworthiness of location information is critically important The trustworthiness of location information is critically important
for some location-based applications, such as emergency calling or for some location-based applications, such as emergency calling or
roadside assistance. roadside assistance.
This document describes threats relating to conveyance of location in This document describes threats to conveying location, particularly
an emergency call, and describes techniques that improve the for emergency calls, and describes techniques that improve the
reliability and security of location information conveyed in a IP- reliability and security of location information. It also provides
based emergency service call. It also provides guidelines for guidelines for assessing the trustworthiness of location information.
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 document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on January 5, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7378.
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 . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology ................................................3
1.2 Emergency Services Architecture . . . . . . . . . . . . . 5 1.2. Emergency Services Architecture ............................5
2. Threat Models . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Threat Models ...................................................8
2.1. Existing Work . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Existing Work ..............................................8
2.2 Adversary Model . . . . . . . . . . . . . . . . . . . . . 9 2.2. Adversary Model ............................................9
2.3. Location Spoofing . . . . . . . . . . . . . . . . . . . . 10 2.3. Location Spoofing .........................................10
2.4. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 10 2.4. Identity Spoofing .........................................11
3. Mitigation Techniques . . . . . . . . . . . . . . . . . . . . 11 3. Mitigation Techniques ..........................................11
3.1. Signed Location-by-Value . . . . . . . . . . . . . . . . . 11 3.1. Signed Location-by-Value ..................................12
3.2. Location-by-Reference . . . . . . . . . . . . . . . . . . 15 3.2. Location-by-Reference .....................................15
3.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 18 3.3. Proxy-Added Location ......................................18
4. Location Trust Assessment . . . . . . . . . . . . . . . . . . 19 4. Location Trust Assessment ......................................20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 5. Security Considerations ........................................23
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 23 6. Privacy Considerations .........................................24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 7. Informative References .........................................26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Acknowledgments ...................................................30
8.1. Informative references . . . . . . . . . . . . . . . . . . 25 Authors' Addresses ................................................30
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Several public and commercial services depend upon location Several public and commercial services need location information to
information in their operations. This includes emergency services operate. This includes emergency services (such as fire, ambulance,
(such as fire, ambulance and police) as well as commercial services and police) as well as commercial services such as food delivery and
such as food delivery and roadside assistance. roadside assistance.
For circuit-switched calls from landlines, as well as for Voice over For circuit-switched calls from landlines, as well as for Voice over
IP (VoIP) services only supporting emergency service calls from IP (VoIP) services that only support emergency service calls from
stationary devices, location provided to the Public Safety Answering stationary Devices, location provided to the Public Safety Answering
Point (PSAP) is determined from a lookup using the calling telephone Point (PSAP) is determined from a lookup using the calling telephone
number. As a result, for landlines or stationary VoIP, spoofing of number. As a result, for landlines or stationary VoIP, spoofing of
caller identification can result in the PSAP incorrectly determining caller identification can result in the PSAP incorrectly determining
the caller's location. Problems relating to calling party number and the caller's location. Problems relating to calling party number and
Caller ID assurance have been analyzed by the "Secure Telephone Caller ID assurance have been analyzed by the Secure Telephone
Identity Revisited" [STIR] Working Group as described in "Secure Identity Revisited [STIR] working group as described in "Secure
Telephone Identity Problem Statement and Requirements" [I-D.ietf- Telephone Identity Problem Statement and Requirements" [RFC7340]. In
stir-problem-statement]. In addition to the work underway in STIR, addition to the work underway in STIR, other mechanisms exist for
other mechanisms exist for validating caller identification. For validating caller identification. For example, as noted in [EENA],
example, as noted in [EENA], one mechanism for validating caller one mechanism for validating caller identification information (as
identification information (as well as the existence of an emergency) well as the existence of an emergency) is for the PSAP to call the
is for the PSAP to call the user back, as described in [RFC7090]. user back, as described in [RFC7090].
Given the existing work on caller identification, this document Given the existing work on caller identification, this document
focuses on the additional threats that are introduced by the support focuses on the additional threats that are introduced by the support
of IP-based emergency services in nomadic and mobile devices, in of IP-based emergency services in nomadic and mobile Devices, in
which location may be conveyed to the PSAP within the emergency call. which location may be conveyed to the PSAP within the emergency call.
Ideally, a call taker at a PSAP should be able to assess, in real- Ideally, a call taker at a PSAP should be able to assess, in real
time, the level of trust that can be placed on the information time, the level of trust that can be placed on the information
provided within a call. This includes automated location conveyed provided within a call. This includes automated location conveyed
along with the call and location information communicated by the along with the call and location information communicated by the
caller, as well as identity information relating to the caller or the caller, as well as identity information relating to the caller or the
device initiating the call. Where real-time assessment is not Device initiating the call. Where real-time assessment is not
possible, it is important to be able to determine the source of the possible, it is important to be able to determine the source of the
call in a post-incident investigation, so as to be able to enforce call in a post-incident investigation, so as to be able to enforce
accountability. accountability.
This document defines terminology (including the meaning of This document defines terminology (including the meaning of
"trustworthy location") in Section 1.1, reviews existing work in "trustworthy location") in Section 1.1, reviews existing work in
Section 1.2, describes the threat model in Section 2, outlines Section 1.2, describes threat models in Section 2, outlines potential
potential mitigation techniques in Section 3, covers trust assessment mitigation techniques in Section 3, covers trust assessment in
in Section 4 and discusses security considerations in Section 5. Section 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 definitions of "Internet Access Provider (IAP)", "Internet We use the definitions of "Internet Access Provider (IAP)", "Internet
Service Provider (ISP)" and "Voice Service Provider (VSP)" are taken Service Provider (ISP)", and "Voice Service Provider (VSP)" found in
from "Requirements for Emergency Context Resolution with Internet "Requirements for Emergency Context Resolution with Internet
Technologies" [RFC5012]. Technologies" [RFC5012].
The definition of a "hoax call" is taken from "False Emergency Calls" [EENA] defines a "hoax call" as follows: "A false or malicious call
[EENA]. is when a person deliberately telephones the emergency services and
tells them there is an emergency when there is not."
The definition of "Device", "Target" and "Location Information The definitions of "Device", "Target", and "Location Information
Server" (LIS) is taken from "An Architecture for Location and Server" (LIS) are taken from "An Architecture for Location and
Location Privacy in Internet Applications" [RFC6280], Section 7. Location Privacy in Internet Applications" [RFC6280], Section 7.
The term "Device" denotes the physical device, such as a mobile The term "Device" denotes the physical device, such as a mobile
phone, PC, or embedded micro-controller, whose location is tracked as phone, PC, or embedded microcontroller, whose location is tracked as
a proxy for the location of a Target. a proxy for the location of a Target.
The term "Target" denotes an individual or other entity whose The term "Target" denotes an individual or other entity whose
location is sought in the Geopriv architecture. In many cases, the location is sought in the Geopriv architecture [RFC6280]. In many
Target will be the human user of a Device, or it may be an object cases, the Target will be the human user of a Device, or it may be an
such as a vehicle or shipping container to which a Device is object such as a vehicle or shipping container to which a Device is
attached. In some instances, the Target will be the Device itself. attached. In some instances, the Target will be the Device itself.
The Target is the entity whose privacy Geopriv seeks to protect. The Target is the entity whose privacy the architecture described in
[RFC6280] seeks to protect.
The term "Location Information Server" denotes an entity responsible The term "Location Information Server" denotes an entity responsible
for providing devices within an access network with information about for providing Devices within an access network with information about
their own locations. A Location Information Server uses knowledge of their own locations. A Location Information Server uses knowledge of
the access network and its physical topology to generate and the access network and its physical topology to generate and
distribute location information to devices. distribute location information to Devices.
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 LIS or by the Target itself. It specifically does not
itself. It specifically does not refer to the location configuration refer to the location configuration protocol (LCP) used to deliver
protocol (LCP) used to deliver location information either to the location information to either the Target or the Recipient. This
Target or the Recipient. This term is re-used from "GEOPRIV PIDF-LO term is reused from "GEOPRIV Presence Information Data Format
Usage Clarification, Considerations, and Recommendations" [RFC5491]. Location Object (PIDF-LO) 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
which a Recipient (Target or Third-Party) obtains location which a Recipient (Target or third party) obtains location
information. information.
Additionally, the terms Location-by-Value (LbyV), Location-by- Additionally, the terms "location-by-value" (LbyV), "location-by-
Reference (LbyR), Location Configuration Protocol, Location reference" (LbyR), "Location Configuration Protocol", "Location
Dereference Protocol, and Location Uniform Resource Identifier (URI) Dereference Protocol", and "Location Uniform Resource Identifier"
are re-used from "Requirements for a Location-by-Reference Mechanism" (URI) are reused from "Requirements for a Location-by-Reference
[RFC5808]. Mechanism" [RFC5808].
"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.
"Identity Spoofing" is where the attacker forges or obscures their "Identity Spoofing" occurs when the attacker forges or obscures their
identity so as to prevent themselves from being identified as the identity so as to prevent themselves from being identified as the
source of the attack. One class of identity spoofing attack involves source of the attack. One class of identity spoofing attack involves
the forging of call origin identification. the forging of call origin identification.
The following additional terms apply to location spoofing: The following additional terms apply to location spoofing
(Section 2.3):
"Place Shifting" is where the attacker constructs a Presence With "Place Shifting", attackers construct a Presence Information
Information Data Format Location Object (PIDF-LO) for a location Data Format Location Object (PIDF-LO) for a location other than where
other than where they are currently located. In some cases, place they are currently located. In some cases, place shifting can be
shifting can be limited in range (e.g., within the coverage area of a limited in range (e.g., within the coverage area of a particular cell
particular cell tower). tower).
"Time Shifting" is where the attacker uses or re-uses location "Time Shifting" occurs when the attacker uses or reuses 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
because the attacker has moved. the attacker has moved.
"Location Theft" is where the attacker captures a Target's location "Location Theft" occurs when the attacker captures a Target's
information (possibly including a signature) and presents it as their location information (possibly including a signature) and presents it
own. Location theft can occur in a single instance, or may be as their own. Location theft can occur in a single instance or may
continuous (e.g., where the attacker has gained control over the be continuous (e.g., where the attacker has gained control over the
victim's device). Location theft may also be combined with time victim's Device). Location theft may also be combined with time
shifting to present someone else's location information after the shifting to present someone else's location information after the
original Target has moved. original Target has moved.
1.2. Emergency Services Architecture 1.2. Emergency Services Architecture
This section describes how location is utilized in the Internet This section describes how location is utilized in the Internet
Emergency Services Architecture, as well as the existing work on the Emergency Services Architecture, as well as the existing work on the
problem of hoax calls. problem of hoax calls.
1.2.1. Location 1.2.1. Location
The Internet architecture for emergency calling is described in The Internet architecture for emergency calling is described in
"Framework for Emergency Calling Using Internet Multimedia" "Framework for Emergency Calling Using Internet Multimedia"
[RFC6443]. Best practices for utilizing the architecture to make [RFC6443]. Best practices for utilizing the architecture to make
emergency calls are described in "Best Current Practice for emergency calls are described in "Best Current Practice for
Communications Services in Support of Emergency Calling" [RFC6881]. Communications Services in Support of Emergency Calling" [RFC6881].
As noted in "An Architecture for Location and Location Privacy in As noted in "An Architecture for Location and Location Privacy in
Internet Applications" [RFC6280] Section 6.3: Internet Applications" [RFC6280], Section 6.3:
"there are three critical steps in the placement of an emergency there are three critical steps in the placement of an emergency
call, each involving location information: call, each involving location information:
1. Determine the location of the caller. 1. Determine the location of the caller.
2. Determine the proper Public Safety Answering Point (PSAP) for 2. Determine the proper Public Safety Answering Point (PSAP) for
the caller's location. the caller's location.
3. Send a SIP INVITE message, including the caller's location, to 3. Send a SIP INVITE message, including the caller's location, to
the PSAP." the PSAP.
The conveyance of location information within the Session Initiation The conveyance of location information within the Session Initiation
Protocol (SIP) is described in "Location Conveyance for the Session Protocol (SIP) is described in "Location Conveyance for the Session
Initiation Protocol" [RFC6442]. Conveyance of Location-by-Value Initiation Protocol" [RFC6442]. Conveyance of location-by-value
(LbyV) as well as Location-by-Reference (LbyR) are supported. The (LbyV) as well as conveyance of location-by-reference (LbyR) are
Security Considerations (Section 7) discusses privacy, authentication supported. Section 7 of [RFC6442] ("Security Considerations")
and integrity concerns relating to conveyed location. This includes discusses privacy, authentication, and integrity concerns relating to
discussion of transmission layer security for confidentiality and conveyed location. This includes discussion of transmission-layer
integrity protection of SIP, as well as (undeployed) end-to-end security for confidentiality and integrity protection of SIP, as well
security mechanisms for protection of location information (e.g. as (undeployed) end-to-end security mechanisms for protection of
S/MIME). Regardless of whether transmission-layer security is location information (e.g., S/MIME). Regardless of whether
utilized, location information may be available for inspection by an transmission-layer security is utilized, location information may be
intermediary which, if it decides that the location value is available for inspection by an intermediary that -- if it decides
unacceptable or insufficiently accurate, may send an error indication that the location value is unacceptable or insufficiently accurate --
or replace the location, as described in [RFC6442] Section 3.4. may send an error indication or replace the location, as described in
[RFC6442], Section 3.4.
Although the infrastructure for location-based routing described in Although the infrastructure for location-based routing described in
[RFC6443] was developed for use in emergency services, [RFC6442] [RFC6443] was developed for use in emergency services, [RFC6442]
supports conveyance of location within non-emergency calls as well as supports conveyance of location within non-emergency calls as well as
emergency calls. "Implications of 'retransmission-allowed' for SIP emergency calls. Section 1 of "Implications of 'retransmission-
Location Conveyance" [RFC5606] Section 1 describes the overall allowed' for SIP Location Conveyance" [RFC5606] describes the overall
architecture, as well as non-emergency usage scenarios: architecture, as well as non-emergency usage scenarios (note: the
[LOC-CONVEY] citation in the quote below refers to the document later
published as [RFC6442]):
The Presence Information Data Format for Location Objects (PIDF-LO The Presence Information Data Format for Location Objects (PIDF-LO
[RFC4119]) carries both location information (LI) and policy [RFC4119]) carries both location information (LI) and policy
information set by the Rule Maker, as is stipulated in [RFC3693]. information set by the Rule Maker, as is stipulated in [RFC3693].
The policy carried along with LI allows the Rule Maker to The policy carried along with LI allows the Rule Maker to
restrict, among other things, the duration for which LI will be restrict, among other things, the duration for which LI will be
retained by recipients and the redistribution of LI by recipients. retained by recipients and the redistribution of LI by recipients.
The Session Initiation Protocol [RFC3261] is one proposed Using The Session Initiation Protocol [RFC3261] is one proposed Using
Protocol for PIDF-LO. The conveyance of PIDF-LO within SIP is Protocol for PIDF-LO. The conveyance of PIDF-LO within SIP is
specified in [RFC6442]. The common motivation for providing LI in specified in [LOC-CONVEY]. The common motivation for providing LI
SIP is to allow location to be considered in routing the SIP in SIP is to allow location to be considered in routing the SIP
message. One example use case would be emergency services, in message. One example use case would be emergency services, in
which the location will be used by dispatchers to direct the which the location will be used by dispatchers to direct the
response. Another use case might be providing location to be used response. Another use case might be providing location to be used
by services associated with the SIP session; a location associated by services associated with the SIP session; a location associated
with a call to a taxi service, for example, might be used to route with a call to a taxi service, for example, might be used to route
to a local franchisee of a national service and also to route the to a local franchisee of a national service and also to route the
taxi to pick up the caller. taxi to pick up the caller.
1.2.2. Hoax Calls 1.2.2. Hoax Calls
Hoax calls have been a problem for emergency services dating back to Hoax calls have been a problem for emergency services dating back to
the time of street corner call boxes. As the European Emergency the time of street corner call boxes. As the European Emergency
Number Association (EENA) has noted [EENA]: "False emergency calls Number Association (EENA) has noted [EENA]:
divert emergency services away from people who may be in life-
threatening situations and who need urgent help. This can mean the False emergency calls divert emergency services away from people
difference between life and death for someone in trouble." 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.
EENA [EENA] has attempted to define terminology and describe best EENA [EENA] has attempted to define terminology and describe best
current practices for dealing with false emergency calls. Reducing current practices for dealing with false emergency calls. Reducing
the number of hoax calls represents a challenge, since emergency the number of hoax calls represents a challenge, since emergency
services authorities in most countries are required to answer every services authorities in most countries are required to answer every
call (whenever possible). Where the caller cannot be identified, the call (whenever possible). Where the caller cannot be identified, the
ability to prosecute is limited. ability to prosecute is limited.
A particularly dangerous form of hoax call is "swatting" - a hoax A particularly dangerous form of hoax call is "swatting" -- a hoax
emergency call that draws a response from law enforcement prepared emergency call that draws a response from law enforcement prepared
for a violent confrontation (e.g. a fake hostage situation that for a violent confrontation (e.g., a fake hostage situation that
results in dispatching of a "Special Weapons And Tactics" (SWAT) results in the dispatching of a "Special Weapons And Tactics" (SWAT)
team). In 2008 the Federal Bureau of Investigation (FBI) issued a team). In 2008, the Federal Bureau of Investigation (FBI) issued a
warning [Swatting] about an increase in the frequency and warning [Swatting] about an increase in the frequency and
sophistication of these attacks. sophistication of these attacks.
As noted in [EENA], many documented cases of "swatting" involve not Many documented cases of "swatting" (also sometimes referred to as
only the faking of an emergency, but also falsification or "SWATing") involve not only the faking of an emergency but also
obfuscation of identity. There are a number of techniques by which falsification or obfuscation of identity [Swatting] [SWATing]. There
hoax callers attempt to avoid identification, and in general, the are a number of techniques by which hoax callers attempt to avoid
ability to identify the caller appears to influence the incidence of identification, and in general, the ability to identify the caller
hoax calls. appears to influence the incidence of hoax calls.
Where a Voice Service Provider enables setting of the outbound caller Where a Voice Service Provider allows the caller to configure its
identification without checking it against the authenticated outbound caller identification without checking it against the
identity, forging caller identification is trivial. Similarly where authenticated identity, forging caller identification is trivial.
an attacker can gain entry to a Private Branch Exchange (PBX), they Similarly, where an attacker can gain entry to a Private Branch
can then subsequently use that access to launch a denial of service Exchange (PBX), they can then subsequently use that access to launch
attack against the PSAP, or to make fraudulent emergency calls. a denial-of-service attack against the PSAP or make fraudulent
Where emergency calls have been allowed from handsets lacking a SIM emergency calls. Where emergency calls have been allowed from
card, or where ownership of the SIM card cannot be determined, the handsets lacking a subscriber identification module (SIM) card,
frequency of hoax calls has often been unacceptably high so-called non-service initialized (NSI) handsets, or where ownership
[TASMANIA][UK][SA]. of the SIM card cannot be determined, the frequency of hoax calls has
often been unacceptably high [TASMANIA] [UK] [SA].
However, there are few documented cases of hoax calls that have However, there are few documented cases of hoax calls that have
arisen from conveyance of untrustworthy location information within arisen from conveyance of untrustworthy location information within
an emergency call, which is the focus of this document. an emergency call, which is the focus of this document.
2. Threat Models 2. Threat Models
This section reviews existing analyses of the security of emergency This section reviews existing analyses of the security of emergency
services, threats to geographic location privacy, threats relating to services, threats to geographic location privacy, threats relating to
spoofing of caller identification and modification of location spoofing of caller identification, and threats related to
information in transit. In addition, the threat model applying to modification of location information in transit. In addition, the
this work is described. threat model applying to this work is described.
2.1. Existing Work 2.1. Existing Work
"An Architecture for Location and Location Privacy in Internet "An Architecture for Location and Location Privacy in Internet
Applications" [RFC6280] describes an architecture for privacy- Applications" [RFC6280] describes an architecture for privacy-
preserving location-based services in the Internet, focusing on preserving location-based services in the Internet, focusing on
authorization, security and privacy requirements for the data formats authorization, security, and privacy requirements for the data
and protocols used by these services. formats and protocols used by these services.
Within the Security Considerations (Section 5), mechanisms for In Section 5 of [RFC6280] ("An Architecture for Location and Location
ensuring the security of the location distribution chain are Privacy in Internet Applications"), mechanisms for ensuring the
discussed; these include mechanisms for hop-by-hop confidentiality security of the location distribution chain are discussed; these
and integrity protection as well as end-to-end assurance. include mechanisms for hop-by-hop confidentiality and integrity
protection as well as end-to-end assurance.
"Geopriv Requirements" [RFC3693] focuses on the authorization, "Geopriv Requirements" [RFC3693] focuses on the authorization,
security and privacy requirements of location-dependent services, security, and privacy requirements of location-dependent services,
including emergency services. Within the Security Considerations including emergency services. Section 8 of [RFC3693] includes
(Section 8), this includes discussion of emergency services discussion of emergency services authentication (Section 8.3), and
authentication (Section 8.3), and issues relating to identity and issues relating to identity and anonymity (Section 8.4).
anonymity (Section 8.4).
"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.
"Security Threats and Requirements for Emergency Call Marking and "Security Threats and Requirements for Emergency Call Marking and
Mapping" [RFC5069] reviews security threats associated with the Mapping" [RFC5069] reviews security threats associated with the
marking of signaling messages and the process of mapping locations to marking of signaling messages and the process of mapping locations to
Universal Resource Identifiers (URIs) that point to PSAPs. RFC 5069 Universal Resource Identifiers (URIs) that point to PSAPs. RFC 5069
describes attacks on the emergency services system, such as describes attacks on the emergency services system, such as
attempting to deny system services to all users in a given area, to 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- gain fraudulent use of services and to divert emergency calls to
emergency sites. In addition, it describes attacks against non-emergency sites. In addition, it 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, as well as receiving aid, or to gain information about an emergency, as well as
attacks on emergency services infrastructure elements, such as attacks on emergency services infrastructure elements, such as
mapping discovery and mapping servers. mapping discovery and mapping servers.
"Secure Telephone Identity Threat Model" [I-D.ietf-stir-threats] "Secure Telephone Identity Threat Model" [RFC7375] analyzes threats
analyzes threats relating to impersonation and obscuring of calling relating to impersonation and obscuring of calling party numbers,
party numbers, reviewing the capabilities available to attackers, and reviewing the capabilities available to attackers, and the scenarios
the scenarios in which attacks are launched. in which attacks are launched.
2.2. Adversary Model 2.2. Adversary 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 infrastructure 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 (which is
mapping locations to PSAP address, or call routing elements, may used for mapping locations to PSAP addresses), or call routing
act maliciously. elements, may 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 the end host is
acting under the control of a third party. acting under the control of a third party.
Since previous work describes attacks against infrastructure elements Since previous work describes attacks against infrastructure elements
(e.g. location servers, call route servers, mapping servers) or the (e.g., location servers, call route servers, mapping servers) or the
emergency services IP network, as well as threats from attackers emergency services IP network, as well as threats from attackers
attempting to snoop location in transit, this document focuses on the attempting to snoop location in transit, this document focuses on the
threats arising from end hosts providing false location information threats arising from end hosts providing false location information
within emergency calls (the malicious end host adversary model). within emergency calls (the malicious end host adversary model).
Since the focus is on malicious hosts, we do not cover threats that Since the focus is on malicious hosts, we do not cover threats that
may arise from attacks on infrastructure that hosts depend on to may arise from attacks on infrastructure that hosts depend on to
obtain location. For example, end hosts may obtain location from obtain location. For example, end hosts may obtain location from
civilian GPS, which is vulnerable to spoofing [GPSCounter] or from civilian GPS, which is vulnerable to spoofing [GPSCounter], or from
third party Location Service Providers (LSPs) which may be vulnerable third-party Location Service Providers (LSPs) that may be vulnerable
to attack or may not provide location accuracy suitable for emergency to attack or may not provide location accuracy suitable for emergency
purposes. purposes.
Also, we do not cover threats arising from inadequate location Also, we do not cover threats arising from inadequate location
infrastructure. For example, a stale wiremap or an inaccurate access infrastructure. For example, the LIS or end host could base its
point location database could be utilized by the Location Information location determination on a stale wiremap or an inaccurate access
Server (LIS) or the end host in its location determination, thereby point location database, leading to an inaccurate location estimate.
leading to an inaccurate determination of location. Similarly, a Similarly, a Voice Service Provider (VSP) (and, indirectly, a LIS)
Voice Service Provider (VSP) (and indirectly a LIS) could utilize the could utilize the wrong identity (such as an IP address) for location
wrong identity (such as an IP address) for location lookup, thereby lookup, thereby providing the end host with misleading location
providing the end host with misleading location information. information.
2.3. Location Spoofing 2.3. Location Spoofing
Where location is attached to the emergency call by an end host, the 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 end host can fabricate a PIDF-LO and convey it within an emergency
call. The following represent examples of location spoofing: call. The following represent examples of location spoofing:
Place shifting: Trudy, the adversary, pretends to be at an Place shifting: Mallory, 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: Mallory pretends to be at a location where she was
while ago. a while ago.
Location theft: Trudy observes or obtains Alice's location and Location theft: Mallory observes or obtains Alice's location and
replays it as her own. replays it as her own.
2.4. Identity Spoofing 2.4. Identity Spoofing
While this document does not focus on the problems created by While this document does not focus on the problems created by
determination of location based on spoofed caller identification, the determination of location based on spoofed caller identification, the
ability to ascertain identity is important, since the threat of ability to ascertain identity is important, since the threat of
punishment reduces hoax calls. As an example, calls from pay phones punishment reduces hoax calls. As an example, calls from pay phones
are subject to greater scrutiny by the call taker. 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 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
(EAP) [RFC3748]); Protocol (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, the network access identity may also not have
as in the case where an open IEEE 802.11 Access Point is used to been authenticated, such as in the case where an open IEEE 802.11
initiate a hoax emergency call. Although endpoint information such Access Point is used to initiate a hoax emergency call. Although
as the IP or MAC address may have been logged, tying this back to the endpoint information such as the IP address or Media Access Control
device owner may be challenging. (MAC) address may have been logged, tying this back to the Device
owner may be challenging.
Unlike the existing telephone system, VoIP emergency calls can Unlike the existing telephone system, VoIP emergency calls can
provide an 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, ISP or VSP. However, due to the business relationship with the IAP, ISP, or VSP. However, due to the
time-critical nature of emergency calls, multi-layer authentication time-critical nature of emergency calls, multi-layer authentication
is undesirable, so that in most cases, only the device placing the is undesirable. Thus, in most cases, only the Device placing the
call will be able to be identified. Furthermore, deploying call will be able to be identified. Furthermore, deploying
additional credentials for emergency service purposes (such as additional credentials for emergency service purposes (such as
certificates) increases costs, introduces a significant 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. Mitigation Techniques 3. Mitigation Techniques
The sections that follow present three mechanisms for mitigating the The sections that follow present three mechanisms for mitigating the
threats presented in Section 2: threats presented in Section 2:
1. Signed location by value (Section 3.1), which provides for 1. Signed location-by-value (Section 3.1), which provides for
authentication and integrity protection of the PIDF-LO. At the authentication and integrity protection of the PIDF-LO. There is
time of this writing, there is only an expired straw-man proposal only an expired straw-man proposal for this mechanism
for this mechanism [I-D.thomson-geopriv-location-dependability], [Loc-Dependability]; thus, as of the time of this writing this
so that it is not suitable for deployment. mechanism is not suitable for deployment.
2. Location-by-reference (Section 3.2), which enables location to 2. Location-by-reference (Section 3.2), which enables location to be
be obtained by the PSAP directly from the location server, over a obtained by the PSAP directly from the location server, over a
confidential and integrity-protected channel, avoiding confidential and integrity-protected channel, avoiding
modification by the end-host or an intermediary. This mechanism modification by the end host or an intermediary. This mechanism
is specified in [RFC6753]. is specified in [RFC6753].
3. Proxy added location (Section 3.3), which protects against 3. Proxy-added location (Section 3.3), which protects against
location forgery by the end host. This mechanism is specified in location forgery by the end host. This mechanism is specified in
[RFC6442]. [RFC6442].
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 Target. The signed location information before it is sent to the Target. The signed location
information is then sent to the location recipient, who verifies it. information is then sent to the Location Recipient, who verifies it.
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
(b) and it is then conveyed to the location recipient in step (c) who step (b), and it is then conveyed to the Location Recipient, who
verifies it. For SIP, the procedures described in "Location verifies it (step (c)). For SIP, the procedures described in
Conveyance for the Session Initiation Protocol" [RFC6442] are "Location Conveyance for the Session Initiation Protocol" [RFC6442]
applicable for location conveyance. are applicable for location conveyance.
+-----------+ +-----------+ +-----------+ +-----------+
| | | Location | | | | Location |
| LIS | | Recipient | | LIS | | Recipient |
| | | | | | | |
+-+-------+-+ +----+------+ +-+-------+-+ +----+------+
^ | --^ ^ | --^
| | -- | | --
Geopriv |Req. | -- Geopriv |Req. | --
Location |Signed |Signed -- Protocol Conveying Location |Signed |Signed -- Protocol Conveying
Configuration |Loc. |Loc. -- Location (e.g. SIP) Configuration |Loc. |Loc. -- Location (e.g., SIP)
Protocol |(a) |(b) -- (c) Protocol |(a) |(b) -- (c)
| v -- | v --
+-+-------+-+ -- +-+-------+-+ --
| Target / | -- | Target / | --
| End Host + | End Host +
| | | |
+-----------+ +-----------+
Figure 1: Location Signing Figure 1: Location Signing
A straw-man proposal for location signing is provided in "Digital A straw-man proposal for location signing is provided in "Digital
Signature Methods for Location Dependability" [I-D.thomson-geopriv- Signature Methods for Location Dependability" [Loc-Dependability].
location-dependability]. Note that since this document is no longer Note that since [Loc-Dependability] is no longer under development,
under development, location signing cannot be considered deployable location signing cannot be considered deployable at the time of this
at the time of this writing. writing.
In order to limit replay attacks, this document proposes the addition In order to limit replay attacks, that proposal calls for the
of a "validity" element to the PIDF-LO, including a "from" sub- addition of a "validity" element to the PIDF-LO, including a "from"
element containing the time that location information was validated sub-element containing the time that location information was
by the signer, as well as an "until" sub-element containing the last validated by the signer, as well as an "until" sub-element containing
time that the signature can be considered valid. 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
LO, or incur the additional delay of querying during an emergency PIDF-LO, or incur the additional delay of querying during an
call. emergency 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:
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 when [RFC4474] is
implemented.
To address location-spoofing attacks, [I-D.thomson-geopriv-location- To address location-spoofing attacks, [Loc-Dependability] proposes
dependability] proposes addition of an "identity" element which could the addition of an "identity" element that could include a SIP URI
include a SIP URI (enabling comparison against the identity asserted (enabling comparison against the identity asserted in the SIP
in the SIP headers) or an X.509v3 certificate. If the target was headers) or an X.509v3 certificate. If the Target was authenticated
authenticated by the LIS, an "authenticated" attribute is added. by the LIS, an "authenticated" attribute is added. However, because
However, inclusion of an "identity" attribute could enable location the inclusion of an "identity" element could enable location
tracking, so that a "hash" element is also proposed which could tracking, a "hash" element is also proposed that could instead
contain a hash of the content of the "identity" element instead. In contain a hash of the content of the "identity" element. 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 cannot deter attacks in which valid location Location signing cannot deter attacks in which valid location
information is provided. For example, an attacker in control of information is provided. For example, an attacker in control of
compromised hosts could launch a denial-of-service attack on the PSAP compromised hosts could launch a denial-of-service attack on the PSAP
by initiating a large number of emergency calls, each containing by initiating a large number of emergency calls, each containing
valid signed location information. Since the work required to verify valid signed location information. Since the work required to verify
the location signature is considerable, this could overwhelm the PSAP the location signature is considerable, this could overwhelm the PSAP
infrastructure. infrastructure.
However, while DDOS attacks are unlikely to be deterred by location However, while DDoS attacks are unlikely to be deterred by location
signing, accurate location information would limit the subset of signing, accurate location information would limit the subset of
compromised hosts that could be used for an attack, as only hosts 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 GPS, and the Recipient will need to rely on its
its ability to assess the level of trust that should be placed in the ability to assess the level of trust that should be placed in the end
end host location claim. host location claim.
Even though location signing mechanisms have not been standardized, Even though location-signing mechanisms have not been standardized,
[NENA-i2] Section 3.7 includes operational recommendations relating [NENA-i2], Section 4.7 includes operational recommendations relating
to location signing: to location signing:
Location determination is out of scope for NENA, but we can offer Location configuration and conveyance requirements are described
guidance on what should be considered when designing mechanisms to in NENA 08-752[27], but guidance is offered here on what should be
report location: considered when designing mechanisms to report location:
1. The location object should be digitally signed. 1. The location object should be digitally signed.
2. The certificate for the signer (LIS operator) should be 2. The certificate for the signer (LIS operator) should be rooted
rooted in VESA. For this purpose, VPC and ERDB operators in VESA. For this purpose, VPC and ERDB operators should issue
should issue certs to LIS operators. certificates to LIS operators.
3. The signature should include a timestamp. 3. The signature should include a timestamp.
4. Where possible, the Location Object should be refreshed 4. Where possible, the Location Object should be refreshed
periodically, with the signature (and thus the timestamp) periodically, with the signature (and thus the timestamp) being
being refreshed as a consequence. refreshed as a consequence.
5. Anti-spoofing mechanisms should be applied to the Location 5. Antispoofing mechanisms should be applied to the Location
Reporting method. Reporting method.
[Note: The term Valid Emergency Services Authority (VESA) refers (Note: The term "Valid Emergency Services Authority" (VESA) refers to
to the root certificate authority. VPC stands for VoIP the root certificate authority. "VPC" stands for VoIP Positioning
Positioning Center and ERDB stands for the Emergency Service Zone Center, and "ERDB" stands for the Emergency Service Zone Routing
Routing Database.] Database.)
As noted above, signing of location objects implies the development As noted above, signing of location objects implies the development
of a trust hierarchy that would enable a certificate chain provided of a trust hierarchy that would enable a certificate chain provided
by the LIS operator to be verified by the PSAP. Rooting the trust by the LIS operator to be verified by the PSAP. Rooting the trust
hierarchy in VESA can be accomplished either by having the VESA hierarchy in the VESA can be accomplished either by having the VESA
directly sign the LIS certificates, or by the creation of directly sign the LIS certificates or by the creation of intermediate
intermediate Certificate Authorities (CAs) certified by the VESA, Certificate Authorities (CAs) certified by the VESA, which will then
which will then issue certificates to the LIS. In terms of the issue certificates to the LIS. In terms of the workload imposed on
workload imposed on the VESA, the latter approach is highly the VESA, the latter approach is highly preferable. However, this
preferable. However, this raises the question of who would operate raises the question of who would operate the intermediate CAs and
the intermediate CAs and what the expectations would be. 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 a Secure Socket
Layer/Transport Layer Security (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. Also, since location-by-reference enables reasonable alternative. Also, since location-by-reference enables
the PSAP to directly contact the location server, it avoids potential the PSAP to directly contact the location server, it avoids potential
attacks by intermediaries. attacks by intermediaries.
As noted in "A Location Dereference Protocol Using HTTP-Enabled As noted in "A Location Dereference Protocol Using HTTP-Enabled
Location Delivery (HELD)" [RFC6753], a location reference can be Location Delivery (HELD)" [RFC6753], a location reference can be
obtained via HTTP-Enabled Location Delivery (HELD) [RFC5985]. In obtained via HELD [RFC5985]. In addition, "Location Configuration
addition, "Location Configuration Extensions for Policy Management" Extensions for Policy Management" [RFC7199] extends location
[RFC7199] extends location configuration protocols such as HELD to configuration protocols such as HELD to provide hosts with a
provide hosts with a reference to the rules that apply to a Location- reference to the rules that apply to a location-by-reference so that
by-Reference so that the host can view or set these rules. the host can view or set these rules.
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 and potentially the policy in step (b), and it is then reference and, potentially, the policy in step (b), and it is then
conveyed to the location recipient in step (c). The location conveyed to the Location Recipient in step (c). The Location
recipient needs to resolve the reference with a request in step (d). Recipient needs to resolve the reference with a request in step (d).
Finally, location information is returned to the Location Recipient Finally, location information is returned to the Location Recipient
afterwards. For location conveyance in SIP, the procedures described afterwards. For location conveyance in SIP, the procedures described
in [RFC6442] are applicable. in [RFC6442] are applicable.
+-----------+ Geopriv +-----------+ +-----------+ Geopriv +-----------+
| | Location | Location | | | Location | Location |
| LIS +<------------->+ Recipient | | LIS +<------------->+ Recipient |
| | Dereferencing | | | | Dereferencing | |
+-+-------+-+ Protocol (d) +----+------+ +-+-------+-+ Protocol (d) +----+------+
^ | --^ ^ | --^
| | -- | | --
Geopriv |Req. |LbyR + -- Geopriv |Req. |LbyR + --
Location |LbyR |Policy -- Protocol Conveying Location |LbyR |Policy -- Protocol Conveying
Configuration |(a) |(b) -- Location (e.g. SIP) Configuration |(a) |(b) -- Location (e.g., SIP)
Protocol | | -- (c) Protocol | | -- (c)
| V -- | 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 dereference the LbyR in order to obtain location. The details for
dereferencing operations vary with the type of reference, such as a the dereferencing operations vary with the type of reference, such as
HTTP, HTTPS, SIP, SIPS URI or a SIP presence URI. an HTTP, HTTPS, SIP, secure SIP (SIPS), or SIP Presence URI.
For location-by-reference, the location server needs to maintain one For location-by-reference, the location server needs to maintain one
or several URIs for each target, timing out these URIs after a or several URIs for each Target, timing out these URIs after a
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 theft. 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 dereference 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
if authentication fails or cannot be attempted. if authentication fails or cannot be attempted.
skipping to change at page 17, line 5 skipping to change at page 17, line 35
Protection of the location URI is necessary, since the policy Protection of the location URI is necessary, since the policy
attached to such a location URI permits anyone who has the URI to attached to such a location URI permits anyone who has the URI to
view the associated location information. This aspect of security view the associated location information. This aspect of security
is covered in more detail in the specification of location is covered in more detail in the specification of location
conveyance protocols, such as [RFC6442]. conveyance protocols, such as [RFC6442].
For authorizing access to location-by-reference, two authorization For authorizing access to location-by-reference, two authorization
models were developed: "Authorization by Possession" and models were developed: "Authorization by Possession" and
"Authorization via Access Control Lists". With respect to "Authorization via Access Control Lists". With respect to
"Authorization by Possession" [RFC6753] Section 4.1 notes: "Authorization by Possession", [RFC6753], Section 4.1 notes:
In this model, possession -- or knowledge -- of the location URI In this model, possession -- or knowledge -- of the location URI
is used to control access to location information. A location URI is used to control access to location information. A location URI
might be constructed such that it is hard to guess (see C8 of might be constructed such that it is hard to guess (see C8 of
[RFC5808]), and the set of entities that it is disclosed to can be [RFC5808]), and the set of entities that it is disclosed to can be
limited. The only authentication this would require by the LS is limited. The only authentication this would require by the LS is
evidence of possession of the URI. The LS could immediately evidence of possession of the URI. The LS could immediately
authorize any request that indicates this URI. authorize any request that indicates this URI.
Authorization by possession does not require direct interaction Authorization by possession does not require direct interaction
with Rule Maker; it is assumed that the Rule Maker is able to with a Rule Maker; it is assumed that the Rule Maker is able to
exert control over the distribution of the location URI. exert control over the distribution of the location URI.
Therefore, the LIS can operate with limited policy input from a Therefore, the LIS can operate with limited policy input from a
Rule Maker. Rule Maker.
Limited disclosure is an important aspect of this authorization Limited disclosure is an important aspect of this authorization
model. The location URI is a secret; therefore, ensuring that model. The location URI is a secret; therefore, ensuring that
adversaries are not able to acquire this information is paramount. adversaries are not able to acquire this information is paramount.
Encryption, such as might be offered by TLS [RFC5246] or S/MIME Encryption, such as might be offered by TLS [RFC5246] or S/MIME
[RFC5751], protects the information from eavesdroppers. [RFC5751], protects the information from eavesdroppers.
...
Using possession as a basis for authorization means that, once Using possession as a basis for authorization means that, once
granted, authorization cannot be easily revoked. Cancellation of granted, authorization cannot be easily revoked. Cancellation of
a location URI ensures that legitimate users are also affected; a location URI ensures that legitimate users are also affected;
application of additional policy is theoretically possible but application of additional policy is theoretically possible but
could be technically infeasible. Expiration of location URIs could be technically infeasible. Expiration of location URIs
limits the usable time for a location URI, requiring that an limits the usable time for a location URI, requiring that an
attacker continue to learn new location URIs to retain access to attacker continue to learn new location URIs to retain access to
current location information. current location information.
In situations where "Authorization by Possession" is not suitable In situations where "Authorization by Possession" is not suitable
(such as where location hiding [RFC6444] is required), the (such as where location hiding [RFC6444] is required), the
"Authorization via Access Control Lists" model may be preferred. "Authorization via Access Control Lists" model may be preferred.
Without the introduction of hierarchy, it would be necessary for the Without the introduction of a hierarchy, it would be necessary for
PSAP to obtain credentials, such as certificates or shared symmetric the PSAP to obtain credentials, such as certificates or shared
keys, for all the LISes in its coverage area, to enable it to symmetric keys, for all the LISs in its coverage area, to enable it
successfully dereference LbyRs. In situations with more than a few to successfully dereference LbyRs. In situations with more than a
LISes per PSAP, this would present operational challenges. few LISs per PSAP, this would present operational challenges.
A certificate hierarchy providing PSAPs with client certificates A certificate hierarchy providing PSAPs with client certificates
chaining to the VESA could be used to enable the LIS to authenticate chaining to the VESA could be used to enable the LIS to authenticate
and authorize PSAPs for dereferencing. Note that unlike PIDF-LO and authorize PSAPs for dereferencing. Note that unlike PIDF-LO
signing (which mitigates against modification of PIDF-LOs), this signing (which mitigates modification of PIDF-LOs), this merely
merely provides the PSAP with access to a (potentially unsigned) provides the PSAP with access to a (potentially unsigned) PIDF-LO,
PIDF-LO, albeit over a protected TLS channel. albeit over a protected TLS channel.
Another approach would be for the local LIS to upload location Another approach would be for the local LIS to upload location
information to a location aggregation point who would in turn manage information to a location aggregation point who would in turn manage
the relationships with the PSAP. This would shift the management the relationships with the PSAP. This would shift the management
burden from the PSAPs to the location aggregation points. burden from the PSAPs to the location aggregation points.
3.3. Proxy Adding Location 3.3. Proxy-Added Location
Instead of relying upon the end host to provide location, is possible Instead of relying upon the end host to provide location, is possible
for a proxy that has the ability to determine the location of the end for a proxy that has the ability to determine the location of the end
point (e.g., based on the end host IP or MAC address) to retrieve and point (e.g., based on the end host IP or MAC address) to retrieve and
add or override location information. This requires deployment of add or override location information. This requires deployment of
application layer entities by ISPs, unlike the two other techniques. application-layer entities by ISPs, unlike the two other techniques.
The proxies could be used for emergency or non-emergency The proxies could be used for emergency or non-emergency
communications, or both. communications, or both.
The use of proxy-added location is primarily applicable in scenarios The use of proxy-added location is primarily applicable in scenarios
where the end host does not provide location. As noted in [RFC6442] where the end host does not provide location. As noted in [RFC6442],
Section 4.1: Section 4.1:
A SIP intermediary SHOULD NOT add location to a SIP request that A SIP intermediary SHOULD NOT add location to a SIP request that
already contains location. This will quite often lead to already contains location. This will quite often lead to
confusion within LRs. However, if a SIP intermediary adds confusion within LRs. However, if a SIP intermediary adds
location, even if location was not previously present in a SIP location, even if location was not previously present in a SIP
request, that SIP intermediary is fully responsible for addressing request, that SIP intermediary is fully responsible for addressing
the concerns of any 424 (Bad Location Information) SIP response it the concerns of any 424 (Bad Location Information) SIP response it
receives about this location addition and MUST NOT pass on receives about this location addition and MUST NOT pass on
(upstream) the 424 response. A SIP intermediary that adds a (upstream) the 424 response. A SIP intermediary that adds a
locationValue MUST position the new locationValue as the last locationValue MUST position the new locationValue as the last
locationValue within the Geolocation header field of the SIP locationValue within the Geolocation header field of the SIP
request. request.
...
A SIP intermediary MAY add a Geolocation header field if one is A SIP intermediary MAY add a Geolocation header field if one is
not present -- for example, when a user agent does not support the not present -- for example, when a user agent does not support the
Geolocation mechanism but their outbound proxy does and knows the Geolocation mechanism but their outbound proxy does and knows the
Target's location, or any of a number of other use cases (see Target's location, or any of a number of other use cases (see
Section 3). Section 3).
As noted in [RFC6442] Section 3.3: As noted in [RFC6442], Section 3.3:
This document takes a "you break it, you bought it" approach to This document takes a "you break it, you bought it" approach to
dealing with second locations placed into a SIP request by an dealing with second locations placed into a SIP request by an
intermediary entity. That entity becomes completely responsible intermediary entity. That entity becomes completely responsible
for all location within that SIP request (more on this in Section for all location within that SIP request (more on this in
4). Section 4).
While it is possible for the proxy to override location included by While it is possible for the proxy to override location included by
the end host, [RFC6442] Section 3.4 notes the operational the end host, [RFC6442], Section 3.4 notes the operational
limitations: limitations:
Overriding location information provided by the user requires a Overriding location information provided by the user requires a
deployment where an intermediary necessarily knows better than an deployment where an intermediary necessarily knows better than an
end user -- after all, it could be that Alice has an on-board GPS, end user -- after all, it could be that Alice has an on-board GPS,
and the SIP intermediary only knows her nearest cell tower. Which and the SIP intermediary only knows her nearest cell tower. Which
is more accurate location information? Currently, there is no way is more accurate location information? Currently, there is no way
to tell which entity is more accurate or which is wrong, for that to tell which entity is more accurate or which is wrong, for that
matter. This document will not specify how to indicate which matter. This document will not specify how to indicate which
location is more accurate than another. location is more accurate than another.
The disadvantage of this approach is the need to deploy application The disadvantage of this approach is the need to deploy application-
layer entities, such as SIP proxies, at IAPs or associated with IAPs. layer entities, such as SIP proxies, at IAPs or associated with IAPs.
This requires a standardized VoIP profile to be deployed at every end This requires that a standardized VoIP profile be deployed at every
device and at every IAP. This might impose interoperability end Device and at every IAP. This might impose interoperability
challenges. challenges.
Additionally, the IAP needs to take responsibility for emergency Additionally, the IAP needs to take responsibility for emergency
calls, even for customers they have no direct or indirect calls, even for customers with whom they have no direct or indirect
relationship with. To provide identity information about the relationship. To provide identity information about the emergency
emergency caller from the VSP it would be necessary to let the IAP caller from the VSP, it would be necessary to let the IAP and the VSP
and the VSP to interact for authentication (see, for example, interact for authentication (see, for example, "Diameter Session
"Diameter Session Initiation Protocol (SIP) Application" [RFC4740]). Initiation Protocol (SIP) Application" [RFC4740]). This interaction
This interaction along the Authentication, Authorization and along the Authentication, Authorization, and Accounting
Accounting infrastructure is often based on business relationships infrastructure is often based on business relationships between the
between the involved entities. An arbitrary IAP and VSP are unlikely involved entities. An arbitrary IAP and VSP are unlikely to have a
to have a business relationship. In case the interaction between the business relationship. If the interaction between the IAP and the
IAP and the VSP fails due to the lack of a business relationship then VSP fails due to the lack of a business relationship, then typically
typically a fall-back would be provided where no emergency caller a fall-back would be provided where no emergency caller identity
identity information is made available to the PSAP and the emergency information is made available to the PSAP and the emergency call
call still has to be completed. 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
as part of the decision making process. As an example, if automated part of the decision-making process. As an example, if automated
location information is understood to be highly suspect or is absent, location information is understood to be highly suspect or is absent,
a call taker can put more effort into verifying the authenticity of a call taker can put more effort into verifying the authenticity of
the call and to obtaining location information from the caller. the call and 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 itself is authenticated (e.g. signed location) or is location itself is authenticated (e.g., signed location) or is
obtained directly from the location server (e.g. location-by- obtained directly from the location server (e.g., location-by-
reference) over security transport, since these mechanisms do not reference) over security transport, since these mechanisms do not
provide assurance of the validity or provenance of location data. provide assurance of the validity or provenance of location data.
To prevent location-theft attacks, the "entity" element of the PIDF- To prevent location-theft attacks, the "entity" element of the
LO is of limited value if an unlinked pseudonym is provided in this PIDF-LO is of limited value if an unlinked pseudonym is provided in
field. However, if the LIS authenticates the target, then the this 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 in a post-incident investigation. recovered in a post-incident investigation.
As noted in [I.D.thomson-geopriv-location-dependability], if the As noted in [Loc-Dependability], if the location object was signed,
location object was signed, the location recipient has additional the Location Recipient has additional information on which to base
information on which to base their trust assessment, such as the their trust assessment, such as the validity of the signature, the
validity of the signature, the identity of the target, the identity identity of the Target, the identity of the LIS, whether the LIS
of the LIS, whether the LIS authenticated the target, and the authenticated the Target, and the identifier included in the "entity"
identifier included in the "entity" field. 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 hoax call, can audit logs be made available layer? In the event of a hoax call, can audit logs be made available
to an investigator, or can information relating to the owner of an to an investigator, or can information relating to the owner of an
unlinked pseudonym be provided, enabling investigators to unravel the unlinked pseudonym be provided, enabling investigators to unravel the
chain of events that lead to the attack? chain of events that led to the attack?
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., United States Phase II E-911 location accuracy)
location information provided by a third party Location Service may be considered more reliable than location information provided by
Provider (LSP) that disclaims use of location information for a third-party Location Service Provider (LSP) that disclaims use of
emergency purposes. location information for emergency purposes.
However, even where an LSP does not attempt to meet the accuracy However, even where an LSP does not attempt to meet the accuracy
requirements for emergency location, it still may be able to provide requirements for emergency location, it still may be able to provide
information useful in assessing about how reliable location information useful in assessing how reliable location information is
information is likely to be. For example, was location determined likely to be. For example, was location determined based on the
based on the nearest cell tower or 802.11 Access Point (AP), or was a nearest cell tower or 802.11 Access Point (AP), or was a
triangulation method used? If based on cell tower or AP location triangulation method used? If based on cell tower or AP location
data, was the information obtained from an authoritative source (e.g. data, was the information obtained from an authoritative source
the tower or AP owner) and when was the last time that the location (e.g., the tower or AP owner), and when was the last time that the
of the tower or access point was verified? location of the tower or access point was verified?
For real-time validation, information in the signaling and media For real-time validation, information in the signaling and media
packets can be cross checked against location information. For packets can be cross-checked against location information. For
example, it may be possible to determine the city, state, country or example, it may be possible to determine the city, state, country, or
continent associated with the IP address included within SIP Via: or continent associated with the IP address included within SIP Via or
Contact: headers, or the media source address, and compare this Contact header fields, or the media source address, and compare this
against the location information reported by the caller or conveyed against the location information reported by the caller or conveyed
in the PIDF-LO. However, in some situations only entities close to in the PIDF-LO. However, in some situations, only entities close to
the caller may be able to verify the correctness of location the caller may be able to verify the correctness of location
information. information.
Real-time validation of the timestamp contained within PIDF-LO Real-time validation of the timestamp contained within PIDF-LO
objects (reflecting the time at which the location was determined) is objects (reflecting the time at which the location was determined) is
also challenging. To address time-shifting attacks, the "timestamp" also challenging. To address time-shifting attacks, the "timestamp"
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 LISs. 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 hoax 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 led 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
LO elements is challenging, where LIS audit logs are available (such PIDF-LO elements is challenging, where LIS audit logs are available
as where a law enforcement agency can present a subpoena), linking of (such as where a law enforcement agency can present a subpoena),
a pseudonym to the device obtaining location can be accomplished linking of a pseudonym to the Device obtaining location can be
during an investigation. accomplished during an investigation.
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 trail 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 Turing 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
Although it is important to ensure that location information cannot Although it is important to ensure that location information cannot
be faked, the mitigation techniques presented in this document are be faked, the mitigation techniques presented in this document are
not universally applicable. For example, there will be many GPS- not universally applicable. For example, there will be many GPS-
enabled devices that will find it difficult to utilize any of the enabled Devices that will find it difficult to utilize any of the
solutions described in Section 3. It is also unlikely that users solutions described in Section 3. It is also unlikely that users
will be willing to upload their location information for will be willing to upload their location information for
"verification" to a nearby location server located in the access "verification" to a nearby location server located in the access
network. network.
This document focuses on threats that arise from conveyance of This document focuses on threats that arise from conveyance of
misleading location information, rather than caller identification or misleading location information, rather than caller identification or
authentication and integrity protection of the messages in which authentication and integrity protection of the messages in which
location is conveyed. Nevertheless, these aspects are important. In location is conveyed. Nevertheless, these aspects are important. In
some countries, regulators may not require the authenticated identity some countries, regulators may not require the authenticated identity
of the emergency caller (e.g. emergency calls placed from PSTN pay of the emergency caller (e.g., emergency calls placed from Public
phones or SIM-less cell phones). Furthermore, if identities can Switched Telephone Network (PSTN) pay phones or SIM-less cell
easily be crafted (as it is the case with many VoIP offerings today), phones). Furthermore, if identities can easily be crafted (as is the
then the value of emergency caller authentication itself might be case with many VoIP offerings today), then the value of emergency
limited. As a result, attackers can forge emergency calls with a caller authentication itself might be limited. As a result,
lower risk of being held accountable, which may encourage hoax calls. attackers can forge emergency calls with a lower risk of being held
accountable, which may encourage hoax calls.
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 (SIP)" [RFC4474]. However, compatibility with Session Border
(SBCs) that modify integrity-protected headers has proven to be an Controllers (SBCs) that modify integrity-protected headers has proven
issue in practice, and as a result, a revision is in progress to be an issue in practice, and as a result, a revision of [RFC4474]
[I.D.ietf-stir-rfc4474bis]. In the absence of an end-to-end is in progress [SIP-Identity]. In the absence of an end-to-end
solution, SIP over Transport Layer Security (TLS) can be used to solution, SIP over Transport Layer Security (TLS) can be used to
provide message authentication and integrity protection hop-by-hop. provide message authentication and integrity protection hop by hop.
PSAPs remain vulnerable to distributed denial of service attacks, PSAPs remain vulnerable to distributed denial-of-service attacks,
even where the mitigation techniques described in this document are even where the mitigation techniques described in this document are
utilized. Placing a large number of emergency calls that appear to utilized. Placing a large number of emergency calls that appear to
come from different locations is an example of an attack that is come from different locations is an example of an attack that is
difficult to carry out within the legacy system, but is easier to difficult to carry out within the legacy system but is easier to
imagine within IP-based emergency services. Also, in the current imagine within IP-based emergency services. Also, in the current
system, it would be very difficult for an attacker from country 'Foo' system, it would be very difficult for an attacker from one country
to attack the emergency services infrastructure located in country to attack the emergency services infrastructure located in another
'Bar', but this attack is possible within IP-based emergency country, but this attack is possible within IP-based emergency
services. services.
While manually mounting the attacks described in Section 2 is non- While manually mounting the attacks described in Section 2 is
trivial, the attacks described in this document can be automated. non-trivial, the attacks described in this document can be automated.
While manually carrying out a location theft would require the While manually carrying out a location theft would require that the
attacker to be in proximity to the location being spoofed, or to attacker be in proximity to the location being spoofed, or to collude
collude with another end host, an attacker able to run code on an end with another end host, an attacker able to run code on an end host
host can obtain its location, and cause an emergency call to be made. can obtain its location and cause an emergency call to be made.
While manually carrying out a time shifting attack would require that While manually carrying out a time-shifting attack would require that
the attacker visit the location and submit it before the location the attacker visit the location and submit it before the location
information is considered stale, while traveling rapidly away from information is considered stale, while traveling rapidly away from
that location to avoid apprehension, these limitations would not that location to avoid apprehension, these limitations would not
apply to an attacker able to run code on the end host. While apply to an attacker able to run code on the end host. While
obtaining a PIDF-LO from a spoofed IP address requires that the obtaining a PIDF-LO from a spoofed IP address requires that the
attacker be on the path between the HELD requester and the LIS, if attacker be on the path between the HELD requester and the LIS, if
the attacker is able to run code requesting the PIDF-LO, retrieve it the attacker is able to run code requesting the PIDF-LO, retrieve it
from the LIS, and then make an emergency call using it, this attack from the LIS, and then make an emergency call using it, this attack
becomes much easier. To mitigate the risk of automated attacks, becomes much easier. To mitigate the risk of automated attacks,
service providers can limit the ability of untrusted code (such as service providers can limit the ability of untrusted code (such as
WebRTC applications written in Javascript) to make emergency calls. WebRTC applications written in JavaScript) to make emergency calls.
Emergency services have three finite resources subject to denial of Emergency services have three finite resources subject to denial-of-
service attacks: the network and server infrastructure, call takers service attacks: the network and server infrastructure; call takers
and dispatchers, and the first responders, such as fire fighters and and dispatchers; and the first responders, such as firefighters and
police officers. Protecting the network infrastructure is similar to police officers. Protecting the network infrastructure is similar to
protecting other high-value service providers, except that location protecting other high-value service providers, except that location
information may be used to filter call setup requests, to weed out information may be used to filter call setup requests, to weed out
requests that are out of area. Even for large cities PSAPs may only requests that are out of area. Even for large cities, PSAPs may only
have a handful of call takers on duty. So even if automated have a handful of call takers on duty. So, even if automated
techniques are utilized to evaluate the trustworthiness of conveyed techniques are utilized to evaluate the trustworthiness of conveyed
location and call takers can, by questioning the caller, eliminate location and call takers can, by questioning the caller, eliminate
many hoax calls, PSAPs can be overwhelmed even by a small-scale many hoax calls, PSAPs can be overwhelmed even by a small-scale
attack. Finally, first responder resources are scarce, particularly attack. Finally, first-responder resources are scarce, particularly
during mass-casualty events. during mass-casualty events.
6. Privacy Considerations 6. Privacy Considerations
The emergency calling architecture described in [RFC6443] utilizes The emergency calling architecture described in [RFC6443] utilizes
the PIDF-LO format defined in [RFC4119]. As described in the the PIDF-LO format defined in [RFC4119]. As described in the
location privacy architecture [RFC6280], privacy rules that may location privacy architecture [RFC6280], privacy rules that may
include policy instructions are conveyed along with the location include policy instructions are conveyed along with the location
object. object.
The intent of the location privacy architecture was to provide strong The intent of the location privacy architecture was to provide strong
privacy protections, as noted in [RFC6280] Section 1.1: privacy protections, as noted in [RFC6280], Section 1.1:
A central feature of the Geopriv architecture is that location A central feature of the Geopriv architecture is that location
information is always bound to privacy rules to ensure that information is always bound to privacy rules to ensure that
entities that receive location information are informed of how entities that receive location information are informed of how
they may use it. These rules can convey simple directives ("do they may use it. These rules can convey simple directives ("do
not share my location with others"), or more robust preferences not share my location with others"), or more robust preferences
("allow my spouse to know my exact location all of the time, but ("allow my spouse to know my exact location all of the time, but
only allow my boss to know it during work hours")... The binding only allow my boss to know it during work hours")... The binding
of privacy rules to location information can convey users' desire of privacy rules to location information can convey users' desire
for and expectations of privacy, which in turn helps to bolster for and expectations of privacy, which in turn helps to bolster
social and legal systems' protection of those expectations. social and legal systems' protection of those expectations.
However, in practice this architecture has limitations which apply However, in practice this architecture has limitations that apply
within emergency and non-emergency situations. As noted in Section within emergency and non-emergency situations. As noted in
1.2.2, concerns about hoax calls have lead to restrictions on Section 1.2.2, concerns about hoax calls have led to restrictions on
anonymous emergency calls. Caller identification (potentially anonymous emergency calls. Caller identification (potentially
asserted in SIP via P-Asserted-Identity and via SIP Identity) may be asserted in SIP via P-Asserted-Identity and SIP Identity) may be used
used during emergency calls. As a result, in many cases location during emergency calls. As a result, in many cases location
information transmitted within SIP messages can be linked to caller information transmitted within SIP messages can be linked to caller
identity. For example, in case of signed LbyV, there are privacy identity. For example, in the case of a signed LbyV, there are
concerns arising from linking the location object to identifiers to privacy concerns arising from linking the location object to
prevent replay attacks, as described in Section 3.1. identifiers to prevent replay attacks, as described in Section 3.1.
The ability to observe location information during emergency calls The ability to observe location information during emergency calls
may also represent a privacy risk. As a result, [RFC6443] requires may also represent a privacy risk. As a result, [RFC6443] requires
transmission layer security for SIP messages, as well as interactions transmission-layer security for SIP messages, as well as interactions
with the location server. However, even where transmission layer with the location server. However, even where transmission-layer
security is used, privacy rules associated with location information security is used, privacy rules associated with location information
may not apply. may not apply.
In many jurisdictions, an individual requesting emergency assistance In many jurisdictions, an individual requesting emergency assistance
is assumed to be granting permission to the PSAP, call taker and is assumed to be granting permission to the PSAP, call taker, and
first responders to obtain their location in order to accelerate first responders to obtain their location in order to accelerate
dispatch. As a result, privacy policies associated with location are dispatch. As a result, privacy policies associated with location are
implicitly waived when an emergency call is initiated. In addition, implicitly waived when an emergency call is initiated. In addition,
when location information is included within SIP messages either in when location information is included within SIP messages in either
emergency or non-emergency uses, SIP entities receiving the SIP emergency or non-emergency uses, SIP entities receiving the SIP
message are implicitly assumed to be authorized location recipients, message are implicitly assumed to be authorized Location Recipients,
as noted in [RFC5606] Section 3.2: as noted in [RFC5606], Section 3.2:
Consensus has emerged that any SIP entity that receives a SIP Consensus has emerged that any SIP entity that receives a SIP
message containing LI through the operation of SIP's normal message containing LI through the operation of SIP's normal
routing procedures or as a result of location-based routing should routing procedures or as a result of location-based routing should
be considered an authorized recipient of that LI. Because of this be considered an authorized recipient of that LI. Because of this
presumption, one SIP element may pass the LI to another even if presumption, one SIP element may pass the LI to another even if
the LO it contains has <retransmission-allowed> set to "no"; this the LO it contains has <retransmission-allowed> set to "no"; this
sees the passing of the SIP message as part of the delivery to sees the passing of the SIP message as part of the delivery to
authorized recipients, rather than as retransmission. SIP authorized recipients, rather than as retransmission. SIP
entities are still enjoined from passing these messages outside entities are still enjoined from passing these messages
the normal routing to external entities if <retransmission- outside the normal routing to external entities if
allowed> is set to "no", as it is the passing to third parties <retransmission-allowed> is set to "no", as it is the passing to
that <retransmission-allowed> is meant to control. third parties that <retransmission-allowed> is meant to control.
Where LbyR is utilized rather than LbyV, it is possible to apply more Where LbyR is utilized rather than LbyV, it is possible to apply more
restrictive authorization policies, limiting access to intermediaries restrictive authorization policies, limiting access to intermediaries
and snoopers. However, this is not possible if the "authorization by and snoopers. However, this is not possible if the "authorization by
possession" model is used. possession" model is used.
7. IANA Considerations 7. Informative References
This document does not require actions by IANA.
8. References
8.1. Informative References [EENA] EENA, "False Emergency Calls", EENA Operations Document,
Version 1.1, May 2011, <http://www.eena.org/ressource/
static/files/2012_05_04-3.1.2.fc_v1.1.pdf>.
[I-D.ietf-stir-problem-statement] [GPSCounter]
Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Warner, J. and R. Johnston, "GPS Spoofing
Telephone Identity Problem Statement", Internet draft (work in Countermeasures", Los Alamos research paper LAUR-03-6163,
progress), draft-ietf-stir-problem-statement-05.txt, May 2014. December 2003.
[I-D.ietf-stir-threats] [Loc-Dependability]
Peterson, J., "Secure Telephone Identity Threat Model", Thomson, M. and J. Winterbottom, "Digital Signature
Internet draft (work in progress), draft-ietf-stir- Methods for Location Dependability", Work in Progress,
threats-03.txt, June 2014. draft-thomson-geopriv-location-dependability-07,
March 2011.
[I-D.ietf-stir-rfc4474bis] [NENA-i2] NENA 08-001, "NENA Interim VoIP Architecture for Enhanced
Peterson, J., Jennings, C. and E. Rescorla, "Authenticated 9-1-1 Services (i2)", Version 2, August 2010.
Identity Management in the Session Initiation Protocol (SIP)",
Internet draft (work in progress), draft-ietf-stir-
rfc4474bis-01.txt, July 2014.
[I-D.thomson-geopriv-location-dependability] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Thomson, M. and J. Winterbottom, "Digital Signature Methods Requirement Levels", BCP 14, RFC 2119, March 1997,
for Location Dependability", Internet draft (work in <http://www.rfc-editor.org/info/rfc2119>.
progress), draft-thomson-geopriv-location-
dependability-07.txt, March 2011.
[EENA] EENA, "False Emergency Calls", EENA Operations Document, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000,
Version 1.1, May 2011, http://www.eena.org/ressource/static/ <http://www.rfc-editor.org/info/rfc2818>.
files/2012_05_04-3.1.2.fc_v1.1.pdf
[GPSCounter] [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
Warner, J. S. and R. G. Johnston, "GPS Spoofing A., Peterson, J., Sparks, R., Handley, M., and E.
Countermeasures", Los Alamos research paper LAUR-03-6163, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
December 2003. June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[NENA-i2] "08-001 NENA Interim VoIP Architecture for Enhanced 9-1-1 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
Services (i2)", December 2005. J. Polk, "Geopriv Requirements", RFC 3693, February 2004,
<http://www.rfc-editor.org/info/rfc3693>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson,
Requirement Levels", BCP 14, RFC 2119, March 1997. "Threat Analysis of the Geopriv Protocol", RFC 3694,
February 2004, <http://www.rfc-editor.org/info/rfc3694>.
[RFC2818] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004,
<http://www.rfc-editor.org/info/rfc3748>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: W., and J. Peterson, "Presence Information Data Format
Session Initiation Protocol", RFC 3261, June 2002. (PIDF)", RFC 3863, August 2004,
<http://www.rfc-editor.org/info/rfc3863>.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Polk, "Geopriv Requirements", RFC 3693, February 2004. Format", RFC 4119, December 2005,
<http://www.rfc-editor.org/info/rfc4119>.
[RFC3694] Danley, M., Mulligan, D., Morris, J. and J. Peterson, "Threat [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Analysis of the Geopriv Protocol", RFC 3694, February 2004. Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006,
<http://www.rfc-editor.org/info/rfc4474>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC July 2006, <http://www.rfc-editor.org/info/rfc4479>.
3748, June 2004.
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and [RFC4740] Garcia-Martin, M., Ed., Belinchon, M., Pallares-Lopez, M.,
J. Peterson, "Presence Information Data Format (PIDF)", RFC Canales-Valenzuela, C., and K. Tammi, "Diameter Session
3863, August 2004. Initiation Protocol (SIP) Application", RFC 4740,
November 2006, <http://www.rfc-editor.org/info/rfc4740>.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for
Format", RFC 4119, December 2005. Emergency Context Resolution with Internet Technologies",
RFC 5012, January 2008,
<http://www.rfc-editor.org/info/rfc5012>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated [RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M.
Identity Management in the Session Initiation Protocol (SIP)", Shanmugam, "Security Threats and Requirements for
RFC 4474, August 2006. Emergency Call Marking and Mapping", RFC 5069,
January 2008, <http://www.rfc-editor.org/info/rfc5069>.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
2006. (TLS) Protocol Version 1.2", RFC 5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales- [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Valenzuela, C., and K. Tammi, "Diameter Session Initiation Presence Information Data Format Location Object (PIDF-LO)
Protocol (SIP) Application", RFC 4740, November 2006. Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009,
<http://www.rfc-editor.org/info/rfc5491>.
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency [RFC5606] Peterson, J., Hardie, T., and J. Morris, "Implications of
Context Resolution with Internet Technologies", RFC 5012, 'retransmission-allowed' for SIP Location Conveyance",
January 2008. RFC 5606, August 2009,
<http://www.rfc-editor.org/info/rfc5606>.
[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H. and M. Shanmugam, [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
"Security Threats and Requirements for Emergency Call Marking Mail Extensions (S/MIME) Version 3.2 Message
and Mapping", RFC 5069, January 2008. Specification", RFC 5751, January 2010,
<http://www.rfc-editor.org/info/rfc5751>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Level Security [RFC5808] Marshall, R., Ed., "Requirements for a Location-by-
(TLS) Protocol Version 1.2", RFC 5246, August 2008. Reference Mechanism", RFC 5808, May 2010,
<http://www.rfc-editor.org/info/rfc5808>.
[RFC5491] Winterbottom, J., Thomson, M. and H. Tschofenig, "GEOPRIV [RFC5985] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)",
Presence Information Data Format Location Object (PIDF-LO) RFC 5985, September 2010,
Usage Clarification, Considerations, and Recommendations", RFC <http://www.rfc-editor.org/info/rfc5985>.
5491, March 2009.
[RFC5606] Peterson, J., Hardie, T. and J. Morris, "Implications of [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
'retransmission-allowed' for SIP Location Conveyance", RFC Tschofenig, H., and H. Schulzrinne, "An Architecture for
5606, August 2009. Location and Location Privacy in Internet Applications",
BCP 160, RFC 6280, July 2011,
<http://www.rfc-editor.org/info/rfc6280>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
Extensions (S/MIME) Version 3.2 Message Specification", RFC for the Session Initiation Protocol", RFC 6442,
5751, January 2010. December 2011, <http://www.rfc-editor.org/info/rfc6442>.
[RFC5808] Marshall, R., "Requirements for a Location-by-Reference [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
Mechanism", RFC 5808, May 2010. "Framework for Emergency Calling Using Internet
Multimedia", RFC 6443, December 2011,
<http://www.rfc-editor.org/info/rfc6443>.
[RFC5985] Barnes, M., "HTTP Enabled Location Delivery (HELD)", RFC 5985, [RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and
September 2010. A. Kuett, "Location Hiding: Problem Statement and
Requirements", RFC 6444, January 2012,
<http://www.rfc-editor.org/info/rfc6444>.
[RFC6280] Barnes, R., et. al, "An Architecture for Location and Location [RFC6753] Winterbottom, J., Tschofenig, H., Schulzrinne, H., and M.
Privacy in Internet Applications", RFC 6280, July 2011. Thomson, "A Location Dereference Protocol Using HTTP-
Enabled Location Delivery (HELD)", RFC 6753, October 2012,
<http://www.rfc-editor.org/info/rfc6753>.
[RFC6442] Polk, J., Rosen, B. and J. Peterson, "Location Conveyance for [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
the Session Initiation Protocol", RFC 6442, December 2011. Communications Services in Support of Emergency Calling",
BCP 181, RFC 6881, March 2013,
<http://www.rfc-editor.org/info/rfc6881>.
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M.
"Framework for Emergency Calling Using Internet Multimedia", Patel, "Public Safety Answering Point (PSAP) Callback",
RFC 6443, December 2011. RFC 7090, April 2014,
<http://www.rfc-editor.org/info/rfc7090>.
[RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A. [RFC7199] Barnes, R., Thomson, M., Winterbottom, J., and H.
Kuett, "Location Hiding: Problem Statement and Requirements", Tschofenig, "Location Configuration Extensions for Policy
RFC 6444, January 2012. Management", RFC 7199, April 2014,
<http://www.rfc-editor.org/info/rfc7199>.
[RFC6753] Winterbottom, J., Tschofenig. H., Schulzrinne, H. and M. [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Thomson, "A Location Dereference Protocol Using HTTP-Enabled Telephone Identity Problem Statement and Requirements",
Location Delivery (HELD)", RFC 6753, October 2012. RFC 7340, September 2014,
<http://www.rfc-editor.org/info/rfc7340>.
[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for [RFC7375] Peterson, J., "Secure Telephone Identity Threat Model",
Communications Services in Support of Emergency Calling", BCP RFC 7375, October 2014,
181, RFC 6881, March 2013. <http://www.rfc-editor.org/info/rfc7375>.
[RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C. and M. Patel, [SA] "Saudi Arabia - Illegal sale of SIMs blamed for surge in
"Public Safety Answering Point (PSAP) Callback", RFC 7090, hoax calls", Arab News, April 5, 2010,
April 2014. <http://www.arabnews.com/node/341463>.
[RFC7199] Barnes, R., Thomson, M., Winterbottom, J. and H. Tschofenig, [SIP-Identity]
"Location Configuration Extensions for Policy Management", RFC Peterson, J., Jennings, C. and E. Rescorla, "Authenticated
7199, April 2014. Identity Management in the Session Initiation Protocol
(SIP)", Work in Progress, draft-ietf-stir-rfc4474bis-02,
October 2014.
[SA] "Saudi Arabia - Illegal sale of SIMs blamed for surge in hoax [STIR] IETF, "Secure Telephone Identity Revisited (stir) Working
calls", Arab News, May 4, 2010, Group", October 2013,
http://www.menafn.com/qn_news_story_s.asp?StoryId=1093319384 <http://datatracker.ietf.org/wg/stir/charter/>.
[STIR] IETF, "Secure Telephone Identity Revisited (stir) Working [SWATing] "SWATing 911 Calls", Dispatch Magazine On-Line,
Group", http://datatracker.ietf.org/wg/stir/charter/, October April 6, 2013, <http://www.911dispatch.com/
2013. swating-911-calls/>.
[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/
http://www.fbi.gov/news/stories/2008/february/swatting020408 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, <http://www.abc.net.au/elections/
Online, August 18, 2006, tas/2006/news/stories/1717956.htm?elections/tas/2006/>.
http://www.abc.net.au/elections/tas/2006/news/stories/
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 and Brian Rosen, for their input at IETF 85 including Marc Linsner and Brian Rosen, for their input at IETF 85
that helped get this documented pointed in the right direction. We that helped get this document pointed in the right direction. We
would also like to thank members of the IETF GEOPRIV WG, including would also like to thank members of the IETF GEOPRIV working group,
Andrew Newton, Murugaraj Shanmugam, Martin Thomson, Richard Barnes including Richard Barnes, Matt Lepinski, Andrew Newton, Murugaraj
and Matt Lepinski for their feedback to previous versions of this Shanmugam, and Martin Thomson for their feedback on previous versions
document. Thanks also to Pete Resnick, Adrian Farrel, Alissa Cooper, of this document. Alissa Cooper, Adrian Farrel, Pete Resnick, Meral
Bert Wijnen and Meral Shirazipour who provided review comments in Shirazipour, and Bert Wijnen provided helpful review comments during
IETF last call. the IETF last call.
Authors' Addresses Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
Austria Austria
Email: Hannes.tschofenig@gmx.net EMail: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building, New York, NY 10027 450 Computer Science Building
US New York, NY 10027
United States
Phone: +1 212 939 7004 Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu URI: http://www.cs.columbia.edu
Bernard Aboba Bernard Aboba (editor)
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
US United States
Email: bernard_aboba@hotmail.com EMail: bernard_aboba@hotmail.com
 End of changes. 212 change blocks. 
602 lines changed or deleted 639 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/