draft-ietf-ecrit-trustworthy-location-11.txt   draft-ietf-ecrit-trustworthy-location-12.txt 
ECRIT Working Group H. Tschofenig ECRIT Working Group H. Tschofenig
INTERNET-DRAFT ARM Ltd. INTERNET-DRAFT ARM Ltd.
Category: Informational H. Schulzrinne Category: Informational H. Schulzrinne
Expires: December 2, 2014 Columbia University Expires: December 2, 2014 Columbia University
B. Aboba (ed.) B. Aboba (ed.)
Microsoft Corporation Microsoft Corporation
1 June 2014 2 June 2014
Trustworthy Location Trustworthy Location
draft-ietf-ecrit-trustworthy-location-11.txt draft-ietf-ecrit-trustworthy-location-12.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 an This document describes threats relating to conveyance of location in
emergency call, and describes techniques that improve the reliability an emergency call, and describes techniques that improve the
and security of location information conveyed in a IP-based emergency reliability and security of location information conveyed in a IP-
service call. It also provides guidelines for assessing the based emergency service call. It also provides guidelines for
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 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/.
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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 Literature review . . . . . . . . . . . . . . . . . . . . 5 1.2 Literature review . . . . . . . . . . . . . . . . . . . . 5
2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 8 2.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 9
2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 9 2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 9
3. Mitigation Techniques . . . . . . . . . . . . . . . . . . . . 9 3. Mitigation Techniques . . . . . . . . . . . . . . . . . . . . 10
3.1. Signed Location by Value . . . . . . . . . . . . . . . . . 10 3.1. Signed Location by Value . . . . . . . . . . . . . . . . . 10
3.2. Location by Reference . . . . . . . . . . . . . . . . . . 13 3.2. Location by Reference . . . . . . . . . . . . . . . . . . 14
3.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 16 3.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 17
4. Location Trust Assessment . . . . . . . . . . . . . . . . . . 18 4. Location Trust Assessment . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Informative references . . . . . . . . . . . . . . . . . . 22 7.1. Informative references . . . . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
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.
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 only supporting emergency service calls from
skipping to change at page 4, line 13 skipping to change at page 4, line 13
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 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)" are taken
from "Requirements for Emergency Context Resolution with Internet from "Requirements for Emergency Context Resolution with Internet
Technologies" [RFC5012]. Technologies" [RFC5012].
The definition of a "hoax call" is taken from "False Emergency Calls" The definition of a "hoax call" is taken from "False Emergency Calls"
[EENA]. [EENA].
The definition of "Target" and "Device" is taken from "An The definition of "Device", "Target" and "Location Information
Architecture for Location and Location Privacy in Internet Server" (LIS) is taken from "An Architecture for Location and
Applications" [RFC6280]. Location Privacy in Internet Applications" [RFC6280], Section 7.
The term "Device" denotes the physical device, such as a mobile
phone, PC, or embedded micro-controller, whose location is tracked as
a proxy for the location of a Target.
The term "Target" denotes an individual or other entity whose
location is sought in the Geopriv architecture. In many cases, the
Target will be the human user of a Device, or it may be an object
such as a vehicle or shipping container to which a Device is
attached. In some instances, the Target will be the Device itself.
The Target is the entity whose privacy Geopriv seeks to protect.
The term "Location Information Server" denotes an entity responsible
for providing devices within an access network with information about
their own locations. A Location Information Server uses knowledge of
the access network and its physical topology to generate and
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 location information server (LIS), or by the Target
itself. It specifically does not refer to the location configuration itself. It specifically does not refer to the location configuration
protocol (LCP) used to deliver location information either to the protocol (LCP) used to deliver location information either to the
Target or the Recipient. This term is re-used from "GEOPRIV PIDF-LO Target or the Recipient. This term is re-used from "GEOPRIV PIDF-LO
Usage Clarification, Considerations, and Recommendations" [RFC5491]. Usage Clarification, Considerations, and Recommendations" [RFC5491].
The term "source" is used to refer to the LIS, node, or device from The term "source" is used to refer to the LIS, node, or device from
skipping to change at page 20, line 25 skipping to change at page 20, line 45
exchange audit trails information in a standardized format between exchange audit trails information in a standardized format between
ISPs and PSAPs / VSPs and PSAPs or heuristics to distinguish ISPs and PSAPs / VSPs and PSAPs or heuristics to distinguish
potentially fraudulent emergency calls from real emergencies. While potentially fraudulent emergency calls from real emergencies. While
a Completely Automated Public 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
It should be understood that mounting the attacks described in
Section 2 is non-trivial. Location theft requires the attacker to be
in proximity to the location being spoofed, or to either collude with
another end host or gain control of an end host so as to obtain its
location. Time shifting attacks require that the attacker visit the
location and submit it before the location information is considered
stale, while travelling rapidly away from that location to avoid
apprehension. Obtaining a PIDF-LO from a spoofed IP address requires
that the attacker be on the path between the HELD requester and the
LIS.
Although it is important to ensure that location information cannot Although it is important to ensure that location information cannot
be faked, it should be understood that the mitigation techniques be faked, the mitigation techniques presented in this document are
presented in this document are not universally applicable. For not universally applicable. For example, there will be many GPS-
example, there will be many GPS-enabled devices that will find it enabled devices that will find it difficult to utilize any of the
difficult to utilize any of the solutions described in Section 3. It solutions described in Section 3. It is also unlikely that users
is also unlikely that users will be willing to upload their location will be willing to upload their location information for
information for "verification" to a nearby location server located in "verification" to a nearby location server located in the access
the access network. network.
While 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, it should be understood that location is conveyed. Nevertheless, these aspects are important. In
these aspects are important. some countries, regulators may not require the authenticated identity
of the emergency caller (e.g. emergency calls placed from PSTN pay
In some countries, regulators may not require the authenticated phones or SIM-less cell phones). Furthermore, if identities can
identity of the emergency caller (e.g. emergency calls placed from easily be crafted (as it is the case with many VoIP offerings today),
PSTN pay phones or SIM-less cell phones). Furthermore, if identities then the value of emergency caller authentication itself might be
can easily be crafted (as it is the case with many VoIP offerings limited. As a result, attackers can forge emergency call information
today), then the value of emergency caller authentication itself with a lower risk of being held accountable, which may encourage hoax
might be limited. As a result, attackers can forge emergency call calls.
information with a lower risk of being held accountable, and this
appears to be correlated with an increase in 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 [RFC4474]. However, compatibility with Session Border Controllers
(SBCs) that modify integrity-protected headers has proven to be an (SBCs) that modify integrity-protected headers has proven to be an
issue in practice, and as a result, a revision is in progress issue in practice, and as a result, a revision is in progress
[I.D.jennings-stir-rfc4474bis]. In the absence of an end-to-end [I.D.jennings-stir-rfc4474bis]. 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.
It should also be understood that even where the mitigation PSAPs remain vulnerable to distributed denial of service attacks,
techniques described in this document are utilized, PSAPs remain even where the mitigation techniques described in this document are
vulnerable to distributed denial of service attacks. Placing a large utilized. Placing a large number of emergency calls that appear to
number of emergency calls that appear to come from different come from different locations is an example of an attack that is
locations is an example of an attack that is difficult to carry out difficult to carry out within the legacy system, but is easier to
within legacy system, but is easier to imagine within IP-based imagine within IP-based emergency services. Also, in the current
emergency services. Also, in the current system, it would be very system, it would be very difficult for an attacker from country 'Foo'
difficult for an attacker from country 'Foo' to attack the emergency to attack the emergency services infrastructure located in country
services infrastructure located in country 'Bar', but this attack is 'Bar', but this attack is possible within IP-based emergency
possible within IP-based emergency services. services.
While manually mounting the attacks described in Section 2 is non-
trivial, the attacks described in this document can be automated.
While manually carrying out a location theft would require the
attacker to be in proximity to the location being spoofed, or to
collude with another end host, an attacker able to run code on an end
host can obtain its location, and cause an emergency call to be made.
While manually carrying out a time shifting attack would require that
the attacker visit the location and submit it before the location
information is considered stale, while travelling rapidly away from
that location to avoid apprehension, these limitations would not
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
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
from the LIS, and then make an emergency call using it, this attack
becomes much easier. To mitigate the risk of automated attacks,
service providers can limit the ability of untrusted code (such as
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 fire fighters 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
 End of changes. 13 change blocks. 
56 lines changed or deleted 79 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/