< draft-ietf-ecrit-trustworthy-location-05.txt   draft-ietf-ecrit-trustworthy-location-06.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: September 12, 2013 Columbia University Expires: January 14, 2014 Columbia University
B. Aboba (ed.) B. Aboba (ed.)
Microsoft Corporation Skype
13 March 2013 15 July 2013
Trustworthy Location Trustworthy Location
draft-ietf-ecrit-trustworthy-location-05.txt draft-ietf-ecrit-trustworthy-location-06.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 how to convey location in a manner that is This document describes how to convey location in a manner that is
inherently secure and reliable. It also provides guidelines for inherently secure and reliable. It also provides guidelines for
assessing the trustworthiness of location information. assessing the trustworthiness of location information.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2013. This Internet-Draft will expire on January 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 6 2.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 6
2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 7 2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 7
3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Signed Location by Value . . . . . . . . . . . . . . . . . 8 3.1. Signed Location by Value . . . . . . . . . . . . . . . . . 8
3.2. Location by Reference . . . . . . . . . . . . . . . . . . 10 3.2. Location by Reference . . . . . . . . . . . . . . . . . . 11
3.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 13 3.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 14
4. Location Trust Assessment . . . . . . . . . . . . . . . . . . 15 4. Location Trust Assessment . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Informative references . . . . . . . . . . . . . . . . . . 19 7.1. Informative references . . . . . . . . . . . . . . . . . . 20
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Several public and commercial services depend upon location Several public and commercial services depend upon location
information in their operations. This includes emergency services information in their operations. This includes emergency services
(such as fire, ambulance and police) as well as commercial services (such as fire, ambulance and police) as well as commercial services
such as food delivery and roadside assistance. such as food delivery and roadside assistance.
Services that depend on location commonly experience security issues Services that depend on location commonly experience security issues
today. While prank calls have been a problem for emergency services today. While prank calls have been a problem for emergency services
skipping to change at page 3, line 49 skipping to change at page 3, line 49
Many documented cases of "swatting" involve not only the faking of an Many documented cases of "swatting" involve not only the faking of an
emergency, but also the absence of accurate caller identification and emergency, but also the absence of accurate caller identification and
the delivery of misleading location data. Today these attacks are the delivery of misleading location data. Today these attacks are
often carried out by providing false caller identification, since for often carried out by providing false caller identification, since for
circuit-switched calls from landlines, location provided to the PSAP circuit-switched calls from landlines, location provided to the PSAP
is determined from a lookup using the calling telephone number. With is determined from a lookup using the calling telephone number. With
IP-based emergency services, in addition to the potential for false IP-based emergency services, in addition to the potential for false
caller identification, it is also possible to attach misleading caller identification, it is also possible to attach misleading
location information to the emergency call. location information to the emergency call.
Ideally, a call taker at a PSAP should be put in the position to Ideally, a call taker at a Public Service Answering Point (PSAP)
assess, in real-time, the level of trust that can be placed on the should be put in the position to assess, in real-time, the level of
information provided within a call. This includes automated location trust that can be placed on the information provided within a call.
conveyed along with the call and location information communicated by This includes automated location conveyed along with the call and
the caller, as well as identity information about the caller. Where location information communicated by the caller, as well as identity
real-time assessment is not possible, it is important to be able to information about the caller. Where real-time assessment is not
determine the source of the call in a post-mortem, so as to be able possible, it is important to be able to determine the source of the
to enforce accountability. call in a post-mortem, so as to be able to enforce accountability.
This document defines terminology (including the meaning of This document defines terminology (including the meaning of
"trustworthy location") in Section 1.1, investigates security threats "trustworthy location") in Section 1.1, investigates security threats
in Section 2, outlines potential solutions in Section 3, covers trust in Section 2, outlines potential solutions in Section 3, covers trust
assessment in Section 4 and discusses security considerations in assessment in Section 4 and discusses security considerations in
Section 5. 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",
skipping to change at page 5, line 5 skipping to change at page 4, line 49
for a Location-by-Reference Mechanism" [RFC5808]. for a Location-by-Reference Mechanism" [RFC5808].
"Trustworthy Location" is defined as location information that can be "Trustworthy Location" is defined as location information that can be
attributed to a trusted source, has been protected against attributed to a trusted source, has been protected against
modification in transmit, and has been assessed as trustworthy. modification in transmit, and has been assessed as trustworthy.
"Location Trust Assessment" refers to the process by which the "Location Trust Assessment" refers to the process by which the
reliability of location information can be assessed. This topic is reliability of location information can be assessed. This topic is
discussed in Section 4. discussed in Section 4.
[I.D.thomson-geopriv-location-dependability] Section 2 defines
terminology relating to location fabrication:
Place Shifting: In place shifting, an attacker selects any location
(presumably somewhere other than where they are currently located)
and constructs a PIDF-LO based on that information.
Time Shifting: In a time shifting, or replay, attack the attacker
uses location information that was valid in the past, but is no
longer valid because the attacker has moved since the location was
generated.
Location Theft: An attacker that is able to observe the Target's
location information can replay this information and thereby
appear to be at the same location.
Location Swapping: Two colluding attackers can conspire to fake
location by exchanging location information. One attacker can
pretend to be at the other's location.
2. Threats 2. Threats
While previous IETF documents have analyzed aspects of the security While previous IETF documents have analyzed aspects of the security
of emergency services or threats to geographic location privacy, of emergency services or threats to geographic location privacy,
those documents do not cover the threats arising from unreliable those documents do not cover the threats arising from unreliable
location information. location information.
A threat analysis of the emergency services system is provided in A threat analysis of the emergency services system is provided in
"Security Threats and Requirements for Emergency Call Marking and "Security Threats and Requirements for Emergency Call Marking and
Mapping" [RFC5069]. RFC 5069 describes attacks on the emergency Mapping" [RFC5069]. RFC 5069 describes attacks on the emergency
skipping to change at page 5, line 29 skipping to change at page 5, line 46
an individual from receiving aid, or to gain information about an an individual from receiving aid, or to gain information about an
emergency. "Threat Analysis of the Geopriv Protocol" [RFC3694] emergency. "Threat Analysis of the Geopriv Protocol" [RFC3694]
describes threats against geographic location privacy, including describes threats against geographic location privacy, including
protocol threats, threats resulting from the storage of geographic protocol threats, threats resulting from the storage of geographic
location data, and threats posed by the abuse of information. location data, and threats posed by the abuse of information.
This document focuses on threats from attackers providing false This document focuses on threats from attackers providing false
location information within emergency calls. Since we do not focus location information within emergency calls. Since we do not focus
on attackers gaining control of infrastructure elements (e.g., on attackers gaining control of infrastructure elements (e.g.,
location servers, call route servers) or the emergency services IP location servers, call route servers) or the emergency services IP
network, the threats are derived from the introduction of network, the threats arise from end hosts. In addition to threats
untrustworthy location information by end hosts. In addition to arising from the intentional forging of caller identification or
threats arising from the intentional forging of location information, location information, end hosts may be induced to provide
end hosts may be induced to provide untrustworthy location untrustworthy location information. For example, end hosts may
information. For example, end hosts may obtain location from obtain location from civilian GPS, which is vulnerable to spoofing
civilian GPS, which is vulnerable to spoofing [GPSCounter] or from [GPSCounter] or from third party Location Service Providers (LSPs)
third party Location Service Providers (LSPs) which may be vulnerable which may be vulnerable to attack or may not provide location
to attack or may not warrant the use of their services for emergency accuracy suitable for emergency purposes.
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.
Malicious infrastructure adversary model: The emergency call routing Malicious infrastructure adversary model: The emergency call routing
elements, such as the LIS, the LoST infrastructure, used for elements, such as the LIS, the LoST infrastructure, used for
mapping locations to PSAP address, or call routing elements, may mapping locations to PSAP address, or call routing elements, may
act maliciously. act maliciously.
Malicious end host adversary model: The end host itself acts Malicious end host adversary model: The end host itself acts
maliciously, whether the owner is aware of this or whether it is maliciously, whether the owner is aware of this or whether it is
acting as a bot. acting under the control of a third party.
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.
2.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 or via a fixed Voice over IP service,
caller-id spoofing. Where location is attached to the emergency call this attack can be carried out via caller-id spoofing. For example,
by an end host, several avenues are available to provide false where a Voice Service Provider enables setting of the outbound caller
location information: identification without checking it against the authenticated
identity, forging caller identification is trivial. Where an
attacker can gain entry to a PBX, they can then subsequently use that
access to launch a denial of service attack against the PSAP, or to
make fraudulent emergency calls.
Where location is attached to the emergency call by an end host,
several avenues are available to provide false location information:
1. The end host could fabricate a 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 end host 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 The following represent examples of location forging threats:
where the conveyed location is suspect (e.g. potentially wrong city,
state, country or continent). However, in other situations only
entities close to the caller may be able to verify the correctness of
location information.
The following list presents threats specific to location information
handling:
Place shifting: Trudy, the adversary, pretends to be at an arbitrary Place shifting: Trudy, the adversary, pretends to be at an arbitrary
location. In some cases, place shifting can be limited in range, location. In some cases, place shifting can be limited in range,
e.g., to the coverage area of a particular cell tower. e.g., to the coverage area of a particular cell tower.
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.
skipping to change at page 7, line 26 skipping to change at page 7, line 42
authentication (e.g., using the Extensible Authentication Protocol authentication (e.g., using the Extensible Authentication Protocol
(EAP) [RFC3748]); (EAP) [RFC3748]);
(b) caller identity, such as might be determined from authentication (b) caller identity, such as might be determined from authentication
of the emergency caller at the VoIP application layer. of the emergency caller at the VoIP application layer.
If the adversary did not authenticate itself to the VSP, then If the adversary did not authenticate itself to the VSP, then
accountability may depend on verification of the network access accountability may depend on verification of the network access
identity. However, this also may not have been authenticated, such identity. However, this also may not have been authenticated, such
as in the case where an open IEEE 802.11 Access Point is used to as in the case where an open IEEE 802.11 Access Point is used to
initiate a nuisance emergency call. Although endpoint information initiate a prank emergency call. Although endpoint information such
such as the IP or MAC address may have been logged, tying this back as the IP or MAC address may have been logged, tying this back to the
to the device owner may be challenging. device owner may be challenging.
Unlike the existing telephone system, VoIP emergency calls could Unlike the existing telephone system, VoIP emergency calls can
require strong identity, which need not necessarily be coupled to a provide a strong identity that 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.
3. Solutions 3. Solutions
This section presents three mechanisms which can be used to convey This section presents three mechanisms which can be used to convey
location: signed location by value (Section 3.1), location by location securely: signed location by value (Section 3.1), location
reference (Section 3.2) and proxy added location (Section 3.3). by reference (Section 3.2) and proxy added location (Section 3.3).
In order for to provide authentication and integrity protection for In order to provide authentication and integrity protection for the
the SIP messages conveying location, several security approaches are SIP messages conveying location, several security approaches are
available. While it is possible for proxies to use security available. It is possible to ensure that modification of the
mechanisms such as SIP Identity [RFC4474] to ensure that identity and location in transit can be detected by the location
modifications to the location in transit can be detected by the recipient (e.g., the PSAP), using cryptographic mechanisms, as
location recipient (e.g., the PSAP), compatibility with Session described in "Enhancements for Authenticated Identity Management in
Border Controllers (SBCs) that modify integrity-protected headers has the Session Initiation Protocol" [RFC4474]. However, compatibility
proven to be an issue in practice. As a result, the use of SIP over with Session Border Controllers (SBCs) that modify integrity-
TLS is at present a more likely mechanism to provide per-message protected headers has proven to be an issue in practice. As a
authentication and integrity protection. result, SIP over TLS is currently a more deployable mechanism to
provide per-message authentication and integrity protection hop-by-
hop.
3.1. Signed Location by Value 3.1. Signed Location by Value
With location signing, a location server signs the location With location signing, a location server signs the location
information before it is sent to the end host, (the entity subject to information before it is sent to the end host, (the entity subject to
the location determination process). the location determination process). The signed location information
is then verified by the location recipient and not by the target. A
straw-man proposal for location signing is provided in "Digital
Signature Methods for Location Dependability" [I-D.thomson-geopriv-
location-dependability].
The signed location information is then verified by the location Figure 1 shows the communication model with the target requesting
recipient and not by the target. Figure 1 shows the communication signed location in step (a), the location server returns it in step
model with the target requesting signed location in step (a), the (b) and it is then conveyed to the location recipient in step (c) who
location server returns it in step (b) and it is then conveyed to the verifies it. For SIP, the procedures described in "Location
location recipient in step (c) who verifies it. For SIP, the Conveyance for the Session Initiation Protocol" [RFC6442] are
procedures described in "Location Conveyance for the Session applicable for location conveyance.
Initiation Protocol" [RFC6442] are applicable for location
conveyance.
+-----------+ +-----------+ +-----------+ +-----------+
| | | Location | | | | Location |
| LIS | | Recipient | | LIS | | Recipient |
| | | | | | | |
+-+-------+-+ +----+------+ +-+-------+-+ +----+------+
^ | --^ ^ | --^
| | -- | | --
Geopriv |Req. | -- Geopriv |Req. | --
Location |Signed |Signed -- Geopriv Location |Signed |Signed -- Geopriv
skipping to change at page 8, line 44 skipping to change at page 9, line 25
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
In order to limit replay attacks, additional information, such as In order to limit replay attacks, [I.D.thomson-geopriv-location-
timestamps or expiration times, has to be included together with the dependability] proposes the addition of a "validity" element to the
signed location. If the location is retrieved from a location PIDF-LO, including a "from" sub-element containing the time that
server, even a stationary end host has to periodically obtain a fresh location information was validated by the signer, as well as an
signed location, or incur the additional delay of querying during the "until" sub-element containing the last time that the signature can
emergency call. be considered valid.
While bot-nets are unlikely to be deterred by location signing, One of the consequences of including an "until" element is that even
accurate location information would limit the subset of the bot-net a stationary target would need to periodically obtain a fresh PIDF-
that could be used for an attack, as only hosts within the PSAP LO, or incur the additional delay of querying during an emergency
serving area would be useful in placing emergency calls. call.
To prevent location-swapping attacks it is necessary to include some Although privacy-preserving procedures may be disabled for emergency
some target-specific identity information. The required information calls, by design, PIDF-LO objects limit the information available for
depends on whether the goal is real-time verification by the location real-time attribution. As noted in [RFC5985] Section 6.6:
recipient or post-mortem analysis (where the goal is determination of
the legal entity responsible for the attack). As argued in Section The LIS MUST NOT include any means of identifying the Device in
4, real-time verification is not always possible. the PIDF-LO unless it is able to verify that the identifier is
correct and inclusion of identity is expressly permitted by a Rule
Maker. Therefore, PIDF parameters that contain identity are
either omitted or contain unlinked pseudonyms [RFC3693]. A
unique, unlinked presentity URI SHOULD be generated by the LIS for
the mandatory presence "entity" attribute of the PIDF document.
Optional parameters such as the "contact" and "deviceID" elements
[RFC4479] are not used.
Also, the device referred to in the PIDF-LO may not necessarily be
the same entity conveying the PIDF-LO to the PSAP. As noted in
[RFC6442] Section 1:
In no way does this document assume that the SIP user agent client
that sends a request containing a location object is necessarily
the Target. The location of a Target conveyed within SIP
typically corresponds to that of a device controlled by the
Target, for example, a mobile phone, but such devices can be
separated from their owners, and moreover, in some cases, the user
agent may not know its own location.
Without the ability to tie the target identity to the identity
asserted in the SIP message, it is possible for an attacker to cut
and paste a PIDF-LO obtained by a different device or user into a SIP
INVITE and send this to the PSAP. This cut and paste attack could
succeed even when a PIDF-LO is signed, or [RFC4474] is implemented.
To address location-swapping attacks, [I-D.thomson-geopriv-location-
dependability] proposes addition of an "identity" element which could
include a SIP URI (enabling comparison against the identity asserted
in the SIP headers) or an X.509v3 certificate. If the target was
authenticated by the LIS, an "authenticated" attribute is added.
However, inclusion of an "identity" attribute could enable location
tracking, so that a "hash" element is also proposed which could
contain a hash of the content of the "identity" element instead. In
practice, such a hash would not be much better for real-time
validation than a pseudonym.
Location signing is unlikely to deter attacks launched by bot-nets, Location signing is unlikely to deter attacks launched by bot-nets,
since the work required to verify the location signature is since the work required to verify the location signature is
considerable. Location signing is also difficult when the host considerable. However, while bot-nets are unlikely to be deterred by
obtains location via mechanisms such as GPS, unless trusted computing location signing, accurate location information would limit the
approaches, with tamper-proof GPS modules, can be applied. subset of the bot-net that could be used for an attack, as only hosts
Otherwise, an end host can pretend to have a GPS device, and the within the PSAP serving area would be useful in placing emergency
recipient will need to rely on its ability to assess the level of calls.
trust that should be placed in the end host location claim.
A straw-man proposal for location signing is provided in [I- Location signing is also difficult when the host obtains location via
D.thomson-geopriv-location-dependability], and [NENA-i2] Section 3.7 mechanisms such as GPS, unless trusted computing approaches, with
includes operational recommendations relating to location signing: 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
its ability to assess the level of trust that should be placed in the
end host location claim.
[NENA-i2] Section 3.7 includes operational recommendations relating
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
rooted in VESA. For this purpose, VPC and ERDB operators rooted in VESA. For this purpose, VPC and ERDB operators
should issue certs to LIS operators. should issue certs to LIS operators.
skipping to change at page 10, line 14 skipping to change at page 11, line 35
by the LIS operator to be verified by the PSAP. Rooting the trust by the LIS operator to be verified by the PSAP. Rooting the trust
hierarchy in VESA can be accomplished either by having the VESA hierarchy in VESA can be accomplished either by having the VESA
directly sign the LIS certificates, or by the creation of directly sign the LIS certificates, or by the creation of
intermediate CAs certified by the VESA, which will then issue intermediate CAs certified by the VESA, which will then issue
certificates to the LIS. In terms of the workload imposed on the certificates to the LIS. In terms of the workload imposed on the
VESA, the latter approach is highly preferable. However, this raises VESA, the latter approach is highly preferable. However, this raises
the question of who would operate the intermediate CAs and what the the question of who would operate the intermediate CAs and what the
expectations would be. expectations would be.
In particular, the question arises as to the requirements for LIS In particular, the question arises as to the requirements for LIS
certificate issuance, and whether they are significantly different certificate issuance, and how they would compare to requirements for
from say, requirements for issuance of an SSL/TLS web certificate. issuance of other certificates such as an SSL/TLS web certificate.
3.2. Location by Reference 3.2. Location by Reference
Location-by-reference was developed so that end hosts can avoid Location-by-reference was developed so that end hosts can avoid
having to periodically query the location server for up- to-date having to periodically query the location server for up- to-date
location information in a mobile environment. Additionally, if location information in a mobile environment. Additionally, if
operators do not want to disclose location information to the end operators do not want to disclose location information to the end
host without charging them, location-by-reference provides a host without charging them, location-by-reference provides a
reasonable alternative. As noted in "A Location Dereference Protocol reasonable alternative. As noted in "A Location Dereference Protocol
Using HTTP-Enabled Location Delivery (HELD)" [RFC6753], a location Using HTTP-Enabled Location Delivery (HELD)" [RFC6753], a location
skipping to change at page 15, line 15 skipping to change at page 16, line 21
4. Location Trust Assessment 4. Location Trust Assessment
The ability to assess the level of trustworthiness of conveyed The ability to assess the level of trustworthiness of conveyed
location information is important, since this makes it possible to location information is important, since this makes it possible to
understand how much value should be placed on location information, understand how much value should be placed on location information,
as part of the decision making process. As an example, if automated as part of the decision making process. As an example, if automated
location information is understood to be highly suspect, a call taker location information is understood to be highly suspect, a call taker
can put more effort into obtaining location information from the can put more effort into obtaining location information from the
caller. caller.
Caller accountability is another important aspect of trust Location trust assessment has value regardless of whether the
location has been conveyed securely (via signed location, location-
by-reference or proxy-added location) or not (via location-by-value
without location signing), since secure conveyance does not provide
assurance relating to the validity or provenance of location data.
To prevent location-swapping attacks, the "entity" element of the
PIDF-LO is of limited value if an unlinked pseudonym is provided in
this field. However, if the LIS authenticates the target, then the
linkage between the pseudonym and the target identity can be
recovered post-mortem.
As noted in [I.D.thomson-geopriv-location-dependability], if the
location object was signed, the location recipient has additional
information on which to base their trust assessment, such as the
validity of the signature, the identity of the target, the identity
of the LIS, whether the LIS authenticated the target, and the
identifier included in the "entity" field.
Caller accountability is also an important aspect of trust
assessment. Can the individual purchasing the device or activating assessment. Can the individual purchasing the device or activating
service be identified or did the call originate from a non-service service be identified or did the call originate from a non-service
initialized (NSI) device whose owner cannot be determined? Prior to initialized (NSI) device whose owner cannot be determined? Prior to
the call, was the caller authenticated at the network or application the call, was the caller authenticated at the network or application
layer? In the event of a prank call, can audit logs be made layer? In the event of a prank call, can audit logs be made
available to an investigator, or can information relating to the available to an investigator, or can information relating to the
owner of an unlinked pseudonym be provided, enabling investigators to owner of an unlinked pseudonym be provided, enabling investigators to
unravel the chain of events that lead to the attack? In practice, unravel the chain of events that lead to the attack? In practice,
the ability to identify a caller may decrease the likelihood of the ability to identify a caller may decrease the likelihood of
caller misbehavior. For example, where emergency calls have been caller misbehavior. For example, where emergency calls have been
allowed from handsets lacking a SIM card, or where ownership of the allowed from handsets lacking a SIM card, or where ownership of the
SIM card cannot be determined, the frequency of nuisance calls has SIM card cannot be determined, the frequency of nuisance calls has
often been unacceptably high [TASMANIA][UK][SA]. often been unacceptably high [TASMANIA][UK][SA].
Note that location trust assessment has value regardless of whether
the location has been conveyed securely (via signed location,
location-by-reference or proxy-added location) or not (via location-
by-value without location signing), since secure conveyance does not
provide assurance relating to the validity or provenance of location
data.
In practice, the source of the location data is important for In practice, the source of the location data is important for
location trust assessment. For example, location provided by a location trust assessment. For example, location provided by a
Location Information Server (LIS) whose administrator has an Location Information Server (LIS) whose administrator has an
established history of meeting emergency location accuracy established history of meeting emergency location accuracy
requirements (e.g. Phase II) may be considered more reliable than requirements (e.g. Phase II) may be considered more reliable than
location information provided by a third party Location Service location information provided by a third party Location Service
Provider (LSP) that disclaims use of location information for Provider (LSP) that disclaims use of location information for
emergency purposes. emergency purposes.
However, even where an LSP does not attempt to meet the accuracy However, even where an LSP does not attempt to meet the accuracy
skipping to change at page 16, line 4 skipping to change at page 17, line 23
Provider (LSP) that disclaims use of location information for Provider (LSP) that disclaims use of location information for
emergency purposes. emergency purposes.
However, even where an LSP does not attempt to meet the accuracy However, even where an LSP does not attempt to meet the accuracy
requirements for emergency location, it still may be able to provide requirements for emergency location, it still may be able to provide
information useful in assessing about how reliable location information useful in assessing about how reliable location
information is likely to be. For example, was location determined 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 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 triangulation method used? If based on cell tower or AP location
data, was the information obtained from an authoritative source (e.g. data, was the information obtained from an authoritative source (e.g.
the tower or AP owner) and when was the last time that the location the tower or AP owner) and when was the last time that the location
of the tower or access point was verified? of the tower or access point was verified?
For real-time validation, information in the signaling and media For real-time validation, information in the signaling and media
packets can be cross checked against location information. For packets can be cross checked against location information. For
example, it may be possible to determine the region associated with example, it may be possible to determine the city, state, country or
the IP address included within SIP Via: or Contact: headers, or the continent associated with the IP address included within SIP Via: or
media source address, and compare this against the location Contact: headers, or the media source address, and compare this
information reported by the caller or conveyed in the PIDF-LO. While against the location information reported by the caller or conveyed
a CAPTCHA-style test may be applied to suspicious calls to lower the in the PIDF-LO. However, in some situations only entities close to
risk from bot-nets, this is quite controversial for emergency the caller may be able to verify the correctness of location
services, due to the risk of delaying or rejecting valid calls. information.
Although privacy-preserving procedures may be disabled for emergency
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 PIDF-LO unless it is able to verify that the identifier is
correct and inclusion of identity is expressly permitted by a Rule
Maker. Therefore, PIDF parameters that contain identity are
either omitted or contain unlinked pseudonyms [RFC3693]. A
unique, unlinked presentity URI SHOULD be generated by the LIS for
the mandatory presence "entity" attribute of the PIDF document.
Optional parameters such as the "contact" and "deviceID" elements
[RFC4479] are not used.
Also, the device referred to in the PIDF-LO may not necessarily be
the same entity conveying the PIDF-LO to the PSAP. As noted in
[RFC6442] Section 1:
In no way does this document assume that the SIP user agent client
that sends a request containing a location object is necessarily
the Target. The location of a Target conveyed within SIP
typically corresponds to that of a device controlled by the
Target, for example, a mobile phone, but such devices can be
separated from their owners, and moreover, in some cases, the user
agent may not know its own location.
Due to these design choices, it is possible for an attacker to cut
and paste a PIDF-LO obtained by a different device or user into a SIP
INVITE and send this to the PSAP. While PIDF-LO signing would
prevent modification of a PIDF-LO or invention of one out of whole
cloth, it would not prevent this cut and paste attack. Neither would
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.
Real-time validation of the timestamp contained within PIDF-LO Real-time validation of the timestamp contained within PIDF-LO
objects (reflecting the time at which the location was determined) is objects (reflecting the time at which the location was determined) is
also challenging. Even if the PIDF-LO is signed the timestamp only also challenging. To address time-shifting attacks, the "timestamp"
represents an assertion by the LIS, which may or may not be element of the PIDF-LO, defined in [RFC3863], can be examined and
trustworthy. For example, the recipient of the signed PIDF-LO may compared against timestamps included within the enclosing SIP
not know whether the LIS supports time synchronization, or whether it message, to determine whether the location data is sufficiently
is possible to reset the LIS clock manually without detection. Even fresh. However, the timestamp only represents an assertion by the
if the timestamp was valid at the time location was determined, a LIS, which may or may not be trustworthy. For example, the recipient
time period may elapse between when the PIDF-LO was provided and when of the signed PIDF-LO may not know whether the LIS supports time
it is conveyed to the recipient. Periodically refreshing location synchronization, or whether it is possible to reset the LIS clock
information to renew the timestamp even though the location manually without detection. Even if the timestamp was valid at the
information itself is unchanged puts additional load on LISes. As a time location was determined, a time period may elapse between when
result, recipients need to validate the timestamp in order to the PIDF-LO was provided and when it is conveyed to the recipient.
determine whether it is credible. 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.
While this document focuses on the discussion of real-time While this document focuses on the discussion of real-time
determination of suspicious emergency calls, the use of audit logs determination of suspicious emergency calls, the use of audit logs
may help in enforcing accountability among emergency callers. For may help in enforcing accountability among emergency callers. For
example, in the event of a prank call, information relating to the example, in the event of a prank 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
skipping to change at page 17, line 42 skipping to change at page 18, line 26
considerable. However, although real-time validation based on PIDF- considerable. However, although real-time validation based on PIDF-
LO elements is challenging, where LIS audit logs are available (such LO elements is challenging, where LIS audit logs are available (such
as where a law enforcement agency can present a subpoena), linking of as where a law enforcement agency can present a subpoena), linking of
a pseudonym to the device obtaining location can be accomplished in a a pseudonym to the device obtaining location can be accomplished in a
post-mortem. post-mortem.
Where attacks are frequent and continuous, automated mechanisms are Where attacks are frequent and continuous, automated mechanisms are
required. For example, it might be valuable to develop mechanisms to required. For example, it might be valuable to develop mechanisms to
exchange audit trails information in a standardized format between exchange audit trails information in a standardized format between
ISPs and PSAPs / VSPs and PSAPs or heuristics to distinguish ISPs and PSAPs / VSPs and PSAPs or heuristics to distinguish
potentially fraudulent emergency calls from real emergencies. potentially fraudulent emergency calls from real emergencies. 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.
5. Security Considerations 5. Security Considerations
IP-based emergency services face a number of security threats that do IP-based emergency services face a number of security threats that do
not exist within the legacy system. In order to limit prank calls, not exist within the legacy system. In order to limit prank calls,
legacy emergency services rely on the ability to identify callers, as legacy emergency services rely on the ability to identify callers, as
well as on the difficulty of location spoofing for normal users. The well as on the difficulty of location spoofing for normal users. The
ability to ascertain identity is important, since the threat of ability to ascertain identity is important, since the threat of
punishment reduces prank calls; as an example, calls from pay phones punishment reduces prank calls; as an example, calls from pay phones
are subject to greater scrutiny by the call taker. are subject to greater scrutiny by the call taker.
skipping to change at page 19, line 9 skipping to change at page 19, line 44
human interaction by these call takers is required then this can very human interaction by these call takers is required then this can very
quickly have severe consequences. 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 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
attacks described in this document is non-trivial. Location theft
requires the attacker to be in proximity to the location to spoofed,
and location swapping requires the attacker to collude with someone
who was at the spoofed 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.
6. IANA Considerations 6. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
7. References 7. References
7.1. Informative References 7.1. Informative References
[DHCP-URI-OPT] [DHCP-URI-OPT]
Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 and Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 and
skipping to change at page 20, line 5 skipping to change at page 20, line 49
[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.
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and
J. Peterson, "Presence Information Data Format (PIDF)", RFC
3863, August 2004.
[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.
skipping to change at page 22, line 28 skipping to change at page 23, line 28
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building, New York, NY 10027 450 Computer Science Building, New York, NY 10027
US US
Phone: +1 212 939 7004 Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu Email: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu URI: http://www.cs.columbia.edu
Bernard Aboba Bernard Aboba
Microsoft Corporation Skype
One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
US US
Email: bernard_aboba@hotmail.com Email: bernard_aboba@hotmail.com
 End of changes. 34 change blocks. 
168 lines changed or deleted 226 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/