draft-ietf-ecrit-trustworthy-location-00.txt   draft-ietf-ecrit-trustworthy-location-01.txt 
ECRIT H. Tschofenig ECRIT Working Group H. Tschofenig
Internet-Draft Nokia Siemens Networks INTERNET-DRAFT Nokia Siemens Networks
Intended status: Informational H. Schulzrinne Category: Informational H. Schulzrinne
Expires: March 25, 2011 Columbia University Expires: April 25, 2011 Columbia University
B. Aboba B. Aboba
Microsoft Corporation Microsoft Corporation
September 21, 2010 24 October 2010
Trustworthy Location Information Trustworthy Location Information
draft-ietf-ecrit-trustworthy-location-00.txt draft-ietf-ecrit-trustworthy-location-01.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, it appears that the identity of the requestor is roadside assistance, it is important to be able to determine whether
less important than accurate and trustworthy location information. location information is trustworthy.
To ensure adequate help location has to be left untouched by the end
point or by entities in transit.
This document lists different threats, an adversary model, outlines This document outlines potential threats to trustworthy location and
three frequentlly discussed solutions and discusses operational analyzes the operational issues with potential solutions.
considerations. Finally, the document concludes with a suggestion on
how to move forward.
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 March 25, 2011. This Internet-Draft will expire on April 25, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Emergency Services . . . . . . . . . . . . . . . . . . . . . . 5 3. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 6
4.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 8 3.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 7
4.2. Call Identity Spoofing . . . . . . . . . . . . . . . . . . 8 4. Solution Proposals . . . . . . . . . . . . . . . . . . . . . . 8
5. Solution Proposals . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Location Signing . . . . . . . . . . . . . . . . . . . . . 8
5.1. Location Signing . . . . . . . . . . . . . . . . . . . . . 10 4.2. Location by Reference . . . . . . . . . . . . . . . . . . 9
5.2. Location by Reference . . . . . . . . . . . . . . . . . . 11 4.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 11
5.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 13 5. Operational Considerations . . . . . . . . . . . . . . . . . . 11
6. Operations Considerations . . . . . . . . . . . . . . . . . . 14 5.1. Attribution to a Specific Trusted Source . . . . . . . . . 11
6.1. Attribution to a Specific Trusted Source . . . . . . . . . 14 5.2. Application to a Specific Point in Time . . . . . . . . . 16
6.2. Application to a Specific Point in Time . . . . . . . . . 18 5.3. Linkage to a Specific Endpoint . . . . . . . . . . . . . . 16
6.3. Linkage to a Specific Endpoint . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.1. Informative references . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
10.2. Informative references . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Much of the focus in trustable networks has been on ensuring the The operation of a number of public and commercial services depend
reliability of personal identity information or verifying privileges. upon location information in their operations. Emergency services,
However, in some cases, access to trustworthy location information is such as fire department, ambulance and police, are among these, as
more important than identity since some services are meant to be are commercial services such as food delivery and roadside
widely available, regardless of the identity of the requestor. assistance.
Emergency services, such as fire department, ambulance and police,
but also commercial services such as food delivery and roadside
assistance are among those. Customers, competitors or emergency
callers lie about their location to harm the service provider or to
deny services to others, by tying up the service capacity. In
addition, if third parties can modify the information, they can deny
services to the requestor.
Physical security is often based on location. As a trivial example, Users of the telephone network can summon emergency services such as
light switches in buildings are not typically protected by keycards ambulance, fire and police using a well-known emergency service
or passwords, but are only accessible to those within the perimeter number (e.g., 9-1-1 in North America, 1-1-2 in Europe). Location
of the building. Merchants processing credit card payments already information is used to route emergency calls to the appropriate
use location information to estimate the risk that a transaction is regional Public Safety Answering Point (PSAP) that serves the caller
fraudulent, based on the HTTP client's IP address (that is then to dispatch first-level responders to the emergency site.
translated to location). In all these cases, trustworthy location
information can be used to augment identity information or, in some
cases, avoid the need for role-based authorization.
A number of standardization organizations have developed mechanisms Physical security is often based on location. Light switches in
to make civic and geodetic location available to the end host. buildings are not typically protected by keycards or passwords, but
Examples for these protocols are LLDP-MED [LLDP-MED], DHCP extensions are only accessible to those within the perimeter of the building.
(see [RFC4776], [RFC3825]), HELD Merchants processing credit card payments already use location
[I-D.ietf-geopriv-http-location-delivery], or the protocols developed information to estimate the risk that a transaction is fraudulent,
within the IEEE as part of their link-layer specifications. The based on translation of the HTTP client's IP address to an estimated
server offering this information is usually called a Location location. In these cases, location information can be used to
Information Server (LIS). More common with high-quality cellular augment identity or, in some cases, avoid the need for role-based
devices is the ability for the end host itself to determine its own authorization.
location using GPS. The location information is then provided, by
reference or value, to the service-providing entities, i.e. location
recipients, via application protocols, such as HTTP, SIP or XMPP.
This document investigates the security threats in Section 4, and For services that depend on the accuracy of location information in
outlines three solutions that are frequently mentioned in Section 5. their operation, the ability to determine the trustworthiness of
We use emergency services an example to illustrate the security location information may be important. Prank calls have been a
problems, as the problems have been typically discussed in that problem for emergency services, dating back to the time of street
context since the stakes are high, but the issues apply also to other corner call boxes. Individual prank calls waste emergency services
examples as cited earlier. We also take a look at the operational and possibly endanger bystanders or emergency service personnel as
considerations in Section 6 since there is a cost associated with the they rush to the reported scene of a fire or accident. However, a
estbalishment of the necessary infrastructure. With the pros of the recent increase in the frequency and sophistication of the attacks
available technology being described and the cons of the operational has lead to the FBI issuing a warning [Swatting].
complexity highlighted we offer a conclusion in Section 7.
2. Terminology In situations where it is possible to place emergency calls without
accountability, experience has shown that the frequency of nuisance
calls can rise dramatically. For example, where emergency calls have
been allowed from handsets lacking a SIM card, or where ownership of
the SIM card cannot be determined, the frequency of nuisance calls
has often been unacceptably high [TASMANIA][UK][SA].
This document re-uses a lot of the terminology defined in Section 3 In emergency services deployments utilizing voice over IP, many of
of [RFC5012]. the assumptions of the public switched telephone network (PSTN) and
public land mobile network (PLMN) no longer hold. While the local
telephone company provides both physical access and the phone
service, with VoIP there is a split between the role of the Access
Infrastructure Provider (AIP), the Application (Voice) Service
Provider (VSP), and possibly a Location Service Provider (LSP). The
VSP may be located far away from the AIP and may either have no
business relationship with the AIP or may be a competitor. It is
also likely that the VSP will have no relationship with the PSAP.
The LSP may have no relationship with the AIP, the VSP, or the PSAP,
3. Emergency Services Standardization organizations have developed mechanisms to make civic
and geodetic location available to the end host, including LLDP-MED
[LLDP-MED], DHCP extensions [RFC4776][RFC3825], HELD [RFC5985], or
link-layer specifications such as [IEEE-802.11y]. The server
offering this information is usually called a Location Information
Server (LIS). This LIS may be deployed by an AIP, or it may be run
by a third party LSP, which may have no relatinoship with the AIP,
the VSP or the PSAP. More common with high-quality cellular devices
is the ability for the end host itself to determine its own location
using GPS. The location information is then provided, by reference
or value, to the service-providing entities, i.e. location
recipients, via application protocols, such as HTTP, SIP or XMPP.
Users of the legacy telephone network can summon emergency services This document investigates security threats in Section 3, and
such as ambulance, fire and police using a well-known emergency outlines potential solutions in Section 4. Operational
service number (e.g., 9-1-1 in North America, 1-1-2 in Europe). considerations are provided in Section 5 and conclusions are
Location information is used to route emergency calls to the discussed in Section 6.
appropriate regional Public Safety Answering Point (PSAP) that serves
the caller to dispatch first-level responders to the emergency site.
Regulators have already started to demand emergency service support 2. Terminology
for voice over IP. However, enabling such critical public services
using the Internet is challenging, as many of the assumptions of the
public switched telephone network (PSTN) / public land mobile network
(PLMN) no longer hold. In particular, while the local telephone
company provides both the physical access and the phone service, VoIP
allows and encourages to split these two roles between the Access
Infrastructure Provider (AIP) and Application (Voice) Service
Provider (VSP). The VSP may be located far away from the AIP and may
either have no business relationship with that AIP or may be a
competitor. It is also likely that the VSP will have no relationship
with the PSAP and will therefore be unknown.
4. Threats The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
IP-based emergency calling faces many security threats, most of which This document uses terms from [RFC5012] Section 3.
are well-known from other realms, such as protecting the privacy of
communications or against denial-of-service attacks using packet
flooding. Here, we focus specifically on a higher-layer threat that
is unique to services where semi-anonymous users can request
expensive services.
Prank calls have been a problem for emergency services, dating back 3. Threats
to the time of street corner call boxes. Individual prank calls
waste emergency services and possibly endanger bystanders or This document focuses on threats deriving from the introduction of
emergency service personnel as they rush to the reported scene of a untrustworthy location information by end hosts, regardless of
fire or accident. A more recent concern is that massive prank calls whether this occurs intentionally or unintentionally.
can be used to disrupt emergency services, e.g., during a mass-
casualty event and thus be used as a means to amplify the effect of a In addition to threats arising from the intentional forging of
terror attack, for example. location information, end hosts may be induced to provide
untrustworthy location information. For example, end hosts may
obtain location from civilian GPS, which is vulnerable to spoofing
[GPSCounter] or from third party Location Service Providers (LSPs)
which may be vulnerable to attack or may not warrant the use of their
services for emergency purposes.
Emergency services have three finite resources subject to denial of Emergency services have three finite resources subject to denial of
service attacks: the network and server infrastructure, call takers service attacks: the network and server infrastructure, call takers
and dispatchers, and the first responders, such as fire fighters and and dispatchers, and the first responders, such as fire fighters and
police officers. Protecting the network infrastructure is similar to police officers. Protecting the network infrastructure is similar to
protecting other high-value service providers, except that protecting other high-value service providers, except that location
trustworthy location information may be used to filter call setup information may be used to filter call setup requests, to weed out
requests, to weed out requests that are out of area. PSAPs even for requests that are out of area. PSAPs even for large cities may only
large cities may only have a handful of PSAP call takers on duty, so have a handful of PSAP call takers on duty, so even if they can, by
even if they can, by questioning the caller, eliminate a lot of prank questioning the caller, eliminate a lot of prank calls, they are
calls, they are quickly overwhelmed by even a small-scale attack. quickly overwhelmed by even a small-scale attack. Finally, first
Finally, first responder resources are scarce, particularly during responder resources are scarce, particularly during mass-casualty
mass-casualty events. events.
Currently, emergency services rely on the fact that location spoofing Legacy emergency services rely on the ability to identify callers, as
is difficult for normal users. Additionally, the identity of most well as on the difficulty of location spoofing for normal users to
callers can be ascertained, so that the threat of severe punishments limit prank calls. The ability to ascertain identity is important,
reduces prank calls. Mechanically placing a large number of since the threat of severe punishments reduces prank calls.
emergency calls that appear to come from different locations is also Mechanically placing a large number of emergency calls that appear to
difficult. Calls from payphones are subject to greater scrutiny by come from different locations is difficult. Calls from pay phones
the call taker. In the current system, it would be very difficult are subject to greater scrutiny by the call taker. In the current
for an attacker from country 'Foo' to attack the emergency services system, it would be very difficult for an attacker from country 'Foo'
infrastructure located in country 'Bar'. to attack the emergency services infrastructure located in country
'Bar'.
One of the main motivations of an adversary in the emergency services One of the main motivations of an adversary in the emergency services
context is to prevent callers from utilizing emergency service context is to prevent callers from utilizing emergency service
support. This can be done by a variety of means, such as support. This can be done by a variety of means, such as
impersonating a PSAP or directory servers, attacking SIP signaling impersonating a PSAP or directory servers, attacking SIP signaling
elements and location servers. elements and location servers.
Attackers may want to modify, prevent or delay emergency calls. In Attackers may want to modify, prevent or delay emergency calls. In
some cases, this will lead the PSAP to dispatch emergency personnel some cases, this will lead the PSAP to dispatch emergency personnel
to an emergency that does not exist and, hence, the personnel might 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 not be available to other callers. It might also be possible for an
attacker to impede the users from reaching an appropriate PSAP by attacker to impede the users from reaching an appropriate PSAP by
modifying the location of an end host or the information returned modifying the location of an end host or the information returned
from the mapping protocol. In some countries, regulators may not from the mapping protocol. In some countries, regulators may not
require the authenticated identity of the emergency caller, as is require the authenticated identity of the emergency caller, as is
true for PSTN-based emergency calls placed from payphones or SIM-less true for PSTN-based emergency calls placed from pay phones or SIM-
cell phones today. Furthermore, if identities can easily be crafted less cell phones today. Furthermore, if identities can easily be
(as it is the case with many VoIP offerings today), then the value of crafted (as it is the case with many VoIP offerings today), then the
emergency caller authentication itself might be limited. As a value of emergency caller authentication itself might be limited. As
consequence, an attacker can forge emergency call information without a consequence, an attacker can forge emergency call information
the chance of being held accountable for its own actions. without the chance of being held accountable for its own actions.
The above-mentioned attacks are mostly targeting individual emergency The above-mentioned attacks are mostly targeting individual emergency
callers or a very small fraction of them. If attacks are, however, callers or a very small fraction of them. If attacks are, however,
launched against the mapping architecture (see launched against the mapping architecture (see [RFC5582] or against
[I-D.ietf-ecrit-mapping-arch] or against the emergency services IP the emergency services IP network (including PSAPs), a larger region
network (including PSAPs), a larger region and a large number of and a large number of potential emergency callers are affected. The
potential emergency callers are affected. The call takers themselves call takers themselves are a particularly scarce resource and if
are a particularly scarce resource and if human interaction by these human interaction by these call takers is required then this can very
call takers is required then this can very quickly have severe quickly have severe consequences.
consequences.
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 as a bot.
We will focus only on the malicious end host adversary model since it In this document, we focus only on the malicious end host adversary
follows today's most common adversary model on the Internet that model.
includes bot nets.
4.1. Location Spoofing 3.1. Location Spoofing
An adversary can provide false location information in order to fool An adversary can provide false location information in an emergency
the emergency personnel. Such an attack is particularly easy if call in order to misdirect emergency resources. For calls
location information is attached to the emergency call by the end originating within the PSTN, this attack can be carried out via
host and is either not verified or cannot be verified by anyone. caller-id spoofing. Where location is attached to the emergency call
Only entities that are close to the caller can verify the correctness by an end host, several avenues are available to provide false
of location information. Another form of this attack is to fool a location information:
VSP (and indirectly a LIS) in using a wrong identity (such as an IP
address) for the location lookup. This type of attack can be 1. The end host could fabricate a PIDF-LO and convey it within an
accomplished in the PSTN today with the help of caller-id spoofing. emergency call;
2. The VSP (and indirectly a LIS) could be fooled into using the
wrong identity (such as an IP address) for location lookup,
thereby providing the end host with misleading location
information;
3. Inaccurate or out-of-date information (such spoofed GPS
signals, a stale wiremap or an inaccurate access point location
database) could be utilized by the LIS or the endhost in its
location determination, thereby leading to an inaccurate
determination of location.
By analysis of the SIP headers, it may be possible to flag situations
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 The following list presents threats specific to location information
handling: 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.
Location swapping: Trudy and Malory, located in different locations, Location swapping: Trudy and Malory, located in different locations,
can collude and swap location information and pretend to be in can collude and swap location information and pretend to be in
each other's location. each other's location.
4.2. Call Identity Spoofing 3.2. Identity Spoofing
If an adversary can place emergency calls without disclosing its With calls originating on an IP network, at least two forms of
identity, then prank calls are more difficult to be traced. There identity are relevant, with the distinction created by the split
are at least two different forms of authentication in this context: between the AIP and the VSP:
(a) network access authentication (e.g., using the Extensible
Authentication Protocol (EAP) [RFC3748] and (b) authentication of the
emergency caller at the VoIP application layer. This differentiation
is created by the split between the AIP and the VSP. Note that
different identities are involved and that the are also managed by
different parties and thus making the linkage between the two quite
difficult.
Trying to find an adversary that did not authenticate itself to the (a) network access identity such as might be determined via
VSP is difficult even though there is still a chance if network authentication (e.g., using the Extensible Authentication Protocol
access authentication was executed. If there is no authentication (EAP) [RFC3748];
(neither to the PSAP, to the VSP nor to the AIP) then it is very
challenging to trace the call back in order to a make a particular
entity accountable. This might, for example, be the case with an
open IEEE 802.11 WLAN access point even if the owner of the access
point can be determined.
However, unlike for the existing telephone system, it is possible to (b) caller identity, such as might be determined from authentication
imagine that VoIP emergency calls could require strong identity, as of the emergency caller at the VoIP application layer.
providing such identity information is not necessarily coupled to
having a business relationship with the AIP, ISP or VSP. However,
due to the time-critical nature of emergency calls, it is unlikely
that multi-layers authentication can be used, so that in most cases,
only the device placing the call will be able to be identified,
making the system vulnerable to botnet attacks. Furthermore,
deploying additional credentials for emergency service purposes, such
as dedicated certificates, increases costs, introduces a significant
administrative overhead and is only useful if widely used.
5. Solution Proposals If the adversary did not authenticate itself to the VSP, then
accountability may depend on verification of the network access
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
initiate a nuisance emergency call. Although endpoint information
such as the IP or MAC address may have been logged, tying this back
to the device owner may be challenging.
This section presents three solution approaches that have been Unlike the existing telephone system, VoIP emergency calls could
discussed in order to mitigate the threats discussed. require strong identity, which need not necessarily be coupled to a
business relationship with the AIP, ISP or VSP. However, due to the
time-critical nature of emergency calls, multi-layer authentication
is undesirable, so that in most cases, only the device placing the
call will be able to be identified, making the system vulnerable to
bot-net attacks. Furthermore, deploying additional credentials for
emergency service purposes (such as certificates) increases costs,
introduces a significant administrative overhead and is only useful
if widely deployed.
5.1. Location Signing 4. Solution Proposals
This section presents three potential solutions to the described
threats: location signing (Section 4.1), location by reference
(Section 4.2) and proxy added location (Section 4.3).
4.1. Location Signing
One way to avoid location spoofing is to let a trusted location One way to avoid location spoofing is to let a trusted location
server sign the location information before it is sent to the end server sign the location information before it is sent to the end
host, i.e., the entity subject to the location determination process. host, i.e., the entity subject to the location determination process.
The signed location information is then verified by the location The signed location information is then verified by the location
recipient and not by the target. Figure 1 shows the communication recipient and not by the target. Figure 1 shows the communication
model with the target requesting signed location in step (a), the model with the target requesting signed location in step (a), the
location server returns it in step (b) and it is then conveyed to the location server returns it in step (b) and it is then conveyed to the
location recipient in step (c) who verifies it. For SIP, the location recipient in step (c) who verifies it. For SIP, the
procedures described in [I-D.ietf-sip-location-conveyance] are procedures described in [I-D.ietf-sip-location-conveyance] are
skipping to change at page 10, line 48 skipping to change at page 9, line 7
| | | |
+-----------+ +-----------+
Figure 1: Location Signing Figure 1: Location Signing
Additional information, such as timestamps or expiration times, has Additional information, such as timestamps or expiration times, has
to be included together with the signed location to limit replay to be included together with the signed location to limit replay
attacks. If the location is retrieved from a location server, even a attacks. If the location is retrieved from a location server, even a
stationary end host has to periodically obtain a fresh signed stationary end host has to periodically obtain a fresh signed
location, or incur the additional delay of querying during the location, or incur the additional delay of querying during the
emergency call. emergency call. Bot nets are also unlikely to be deterred by
location signing. However, accurate location information would limit
Bot nets are also unlikely to be deterred by location signing. the usable subset of the bot net, as only hosts within the PSAP
However, accurate location information would limit the usable subset serving area would be useful in placing calls.
of the bot net, as only hosts within the PSAP serving area would be
useful in placing calls.
To prevent location-swapping attacks it is necessary to include some To prevent location-swapping attacks it is necessary to include some
some target specific identity information. The included information some target specific identity information. The included information
depends on the purpose, namely either real-time verification by the depends on the purpose, namely either real-time verification by the
location recipient or for the purpose of a post-mortem analysis when location recipient or for the purpose of a post-mortem analysis when
the location recipient wants to determine the legal entity behind the the location recipient wants to determine the legal entity behind the
target for prosecution (if this is possible). As argued in Section 6 target for prosecution (if this is possible). As argued in Section 6
the operational considerations make a real-time verification the operational considerations make a real-time verification
difficult. A strawman proposal for location signing is provided by difficult. A strawman proposal for location signing is provided by
[I-D.thomson-geopriv-location-dependability]. [I-D.thomson-geopriv-location-dependability].
skipping to change at page 11, line 35 skipping to change at page 9, line 40
Location verification may be most useful if it is used in conjunction Location verification may be most useful if it is used in conjunction
with other mechanisms. For example, a call taker can verify that the with other mechanisms. For example, a call taker can verify that the
region that corresponds to the IP address of the media stream roughly region that corresponds to the IP address of the media stream roughly
corresponds to the location information reported by the caller. To corresponds to the location information reported by the caller. To
make the use of bot nets more difficult, a CAPTCHA-style test may be make the use of bot nets more difficult, a CAPTCHA-style test may be
applied to suspicious calls, although this idea is quite applied to suspicious calls, although this idea is quite
controversial for emergency services, at the danger of delaying or controversial for emergency services, at the danger of delaying or
even rejecting valid calls. even rejecting valid calls.
5.2. Location by Reference 4.2. Location by Reference
The location-by-reference concept was developed so that end hosts The location-by-reference concept was developed so that end hosts
could avoid having to periodically query the location server for up- could avoid having to periodically query the location server for up-
to-date location information in a mobile environment. Additionally, to-date location information in a mobile environment. Additionally,
if operators do not want to disclose location information to the end if operators do not want to disclose location information to the end
host without charging them, location-by-reference provides a host without charging them, location-by-reference provides a
reasonable alternative. reasonable alternative.
Figure 2 shows the communication model with the target requesting a Figure 2 shows the communication model with the target requesting a
location reference in step (a), the location server returns the location reference in step (a), the location server returns the
reference in step (b), and it is then conveyed to the location reference in step (b), and it is then conveyed to the location
recipient in step (c). The location recipient needs to resolve the recipient in step (c). The location recipient needs to resolve the
reference with a request in step (d). Finally, location information reference with a request in step (d). Finally, location information
is returned to the Location Recipient afterwards. For location is returned to the Location Recipient afterwards. For location
conveyance in SIP, the procedures described in conveyance in SIP, the procedures described in [I-D.ietf-sip-
[I-D.ietf-sip-location-conveyance] are applicable. location-conveyance] are applicable.
+-----------+ Geopriv +-----------+ +-----------+ Geopriv +-----------+
| | Location | Location | | | Location | Location |
| LIS +<------------->+ Recipient | | LIS +<------------->+ Recipient |
| | Dereferencing | | | | Dereferencing | |
+-+-------+-+ Protocol (d) +----+------+ +-+-------+-+ Protocol (d) +----+------+
^ | --^ ^ | --^
| | -- | | --
Geopriv |Req. | -- Geopriv |Req. | --
Location |LbyR |LbyR -- Geopriv Location |LbyR |LbyR -- Geopriv
skipping to change at page 12, line 27 skipping to change at page 10, line 32
+-+-------+-+ -- +-+-------+-+ --
| Target / | -- | Target / | --
| End Host + | End Host +
| | | |
+-----------+ +-----------+
Figure 2: Location by Reference Figure 2: Location by Reference
The details for the dereferencing operations vary with the type of The details for the dereferencing operations vary with the type of
reference, such as a HTTP, HTTPS, SIP, SIPS URI or a SIP presence reference, such as a HTTP, HTTPS, SIP, SIPS URI or a SIP presence
URI. HTTP-Enabled Location Delivery (HELD) URI. HTTP-Enabled Location Delivery (HELD) [RFC5985] is an example
[I-D.ietf-geopriv-http-location-delivery] is an example of a protocol of a protocol that is able to return such references.
that is able to return such references.
For location-by-reference, the location server needs to maintain one For location-by-reference, the location server needs to maintain one
or several URIs for each target, timing out these URIs after a or several URIs for each target, timing out these URIs after a
certain amount of time. References need to expire to prevent the certain amount of time. References need to expire to prevent the
recipient of such a URL from being able to permanently track a host recipient of such a URL from being able to permanently track a host
and to offer garbage collection functionality for the location and to offer garbage collection functionality for the location
server. server.
Off-path adversaries must be prevented from obtaining the target's Off-path adversaries must be prevented from obtaining the target's
location. The reference contains a randomized component that location. The reference contains a randomized component that
skipping to change at page 13, line 5 skipping to change at page 11, line 7
fetches up-to-date location information from the location server, it fetches up-to-date location information from the location server, it
can also be assured that the location information is fresh and not can also be assured that the location information is fresh and not
replayed. However, this does not address location swapping. replayed. However, this does not address location swapping.
However, location-by-reference does not offer significant security However, location-by-reference does not offer significant security
benefits if the end host uses GPS to determine its location. At benefits if the end host uses GPS to determine its location. At
best, a network provider can use cell tower or triangulation best, a network provider can use cell tower or triangulation
information to limit the inaccuracy of user-provided location information to limit the inaccuracy of user-provided location
information. information.
5.3. Proxy Adding Location 4.3. Proxy Adding Location
Instead of making location information available to the end host, it Instead of making location information available to the end host, it
is possible to allow an entity in the AIP, or associated with the is possible to allow an entity in the AIP, or associated with the
AIP, to retrieve the location information on behalf of the end point. AIP, to retrieve the location information on behalf of the end point.
This solution is possible when the application layer messages are This solution is possible when the application layer messages are
routed through an entity with the ability to determine the location routed through an entity with the ability to determine the location
information of the end point, for example based on the end host's IP information of the end point, for example based on the end host's IP
or MAC address. or MAC address.
When the untrustworthy end host does not have the ability to access When the untrustworthy end host does not have the ability to access
skipping to change at page 13, line 39 skipping to change at page 11, line 41
emergency calls, even for customers they have no direct or indirect emergency calls, even for customers they have no direct or indirect
relationship with. To provide identity information about the relationship with. To provide identity information about the
emergency caller from the VSP it would be necessary to let the AIP emergency caller from the VSP it would be necessary to let the AIP
and the VSP to interact for authentication (see, for example, and the VSP to interact for authentication (see, for example,
[RFC4740]). This interaction along the Authentication, Authorization [RFC4740]). This interaction along the Authentication, Authorization
and Accounting infrastructure (see ) is often based on business and Accounting infrastructure (see ) is often based on business
relationships between the involved entities. The AIP and the VSP are relationships between the involved entities. The AIP and the VSP are
very likely to have no such business relationship, particularly when very likely to have no such business relationship, particularly when
talking about an arbitrary VSP somewhere on the Internet. In case talking about an arbitrary VSP somewhere on the Internet. In case
that the interaction between the AIP and the VSP fails due to the that the interaction between the AIP and the VSP fails due to the
lack of a business relationship then the procedures described in lack of a business relationship then typically a fall-back would be
[I-D.schulzrinne-ecrit-unauthenticated-access] are applicable and provided where no emergency caller identity information is made
typically a fall-back would be provided where no emergency caller available to the PSAP and the emergency call still has to be
identity information is made available to the PSAP and the emergency completed.
call still has to be completed.
6. Operations Considerations 5. Operational Considerations
6.1. Attribution to a Specific Trusted Source 5.1. Attribution to a Specific Trusted Source
[NENA-i2] Section 3.7 describes some of the aspects of attribution as [NENA-i2] Section 3.7 describes some of the aspects of attribution as
follows: follows:
The i2 solution proposes a Location Information Server (LIS) be The i2 solution proposes a Location Information Server (LIS) be
the source for distributing location information within an access the source for distributing location information within an access
network. Furthermore the validity, integrity and authenticity of network. Furthermore the validity, integrity and authenticity of
this information are directly attributed to the LIS operator. this information are directly attributed to the LIS operator.
Section 6.1.1 describes the issues that arise in ensuring the Section 6.1.1 describes the issues that arise in ensuring the
validity of location information provided by the LIS operator. validity of location information provided by the LIS operator.
Section 6.1.2 and Section 6.1.3 describe operational issues that Section 6.1.2 and Section 6.1.3 describe operational issues that
arise in ensuring the integrity and authenticity of location arise in ensuring the integrity and authenticity of location
information provided by the LIS operator. information provided by the LIS operator.
6.1.1. Validity 5.1.1. Validity
In existing networks where location information is both determined by In existing networks where location information is both determined by
the access/voice service provider as well as communicated by the AIP/ the access/voice service provider as well as communicated by the AIP/
VSP, responsibility for location validity can be attributed entirely VSP, responsibility for location validity can be attributed entirely
to a single party, namely the AIP/VSP. to a single party, namely the AIP/VSP.
However, on the Internet, not only may the AIP and VSP represent However, on the Internet, not only may the AIP and VSP represent
different parties, but location determination may depend on different parties, but location determination may depend on
information contributed by parties trusted by neither the AIP nor information contributed by parties trusted by neither the AIP nor
VSP, or even the operator of the Location Information Server (LIS). VSP, or even the operator of the Location Information Server (LIS).
skipping to change at page 15, line 6 skipping to change at page 12, line 48
determination on information gathered from a variety of sources which determination on information gathered from a variety of sources which
may merit varying levels of trust, such as information obtained from may merit varying levels of trust, such as information obtained from
the calling endpoint, or wiremap information that is time consuming the calling endpoint, or wiremap information that is time consuming
to verify or may rapidly go out of date. to verify or may rapidly go out of date.
For example, consider the case of a Location Information Server (LIS) For example, consider the case of a Location Information Server (LIS)
that utilizes LLDP-MED [LLDP-MED] endpoint move detection that utilizes LLDP-MED [LLDP-MED] endpoint move detection
notifications in determining calling endpoint location. Regardless notifications in determining calling endpoint location. Regardless
of whether the LIS implementation utilizes an LCP operating above the of whether the LIS implementation utilizes an LCP operating above the
link layer (such as an application layer protocol such as HELD link layer (such as an application layer protocol such as HELD
[I-D.ietf-geopriv-http-location-delivery]), the validity of the [RFC5985]), the validity of the location information conveyed would
location information conveyed would be dependent on the security be dependent on the security properties of LLDP-MED.
properties of LLDP-MED.
[LLDP-MED] Section 13.3 defines the endpoint move detection [LLDP-MED] Section 13.3 defines the endpoint move detection
notification as follows: notification as follows:
lldpXMedTopologyChangeDetected NOTIFICATION-TYPE lldpXMedTopologyChangeDetected NOTIFICATION-TYPE
OBJECTS { lldpRemChassisIdSubtype, OBJECTS { lldpRemChassisIdSubtype,
lldpRemChassisId, lldpRemChassisId,
lldpXMedRemDeviceClass lldpXMedRemDeviceClass
} }
STATUS current STATUS current
skipping to change at page 16, line 10 skipping to change at page 13, line 49
endpoint device may not be advertised in LLDP, or even if they are, endpoint device may not be advertised in LLDP, or even if they are,
endpoint move detection notification may not be triggered, either endpoint move detection notification may not be triggered, either
because no LinkUp/LinkDown notifications occur (e.g. the host adds or because no LinkUp/LinkDown notifications occur (e.g. the host adds or
changes an address without rebooting) or because these notifications changes an address without rebooting) or because these notifications
were not detectable by the Network Connectivity device (the endpoint were not detectable by the Network Connectivity device (the endpoint
device was connected to a hub rather than directly to a switch). device was connected to a hub rather than directly to a switch).
Similar issues may arise in situations where the LIS utilizes DHCP Similar issues may arise in situations where the LIS utilizes DHCP
lease data to obtain location information. Where the endpoint lease data to obtain location information. Where the endpoint
address was not obtained via DHCP (such as via manual assignment, address was not obtained via DHCP (such as via manual assignment,
stateless autoconfiguration [RFC4862] or Link-Local IPv4 self- stateless auto-configuration [RFC4862] or Link-Local IPv4 self-
assignment), no lease information will be available to enable assignment), no lease information will be available to enable
determination of device location. This situation should be expected determination of device location. This situation should be expected
to become increasingly common as IPv6-capable endpoints are deployed, to become increasingly common as IPv6-capable endpoints are deployed,
and Location Configuration Protocol (LCP) interactions occur over and Location Configuration Protocol (LCP) interactions occur over
IPv6. IPv6.
Even in scenarios in which the LIS relies on location data obtained Even in scenarios in which the LIS relies on location data obtained
from the IP MIB [RFC4293] and the Bridge MIB [RFC4188], availability from the IP MIB [RFC4293] and the Bridge MIB [RFC4188], availability
of location determination information is not assured. In an of location determination information is not assured. In an
enterprise scale network, maintenance of current location information enterprise scale network, maintenance of current location information
skipping to change at page 16, line 45 skipping to change at page 14, line 35
authenticity is not assured in transit between the network authenticity is not assured in transit between the network
connectivity device and the LIS. connectivity device and the LIS.
From these examples, it should be clear that the availability or From these examples, it should be clear that the availability or
validity of location data is a property of the LIS system design and validity of location data is a property of the LIS system design and
implementation rather than an inherent property of the LCP. As a implementation rather than an inherent property of the LCP. As a
result, mechanisms utilized to protect the integrity and authenticity result, mechanisms utilized to protect the integrity and authenticity
of location data do not necessarily provide assurances relating to of location data do not necessarily provide assurances relating to
the validity or provenance of that data. the validity or provenance of that data.
6.1.2. Location Signing 5.1.2. Location Signing
[NENA-i2] Section 3.7 includes recommendations relating to location [NENA-i2] Section 3.7 includes recommendations relating to location
signing: 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 rooted 2. The certificate for the signer (LIS operator) should be
in VESA. For this purpose, VPC and ERDB operators should issue rooted in VESA. For this purpose, VPC and ERDB operators
certs to LIS operators. should issue certs to LIS operators.
3. The signature should include a timestamp. 3. The signature should include a timestamp.
4. Where possible, the Location Object should be refreshed 4. Where possible, the Location Object should be refreshed
periodically, with the signature (and thus the timestamp) being periodically, with the signature (and thus the timestamp)
refreshed as a consequence. being refreshed as a consequence.
5. Antispoofing mechanisms should be applied to the Location 5. Anti-spoofing mechanisms should be applied to the Location
Reporting method. Reporting method.
[Note: The term Valid Emergency Services Authority (VESA) refers to [Note: The term Valid Emergency Services Authority (VESA) refers
the root certificate authority.] to the root certificate authority.]
Signing of location objects implies the development of a trust Signing of location objects implies the development of a trust
hierarchy that would enable a certificate chain provided by the LIS hierarchy that would enable a certificate chain provided by the LIS
operator to be verified by the PSAP. Rooting the trust hierarchy in operator to be verified by the PSAP. Rooting the trust hierarchy in
VESA can be accomplished either by having the VESA directly sign the VESA can be accomplished either by having the VESA directly sign the
LIS certificates, or by the creation of intermediate CAs certified by LIS certificates, or by the creation of intermediate CAs certified by
the VESA, which will then issue certificates to the LIS. In terms of the VESA, which will then issue certificates to the LIS. In terms of
the workload imposed on the VESA, the latter approach is highly the workload imposed on the VESA, the latter approach is highly
preferable. However, this raises the question of who would operate preferable. However, this raises the question of who would operate
the intermediate CAs and what the expectations would be. the intermediate CAs and what the expectations would be.
In particular, the question arises as to the requirements for LIS In particular, the question arises as to the requirements for LIS
certificate issuance, and whether they are significantly different certificate issuance, and whether they are significantly different
from say, requirements for issuance of an SSL/TLS web certificate. from say, requirements for issuance of an SSL/TLS web certificate.
6.1.3. Location by Reference 5.1.3. Location by Reference
Where location by reference is provided, the recipient needs to Where location by reference is provided, the recipient needs to
deference the LbyR in order to obtain location. With the deference the LbyR in order to obtain location. With the
introduction of location by reference concept two authorization introduction of location by reference concept two authorization
models were developed, see [I-D.winterbottom-geopriv-deref-protocol], models were developed, see [I-D.winterbottom-geopriv-deref-protocol],
namely the "Authorization by Possession" and "Authorization via namely the "Authorization by Possession" and "Authorization via
Access Control Lists" model. With the "Authorization by Possession" Access Control Lists" model. With the "Authorization by Possession"
model everyone in possession of the reference is able to obtain the model everyone in possession of the reference is able to obtain the
corresponding location information. This might, however, be corresponding location information. This might, however, be
incompatible with other requirements typically imposed by AIPs, such incompatible with other requirements typically imposed by AIPs, such
skipping to change at page 18, line 26 skipping to change at page 16, line 16
complex operational problem. complex operational problem.
As with PIDF-LO signing, the operational issues of LbyR can be As with PIDF-LO signing, the operational issues of LbyR can be
addressed to some extent by introduction of hierarchy. Rather than addressed to some extent by introduction of hierarchy. Rather than
requiring the PSAP to obtain credentials for accessing each LIS, the requiring the PSAP to obtain credentials for accessing each LIS, the
local LIS could be required to upload location information to local LIS could be required to upload location information to
location aggregation points who would in turn manage the location aggregation points who would in turn manage the
relationships with the PSAP. This would shift the management burden relationships with the PSAP. This would shift the management burden
from the PSAPs to the location aggregation points. from the PSAPs to the location aggregation points.
6.2. Application to a Specific Point in Time 5.2. Application to a Specific Point in Time
PIDF-LO objects contain a timestamp, which reflects the time at which PIDF-LO objects contain a timestamp, which reflects the time at which
the location was determined. Even if the PIDF-LO is signed, the the location was determined. Even if the PIDF-LO is signed, the
timestamp only represents an assertion by the LIS, which may or may timestamp only represents an assertion by the LIS, which may or may
not be trustworthy. For example, the recipient of the signed PIDF-LO not be trustworthy. For example, the recipient of the signed PIDF-LO
may not know whether the LIS supports time synchronization, or may not know whether the LIS supports time synchronization, or
whether it is possible to reset the LIS clock manually without whether it is possible to reset the LIS clock manually without
detection. Even if the timestamp was valid at the time location was detection. Even if the timestamp was valid at the time location was
determined, a time period may elapse between when the PIDF-LO was determined, a time period may elapse between when the PIDF-LO was
provided and when it is conveyed to the recipient. Periodically provided and when it is conveyed to the recipient. Periodically
refreshing location information to renew the timestamp even though refreshing location information to renew the timestamp even though
the location information itself is unchanged puts additional load on the location information itself is unchanged puts additional load on
LISs. As a result, recipients need to validate the timestamp in LISes. As a result, recipients need to validate the timestamp in
order to determine whether it is credible. order to determine whether it is credible.
6.3. Linkage to a Specific Endpoint 5.3. Linkage to a Specific Endpoint
As noted in the "HTTP Enabled Location Delivery (HELD)" As noted in the "HTTP Enabled Location Delivery (HELD)" [RFC5985]
[I-D.ietf-geopriv-http-location-delivery] Section 6.6: Section 6.6:
The LIS MUST NOT include any means of identifying the Device in The LIS MUST NOT include any means of identifying the Device in
the PIDF-LO unless it is able to verify that the identifier is the PIDF-LO unless it is able to verify that the identifier is
correct and inclusion of identity is expressly permitted by a Rule correct and inclusion of identity is expressly permitted by a Rule
Maker. Therefore, PIDF parameters that contain identity are Maker. Therefore, PIDF parameters that contain identity are
either omitted or contain unlinked pseudonyms [RFC3693]. A either omitted or contain unlinked pseudonyms [RFC3693]. A
unique, unlinked presentity URI SHOULD be generated by the LIS for unique, unlinked presentity URI SHOULD be generated by the LIS for
the mandatory presence "entity" attribute of the PIDF document. the mandatory presence "entity" attribute of the PIDF document.
Optional parameters such as the "contact" element and the Optional parameters such as the "contact" element and the
"deviceID" element [RFC4479] are not used. "deviceID" element [RFC4479] are not used.
skipping to change at page 20, line 5 skipping to change at page 17, line 20
for the recipient to verify whether the conveyed location actually for the recipient to verify whether the conveyed location actually
relates to the entity identified in the From: header. relates to the entity identified in the From: header.
This lack of binding between the entity obtaining the PIDF-LO and the This lack of binding between the entity obtaining the PIDF-LO and the
entity conveying the PIDF-LO to the recipient enables cut and paste entity conveying the PIDF-LO to the recipient enables cut and paste
attacks which would enable an attacker to assert a bogus location, attacks which would enable an attacker to assert a bogus location,
even where both the SIP message and PIDF-LO are signed. As a result, even where both the SIP message and PIDF-LO are signed. As a result,
even implementation of both [RFC4474] and location signing does not even implementation of both [RFC4474] and location signing does not
guarantee that location can be tied to a specific endpoint. guarantee that location can be tied to a specific endpoint.
7. Conclusion 6. Security Considerations
Emergency services raise a number of architectural questions, see IP-based emergency services face many security threats. "Security
[I-D.ietf-ecrit-framework], Threats and Requirements for Emergency Call Marking and Mapping"
[I-D.schulzrinne-ecrit-unauthenticated-access], [RFC5069] describes attacks on the emergency services system, such as
[I-D.ietf-ecrit-location-hiding-req], and attempting to deny system services to all users in a given area, to
[I-D.tschofenig-ecrit-architecture-overview]. With the generalized gain fraudulent use of services and to divert emergency calls to non-
emergency architecture considered within the ECRIT working group emergency sites. [RFC5069] also describes attacks against
various security challenges need to be addressed, including the individuals, including attempts to prevent an individual from
ability to report faked location and other attacks against the receiving aid, or to gain information about an emergency.
emergency services infrastructure. These types of attacks also show
that the attack characteristics play an important role when dealing "Threat Analysis of the Geopriv Protocol" [RFC3694] describes threats
with the problems and lower-layer solutions, as they have been against geographic location privacy, including protocol threats,
proposed as solutions for Denial of Service prevention (for example threats resulting from the storage of geographic location data, and
using cryptographic puzzles), have limited applicability. threats posed by the abuse of information.
This document focuses on threats deriving from the introduction of
untrustworthy location information by end hosts, regardless of
whether this occurs intentionally or unintentionally.
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 a larger number of GPS-enabled devices out be faked there will be a larger number of GPS-enabled devices out
there that make it difficult to utilize any of the security there that will find it difficult to utilize any of the security
mechanisms described in Section 5. It will be very unlikely that end mechanisms described in Section 5. It is unlikely that end users
users will upload their location information for "verification" to a will upload their location information for "verification" to a nearby
nearby location server located in the access network. location server located in the access network.
Given the practical and operational limitations in the technology, it Given the practical and operational limitations in the technology, it
may be worthwhile to consider whether the goals of trustworthy may be worthwhile to consider whether the goals of trustworthy
location, as for example defined by NENA i2 [NENA-i2], are location, as for example defined by NENA i2 [NENA-i2], are
attainable, or whether lesser goals (such as auditability) should be attainable, or whether lesser goals (such as auditability) should be
substituted instead. substituted instead.
The goal of auditability is to enable an investigator to determine The goal of auditability is to enable an investigator to determine
the source of a rogue emergency call after the fact. Since such an the source of a rogue emergency call after the fact. Since such an
investigation can rely on audit logs provided under court order, the investigation can rely on audit logs provided under court order, the
skipping to change at page 22, line 5 skipping to change at page 18, line 26
to be relatively infrequent, since the resources required to pursue to be relatively infrequent, since the resources required to pursue
an investigation are likely to be considerable. an investigation are likely to be considerable.
Where attacks are frequent and continuous, a reliance on non- Where attacks are frequent and continuous, a reliance on non-
automated mechanisms is unlikely to be satisfactory. As such, automated mechanisms is unlikely to be satisfactory. As such,
mechanisms to exchange audit trails information in a standardized mechanisms to exchange audit trails information in a standardized
format between ISPs and PSAPs / VSPs and PSAPs or heuristics to format between ISPs and PSAPs / VSPs and PSAPs or heuristics to
distinguish potentially fraudulent emergency calls from real distinguish potentially fraudulent emergency calls from real
emergencies might be valuable for the emergency services community. emergencies might be valuable for the emergency services community.
8. IANA Considerations 7. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
9. Acknowledgments 8. Acknowledgments
We would like to thank the members of the IETF ECRIT and the IETF We would like to thank the members of the IETF ECRIT and the IETF
GEOPRIV working group for their input to the discussions related to GEOPRIV working group for their input to the discussions related to
this topic. We would also like to thank Andrew Newton, Murugaraj this topic. We would also like to thank Andrew Newton, Murugaraj
Shanmugam, Richard Barnes and Matt Lepinski for their feedback to Shanmugam, Richard Barnes and Matt Lepinski for their feedback to
previous versions of this document. Martin Thomson provided valuable previous versions of this document. Martin Thomson provided valuable
input to version -02 of this document. input to version -02 of this document.
10. References 9. References
10.1. Normative References 9.1. Informative References
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for [GPSCounter]
Emergency Context Resolution with Internet Technologies", Warner, J. S. and R. G. Johnston, "GPS Spoofing
RFC 5012, January 2008. Countermeasures", Los Alamos research paper LAUR-03-6163,
December 2003.
10.2. Informative references [I-D.ietf-ecrit-location-hiding-req]
Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A.
Kuett, "Location Hiding: Problem Statement and Requirements",
draft-ietf-ecrit-location-hiding-req-04 (work in progress),
February 2010.
[I-D.ietf-ecrit-framework] [I-D.ietf-sip-location-conveyance]
Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, Polk, J. and B. Rosen, "Location Conveyance for the Session
"Framework for Emergency Calling using Internet Initiation Protocol", draft-ietf-sip-location-conveyance-13
Multimedia", draft-ietf-ecrit-framework-11 (work in (work in progress), March 2009.
progress), July 2010.
[I-D.ietf-ecrit-location-hiding-req] [I-D.thomson-geopriv-location-dependability]
Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and Thomson, M. and J. Winterbottom, "Digital Signature Methods
A. Kuett, "Location Hiding: Problem Statement and for Location Dependability", draft-thomson-geopriv-location-
Requirements", draft-ietf-ecrit-location-hiding-req-04 dependability-06 (work in progress), August 2010.
(work in progress), February 2010.
[I-D.ietf-ecrit-mapping-arch] [I-D.winterbottom-geopriv-deref-protocol]
Schulzrinne, H., "Location-to-URL Mapping Architecture and Winterbottom, J., Tschofenig, H., Schulzrinne, H., Thomson,
Framework", draft-ietf-ecrit-mapping-arch-04 (work in M., and M. Dawson, "A Location Dereferencing Protocol Using
progress), March 2009. HELD", draft-winterbottom-geopriv-deref-protocol-05 (work in
progress), January 2010.
[I-D.ietf-geopriv-http-location-delivery] [IEEE-802.11y]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, Information technology - Telecommunications and information
"HTTP Enabled Location Delivery (HELD)", exchange between systems - Local and metropolitan area
draft-ietf-geopriv-http-location-delivery-16 (work in networks - Specific requirements - Part 11: Wireless LAN
progress), August 2009. Medium Access Control (MAC) and Physical Layer (PHY)
specifications Amendment 3: 3650-3700 MHz Operation in USA,
November 2008.
[I-D.ietf-sip-location-conveyance] [LLDP-MED]
Polk, J. and B. Rosen, "Location Conveyance for the "Telecommunications: IP Telephony Infrastructure: Link Layer
Session Initiation Protocol", Discovery Protocol for Media Endpoint Devices, ANSI/
draft-ietf-sip-location-conveyance-13 (work in progress), TIA-1057-2006", April 2006.
March 2009.
[I-D.schulzrinne-ecrit-unauthenticated-access] [NENA-i2] "08-001 NENA Interim VoIP Architecture for Enhanced 9-1-1
Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H., Services (i2)", December 2005.
and D. Kroeselberg, "Extensions to the Emergency Services
Architecture for dealing with Unauthenticated and
Unauthorized Devices",
draft-schulzrinne-ecrit-unauthenticated-access-08 (work in
progress), July 2010.
[I-D.thomson-geopriv-location-dependability] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Thomson, M. and J. Winterbottom, "Digital Signature Requirement Levels", BCP 14, RFC 2119, March 1997.
Methods for Location Dependability",
draft-thomson-geopriv-location-dependability-06 (work in
progress), August 2010.
[I-D.tschofenig-ecrit-architecture-overview] [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture
Tschofenig, H. and H. Schulzrinne, "Emergency Services for Describing Simple Network Management Protocol (SNMP)
Architecture Overview: Sharing Responsibilities", Management Frameworks", STD 62, RFC 3411, December 2002.
draft-tschofenig-ecrit-architecture-overview-00 (work in
progress), July 2007.
[I-D.winterbottom-geopriv-deref-protocol] [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Winterbottom, J., Tschofenig, H., Schulzrinne, H., Polk, "Geopriv Requirements", RFC 3693, February 2004.
Thomson, M., and M. Dawson, "A Location Dereferencing
Protocol Using HELD",
draft-winterbottom-geopriv-deref-protocol-05 (work in
progress), January 2010.
[LLDP-MED] [RFC3694] Danley, M., Mulligan, D., Morris, J. and J. Peterson, "Threat
"Telecommunications: IP Telephony Infrastructure: Link Analysis of the Geopriv Protocol", RFC 3694, February 2004.
Layer Discovery Protocol for Media Endpoint Devices, ANSI/
TIA-1057-2006", April 2006.
[NENA-i2] "08-001 NENA Interim VoIP Architecture for Enhanced 9-1-1 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Services (i2)", December 2005. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Architecture for Describing Simple Network Management Configuration Protocol Option for Coordinate-based Location
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, Configuration Information", RFC 3825, July 2004.
December 2002.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. Configuration of IPv4 Link-Local Addresses", RFC 3927, May
2005.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC4188] Norseth, K. and E. Bell, "Definitions of Managed Objects for
Levkowetz, "Extensible Authentication Protocol (EAP)", Bridges", RFC 4188, September 2005.
RFC 3748, June 2004.
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host [RFC4293] Routhier, S., "Management Information Base for the Internet
Configuration Protocol Option for Coordinate-based Protocol (IP)", RFC 4293, April 2006.
Location Configuration Information", RFC 3825, July 2004.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Configuration of IPv4 Link-Local Addresses", RFC 3927, Identity Management in the Session Initiation Protocol (SIP)",
May 2005. RFC 4474, August 2006.
[RFC4188] Norseth, K. and E. Bell, "Definitions of Managed Objects [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July
for Bridges", RFC 4188, September 2005. 2006.
[RFC4293] Routhier, S., "Management Information Base for the [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales-
Internet Protocol (IP)", RFC 4293, April 2006. Valenzuela, C., and K. Tammi, "Diameter Session Initiation
Protocol (SIP) Application", RFC 4740, November 2006.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
Authenticated Identity Management in the Session and DHCPv6) Option for Civic Addresses Configuration
Initiation Protocol (SIP)", RFC 4474, August 2006. Information", RFC 4776, November 2006.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
July 2006. Address Autoconfiguration", RFC 4862, September 2007.
[RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Canales-Valenzuela, C., and K. Tammi, "Diameter Session Context Resolution with Internet Technologies", RFC 5012,
Initiation Protocol (SIP) Application", RFC 4740, January 2008.
November 2006.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H. and M. Shanmugam,
(DHCPv4 and DHCPv6) Option for Civic Addresses "Security Threats and Requirements for Emergency Call Marking
Configuration Information", RFC 4776, November 2006. and Mapping", RFC 5069, January 2008.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and
Address Autoconfiguration", RFC 4862, September 2007. Framework", RFC 5582, September 2009.
[RFC5985] Barnes, M., "HTTP Enabled Location Delivery (HELD)", RFC 5985,
September 2010.
[SA] "Saudi Arabia - Illegal sale of SIMs blamed for surge in prank
calls", Arab News, May 4, 2010,
http://www.menafn.com/qn_news_story_s.asp?StoryId=1093319384
[Swatting]
"Don't Make the Call: The New Phenomenon of 'Swatting',
Federal Bureau of Investigation, February 4, 2008,
http://www.fbi.gov/news/stories/2008/february/swatting020408
[TASMANIA]
"Emergency services seek SIM-less calls block", ABC News
Online, August 18, 2006,
http://www.abc.net.au/news/newsitems/200608/s1717956.htm
[UK] "Rapper makes thousands of prank 999 emergency calls to UK
police", Digital Journal, June 24, 2010,
http://www.digitaljournal.com/article/293796?tp=1
Authors' Addresses Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
 End of changes. 87 change blocks. 
345 lines changed or deleted 362 lines changed or added

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