< draft-ietf-ecrit-trustworthy-location-04.txt   draft-ietf-ecrit-trustworthy-location-05.txt >
ECRIT Working Group H. Tschofenig ECRIT Working Group H. Tschofenig
INTERNET-DRAFT Nokia Siemens Networks INTERNET-DRAFT Nokia Siemens Networks
Category: Informational H. Schulzrinne Category: Informational H. Schulzrinne
Expires: April 22, 2013 Columbia University Expires: September 12, 2013 Columbia University
B. Aboba (ed.) B. Aboba (ed.)
Microsoft Corporation Microsoft Corporation
22 October 2012 13 March 2013
Trustworthy Location Trustworthy Location
draft-ietf-ecrit-trustworthy-location-04.txt draft-ietf-ecrit-trustworthy-location-05.txt
Abstract Abstract
For some location-based applications, such as emergency calling or For some location-based applications, such as emergency calling or
roadside assistance, the trustworthiness of location information is roadside assistance, the trustworthiness of location information is
critically important. critically important.
This document describes the problem of "trustworthy location" as well This document describes how to convey location in a manner that is
as potential solutions. inherently secure and reliable. It also provides guidelines for
assessing the trustworthiness of location information.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 22, 2013. This Internet-Draft will expire on September 12, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . 4
2. Emergency Services Architecture . . . . . . . . . . . . . . . 4 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 6
3.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 6 2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 7
3.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 7 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Solution Proposals . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Signed Location by Value . . . . . . . . . . . . . . . . . 8
4.1. Location Signing . . . . . . . . . . . . . . . . . . . . . 8 3.2. Location by Reference . . . . . . . . . . . . . . . . . . 10
4.2. Location by Reference . . . . . . . . . . . . . . . . . . 10 3.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 13
4.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 11 4. Location Trust Assessment . . . . . . . . . . . . . . . . . . 15
5. Operational Considerations . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5.1. Attribution to a Specific Trusted Source . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
5.2. Application to a Specific Point in Time . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3. Linkage to a Specific Endpoint . . . . . . . . . . . . . . 17 7.1. Informative references . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Informative references . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Several public and commercial services depend upon location Several public and commercial services depend upon location
information in their operations. This includes emergency services information in their operations. This includes emergency services
(such as fire, ambulance and police) as well as commercial services (such as fire, ambulance and police) as well as commercial services
such as food delivery and roadside assistance. such as food delivery and roadside assistance.
Services that depend on accurate location commonly experience Services that depend on location commonly experience security issues
security issues today. While prank calls have been a problem for today. While prank calls have been a problem for emergency services
emergency services dating back to the time of street corner call dating back to the time of street corner call boxes, with the move to
boxes, a recent increase in the frequency and sophistication of the IP-based emergency services, the ability to launch automated attacks
attacks has lead to the FBI issuing a warning [Swatting]. Since has increased. As the European Emergency Number Association (EENA)
prank emergency calls can endanger bystanders or emergency services has noted [EENA]: "False emergency calls divert emergency services
personnel, or divert resources away from legitimate emergencies, they away from people who may be in life-threatening situations and who
can be life threatening. need urgent help. This can mean the difference between life and
death for someone in trouble."
It should be kept in mind that issues of location trust and EENA [EENA] has attempted to define terminology and describe best
attribution are closely linked. In situations where tracing of an current practices for dealing with false emergency calls, which in
emergency call back to the originator is more difficult, experience certain European countries can constitute as much as 70% of all
has shown that the frequency of nuisance calls can rise dramatically. emergency calls. Reducing the number of prank calls represents a
For example, where emergency calls have been allowed from handsets challenge, since emergency services authorities in most countries are
lacking a SIM card, or where ownership of the SIM card cannot be required to answer every call (whenever possible). Where the caller
determined, the frequency of nuisance calls has often been cannot be identified, the ability to prosecute is limited.
unacceptably high [TASMANIA][UK][SA].
Conversely, where the ability exists enable an investigator to Since prank emergency calls can endanger bystanders or emergency
determine the originator of a prank emergency call after the fact, services personnel, or divert resources away from legitimate
the trustworthiness of location is likely to improve, even without emergencies, they can be life threatening. A particularly dangerous
the introduction of measures to limit location spoofing. Under a form of prank call is "swatting" - an prank emergency call that draws
court order, an investigator can have access to additional a response from law enforcement (e.g. a fake hostage situation that
information beyond the messages conveyed in the emergency call. For results in dispatching of a "Special Weapons And Tactics" (SWAT)
example, in such a situation, audit logs will often be made available team). In 2008 the FBI issued a warning [Swatting] about an increase
and in addition, information relating to the owner of an unlinked in the frequency and sophistication of these attacks.
pseudonym could be provided to investigators, enabling them to
unravel the chain of events that lead to the attack.
This document reviews the emergency services architecture in Section Many documented cases of "swatting" involve not only the faking of an
2, investigates security threats in Section 3, and outlines potential emergency, but also the absence of accurate caller identification and
solutions in Section 4. Operational considerations are provided in the delivery of misleading location data. Today these attacks are
Section 5 and security considerations are discussed in Section 6. often carried out by providing false caller identification, since for
circuit-switched calls from landlines, location provided to the PSAP
is determined from a lookup using the calling telephone number. With
IP-based emergency services, in addition to the potential for false
caller identification, it is also possible to attach misleading
location information to the emergency call.
Ideally, a call taker at a PSAP should be put in the position to
assess, in real-time, the level of trust that can be placed on the
information provided within a call. This includes automated location
conveyed along with the call and location information communicated by
the caller, as well as identity information about the caller. Where
real-time assessment is not possible, it is important to be able to
determine the source of the call in a post-mortem, so as to be able
to enforce accountability.
This document defines terminology (including the meaning of
"trustworthy location") in Section 1.1, investigates security threats
in Section 2, outlines potential solutions in Section 3, covers trust
assessment in 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].
This document uses terms from [RFC5012] Section 3. The definition for "Target" is taken from "Geopriv Requirements"
[RFC3693].
2. Emergency Services Architecture
Users of the telephone network can summon emergency services such as
ambulance, fire and police using a well-known emergency service
number (e.g., 9-1-1 in North America, 1-1-2 in Europe). Location
information is used to route emergency calls to the appropriate
regional Public Safety Answering Point (PSAP) that serves the caller
to dispatch first-level responders to the emergency site.
In emergency services deployments utilizing voice over IP, many of
the assumptions of the Plain Old Telephone Service (POTS) and public
land mobile network (PLMN) no longer hold. While both POTS and PLMN
service providers often both physical access as well as phone
service, with Voice over IP (VoIP) there is a split between the role
of the Access Infrastructure Provider (AIP), and the Application
(Voice) Service Provider (VSP). The VSP may be located far away from
the AIP and may either have no business relationship with the AIP or
may be a competitor. It is also likely that the VSP will have no
relationship with the PSAP.
In some situations it is possible for the end host to determine its
own location using technology such as the Global Positioning System
(GPS). Where the end host cannot determine location on its own,
mechanisms have been standardized to make civic and geodetic location
available to the end host, including LLDP-MED [LLDP-MED], DHCP
extensions [RFC4776][RFC6225], HELD [RFC5985], or link-layer
specifications such as [IEEE-802.11y]. The server offering this
information is known as a Location Information Server (LIS). The LIS
may be deployed by an AIP, or it may be run by a Location Service
Provider (LSP) which may have no relationship with the AIP, the VSP
or the PSAP. The location information, provided by reference or by
value, is then conveyed to the service-providing entities, i.e.
location recipients, via application protocols, such as HTTP, SIP or
XMPP.
Where the end host does not provide location, or is not trusted to do The term "location determination method" refers to the mechanism used
so, it is possible for an intermediary to retrieve location to determine the location of a Target. This may be something
information on behalf of the endpoint. employed by a location information server (LIS), or by the Target
itself. It specifically does not refer to the location configuration
protocol (LCP) used to deliver location information either to the
Target or the Recipient. This term is re-used from "GEOPRIV PIDF-LO
Usage Clarification, Considerations, and Recommendations" [RFC5491].
3. Threats The term "source" is used to refer to the LIS, node, or device from
which a Recipient (Target or Third-Party) obtains location
information.
This section focuses on threats deriving from the introduction of Additionally, the terms Location-by-Value (LbyV), Location-by-
untrustworthy location information, regardless of whether this occurs Reference (LbyR), Location Configuration Protocol, Location
intentionally or unintentionally. Dereference Protocol, and Location URI are re-used from "Requirements
for a Location-by-Reference Mechanism" [RFC5808].
In addition to threats arising from the intentional forging of "Trustworthy Location" is defined as location information that can be
location information, end hosts may be induced to provide attributed to a trusted source, has been protected against
untrustworthy location information. For example, end hosts may modification in transmit, and has been assessed as trustworthy.
obtain location from civilian GPS, which is vulnerable to spoofing
[GPSCounter] or from third party Location Service Providers (LSPs)
which may be vulnerable to attack or may not warrant the use of their
services for emergency purposes.
Emergency services have three finite resources subject to denial of "Location Trust Assessment" refers to the process by which the
service attacks: the network and server infrastructure, call takers reliability of location information can be assessed. This topic is
and dispatchers, and the first responders, such as fire fighters and discussed in Section 4.
police officers. Protecting the network infrastructure is similar to
protecting other high-value service providers, except that location
information may be used to filter call setup requests, to weed out
requests that are out of area. PSAPs even for large cities may only
have a handful of PSAP call takers on duty, so even if they can, by
questioning the caller, eliminate a lot of prank calls, they are
quickly overwhelmed by even a small-scale attack. Finally, first
responder resources are scarce, particularly during mass-casualty
events.
Legacy emergency services rely on the ability to identify callers, as 2. Threats
well as on the difficulty of location spoofing for normal users to
limit prank calls. The ability to ascertain identity is important,
since the threat of severe punishments reduces prank calls.
Mechanically placing a large number of emergency calls that appear to
come from different locations is difficult. Calls from pay phones
are subject to greater scrutiny by the call taker. In the current
system, it would be very difficult for an attacker from country 'Foo'
to attack the emergency services infrastructure located in country
'Bar'.
One of the main motivations of an adversary in the emergency services While previous IETF documents have analyzed aspects of the security
context is to prevent callers from utilizing emergency service of emergency services or threats to geographic location privacy,
support. This can be done by a variety of means, such as those documents do not cover the threats arising from unreliable
impersonating a PSAP or directory servers, attacking SIP signaling location information.
elements and location servers.
Attackers may want to modify, prevent or delay emergency calls. In A threat analysis of the emergency services system is provided in
some cases, this will lead the PSAP to dispatch emergency personnel "Security Threats and Requirements for Emergency Call Marking and
to an emergency that does not exist and, hence, the personnel might Mapping" [RFC5069]. RFC 5069 describes attacks on the emergency
not be available to other callers. It might also be possible for an services system, such as attempting to deny system services to all
attacker to impede the users from reaching an appropriate PSAP by users in a given area, to gain fraudulent use of services and to
modifying the location of an end host or the information returned divert emergency calls to non-emergency sites. [RFC5069] also
from the mapping protocol. In some countries, regulators may not describes attacks against individuals, including attempts to prevent
require the authenticated identity of the emergency caller, as is an individual from receiving aid, or to gain information about an
true for PSTN-based emergency calls placed from pay phones or SIM- emergency. "Threat Analysis of the Geopriv Protocol" [RFC3694]
less cell phones today. Furthermore, if identities can easily be describes threats against geographic location privacy, including
crafted (as it is the case with many VoIP offerings today), then the protocol threats, threats resulting from the storage of geographic
value of emergency caller authentication itself might be limited. As location data, and threats posed by the abuse of information.
a consequence, an attacker can forge emergency call information
without the chance of being held accountable for its own actions.
The above-mentioned attacks are mostly targeting individual emergency This document focuses on threats from attackers providing false
callers or a very small fraction of them. If attacks are, however, location information within emergency calls. Since we do not focus
launched against the mapping architecture (see [RFC5582] or against on attackers gaining control of infrastructure elements (e.g.,
the emergency services IP network (including PSAPs), a larger region location servers, call route servers) or the emergency services IP
and a large number of potential emergency callers are affected. The network, the threats are derived from the introduction of
call takers themselves are a particularly scarce resource and if untrustworthy location information by end hosts. In addition to
human interaction by these call takers is required then this can very threats arising from the intentional forging of location information,
quickly have severe consequences. end hosts may be induced to provide untrustworthy location
information. For example, end hosts may obtain location from
civilian GPS, which is vulnerable to spoofing [GPSCounter] or from
third party Location Service Providers (LSPs) which may be vulnerable
to attack or may not warrant the use of their services for emergency
purposes.
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.
skipping to change at page 6, line 36 skipping to change at page 6, line 12
mapping locations to PSAP address, or call routing elements, may mapping locations to PSAP address, or call routing elements, may
act maliciously. act maliciously.
Malicious end host adversary model: The end host itself acts Malicious end host adversary model: The end host itself acts
maliciously, whether the owner is aware of this or whether it is maliciously, whether the owner is aware of this or whether it is
acting as a bot. acting as a bot.
In this document, we focus only on the malicious end host adversary In this document, we focus only on the malicious end host adversary
model. model.
3.1. Location Spoofing 2.1. Location Spoofing
An adversary can provide false location information in an emergency An adversary can provide false location information in an emergency
call in order to misdirect emergency resources. For calls call in order to misdirect emergency resources. For calls
originating within the PSTN, this attack can be carried out via originating within the PSTN, this attack can be carried out via
caller-id spoofing. Where location is attached to the emergency call caller-id spoofing. Where location is attached to the emergency call
by an end host, several avenues are available to provide false by an end host, several avenues are available to provide false
location information: location information:
1. The end host could fabricate a PIDF-LO and convey it within an 1. The end host could fabricate a PIDF-LO and convey it within an
emergency call; emergency call;
skipping to change at page 7, line 4 skipping to change at page 6, line 28
by an end host, several avenues are available to provide false by an end host, several avenues are available to provide false
location information: location information:
1. The end host could fabricate a PIDF-LO and convey it within an 1. The end host could fabricate a PIDF-LO and convey it within an
emergency call; emergency call;
2. The VSP (and indirectly a LIS) could be fooled into using the 2. The VSP (and indirectly a LIS) could be fooled into using the
wrong identity (such as an IP address) for location lookup, wrong identity (such as an IP address) for location lookup,
thereby providing the end host with misleading location thereby providing the end host with misleading location
information; information;
3. Inaccurate or out-of-date information (such spoofed GPS 3. Inaccurate or out-of-date information (such spoofed GPS
signals, a stale wiremap or an inaccurate access point location signals, a stale wiremap or an inaccurate access point location
database) could be utilized by the LIS or the endhost in its database) could be utilized by the LIS or the end host in its
location determination, thereby leading to an inaccurate location determination, thereby leading to an inaccurate
determination of location. determination of location.
By analysis of the SIP headers, it may be possible to flag situations By analysis of the SIP headers, it may be possible to flag situations
where the conveyed location is suspect (e.g. potentially wrong city, where the conveyed location is suspect (e.g. potentially wrong city,
state, country or continent). However, in other situations only state, country or continent). However, in other situations only
entities close to the caller may be able to verify the correctness of entities close to the caller may be able to verify the correctness of
location information. location information.
The following list presents threats specific to location information The following list presents threats specific to location information
skipping to change at page 7, line 33 skipping to change at page 7, line 9
Time shifting: Trudy pretends to be at a location she was a while Time shifting: Trudy pretends to be at a location she was a while
ago. ago.
Location theft: Trudy observes Alice's location and replays it as Location theft: Trudy observes Alice's location and replays it as
her own. her own.
Location swapping: Trudy and Malory, located in different locations, Location swapping: Trudy and Malory, located in different locations,
can collude and swap location information and pretend to be in can collude and swap location information and pretend to be in
each other's location. each other's location.
3.2. Identity Spoofing 2.2. Identity Spoofing
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 AIP and the VSP: between the AIP and the VSP:
(a) network access identity such as might be determined via (a) network access identity such as might be determined via
authentication (e.g., using the Extensible Authentication Protocol authentication (e.g., using the Extensible Authentication Protocol
(EAP) [RFC3748]); (EAP) [RFC3748]);
(b) caller identity, such as might be determined from authentication (b) caller identity, such as might be determined from authentication
skipping to change at page 8, line 17 skipping to change at page 7, line 41
require strong identity, which need not necessarily be coupled to a require strong identity, which need not necessarily be coupled to a
business relationship with the AIP, ISP or VSP. However, due to the business relationship with the AIP, 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, so that in most cases, only the device placing the
call will be able to be identified, making the system vulnerable to call will be able to be identified, making the system vulnerable to
bot-net attacks. Furthermore, deploying additional credentials for bot-net attacks. Furthermore, deploying additional credentials for
emergency service purposes (such as certificates) increases costs, emergency service purposes (such as certificates) increases costs,
introduces a significant administrative overhead and is only useful introduces a significant administrative overhead and is only useful
if widely deployed. if widely deployed.
4. Solution Proposals 3. Solutions
This section presents three potential solutions to the described This section presents three mechanisms which can be used to convey
threats: location signing (Section 4.1), location by reference location: signed location by value (Section 3.1), location by
(Section 4.2) and proxy added location (Section 4.3). reference (Section 3.2) and proxy added location (Section 3.3).
4.1. Location Signing In order for to provide authentication and integrity protection for
the SIP messages conveying location, several security approaches are
available. While it is possible for proxies to use security
mechanisms such as SIP Identity [RFC4474] to ensure that
modifications to the location in transit can be detected by the
location recipient (e.g., the PSAP), compatibility with Session
Border Controllers (SBCs) that modify integrity-protected headers has
proven to be an issue in practice. As a result, the use of SIP over
TLS is at present a more likely mechanism to provide per-message
authentication and integrity protection.
3.1. Signed Location by Value
With location signing, a location server signs the location
information before it is sent to the end host, (the entity subject to
the location determination process).
One way to avoid location spoofing is to let a trusted location
server sign the location information before it is sent to the end
host, i.e., the entity subject to the location determination process.
The signed location information is then verified by the location The signed location information is then verified by the location
recipient and not by the target. Figure 1 shows the communication recipient and not by the target. Figure 1 shows the communication
model with the target requesting signed location in step (a), the model with the target requesting signed location in step (a), the
location server returns it in step (b) and it is then conveyed to the location server returns it in step (b) and it is then conveyed to the
location recipient in step (c) who verifies it. For SIP, the location recipient in step (c) who verifies it. For SIP, the
procedures described in [RFC6442] are applicable for location procedures described in "Location Conveyance for the Session
Initiation Protocol" [RFC6442] are applicable for location
conveyance. conveyance.
+-----------+ +-----------+ +-----------+ +-----------+
| | | Location | | | | Location |
| LIS | | Recipient | | LIS | | Recipient |
| | | | | | | |
+-+-------+-+ +----+------+ +-+-------+-+ +----+------+
^ | --^ ^ | --^
| | -- | | --
Geopriv |Req. | -- Geopriv |Req. | --
skipping to change at page 9, line 25 skipping to change at page 8, line 44
Protocol |(a) |(b) -- (e.g., SIP) Protocol |(a) |(b) -- (e.g., SIP)
| v -- (c) | v -- (c)
+-+-------+-+ -- +-+-------+-+ --
| Target / | -- | Target / | --
| End Host + | End Host +
| | | |
+-----------+ +-----------+
Figure 1: Location Signing Figure 1: Location Signing
Additional information, such as timestamps or expiration times, has In order to limit replay attacks, additional information, such as
to be included together with the signed location to limit replay timestamps or expiration times, has to be included together with the
attacks. If the location is retrieved from a location server, even a signed location. If the location is retrieved from a location
stationary end host has to periodically obtain a fresh signed server, even a stationary end host has to periodically obtain a fresh
location, or incur the additional delay of querying during the signed location, or incur the additional delay of querying during the
emergency call. Bot nets are also unlikely to be deterred by emergency call.
location signing. However, accurate location information would limit
the usable subset of the bot net, as only hosts within the PSAP While bot-nets are unlikely to be deterred by location signing,
serving area would be useful in placing calls. accurate location information would limit the subset of the bot-net
that could be used for an attack, as only hosts within the PSAP
serving area would be useful in placing emergency calls.
To prevent location-swapping attacks it is necessary to include some To prevent location-swapping attacks it is necessary to include some
some target specific identity information. The included information some target-specific identity information. The required information
depends on the purpose, namely either real-time verification by the depends on whether the goal is real-time verification by the location
location recipient or for the purpose of a post-mortem analysis when recipient or post-mortem analysis (where the goal is determination of
the location recipient wants to determine the legal entity behind the the legal entity responsible for the attack). As argued in Section
target for prosecution (if this is possible). As argued in Section 6 4, real-time verification is not always possible.
the operational considerations make a real-time verification
difficult. A strawman proposal for location signing is provided by
[I-D.thomson-geopriv-location-dependability].
Still, for large-scale attacks launched by bot nets, this is unlikely Location signing is unlikely to deter attacks launched by bot-nets,
to be helpful. Location signing is also difficult when the host since the work required to verify the location signature is
provides its own location via GPS, which is likely to be a common considerable. Location signing is also difficult when the host
occurrence for mobile devices. Trusted computing approaches, with obtains location via mechanisms such as GPS, unless trusted computing
tamper-proof GPS modules, may be needed in that case. After all, a approaches, with tamper-proof GPS modules, can be applied.
device can always pretend to have a GPS device and the recipient has Otherwise, an end host can pretend to have a GPS device, and the
no way of verifying this or forcing disclosure of non-GPS-derived recipient will need to rely on its ability to assess the level of
location information. trust that should be placed in the end host location claim.
Location verification may be most useful if it is used in conjunction A straw-man proposal for location signing is provided in [I-
with other mechanisms. For example, a call taker can verify that the D.thomson-geopriv-location-dependability], and [NENA-i2] Section 3.7
region that corresponds to the IP address of the media stream roughly includes operational recommendations relating to location signing:
corresponds to the location information reported by the caller. To
make the use of bot nets more difficult, a CAPTCHA-style test may be
applied to suspicious calls, although this idea is quite
controversial for emergency services, at the danger of delaying or
even rejecting valid calls.
4.2. Location by Reference Location determination is out of scope for NENA, but we can offer
guidance on what should be considered when designing mechanisms to
report location:
The location-by-reference concept was developed so that end hosts 1. The location object should be digitally signed.
could avoid having to periodically query the location server for up-
to-date location information in a mobile environment. Additionally, 2. The certificate for the signer (LIS operator) should be
if operators do not want to disclose location information to the end rooted in VESA. For this purpose, VPC and ERDB operators
should issue certs to LIS operators.
3. The signature should include a timestamp.
4. Where possible, the Location Object should be refreshed
periodically, with the signature (and thus the timestamp)
being refreshed as a consequence.
5. Anti-spoofing mechanisms should be applied to the Location
Reporting method.
[Note: The term Valid Emergency Services Authority (VESA) refers
to the root certificate authority.]
As noted above, signing of location objects implies the development
of a trust hierarchy that would enable a certificate chain provided
by the LIS operator to be verified by the PSAP. Rooting the trust
hierarchy in VESA can be accomplished either by having the VESA
directly sign the LIS certificates, or by the creation of
intermediate CAs certified by the VESA, which will then issue
certificates to the LIS. In terms of the workload imposed on the
VESA, the latter approach is highly preferable. However, this raises
the question of who would operate the intermediate CAs and what the
expectations would be.
In particular, the question arises as to the requirements for LIS
certificate issuance, and whether they are significantly different
from say, requirements for issuance of an SSL/TLS web certificate.
3.2. Location by Reference
Location-by-reference was developed so that end hosts can avoid
having to periodically query the location server for up- to-date
location information in a mobile environment. Additionally, if
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. reasonable alternative. As noted in "A Location Dereference Protocol
Using HTTP-Enabled Location Delivery (HELD)" [RFC6753], a location
reference can be obtained via HTTP-Enabled Location Delivery (HELD)
[RFC5985] or the Dynamic Host Configuration Protocol (DHCP) location
URI option [DHCP-URI-OPT].
Figure 2 shows the communication model with the target requesting a Figure 2 shows the communication model with the target requesting a
location reference in step (a), the location server returns the location reference in step (a), the location server returns the
reference in step (b), and it is then conveyed to the location reference in step (b), and it is then conveyed to the location
recipient in step (c). The location recipient needs to resolve the recipient in step (c). The location recipient needs to resolve the
reference with a request in step (d). Finally, location information reference with a request in step (d). Finally, location information
is returned to the Location Recipient afterwards. For location is returned to the Location Recipient afterwards. For location
conveyance in SIP, the procedures described in [I-D.ietf-sip- conveyance in SIP, the procedures described in [RFC6442] are
location-conveyance] are applicable. applicable.
+-----------+ Geopriv +-----------+ +-----------+ Geopriv +-----------+
| | Location | Location | | | Location | Location |
| LIS +<------------->+ Recipient | | LIS +<------------->+ Recipient |
| | Dereferencing | | | | Dereferencing | |
+-+-------+-+ Protocol (d) +----+------+ +-+-------+-+ Protocol (d) +----+------+
^ | --^ ^ | --^
| | -- | | --
Geopriv |Req. | -- Geopriv |Req. | --
Location |LbyR |LbyR -- Geopriv Location |LbyR |LbyR -- Geopriv
skipping to change at page 10, line 52 skipping to change at page 11, line 25
Protocol | | -- (e.g., SIP) Protocol | | -- (e.g., SIP)
| V -- (c) | V -- (c)
+-+-------+-+ -- +-+-------+-+ --
| Target / | -- | Target / | --
| End Host + | End Host +
| | | |
+-----------+ +-----------+
Figure 2: Location by Reference Figure 2: Location by Reference
The details for the dereferencing operations vary with the type of Where location by reference is provided, the recipient needs to
reference, such as a HTTP, HTTPS, SIP, SIPS URI or a SIP presence deference the LbyR in order to obtain location. The details for the
URI. HTTP-Enabled Location Delivery (HELD) [RFC5985] is an example dereferencing operations vary with the type of reference, such as a
of a protocol that is able to return such references. HTTP, HTTPS, SIP, SIPS URI or a 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 URL from being able to permanently track a host recipient of such a URL from being able to permanently track a host
and to offer garbage collection functionality for the location and to offer garbage collection functionality for the location
server. server.
Off-path adversaries must be prevented from obtaining the target's Off-path adversaries must be prevented from obtaining the target's
location. The reference contains a randomized component that location. The reference contains a randomized component that
prevents third parties from guessing it. When the location recipient prevents third parties from guessing it. When the location recipient
fetches up-to-date location information from the location server, it fetches up-to-date location information from the location server, it
can also be assured that the location information is fresh and not can also be assured that the location information is fresh and not
replayed. However, this does not address location swapping. replayed. However, this does not address location swapping.
However, location-by-reference does not offer significant security With respect to the security of the de-reference operation, [RFC6753]
benefits if the end host uses GPS to determine its location. At Section 6 states:
best, a network provider can use cell tower or triangulation
information to limit the inaccuracy of user-provided location
information.
4.3. Proxy Adding Location
Instead of making location information available to the end host, it
is possible to allow an entity in the AIP, or associated with the
AIP, to retrieve the location information on behalf of the end point.
This solution is possible when the application layer messages are
routed through an entity with the ability to determine the location
information of the end point, for example based on the end host's IP
or MAC address.
When the untrustworthy end host does not have the ability to access
location information, it cannot modify it either. Proxies can use
various authentication security techniques, including SIP Identity
[RFC4474], to ensure that modifications to the location in transit
can be detected by the location recipient (e.g., the PSAP). As noted
above, this is unlikely to work for GPS-based location determination
techniques.
The obvious disadvantage of this approach is that there is a need to
deploy application layer entities, such as SIP proxies, at AIPs or
associated with AIPs. This requires a standardized VoIP profile to
be deployed at every end device and at every AIP, for example, based
on SIP. This might impose a certain interoperability challenge.
Additionally, the AIP more or less takes the responsibility for
emergency calls, even for customers they have no direct or indirect
relationship with. To provide identity information about the
emergency caller from the VSP it would be necessary to let the AIP
and the VSP to interact for authentication (see, for example,
[RFC4740]). This interaction along the Authentication, Authorization
and Accounting infrastructure (see ) is often based on business
relationships between the involved entities. The AIP and the VSP are
very likely to have no such business relationship, particularly when
talking about an arbitrary VSP somewhere on the Internet. In case
that the interaction between the AIP and the VSP fails due to the
lack of a business relationship then typically a fall-back would be
provided where no emergency caller identity information is made
available to the PSAP and the emergency call still has to be
completed.
5. Operational Considerations
5.1. Attribution to a Specific Trusted Source
[NENA-i2] Section 3.7 describes some of the aspects of attribution as
follows:
The i2 solution proposes a Location Information Server (LIS) be
the source for distributing location information within an access
network. Furthermore the validity, integrity and authenticity of
this information are directly attributed to the LIS operator.
Section 5.1.1 describes the issues that arise in ensuring the
validity of location information provided by the LIS operator.
Section 5.1.2 and Section 5.1.3 describe operational issues that
arise in ensuring the integrity and authenticity of location
information provided by the LIS operator.
5.1.1. Validity TLS MUST be used for dereferencing location URIs unless
confidentiality and integrity are provided by some other
mechanism, as discussed in Section 3. Location Recipients MUST
authenticate the host identity using the domain name included in
the location URI, using the procedure described in Section 3.1 of
[RFC2818]. Local policy determines what a Location Recipient does
if authentication fails or cannot be attempted.
In existing networks where location information is both determined by The authorization by possession model (Section 4.1) further relies
the access/voice service provider as well as communicated by the AIP/ on TLS when transmitting the location URI to protect the secrecy
VSP, responsibility for location validity can be attributed entirely of the URI. Possession of such a URI implies the same privacy
to a single party, namely the AIP/VSP. considerations as possession of the PIDF-LO document that the URI
references.
However, on the Internet, not only may the AIP and VSP represent Location URIs MUST only be disclosed to authorized Location
different parties, but location determination may depend on Recipients. The GEOPRIV architecture [RFC6280] designates the
information contributed by parties trusted by neither the AIP nor Rule Maker to authorize disclosure of the URI.
VSP, or even the operator of the Location Information Server (LIS).
In such circumstances, mechanisms for enhancing the integrity or
authenticity of location data contribute little toward ensuring the
validity of that data.
It should be understood that the means by which location is Protection of the location URI is necessary, since the policy
determined may not necessarily relate to the means by which the attached to such a location URI permits anyone who has the URI to
endpoint communicates with the LIS. Just because a Location view the associated location information. This aspect of security
Configuration Protocol (LCP) operates at a particular layer does not is covered in more detail in the specification of location
imply that the location data communicated by that protocol is derived conveyance protocols, such as [RFC6442].
solely based on information obtained at that layer. In some
circumstances, LCP implementations may base their location
determination on information gathered from a variety of sources which
may merit varying levels of trust, such as information obtained from
the calling endpoint, or wiremap information that is time consuming
to verify or may rapidly go out of date.
For example, consider the case of a Location Information Server (LIS) For authorizing access to location-by-reference, two authorization
that utilizes LLDP-MED [LLDP-MED] endpoint move detection models were developed: "Authorization by Possession" and
notifications in determining calling endpoint location. Regardless "Authorization via Access Control Lists". With respect to
of whether the LIS implementation utilizes an LCP operating above the "Authorization by Possession" [RFC6753] Section 4.1 notes:
link layer (such as an application layer protocol such as HELD
[RFC5985]), the validity of the location information conveyed would
be dependent on the security properties of LLDP-MED.
[LLDP-MED] Section 13.3 defines the endpoint move detection In this model, possession -- or knowledge -- of the location URI
notification as follows: is used to control access to location information. A location URI
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
limited. The only authentication this would require by the LS is
evidence of possession of the URI. The LS could immediately
authorize any request that indicates this URI.
lldpXMedTopologyChangeDetected NOTIFICATION-TYPE Authorization by possession does not require direct interaction
OBJECTS { lldpRemChassisIdSubtype, with Rule Maker; it is assumed that the Rule Maker is able to
lldpRemChassisId, exert control over the distribution of the location URI.
lldpXMedRemDeviceClass Therefore, the LIS can operate with limited policy input from a
} Rule Maker.
STATUS current
DESCRIPTION
"A notification generated by the local device
sensing a change in the topology that
indicates a new remote device attached to a
local port, or a remote device disconnected
or moved from one port to another."
::= { lldpXMedNotifications 1 }
Figure 3: Interworking Architecture Limited disclosure is an important aspect of this authorization
model. The location URI is a secret; therefore, ensuring that
adversaries are not able to acquire this information is paramount.
Encryption, such as might be offered by TLS [RFC5246] or S/MIME
[RFC5751], protects the information from eavesdroppers.
As noted in Section 7.4 of [LLDP-MED], the lldpRemChassisIdSubtype, Using possession as a basis for authorization means that, once
lldpRemChassisId and lldpXMedRemDeviceClass variables are determined granted, authorization cannot be easily revoked. Cancellation of
from the Chassis ID (1) and LLDP-MED Device Type Type-Length-Value a location URI ensures that legitimate users are also affected;
(TLV) tuples provided within the LLDP advertisement of the calling application of additional policy is theoretically possible but
device. As noted in [LLDP-MED] Section 9.2.3, all Endpoint Devices could be technically infeasible. Expiration of location URIs
use the Network address ID subtype (5) by default. In order to limits the usable time for a location URI, requiring that an
provide topology change notifications in a timely way, it cannot attacker continue o learn new location URIs to retain access to
necessarily be assumed that a Network Connectivity devices will current location information.
validate the network address prior to transmission of the move
detection notification. As a result, there is no guarantee that the
network address reported by the endpoint will correspond to that
utilized by the device.
The discrepancy need not be due to nefarious reasons. For example, In situations where "Authorization by Possession" is not suitable
an IPv6-capable endpoint may utilize multiple IPv6 addresses. (such as where location hiding [RFC6444] is required), the
Similarly, an IPv4-capable endpoint may initially utilize a Link- "Authorization via Access Control Lists" model may be preferred.
Local IPv4 address [RFC3927] and then may subsequently acquire a
DHCP-assigned routable address. All addresses utilized by the
endpoint device may not be advertised in LLDP, or even if they are,
endpoint move detection notification may not be triggered, either
because no LinkUp/LinkDown notifications occur (e.g. the host adds or
changes an address without rebooting) or because these notifications
were not detectable by the Network Connectivity device (the endpoint
device was connected to a hub rather than directly to a switch).
Similar issues may arise in situations where the LIS utilizes DHCP Without the introduction of hierarchy, it would be necessary for the
lease data to obtain location information. Where the endpoint PSAP to obtain client certificates or Digest credentials for all the
address was not obtained via DHCP (such as via manual assignment, LISes in its coverage area, to enable it to successfully dereference
stateless auto-configuration [RFC4862] or Link-Local IPv4 self- LbyRs. In situations with more than a few LISes per PSAP, this would
assignment), no lease information will be available to enable present operational challenges.
determination of device location. This situation should be expected
to become increasingly common as IPv6-capable endpoints are deployed,
and Location Configuration Protocol (LCP) interactions occur over
IPv6.
Even in scenarios in which the LIS relies on location data obtained A certificate hierarchy providing PSAPs with client certificates
from the IP MIB [RFC4293] and the Bridge MIB [RFC4188], availability chaining to the VESA could be used to enable the LIS to authenticate
of location determination information is not assured. In an and authorize PSAPs for dereferencing. Note that unlike PIDF-LO
enterprise scale network, maintenance of current location information signing (which mitigates against modification of PIDF-LOs), this
depends on the ability of the management station to retrieve data via merely provides the PSAP with access to a (potentially unsigned)
polling of network devices. As the number of devices increases, PIDF-LO, albeit over a protected TLS channel.
constraints of network latency and packet loss may make it
increasingly difficult to ensure that all devices are polled on a
sufficiently frequent interval. In addition, in large networks, it
is likely that tables will be large so that when UDP transport is
used, query responses will fragment, resulting in increasing packet
loss or even difficulties in firewall or NAT traversal.
Furthermore, even in situations where the location data can be Another approach would be for the local LIS to upload location
presumed to exist and be valid, there may be issues with the information to a location aggregation point who would in turn manage
integrity of the retrieval process. For example, where the LIS the relationships with the PSAP. This would shift the management
depends on location information obtained from a MIB notification or burden from the PSAPs to the location aggregation points.
query, unless SNMPv3 [RFC3411] is used, data integrity and
authenticity is not assured in transit between the network
connectivity device and the LIS.
From these examples, it should be clear that the availability or 3.3. Proxy Adding Location
validity of location data is a property of the LIS system design and
implementation rather than an inherent property of the LCP. As a
result, mechanisms utilized to protect the integrity and authenticity
of location data do not necessarily provide assurances relating to
the validity or provenance of that data.
5.1.2. Location Signing 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
point (e.g., based on the end host IP or MAC address) to retrieve and
add or override location information.
[NENA-i2] Section 3.7 includes recommendations relating to location The use of proxy-added location is primarily applicable in scenarios
signing: where the end host does not provide location. As noted in [RFC6442]
Section 4.1:
Location determination is out of scope for NENA, but we can offer A SIP intermediary SHOULD NOT add location to a SIP request that
guidance on what should be considered when designing mechanisms to already contains location. This will quite often lead to
report location: confusion within LRs. However, if a SIP intermediary adds
location, even if location was not previously present in a SIP
request, that SIP intermediary is fully responsible for addressing
the concerns of any 424 (Bad Location Information) SIP response it
receives about this location addition and MUST NOT pass on
(upstream) the 424 response. A SIP intermediary that adds a
locationValue MUST position the new locationValue as the last
locationValue within the Geolocation header field of the SIP
request.
1. The location object should be digitally signed. A SIP intermediary MAY add a Geolocation header field if one is
not present -- for example, when a user agent does not support the
Geolocation mechanism but their outbound proxy does and knows the
Target's location, or any of a number of other use cases (see
Section 3).
2. The certificate for the signer (LIS operator) should be As noted in [RFC6442] Section 3.3:
rooted in VESA. For this purpose, VPC and ERDB operators
should issue certs to LIS operators.
3. The signature should include a timestamp. This document takes a "you break it, you bought it" approach to
dealing with second locations placed into a SIP request by an
intermediary entity. That entity becomes completely responsible
for all location within that SIP request (more on this in Section
4).
4. Where possible, the Location Object should be refreshed While it is possible for the proxy to override location included by
periodically, with the signature (and thus the timestamp) the end host, [RFC6442] Section 3.4 notes the operational
being refreshed as a consequence. limitations:
5. Anti-spoofing mechanisms should be applied to the Location Overriding location information provided by the user requires a
Reporting method. deployment where an intermediary necessarily knows better than an
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
is more accurate location information? Currently, there is no way
to tell which entity is more accurate or which is wrong, for that
matter. This document will not specify how to indicate which
location is more accurate than another.
[Note: The term Valid Emergency Services Authority (VESA) refers The disadvantage of this approach is the need to deploy application
to the root certificate authority.] layer entities, such as SIP proxies, at AIPs or associated with AIPs.
This requires a standardized VoIP profile to be deployed at every end
device and at every AIP. This might impose interoperability
challenges.
Signing of location objects implies the development of a trust Additionally, the AIP needs to take responsibility for emergency
hierarchy that would enable a certificate chain provided by the LIS calls, even for customers they have no direct or indirect
operator to be verified by the PSAP. Rooting the trust hierarchy in relationship with. To provide identity information about the
VESA can be accomplished either by having the VESA directly sign the emergency caller from the VSP it would be necessary to let the AIP
LIS certificates, or by the creation of intermediate CAs certified by and the VSP to interact for authentication (see, for example,
the VESA, which will then issue certificates to the LIS. In terms of [RFC4740]). This interaction along the Authentication, Authorization
the workload imposed on the VESA, the latter approach is highly and Accounting infrastructure is often based on business
preferable. However, this raises the question of who would operate relationships between the involved entities. The AIP and the VSP are
the intermediate CAs and what the expectations would be. very likely to have no such business relationship, particularly when
talking about an arbitrary VSP somewhere on the Internet. In case
that the interaction between the AIP and the VSP fails due to the
lack of a business relationship then typically a fall-back would be
provided where no emergency caller identity information is made
available to the PSAP and the emergency call still has to be
completed.
In particular, the question arises as to the requirements for LIS 4. Location Trust Assessment
certificate issuance, and whether they are significantly different
from say, requirements for issuance of an SSL/TLS web certificate.
5.1.3. Location by Reference The ability to assess the level of trustworthiness of conveyed
location information is important, since this makes it possible to
understand how much value should be placed on location information,
as part of the decision making process. As an example, if automated
location information is understood to be highly suspect, a call taker
can put more effort into obtaining location information from the
caller.
Where location by reference is provided, the recipient needs to Caller accountability is another important aspect of trust
deference the LbyR in order to obtain location. With the assessment. Can the individual purchasing the device or activating
introduction of location by reference concept two authorization service be identified or did the call originate from a non-service
models were developed, see [I-D.ietf-geopriv-deref-protocol], namely initialized (NSI) device whose owner cannot be determined? Prior to
the "Authorization by Possession" and "Authorization via Access the call, was the caller authenticated at the network or application
Control Lists" model. With the "Authorization by Possession" model layer? In the event of a prank call, can audit logs be made
everyone in possession of the reference is able to obtain the available to an investigator, or can information relating to the
corresponding location information. This might, however, be owner of an unlinked pseudonym be provided, enabling investigators to
incompatible with other requirements typically imposed by AIPs, such unravel the chain of events that lead to the attack? In practice,
as location hiding (see [RFC6444]). As such, the "Authorization via the ability to identify a caller may decrease the likelihood of
Access Control Lists" model is likely to be the preferred model for caller misbehavior. For example, where emergency calls have been
many AIPs and subject for discussion in the subsequent paragraphs. allowed from handsets lacking a SIM card, or where ownership of the
SIM card cannot be determined, the frequency of nuisance calls has
often been unacceptably high [TASMANIA][UK][SA].
Just as with PIDF-LO signing, the operational considerations in Note that location trust assessment has value regardless of whether
managing credentials for use in LbyR dereferencing can be the location has been conveyed securely (via signed location,
considerable without the introduction of some kind of hierarchy. It location-by-reference or proxy-added location) or not (via location-
does not seem reasonable for a PSAP to manage client certificates or by-value without location signing), since secure conveyance does not
Digest credentials for all the LISes in its coverage area, so as to provide assurance relating to the validity or provenance of location
enable it to successfully dereference LbyRs. In some respects, this data.
issue is even more formidable than the validation of signed PIDF-
LOs. While PIDF-LO signing credentials are provided to the LIS
operator, in the case of de-referencing, the PSAP needs to be obtain
credentials compatible with the LIS configuration, a potentially more
complex operational problem.
As with PIDF-LO signing, the operational issues of LbyR can be In practice, the source of the location data is important for
addressed to some extent by introduction of hierarchy. Rather than location trust assessment. For example, location provided by a
requiring the PSAP to obtain credentials for accessing each LIS, the Location Information Server (LIS) whose administrator has an
local LIS could be required to upload location information to established history of meeting emergency location accuracy
location aggregation points who would in turn manage the requirements (e.g. Phase II) may be considered more reliable than
relationships with the PSAP. This would shift the management burden location information provided by a third party Location Service
from the PSAPs to the location aggregation points. Provider (LSP) that disclaims use of location information for
emergency purposes.
5.2. Application to a Specific Point in Time However, even where an LSP does not attempt to meet the accuracy
requirements for emergency location, it still may be able to provide
information useful in assessing about how reliable location
information is likely to be. For example, was location determined
based on the nearest cell tower or 802.11 Access Point (AP), or was a
triangulation method used? If based on cell tower or AP location
data, was the information obtained from an authoritative source (e.g.
PIDF-LO objects contain a timestamp, which reflects the time at which the tower or AP owner) and when was the last time that the location
the location was determined. Even if the PIDF-LO is signed, the of the tower or access point was verified?
timestamp only represents an assertion by the 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 synchronization, or
whether it is possible to reset the LIS clock manually without
detection. Even if the timestamp was valid at the time location was
determined, a time period may elapse between when the PIDF-LO was
provided and when it is conveyed to the recipient. Periodically
refreshing location information to renew the timestamp even though
the location information itself is unchanged puts additional load on
LISes. As a result, recipients need to validate the timestamp in
order to determine whether it is credible.
5.3. Linkage to a Specific Endpoint For real-time validation, information in the signaling and media
packets can be cross checked against location information. For
example, it may be possible to determine the region associated with
the IP address included within SIP Via: or Contact: headers, or the
media source address, and compare this against the location
information reported by the caller or conveyed in the PIDF-LO. While
a CAPTCHA-style test may be applied to suspicious calls to lower the
risk from bot-nets, this is quite controversial for emergency
services, due to the risk of delaying or rejecting valid calls.
As noted in the "HTTP Enabled Location Delivery (HELD)" [RFC5985] Although privacy-preserving procedures may be disabled for emergency
Section 6.6: calls, by design, PIDF-LO objects limit the information available for
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" element and the Optional parameters such as the "contact" and "deviceID" elements
"deviceID" element [RFC4479] are not used. [RFC4479] are not used.
Given the restrictions on inclusion of identification information Also, the device referred to in the PIDF-LO may not necessarily be
within the PIDF-LO, it may not be possible for a recipient to verify the same entity conveying the PIDF-LO to the PSAP. As noted in
that the entity on whose behalf location was determined represents [RFC6442] Section 1:
the same entity conveying location to the recipient.
Where "Enhancements for Authenticated Identity Management in the In no way does this document assume that the SIP user agent client
Session Initiation Protocol (SIP)" [RFC4474] is used, it is possible that sends a request containing a location object is necessarily
for the recipient to verify the identity assertion in the From: the Target. The location of a Target conveyed within SIP
header. However, if PIDF parameters that contain identity are typically corresponds to that of a device controlled by the
omitted or contain an unlinked pseudonym, then it may not be possible Target, for example, a mobile phone, but such devices can be
for the recipient to verify whether the conveyed location actually separated from their owners, and moreover, in some cases, the user
relates to the entity identified in the From: header. agent may not know its own location.
This lack of binding between the entity obtaining the PIDF-LO and the Due to these design choices, it is possible for an attacker to cut
entity conveying the PIDF-LO to the recipient enables cut and paste and paste a PIDF-LO obtained by a different device or user into a SIP
attacks which would enable an attacker to assert a bogus location, INVITE and send this to the PSAP. While PIDF-LO signing would
even where both the SIP message and PIDF-LO are signed. As a result, prevent modification of a PIDF-LO or invention of one out of whole
even implementation of both [RFC4474] and location signing does not cloth, it would not prevent this cut and paste attack. Neither would
guarantee that location can be tied to a specific endpoint. implementation of "Enhancements for Authenticated Identity Management
in the Session Initiation Protocol (SIP)" [RFC4474], allowing the
recipient to verify the identity assertion in the From: header.
However, while it might not be possible to detect the cut and paste
in real-time, examination of the audit logs might provide enough
information to enable events to be reconstructed.
6. Security Considerations Real-time validation of the timestamp contained within PIDF-LO
objects (reflecting the time at which the location was determined) is
also challenging. Even if the PIDF-LO is signed the timestamp only
represents an assertion by the 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 synchronization, or whether it
is possible to reset the LIS clock manually without detection. Even
if the timestamp was valid at the time location was determined, a
time period may elapse between when the PIDF-LO was provided and when
it is conveyed to the recipient. Periodically refreshing location
information to renew the timestamp even though the location
information itself is unchanged puts additional load on LISes. As a
result, recipients need to validate the timestamp in order to
determine whether it is credible.
IP-based emergency services face many security threats. "Security While this document focuses on the discussion of real-time
Threats and Requirements for Emergency Call Marking and Mapping" determination of suspicious emergency calls, the use of audit logs
[RFC5069] describes attacks on the emergency services system, such as may help in enforcing accountability among emergency callers. For
attempting to deny system services to all users in a given area, to example, in the event of a prank call, information relating to the
gain fraudulent use of services and to divert emergency calls to non- owner of the unlinked pseudonym could be provided to investigators,
emergency sites. [RFC5069] also describes attacks against enabling them to unravel the chain of events that lead to the attack.
individuals, including attempts to prevent an individual from However, while auditability is an important deterrent, it is likely
receiving aid, or to gain information about an emergency. to be of most benefit in situations where attacks on the emergency
services system are likely to be relatively infrequent, since the
resources required to pursue an investigation are likely to be
considerable. However, although real-time validation based on PIDF-
LO elements is challenging, where LIS audit logs are available (such
as where a law enforcement agency can present a subpoena), linking of
a pseudonym to the device obtaining location can be accomplished in a
post-mortem.
"Threat Analysis of the Geopriv Protocol" [RFC3694] describes threats Where attacks are frequent and continuous, automated mechanisms are
against geographic location privacy, including protocol threats, required. For example, it might be valuable to develop mechanisms to
threats resulting from the storage of geographic location data, and exchange audit trails information in a standardized format between
threats posed by the abuse of information. ISPs and PSAPs / VSPs and PSAPs or heuristics to distinguish
potentially fraudulent emergency calls from real emergencies.
Although it is important to ensure that location information cannot 5. Security Considerations
be faked there will be many GPS-enabled devices that will find it
difficult to utilize any of the security mechanisms described in
Section 5. It is also unlikely that users will be willing to upload
their location information for "verification" to a nearby location
server located in the access network.
While auditability is an important deterrent, it is likely to be of IP-based emergency services face a number of security threats that do
most benefit in situations where attacks on the emergency services not exist within the legacy system. In order to limit prank calls,
system are likely to be relatively infrequent, since the resources legacy emergency services rely on the ability to identify callers, as
required to pursue an investigation are likely to be considerable. well as on the difficulty of location spoofing for normal users. The
ability to ascertain identity is important, since the threat of
punishment reduces prank calls; as an example, calls from pay phones
are subject to greater scrutiny by the call taker.
Where attacks are frequent and continuous, automated mechanisms are Mechanically placing a large number of emergency calls that appear to
required. For example, mechanisms to exchange audit trails come from different locations is difficult in a legacy environment.
information in a standardized format between ISPs and PSAPs / VSPs Also, in the current system, it would be very difficult for an
and PSAPs or heuristics to distinguish potentially fraudulent attacker from country 'Foo' to attack the emergency services
emergency calls from real emergencies might be valuable. infrastructure located in country 'Bar'.
7. IANA Considerations However, within an IP-based emergency services a number of these
attacks become much easier to mount. Emergency services have three
finite resources subject to denial of service attacks: the network
and server infrastructure, call takers and dispatchers, and the first
responders, such as fire fighters and police officers. Protecting
the network infrastructure is similar to protecting other high-value
service providers, except that location information may be used to
filter call setup requests, to weed out requests that are out of
area. PSAPs even for large cities may only have a handful of PSAP
call takers on duty, so even if they can, by questioning the caller,
eliminate a lot of prank calls, they are quickly overwhelmed by even
a small-scale attack. Finally, first responder resources are scarce,
particularly during mass-casualty events.
Attackers may want to modify, prevent or delay emergency calls. In
some cases, this will lead the PSAP to dispatch emergency personnel
to an emergency that does not exist and, hence, the personnel might
not be available to other callers. It might also be possible for an
attacker to impede the users from reaching an appropriate PSAP by
modifying the location of an end host or the information returned
from the mapping protocol. In some countries, regulators may not
require the authenticated identity of the emergency caller, as is
true for PSTN-based emergency calls placed from pay phones or SIM-
less cell phones today. Furthermore, if identities can easily be
crafted (as it is the case with many VoIP offerings today), then the
value of emergency caller authentication itself might be limited. As
a consequence, an attacker can forge emergency call information
without the chance of being held accountable for its own actions.
The above-mentioned attacks are mostly targeting individual emergency
callers or a very small fraction of them. If attacks are, however,
launched against the mapping architecture (see [RFC5582] or against
the emergency services IP network (including PSAPs), a larger region
and a large number of potential emergency callers are affected. The
call takers themselves are a particularly scarce resource and if
human interaction by these call takers is required then this can very
quickly have severe consequences.
Although it is important to ensure that location information cannot
be faked there will be many GPS-enabled devices that will find it
difficult to utilize any of the solutions described in Section 3. It
is also unlikely that users will be willing to upload their location
information for "verification" to a nearby location server located in
the access network.
6. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
8. Acknowledgments 7. References
We would like to thank the members of the IETF ECRIT and the IETF 7.1. Informative References
GEOPRIV working group for their input to the discussions related to
this topic. We would also like to thank Andrew Newton, Murugaraj
Shanmugam, Richard Barnes and Matt Lepinski for their feedback to
previous versions of this document. Martin Thomson provided valuable
input to version -02 of this document.
9. References [DHCP-URI-OPT]
Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 and
IPv6 Option for a Location Uniform Resource Identifier (URI)",
Internet draft (work in progress), draft-ietf-geopriv-dhcp-
lbyr-uri-option-19, February 2013.
9.1. Informative References [EENA] EENA, "False Emergency Calls", EENA Operations Document,
Version 1.0, March 2011,
http://www.eena.org/ressource/static/files/
2011_03_15_3.1.2.fc_v1.0.pdf
[GPSCounter] [GPSCounter]
Warner, J. S. and R. G. Johnston, "GPS Spoofing Warner, J. S. and R. G. Johnston, "GPS Spoofing
Countermeasures", Los Alamos research paper LAUR-03-6163, Countermeasures", Los Alamos research paper LAUR-03-6163,
December 2003. December 2003.
[I-D.thomson-geopriv-location-dependability]
Thomson, M. and J. Winterbottom, "Digital Signature Methods
for Location Dependability", draft-thomson-geopriv-location-
dependability-07 (work in progress), March 2011.
[I-D.ietf-geopriv-deref-protocol]
Winterbottom, J., Tschofenig, H., Schulzrinne, H. and M.
Thomson, "A Location Dereferencing Protocol Using HELD",
draft-ietf-geopriv-deref-protocol-07 (work in progress), July
2012.
[IEEE-802.11y]
Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area
networks - Specific requirements - Part 11: Wireless LAN
Medium Access Control (MAC) and Physical Layer (PHY)
specifications Amendment 3: 3650-3700 MHz Operation in USA,
November 2008.
[LLDP-MED]
"Telecommunications: IP Telephony Infrastructure: Link Layer
Discovery Protocol for Media Endpoint Devices, ANSI/
TIA-1057-2006", April 2006.
[NENA-i2] "08-001 NENA Interim VoIP Architecture for Enhanced 9-1-1 [NENA-i2] "08-001 NENA Interim VoIP Architecture for Enhanced 9-1-1
Services (i2)", December 2005. Services (i2)", December 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture [RFC2818] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000.
for Describing Simple Network Management Protocol (SNMP)
Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3694] Danley, M., Mulligan, D., Morris, J. and J. Peterson, "Threat [RFC3694] Danley, M., Mulligan, D., Morris, J. and J. Peterson, "Threat
Analysis of the Geopriv Protocol", RFC 3694, February 2004. Analysis of the Geopriv Protocol", RFC 3694, February 2004.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004. 3748, June 2004.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927, May
2005.
[RFC4188] Norseth, K. and E. Bell, "Definitions of Managed Objects for
Bridges", RFC 4188, September 2005.
[RFC4293] Routhier, S., "Management Information Base for the Internet
Protocol (IP)", RFC 4293, April 2006.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)", Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006. RFC 4474, August 2006.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July
2006. 2006.
[RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales- [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales-
Valenzuela, C., and K. Tammi, "Diameter Session Initiation Valenzuela, C., and K. Tammi, "Diameter Session Initiation
Protocol (SIP) Application", RFC 4740, November 2006. Protocol (SIP) Application", RFC 4740, November 2006.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
and DHCPv6) Option for Civic Addresses Configuration
Information", RFC 4776, November 2006.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Context Resolution with Internet Technologies", RFC 5012,
January 2008.
[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H. and M. Shanmugam, [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H. and M. Shanmugam,
"Security Threats and Requirements for Emergency Call Marking "Security Threats and Requirements for Emergency Call Marking
and Mapping", RFC 5069, January 2008. and Mapping", RFC 5069, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Level Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5491] Winterbottom, J., Thomson, M. and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", RFC
5491, March 2009.
[RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", RFC 5582, September 2009. Framework", RFC 5582, September 2009.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.2 Message Specification", RFC
5751, January 2010.
[RFC5808] Marshall, R., "Requirements for a Location-by-Reference
Mechanism", RFC 5808, May 2010.
[RFC5985] Barnes, M., "HTTP Enabled Location Delivery (HELD)", RFC 5985, [RFC5985] Barnes, M., "HTTP Enabled Location Delivery (HELD)", RFC 5985,
September 2010. September 2010.
[RFC6225] Polk, J., Linsner, M., Thomson, M. and B. Aboba, "Dynamic Host [RFC6280] Barnes, R., et. al, "An Architecture for Location and Location
Configuration Protocol Options for Coordinate-based Location Privacy in Internet Applications", RFC 6280, July 2011.
Configuration Information", RFC 6225, July 2011.
[RFC6442] Polk, J., Rosen, B. and J. Peterson, "Location Conveyance for [RFC6442] Polk, J., Rosen, B. and J. Peterson, "Location Conveyance for
the Session Initiation Protocol", RFC 6442, December 2011. the Session Initiation Protocol", RFC 6442, December 2011.
[RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A. [RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A.
Kuett, "Location Hiding: Problem Statement and Requirements", Kuett, "Location Hiding: Problem Statement and Requirements",
RFC 6444, January 2012. RFC 6444, January 2012.
[RFC6753] Winterbottom, J., Tschofenig. H., Schulzrinne, H. and M.
Thomson, "A Location Dereference Protocol Using HTTP-Enabled
Location Delivery (HELD)", RFC 6753, October 2012.
[SA] "Saudi Arabia - Illegal sale of SIMs blamed for surge in prank [SA] "Saudi Arabia - Illegal sale of SIMs blamed for surge in prank
calls", Arab News, May 4, 2010, calls", Arab News, May 4, 2010,
http://www.menafn.com/qn_news_story_s.asp?StoryId=1093319384 http://www.menafn.com/qn_news_story_s.asp?StoryId=1093319384
[Swatting] [Swatting]
"Don't Make the Call: The New Phenomenon of 'Swatting', "Don't Make the Call: The New Phenomenon of 'Swatting',
Federal Bureau of Investigation, February 4, 2008, Federal Bureau of Investigation, February 4, 2008,
http://www.fbi.gov/news/stories/2008/february/swatting020408 http://www.fbi.gov/news/stories/2008/february/swatting020408
[TASMANIA] [TASMANIA]
"Emergency services seek SIM-less calls block", ABC News "Emergency services seek SIM-less calls block", ABC News
Online, August 18, 2006, Online, August 18, 2006,
http://www.abc.net.au/news/newsitems/200608/s1717956.htm http://www.abc.net.au/news/newsitems/200608/s1717956.htm
[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
We would like to thank the members of the IETF ECRIT working group,
including Marc Linsner, Henning Schulzrinne and Brian Rosen, for
their input at IETF 85 that helped get this documented pointed in the
right direction. We would also like to thank members of the IETF
GEOPRIV WG, including Andrew Newton, Murugaraj Shanmugam, Martin
Thomson, Richard Barnes and Matt Lepinski for their feedback to
previous versions of this document.
Authors' Addresses Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net Email: Hannes.Tschofenig@gmx.net
 End of changes. 97 change blocks. 
563 lines changed or deleted 575 lines changed or added

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