< draft-ietf-ecrit-trustworthy-location-10.txt   draft-ietf-ecrit-trustworthy-location-11.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 1, 2014 Columbia University Expires: December 2, 2014 Columbia University
B. Aboba (ed.) B. Aboba (ed.)
Microsoft Corporation Microsoft Corporation
31 May 2014 1 June 2014
Trustworthy Location Trustworthy Location
draft-ietf-ecrit-trustworthy-location-10.txt draft-ietf-ecrit-trustworthy-location-11.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 focuses on the security issues arising from conveyance This document describes threats relating to conveyance of location an
of location within an emergency call, and describes mechanisms emergency call, and describes techniques that improve the reliability
availble to convey location in a manner that is inherently secure and and security of location information conveyed in a IP-based emergency
reliable. It also provides guidelines for assessing the service call. It also provides guidelines for assessing the
trustworthiness of location information. 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 December 1, 2014. This Internet-Draft will expire on December 2, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 8 2.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 8
2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 9 2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 9
3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Mitigation Techniques . . . . . . . . . . . . . . . . . . . . 9
3.1. Signed Location by Value . . . . . . . . . . . . . . . . . 10 3.1. Signed Location by Value . . . . . . . . . . . . . . . . . 10
3.2. Location by Reference . . . . . . . . . . . . . . . . . . 14 3.2. Location by Reference . . . . . . . . . . . . . . . . . . 13
3.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 17 3.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
skipping to change at page 3, line 39 skipping to change at page 3, line 39
focuses on the additional threats that are introduced by the support focuses on the additional threats that are introduced by the support
of IP-based emergency services in nomadic and mobile devices, in of IP-based emergency services in nomadic and mobile devices, in
which location may be conveyed to the PSAP within the emergency call. which location may be conveyed to the PSAP within the emergency call.
Ideally, a call taker at a PSAP should be able to assess, in real- Ideally, a call taker at a PSAP should be able to assess, in real-
time, the level of trust that can be placed on the information time, the level of trust that can be placed on the information
provided within a call. This includes automated location conveyed provided within a call. This includes automated location conveyed
along with the call and location information communicated by the along with the call and location information communicated by the
caller, as well as identity information relating to the caller or the caller, as well as identity information relating to the caller or the
device initiating the call. Where real-time assessment is not device initiating the call. Where real-time assessment is not
possible, it is important to be able to determine the source of the possible, it is important to be able to determine the source of the
call after the fact, so as to be able to enforce accountability. call in a post-incident investigation, so as to be able to enforce
accountability.
This document defines terminology (including the meaning of This document defines terminology (including the meaning of
"trustworthy location") in Section 1.1, reviews existing work in "trustworthy location") in Section 1.1, reviews existing work in
Section 1.2, describes the threat model in Section 2, outlines Section 1.2, describes the threat model in Section 2, outlines
potential solutions in Section 3, covers trust assessment in Section potential mitigation techniques in Section 3, covers trust assessment
4 and discusses security considerations in Section 5. 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].
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
skipping to change at page 4, line 43 skipping to change at page 4, line 43
[RFC5808]. [RFC5808].
"Trustworthy Location" is defined as location information that can be "Trustworthy Location" is defined as location information that can be
attributed to a trusted source, has been protected against attributed to a trusted source, has been protected against
modification in transmit, and has been assessed as trustworthy. modification in transmit, and has been assessed as trustworthy.
"Location Trust Assessment" refers to the process by which the "Location Trust Assessment" refers to the process by which the
reliability of location information can be assessed. This topic is reliability of location information can be assessed. This topic is
discussed in Section 4. discussed in Section 4.
"Identity Spoofing" is where the attacker forges or obscures their
identity so as to prevent themselves from being identified as the
source of the attack. One class of identity spoofing attack involves
the forging of call origin identification.
The following additional terms apply to location spoofing: The following additional terms apply to location spoofing:
"Place Shifting" is where the attacker constructs a Presence "Place Shifting" is where the attacker constructs a Presence
Information Data Format Location Object (PIDF-LO) for a location Information Data Format Location Object (PIDF-LO) for a location
other than where they are currently located. In some cases, place other than where they are currently located. In some cases, place
shifting can be limited in range (e.g., within the coverage area of a shifting can be limited in range (e.g., within the coverage area of a
particular cell tower). particular cell tower).
"Time Shifting" is where the attacker uses or re-uses location "Time Shifting" is where the attacker uses or re-uses location
information that was valid in the past, but is no longer valid information that was valid in the past, but is no longer valid
because the attacker has moved. because the attacker has moved.
"Location Theft" is where the attacker captures a Target's location "Location Theft" is where the attacker captures a Target's location
information and presents it as their own. Location theft can occur information (possibly including a signature) and presents it as their
in a single instance, or may be continuous (e.g., where the attacker own. Location theft can occur in a single instance, or may be
has gained control over the victim's device). Location theft may continuous (e.g., where the attacker has gained control over the
also be combined with time shifting to present someone else's victim's device). Location theft may also be combined with time
location information after the original Target has moved. shifting to present someone else's location information after the
original Target has moved.
"Identity Spoofing" is where the attacker forges or obscures their
identity so as to prevent themselves from being identified as the
source of the attack. One class of identity spoofing attack involves
the forging of call origin identification.
1.2. Literature Review 1.2. Literature Review
There is existing work on the problem of hoax calls, as well as There is existing work on the problem of hoax calls, as well as
analyses of aspects of the security of emergency services, threats to analyses of aspects of the security of emergency services, threats to
geographic location privacy, threats relating to spoofing of caller geographic location privacy, threats relating to spoofing of caller
identification and modification of location information in transit. identification and modification of location information in transit.
This section reviews the literature. This section reviews the literature.
1.2.1. Hoax Calls 1.2.1. Hoax Calls
Hoax calls have been a problem for emergency services dating back to Hoax calls have been a problem for emergency services dating back to
the time of street corner call boxes. The European Emergency Number the time of street corner call boxes. As the European Emergency
Association (EENA) has noted [EENA]: "False emergency calls divert Number Association (EENA) has noted [EENA]: "False emergency calls
emergency services away from people who may be in life-threatening divert emergency services away from people who may be in life-
situations and who need urgent help. This can mean the difference threatening situations and who need urgent help. This can mean the
between life and death for someone in trouble." As a result, difference between life and death for someone in trouble."
considerable attention has been focused on the problem.
EENA [EENA] has attempted to define terminology and describe best EENA [EENA] has attempted to define terminology and describe best
current practices for dealing with false emergency calls. Reducing current practices for dealing with false emergency calls. Reducing
the number of hoax calls represents a challenge, since emergency the number of hoax calls represents a challenge, since emergency
services authorities in most countries are required to answer every services authorities in most countries are required to answer every
call (whenever possible). Where the caller cannot be identified, the call (whenever possible). Where the caller cannot be identified, the
ability to prosecute is limited. ability to prosecute is limited.
A particularly dangerous form of hoax call is "swatting" - a hoax A particularly dangerous form of hoax call is "swatting" - a hoax
emergency call that draws a response from law enforcement prepared emergency call that draws a response from law enforcement prepared
for a violent confrontation (e.g. a fake hostage situation that for a violent confrontation (e.g. a fake hostage situation that
results in dispatching of a "Special Weapons And Tactics" (SWAT) results in dispatching of a "Special Weapons And Tactics" (SWAT)
team). In 2008 the Federal Bureau of Investigation (FBI) issued a team). In 2008 the Federal Bureau of Investigation (FBI) issued a
warning [Swatting] about an increase in the frequency and warning [Swatting] about an increase in the frequency and
sophistication of these attacks. sophistication of these attacks.
As noted in [EENA], many documented cases of "swatting" involve not As noted in [EENA], many documented cases of "swatting" involve not
only the faking of an emergency, but also falsification or only the faking of an emergency, but also falsification or
obfuscation of identity. In general, the ability to identify the obfuscation of identity. There are a number of techniques by which
caller also appears to influence the incidence of hoax calls. Where hoax callers attempt to avoid identification, and in general, the
a Voice Service Provider enables setting of the outbound caller ability to identify the caller appears to influence the incidence of
hoax calls.
Where a Voice Service Provider enables setting of the outbound caller
identification without checking it against the authenticated identification without checking it against the authenticated
identity, forging caller identification is trivial. Similarly where identity, forging caller identification is trivial. Similarly where
an attacker can gain entry to a Private Branch Exchange (PBX), they an attacker can gain entry to a Private Branch Exchange (PBX), they
can then subsequently use that access to launch a denial of service can then subsequently use that access to launch a denial of service
attack against the PSAP, or to make fraudulent emergency calls. attack against the PSAP, or to make fraudulent emergency calls.
Where emergency calls have been allowed from handsets lacking a SIM Where emergency calls have been allowed from handsets lacking a SIM
card, or where ownership of the SIM card cannot be determined, the card, or where ownership of the SIM card cannot be determined, the
frequency of hoax calls has often been unacceptably high frequency of hoax calls has often been unacceptably high
[TASMANIA][UK][SA]. [TASMANIA][UK][SA].
However, to date there have been few documented cases of hoax calls However, there are few documented cases of hoax calls that have
that have arisen from conveyance of untrustworthy location arisen from conveyance of untrustworthy location information within
information within an emergency call, which is the focus of this an emergency call, which is the focus of this document.
document.
1.2.2. Existing IETF Work 1.2.2. Existing IETF Work
The Internet architecture for emergency calling is described in The Internet architecture for emergency calling is described in
"Framework for Emergency Calling Using Internet Multimedia" [RFC6443] "Framework for Emergency Calling Using Internet Multimedia" [RFC6443]
and "Best Current Practice for Communications Services in Support of and "Best Current Practice for Communications Services in Support of
Emergency Calling" [RFC6881]. The conveyance of location information Emergency Calling" [RFC6881]. The conveyance of location information
within the Session Initiation Protocol (SIP) is described in within the Session Initiation Protocol (SIP) is described in
"Location Conveyance for the Session Initiation Protocol" [RFC6442], "Location Conveyance for the Session Initiation Protocol" [RFC6442],
which in the Security Considerations (Section 7) includes discussion which in the Security Considerations (Section 7) includes discussion
skipping to change at page 7, line 7 skipping to change at page 7, line 9
"An Architecture for Location and Location Privacy in Internet "An Architecture for Location and Location Privacy in Internet
Applications" [RFC6280] describes an architecture for privacy- Applications" [RFC6280] describes an architecture for privacy-
preserving location-based services in the Internet, focusing on preserving location-based services in the Internet, focusing on
authorization, security and privacy requirements for the data formats authorization, security and privacy requirements for the data formats
and protocols used by these services. Within the Security and protocols used by these services. Within the Security
Considerations (Section 5), mechanisms for ensuring the security of Considerations (Section 5), mechanisms for ensuring the security of
the location distribution chain are discussed; these include the location distribution chain are discussed; these include
mechanisms for hop-by-hop confidentiality and integrity protection as mechanisms for hop-by-hop confidentiality and integrity protection as
well as end-to-end assurance. As noted in Section 6.3: well as end-to-end assurance. As noted in Section 6.3:
"there are three critical steps in the placement of an emergency "there are three critical steps in the placement of an emergency
call, each involving location information: call, each involving location information:
1. Determine the location of the caller. 1. Determine the location of the caller.
2. Determine the proper Public Safety Answering Point (PSAP) for the 2. Determine the proper Public Safety Answering Point (PSAP) for
caller's location. the caller's location.
3. Send a SIP INVITE message, including the caller's location, to the 3. Send a SIP INVITE message, including the caller's location, to
PSAP." the PSAP."
"Geopriv Requirements" [RFC3693] focuses on the authorization, "Geopriv Requirements" [RFC3693] focuses on the authorization,
security and privacy requirements of location-dependent services, security and privacy requirements of location-dependent services,
including emergency services. Within the Security Considerations including emergency services. Within the Security Considerations
(Section 8), this includes discussion of emergency services (Section 8), this includes discussion of emergency services
authentication (Section 8.3), and issues relating to identity and authentication (Section 8.3), and issues relating to identity and
anonymity (Section 8.4). anonymity (Section 8.4).
"Threat Analysis of the Geopriv Protocol" [RFC3694] describes threats "Threat Analysis of the Geopriv Protocol" [RFC3694] describes threats
against geographic location privacy, including protocol threats, against geographic location privacy, including protocol threats,
skipping to change at page 9, line 45 skipping to change at page 9, line 46
Unlike the existing telephone system, VoIP emergency calls can Unlike the existing telephone system, VoIP emergency calls can
provide an identity that need not necessarily be coupled to a provide an identity that need not necessarily be coupled to a
business relationship with the IAP, ISP or VSP. However, due to the business relationship with the IAP, ISP or VSP. However, due to the
time-critical nature of emergency calls, multi-layer authentication time-critical nature of emergency calls, multi-layer authentication
is undesirable, so that in most cases, only the device placing the is undesirable, so that in most cases, only the device placing the
call will be able to be identified. Furthermore, deploying call will be able to be identified. Furthermore, deploying
additional credentials for emergency service purposes (such as additional credentials for emergency service purposes (such as
certificates) increases costs, introduces a significant certificates) increases costs, introduces a significant
administrative overhead and is only useful if widely deployed. administrative overhead and is only useful if widely deployed.
3. Solutions 3. Mitigation Techniques
This section presents two mechanisms which can be used to enable The sections that follow present three mechanisms for mitigating the
location to be authenticated: signed location by value (Section 3.1), threats presented in Section 2:
which provides for authentication and integrity protection of the
PIDF-LO, and location-by-reference (Section 3.2), which enables
location to be obtained by the PSAP via direct contact with the
location server. In addition, a mechanism is presented which
protects against location forgery by the end host: proxy added
location (Section 3.3). Since at the time of this writing there is
no completed specification for signed location by value, only an
expired straw-man proposal, it should be understood that only the
location-by-reference and proxy added location mechanisms are
suitable for deployment.
In order to provide authentication and integrity protection for the 1. Signed location by value (Section 3.1), which provides for
Session Initiation Protocol (SIP) messages conveying location, authentication and integrity protection of the PIDF-LO. At the
several security approaches are available. It is possible to ensure time of this writing, there is only an expired straw-man proposal
that modification of the identity and location in transit can be for this mechanism [I-D.thomson-geopriv-location-dependability],
detected by the location recipient (e.g., the PSAP), using so that it is not suitable for deployment.
cryptographic mechanisms, as described in "Enhancements for
Authenticated Identity Management in the Session Initiation Protocol" 2. Location-by-reference (Section 3.2), which enables location to
[RFC4474]. However, compatibility with Session Border Controllers be obtained by the PSAP directly from the location server, over a
(SBCs) that modify integrity-protected headers has proven to be an confidential and integrity-protected channel, avoiding
issue in practice. As a result, SIP over Transport Layer Security modification by the end-host or an intermediary. This mechanism
(TLS) is currently a more deployable mechanism to provide per-message is specified in [RFC6753].
authentication and integrity protection hop-by-hop.
3. Proxy added location (Section 3.3), which protects against
location forgery by the end host. This mechanism is specified in
[RFC6442].
3.1. Signed Location by Value 3.1. Signed Location by Value
With location signing, a location server signs the location With location signing, a location server signs the location
information before it is sent to the Target. The signed location information before it is sent to the Target. The signed location
information is then sent to the location recipient, who verifies it. information is then sent to the location recipient, who verifies it.
Figure 1 shows the communication model with the target requesting Figure 1 shows the communication model with the target requesting
signed location in step (a), the location server returns it in step signed location in step (a), the location server returns it in step
(b) and it is then conveyed to the location recipient in step (c) who (b) and it is then conveyed to the location recipient in step (c) who
skipping to change at page 13, line 9 skipping to change at page 12, line 37
within the PSAP serving area would be useful in placing emergency within the PSAP serving area would be useful in placing emergency
calls. calls.
Location signing is also difficult when the host obtains location via Location signing is also difficult when the host obtains location via
mechanisms such as GPS, unless trusted computing approaches, with mechanisms such as GPS, unless trusted computing approaches, with
tamper-proof GPS modules, can be applied. Otherwise, an end host can tamper-proof GPS modules, can be applied. Otherwise, an end host can
pretend to have a GPS device, and the recipient will need to rely on pretend to have a GPS device, and the recipient will need to rely on
its ability to assess the level of trust that should be placed in the its ability to assess the level of trust that should be placed in the
end host location claim. end host location claim.
Even though location signing mechanisms have not been standardized,
[NENA-i2] Section 3.7 includes operational recommendations relating [NENA-i2] Section 3.7 includes operational recommendations relating
to location signing: to location signing:
Location determination is out of scope for NENA, but we can offer Location determination is out of scope for NENA, but we can offer
guidance on what should be considered when designing mechanisms to guidance on what should be considered when designing mechanisms to
report location: report location:
1. The location object should be digitally signed. 1. The location object should be digitally signed.
2. The certificate for the signer (LIS operator) should be 2. The certificate for the signer (LIS operator) should be
skipping to change at page 18, line 47 skipping to change at page 18, line 27
Location trust assessment has value regardless of whether the Location trust assessment has value regardless of whether the
location itself is authenticated (e.g. signed location) or is location itself is authenticated (e.g. signed location) or is
obtained directly from the location server (e.g. location-by- obtained directly from the location server (e.g. location-by-
reference) over security transport, since these mechanisms do not reference) over security transport, since these mechanisms do not
provide assurance of the validity or provenance of location data. provide assurance of the validity or provenance of location data.
To prevent location-theft attacks, the "entity" element of the PIDF- To prevent location-theft attacks, the "entity" element of the PIDF-
LO is of limited value if an unlinked pseudonym is provided in this LO is of limited value if an unlinked pseudonym is provided in this
field. However, if the LIS authenticates the target, then the field. However, if the LIS authenticates the target, then the
linkage between the pseudonym and the target identity can be linkage between the pseudonym and the target identity can be
recovered after the fact. recovered in a post-incident investigation.
As noted in [I.D.thomson-geopriv-location-dependability], if the As noted in [I.D.thomson-geopriv-location-dependability], if the
location object was signed, the location recipient has additional location object was signed, the location recipient has additional
information on which to base their trust assessment, such as the information on which to base their trust assessment, such as the
validity of the signature, the identity of the target, the identity validity of the signature, the identity of the target, the identity
of the LIS, whether the LIS authenticated the target, and the of the LIS, whether the LIS authenticated the target, and the
identifier included in the "entity" field. identifier included in the "entity" field.
Caller accountability is also an important aspect of trust Caller accountability is also an important aspect of trust
assessment. Can the individual purchasing the device or activating assessment. Can the individual purchasing the device or activating
skipping to change at page 20, line 30 skipping to change at page 20, line 10
example, in the event of a hoax call, information relating to the example, in the event of a hoax call, information relating to the
owner of the unlinked pseudonym could be provided to investigators, owner of the unlinked pseudonym could be provided to investigators,
enabling them to unravel the chain of events that lead to the attack. enabling them to unravel the chain of events that lead to the attack.
However, while auditability is an important deterrent, it is likely However, while auditability is an important deterrent, it is likely
to be of most benefit in situations where attacks on the emergency to be of most benefit in situations where attacks on the emergency
services system are likely to be relatively infrequent, since the services system are likely to be relatively infrequent, since the
resources required to pursue an investigation are likely to be resources required to pursue an investigation are likely to be
considerable. However, although real-time validation based on PIDF- considerable. However, although real-time validation based on PIDF-
LO elements is challenging, where LIS audit logs are available (such LO elements is challenging, where LIS audit logs are available (such
as where a law enforcement agency can present a subpoena), linking of as where a law enforcement agency can present a subpoena), linking of
a pseudonym to the device obtaining location can be accomplished in a a pseudonym to the device obtaining location can be accomplished
post-mortem. during an investigation.
Where attacks are frequent and continuous, automated mechanisms are Where attacks are frequent and continuous, automated mechanisms are
required. For example, it might be valuable to develop mechanisms to required. For example, it might be valuable to develop mechanisms to
exchange audit trails information in a standardized format between exchange audit 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
IP-based emergency services face a number of security threats that do It should be understood that mounting the attacks described in
not exist within the legacy system. Mechanically placing a large Section 2 is non-trivial. Location theft requires the attacker to be
number of emergency calls that appear to come from different in proximity to the location being spoofed, or to either collude with
locations is difficult in a legacy environment. Also, in the current another end host or gain control of an end host so as to obtain its
system, it would be very difficult for an attacker from country 'Foo' location. Time shifting attacks require that the attacker visit the
to attack the emergency services infrastructure located in country location and submit it before the location information is considered
'Bar'. stale, while travelling rapidly away from that location to avoid
apprehension. Obtaining a PIDF-LO from a spoofed IP address requires
However, within an IP-based emergency services a number of these that the attacker be on the path between the HELD requester and the
attacks become much easier to mount. Emergency services have three LIS.
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. Even for large cities PSAPs may only have a handful of call
takers on duty. So even if call takers can, by questioning the
caller, eliminate many hoax calls, PSAPs can be overwhelmed even by 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 (e.g.
emergency calls placed from PSTN pay phones or SIM-less cell phones).
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 result, attackers can
forge emergency call information with a lower risk of being held
accountable.
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 "Location-URL Mapping
Architecture and Framework" [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 Although it is important to ensure that location information cannot
be faked there will be many GPS-enabled devices that will find it be faked, it should be understood that the mitigation techniques
presented in this document are not universally applicable. For
example, there will be many GPS-enabled devices that will find it
difficult to utilize any of the solutions described in Section 3. It difficult to utilize any of the solutions described in Section 3. It
is also unlikely that users will be willing to upload their location is also unlikely that users will be willing to upload their location
information for "verification" to a nearby location server located in information for "verification" to a nearby location server located in
the access network. the access network.
Nevertheless, it should be understood that mounting several of the While this document focuses on threats that arise from conveyance of
attacks described in this document is non-trivial. Location theft misleading location information, rather than caller identification or
requires the attacker to be in proximity to the location being authentication and integrity protection of the messages in which
spoofed, or to either collude with another endhost or gain control of location is conveyed. Nevertheless, it should be understood that
an endhost so as to obtain its location. Time shifting attacks these aspects are important.
require that the attacker visit the location and submit it before the
location information is considered stale, while travelling rapidly In some countries, regulators may not require the authenticated
away from that location to avoid apprehension. Obtaining a PIDF-LO identity of the emergency caller (e.g. emergency calls placed from
from a spoofed IP address requires that the attacker be on the path PSTN pay phones or SIM-less cell phones). Furthermore, if identities
between the HELD requester and the LIS. 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 result, attackers can forge emergency call
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
Session Initiation Protocol (SIP) messages conveying location,
several security approaches are available. It is possible to ensure
that modification of the identity and location in transit can be
detected by the location recipient (e.g., the PSAP), using
cryptographic mechanisms, as described in "Enhancements for
Authenticated Identity Management in the Session Initiation Protocol"
[RFC4474]. However, compatibility with Session Border Controllers
(SBCs) that modify integrity-protected headers has proven to be an
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
solution, SIP over Transport Layer Security (TLS) can be used to
provide message authentication and integrity protection hop-by-hop.
It should also be understood that even where the mitigation
techniques described in this document are utilized, PSAPs remain
vulnerable to distributed denial of service attacks. Placing a large
number of emergency calls that appear to come from different
locations is an example of an attack that is difficult to carry out
within legacy system, but is easier to imagine within IP-based
emergency services. Also, in the current system, it would be very
difficult for an attacker from country 'Foo' to attack the emergency
services infrastructure located in country 'Bar', but this attack is
possible within IP-based emergency services.
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. Even for large cities PSAPs may only
have a handful of call takers on duty. So even if automated
techniques are utilized to evaluate the trustworthiness of conveyed
location and call takers can, by questioning the caller, eliminate
many hoax calls, PSAPs can be overwhelmed even by a small-scale
attack. Finally, first responder resources are scarce, particularly
during mass-casualty events.
6. IANA Considerations 6. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
7. References 7. References
7.1. Informative References 7.1. Informative References
[I-D.ietf-stir-problem-statement] [I-D.ietf-stir-problem-statement]
Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Telephone Identity Problem Statement", Internet draft (work in Telephone Identity Problem Statement", Internet draft (work in
progress), draft-ietf-stir-problem-statement-05.txt, May 2014. progress), draft-ietf-stir-problem-statement-05.txt, May 2014.
[I-D.ietf-stir-threats] [I-D.ietf-stir-threats]
Peterson, J., "Secure Telephone Identity Threat Model", Peterson, J., "Secure Telephone Identity Threat Model",
Internet draft (work in progress), draft-ietf-stir- Internet draft (work in progress), draft-ietf-stir-
threats-02.txt, February 2014. threats-02.txt, February 2014.
[I-D.jennings-stir-rfc4474bis]
Peterson, J., Jennings, C. and E. Rescorla, "Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
Internet draft (work in progress), draft-jennings-stir-
rfc4474bis-01.txt, February 2014.
[I-D.thomson-geopriv-location-dependability]
Thomson, M. and J. Winterbottom, "Digital Signature Methods
for Location Dependability", Internet draft (work in
progress), draft-thomson-geopriv-location-
dependability-07.txt, March 2011.
[EENA] EENA, "False Emergency Calls", EENA Operations Document, [EENA] EENA, "False Emergency Calls", EENA Operations Document,
Version 1.1, May 2011, http://www.eena.org/ressource/static/ Version 1.1, May 2011, http://www.eena.org/ressource/static/
files/2012_05_04-3.1.2.fc_v1.1.pdf files/2012_05_04-3.1.2.fc_v1.1.pdf
[GPSCounter] [GPSCounter]
Warner, J. S. and R. G. Johnston, "GPS Spoofing Warner, J. S. and R. G. Johnston, "GPS Spoofing
Countermeasures", Los Alamos research paper LAUR-03-6163, Countermeasures", Los Alamos research paper LAUR-03-6163,
December 2003. December 2003.
[NENA-i2] "08-001 NENA Interim VoIP Architecture for Enhanced 9-1-1 [NENA-i2] "08-001 NENA Interim VoIP Architecture for Enhanced 9-1-1
skipping to change at page 23, line 43 skipping to change at page 23, line 46
and Mapping", RFC 5069, January 2008. and Mapping", RFC 5069, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Level Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Level Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5491] Winterbottom, J., Thomson, M. and H. Tschofenig, "GEOPRIV [RFC5491] Winterbottom, J., Thomson, M. and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", RFC Usage Clarification, Considerations, and Recommendations", RFC
5491, March 2009. 5491, March 2009.
[RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", RFC 5582, September 2009.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.2 Message Specification", RFC Extensions (S/MIME) Version 3.2 Message Specification", RFC
5751, January 2010. 5751, January 2010.
[RFC5808] Marshall, R., "Requirements for a Location-by-Reference [RFC5808] Marshall, R., "Requirements for a Location-by-Reference
Mechanism", RFC 5808, May 2010. 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.
 End of changes. 29 change blocks. 
132 lines changed or deleted 147 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/