ECRIT H. Tschofenig
Internet-Draft Nokia Siemens Networks
Intended status: Informational H. Schulzrinne
Expires: January 8, 2009 Columbia University
July 7, 2008
Trustworthy Location Information
draft-tschofenig-ecrit-trustworthy-location-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 8, 2009.
Tschofenig & Schulzrinne Expires January 8, 2009 [Page 1]
Internet-Draft Trustworthy Location Information July 2008
Abstract
For location-based applications, such as emergency calling or
roadside assistance, the identity of the requestor is less important
than accurate and trustworthy location information.
A number of protocols are available to supply end systems with either
civic or geodetic information. For some applications it is an
important requirement that location information has not been modified
in transit or by the end point itself.
This document investigates different threats, the adversary model,
and outlines three possible solutions. The document concludes with a
suggestion on how to move forward.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Emergency Services . . . . . . . . . . . . . . . . . . . . . . 5
4. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 7
4.2. Call Identity Spoofing . . . . . . . . . . . . . . . . . . 8
5. Solution Proposals . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Location Signing . . . . . . . . . . . . . . . . . . . . . 9
5.2. Location by Reference . . . . . . . . . . . . . . . . . . 10
5.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 12
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative references . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Tschofenig & Schulzrinne Expires January 8, 2009 [Page 2]
Internet-Draft Trustworthy Location Information July 2008
1. Introduction
Much of the focus in trustable networks has been on ensuring the
reliability of personal identity information or verifying privileges.
However, in some cases, access to trustworthy location information is
more important than identity since some services are meant to be
widely available, regardless of the identity of the requestor.
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,
light switches in buildings are not typically protected by keycards
or passwords, but are only accessible to those within the perimeter
of the building. Merchants processing credit card payments already
use location information to estimate the risk that a transaction is
fraudulent, based on the HTTP client's IP address (that is then
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
to make civic and geodetic location available to the end host.
Examples for these protocols are LLDP-MED, DHCP extensions (see [2],
[3]), HELD (see [4]) or the protocols developed within the IEEE as
part of their link-layer specifications. The server offering this
information is usually called a Location Information Server (LIS).
In many cases, the end host itself can determine its location, e.g.,
via 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 SIP or HTTP.
This document investigates the security threats in Section 4, and
outlines three solutions in Section 5 that should serve as a
discussion starter. We use emergency services an example to
illustrate the security problems and the architectural impact, as the
problems have been typically discussed in that context since the
stakes are high, but the issues apply also to other examples as cited
earlier.
Tschofenig & Schulzrinne Expires January 8, 2009 [Page 3]
Internet-Draft Trustworthy Location Information July 2008
2. Terminology
This document re-uses a lot of the terminology defined in Section 3
of [1].
Tschofenig & Schulzrinne Expires January 8, 2009 [Page 4]
Internet-Draft Trustworthy Location Information July 2008
3. Emergency Services
Users of the legacy telephone network can summon emergency services
such as ambulance, fire and police using a well-known emergency
service number (e.g., 9-1-1 in North America, 1-1-2 in Europe).
Location information is used to route emergency calls to the
appropriate regional Public Safety Answering Point (PSAP) that serves
the caller to dispatch first-level responders to the emergency site.
Regulators have already started to demand emergency service support
for voice over IP. However, enabling such critical public services
using the Internet is challenging, as many of the assumptions of the
PSTN 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.
Tschofenig & Schulzrinne Expires January 8, 2009 [Page 5]
Internet-Draft Trustworthy Location Information July 2008
4. Threats
IP-based emergency calling faces many security threats, most of which
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
to the time of street corner call boxes. Individual prank calls
waste emergency services and possibly endanger bystanders or
emergency service personnel as they rush to the reported scene of a
fire or accident. A more recent concern is that massive prank calls
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
terror attack, for example.
Emergency services have three finite resources subject to denial of
service attacks: the network and server infrastructure, call takers
and dispatchers, and the first responders, such as fire fighters and
police officers. Protecting the network infrastructure is similar to
protecting other high-value service providers, except that
trustworthy location information may be used to filter call setup
requests, to weed out requests that are out of area. PSAPs even for
large cities may only have a handful of PSAP call takers on duty, so
even if they can, by questioning the caller, eliminate a lot of prank
calls, they are quickly overwhelmed by even a small-scale attack.
Finally, first responder resources are scarce, particularly during
mass-casualty events.
Currently, emergency services rely on the fact that location spoofing
is difficult for normal users. Additionally, the identity of most
callers can be ascertained, so that the threat of severe punishments
reduces prank calls. Mechanically placing a large number of
emergency calls that appear to come from different locations is also
difficult. Calls from payphones are subject to greater scrutiny by
the call taker. In the current system, it would be very difficult
for an attacker from country 'Foo' to attack the emergency services
infrastructure located in country 'Bar'.
One of the main motivations of an adversary in the emergency services
context is to prevent callers from utilizing emergency service
support. This can be done by a variety of means, such as
impersonating a PSAP or directory servers, attacking SIP signaling
elements and location servers.
Attackers may want to modify, prevent or delay emergency calls. In
Tschofenig & Schulzrinne Expires January 8, 2009 [Page 6]
Internet-Draft Trustworthy Location Information July 2008
some cases, this will lead the PSAP to dispatch emergency personnel
to an emergency that does not exist and, hence, the personnel might
not be available to other callers. It might also be possible for an
attacker to impede the users from reaching an appropriate PSAP by
modifying the location of an end host or the information returned
from the mapping protocol. In some countries, regulators may not
demand authentication of the emergency caller, as is true for PSTN-
based emergency calls placed from payphones or no-account cell phones
today. Furthermore, if identities can easily be crafted, then the
value of emergency caller authentication might be limited. As a
consequence, an attacker can forge emergency call information without
being traced.
The above-mentioned attacks are mostly targeting individual emergency
callers or a very small fraction of them. If attacks are, however,
launched against the mapping architecture or against PSAP entities, a
larger region and a large number of potential emergency callers are
affected, particularly targeting the call takers at the PSAP.
In this context, three adversary models need to be considered:
External adversary model: The end host, e.g., an emergency caller
whose location is going to be communicated, is honest and the
adversary may be located between the end host and the location
server or between the end host and the PSAP. None of the
emergency service infrastructure elements act maliciously.
Malicious infrastructure adversary model: The emergency call routing
elements, such as the LIS, the LoST infrastructure, used for
mapping locations to PSAP address, or call routing elements, may
act maliciously.
Malicious end host adversary model: The end host itself acts
maliciously, whether the owner is aware of this or whether it is
acting as a bot.
We will focus only on the malicious end host adversary model since it
follows today's most common adversary model on the Internet that
includes bot nets.
4.1. Location Spoofing
An adversary can provide false location information in order to fool
the emergency personnel. Such an attack is particularly easy if
location information is attached to the emergency call by the end
host and is either not verified or cannot be verified by anyone.
Only entities that are close to the caller can verify the correctness
of location information.
Tschofenig & Schulzrinne Expires January 8, 2009 [Page 7]
Internet-Draft Trustworthy Location Information July 2008
The following list presents threats specific to location information
handling:
Place shifting: Trudy, the adversary, pretends to be at an arbitrary
location. In some cases, place shifting can be limited in range,
e.g., to the coverage area of a particular cell tower.
Time shifting: Trudy pretends to be at a location she was a while
ago.
Location theft: Trudy observes Alice's location and replays it as
her own.
Location swapping: Trudy and Malory, located in different locations,
can collude and swap location information and pretend to be in
each other's location.
4.2. Call Identity Spoofing
If an adversary can place emergency calls without disclosing its
identity, then prank calls are more difficult to be traced. There
are at least two different forms of authentication in this context;
network access authentication and authentication of the emergency
caller at the application layer. This differentiation is created by
the split between the AIP and the VSP whereby different identities
are involved.
Trying to find an adversary that did not authenticate itself to the
VSP is difficult even though there is still a chance that network
access authentication was exercised. If there is no authentication
(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
imagine that VoIP emergency calls could require strong identity, as
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 certificates, increases costs, introduces a significant
administrative overhead and is only useful if widely used.
Tschofenig & Schulzrinne Expires January 8, 2009 [Page 8]
Internet-Draft Trustworthy Location Information July 2008
5. Solution Proposals
This section presents three solution approaches to mitigate the
threats discussed.
5.1. Location Signing
One way to avoid location spoofing is to let a trusted location
server sign the location information before it is sent to the end
host, i.e., the entity subject to the location determination process.
The signed location information is then verified by the location
recipient and not by the target. Figure 1 shows the communication
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 recipient in step (c) who verifies it. For SIP, the
procedures described in [5] are applicable for location conveyance.
+-----------+ +-----------+
| | | Location |
| LIS | | Recipient |
| | | |
+-+-------+-+ +----+------+
^ | --^
| | --
Geopriv |Req. | --
Location |Signed |Signed -- Geopriv
Configuration |Loc. |Loc. -- Using Protocol
Protocol |(a) |(b) -- (e.g., SIP)
| v -- (c)
+-+-------+-+ --
| Target / | --
| End Host +
| |
+-----------+
Figure 1: Location Signing
Additional information, such as timestamps or expiration times, has
to be included together with the signed location to limit replay
attacks. If the location is retrieved from a location server, even a
stationary end host has to periodically obtain a fresh signed
location, or incur the additional delay of querying during the
emergency call.
Bot nets are also unlikely to be deterred by location signing.
However, accurate location information would limit the usable subset
of the bot net, as only hosts within the PSAP serving area would be
Tschofenig & Schulzrinne Expires January 8, 2009 [Page 9]
Internet-Draft Trustworthy Location Information July 2008
useful in placing calls.
To prevent location-swapping attacks it is necessary to include some
some target specific identity information. The included information
depends on the purpose, namely either real-time verification by the
location recipient or for the purpose of a post-mortem analysis when
the location recipient wants to determine the legal entity behind the
target for prosecution (if this is possible). As an example, a
solution proposal is provided by [6].
Still, for large-scale attacks launched by bot nets, this is unlikely
to be helpful. Location signing is also difficult when the host
provides its own location via GPS, which is likely to be a common
occurrence for mobile devices. Trusted computing approaches, with
tamper-proof GPS modules, may be needed in that case. After all, a
device can always pretend to have a GPS device and the recipient has
no way of verifying this or forcing disclosure of non-GPS-derived
location information.
Location verification may be most useful if it is used in conjunction
with other mechanisms. For example, a call taker can verify that the
region that corresponds to the IP address of the media stream roughly
corresponds to the location information reported by the caller. To
make the use of bot nets more difficult, a CAPTCHA-style test may be
applied to suspicious calls, although this idea is quite
controversial for emergency services, at the danger of delaying or
even rejecting valid calls.
5.2. Location by Reference
The location-by-reference concept was developed so that end hosts
could avoid having to periodically query the location server for up-
to-date location information in a mobile environment. Additionally,
if operators do not want to disclose location information to the end
host without charging them, location-by-reference provides a
reasonable alternative.
Figure 2 shows the communication model with the target requesting a
location reference in step (a), the location server returns the
reference in step (b), and it is then conveyed to the location
recipient in step (c). The location recipient needs to resolve the
reference with a request in step (d). Finally, location information
is returned to the Location Recipient afterwards. For location
conveyance in SIP, the procedures described in [5] are applicable.
Tschofenig & Schulzrinne Expires January 8, 2009 [Page 10]
Internet-Draft Trustworthy Location Information July 2008
+-----------+ Geopriv +-----------+
| | Location | Location |
| LIS +<------------->+ Recipient |
| | Dereferencing | |
+-+-------+-+ Protocol (d) +----+------+
^ | --^
| | --
Geopriv |Req. | --
Location |LbyR |LbyR -- Geopriv
Configuration |(a) |(b) -- Using Protocol
Protocol | | -- (e.g., SIP)
| V -- (c)
+-+-------+-+ --
| Target / | --
| End Host +
| |
+-----------+
Figure 2: Location by Reference
The details for the dereferencing operations vary with the type of
reference, such as a HTTP, HTTPS, SIP, SIPS URI or a SIP presence
URI. HTTP-Enabled Location Delivery (HELD) [4] is an example of a
protocol that is able to return such references.
For location-by-reference, the location server needs to maintain one
or several URIs for each target, timing out these URIs after a
certain amount of time. References need to expire to prevent the
recipient of such a URL from being able to permanently track a host
and to offer garbage collection functionality for the location
server.
Off-path adversaries must be prevented from obtaining the target's
location. The reference contains a randomized component that
prevents third parties from guessing it. When the location recipient
fetches up-to-date location information from the location server, it
can also be assured that the location information is fresh and not
replayed. However, this does not address location swapping.
However, location-by-reference does not offer significant security
benefits if the end host uses GPS to determine its location. At
best, a network provider can use cell tower or triangulation
information to limit the inaccuracy of user-provided location
information.
Tschofenig & Schulzrinne Expires January 8, 2009 [Page 11]
Internet-Draft Trustworthy Location Information July 2008
5.3. Proxy Adding Location
Instead of making location information available to the end host, it
is possible to allow an entity in the AIP, or associated with the
AIP, to retrieve the location information on behalf of the end point.
This solution is possible when the application layer messages are
routed through an entity with the ability to determine the location
information of the end point, for example based on the end host's IP
or MAC address.
When the untrustworthy end host does not have the ability to access
location information, it cannot modify it either. Proxies can use
various techniques, including SIP Identity, to ensure that
modifications to the location in transit can be detected by the
location recipient (e.g., the PSAP). As noted above, this is
unlikely to work for GPS-based location determination techniques.
The obvious disadvantage of this approach is that there is a need to
deploy application layer entities, such as SIP proxies, at AIPs or
associated with AIPs. In case of devices that lack credentials or
are unauthorized to access certain networks the procedures described
in [7] may very well be aligned with such an approach. Finally, it
has to be noted that routing emergency calls through SIP proxies in
the AIP closely matches the approaches favored by the 3GPP in their
IMS emergency architecture.
Tschofenig & Schulzrinne Expires January 8, 2009 [Page 12]
Internet-Draft Trustworthy Location Information July 2008
6. Conclusion
Emergency services raise a number of architectural questions,
see~\cite{draft-ietf-ecrit-framework}. With the generalized
emergency architecture considered within the ECRIT working group
various security challenges need to be addressed, including the
ability to report faked location and other attacks against the
emergency services infrastructure. These types of attacks also show
that the attack characteristics play an important role when dealing
with the problems and lower-layer solutions, as they have been
proposed as solutions to generic Denial of Service prevention (for
example using cryptographic puzzles), have limited applicability.
Although it is important to ensure that location information cannot
be faked there will be a larger number of GPS-enabled devices out
there that make it difficult to utilize any of the security
mechanisms described in Section 5. It will be very unlikely that end
users will upload their location information for "verification" to a
nearby location server located in the access network. When location
is obtained from the network then there one mechanism, namely
Location by Reference, is currently being specified already to offer
a high degree of security protection. In addition, it is extremely
important to stress the need for a strong identity mechanism that
allows user's to be traced back and to hold them responsible for
their actions.
Tschofenig & Schulzrinne Expires January 8, 2009 [Page 13]
Internet-Draft Trustworthy Location Information July 2008
7. IANA Considerations
This document does not require actions by IANA.
Tschofenig & Schulzrinne Expires January 8, 2009 [Page 14]
Internet-Draft Trustworthy Location Information July 2008
8. Acknowledgments
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
this topic. We would also like to thank Andrew Newton, Murugaraj
Shanmugam, Richard Barnes and Matt Lepinski for their feedback to
previous versions to this document.
Tschofenig & Schulzrinne Expires January 8, 2009 [Page 15]
Internet-Draft Trustworthy Location Information July 2008
9. References
9.1. Normative References
[1] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Context Resolution with Internet Technologies", RFC 5012,
January 2008.
9.2. Informative references
[2] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
and DHCPv6) Option for Civic Addresses Configuration
Information", RFC 4776, November 2006.
[3] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004.
[4] Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP
Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-07 (work in progress),
April 2008.
[5] Polk, J. and B. Rosen, "Location Conveyance for the Session
Initiation Protocol", draft-ietf-sip-location-conveyance-10
(work in progress), February 2008.
[6] Thomson, M. and J. Winterbottom, "Digital Signature Methods for
Location Dependability",
draft-thomson-geopriv-location-dependability-02 (work in
progress), July 2008.
[7] Schulzrinne, H., McCann, S., Bajko, G., and H. Tschofenig,
"Extensions to the Emergency Services Architecture for dealing
with Unauthenticated and Unauthorized Devices",
draft-schulzrinne-ecrit-unauthenticated-access-02 (work in
progress), February 2008.
Tschofenig & Schulzrinne Expires January 8, 2009 [Page 16]
Internet-Draft Trustworthy Location Information July 2008
Authors' Addresses
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building, New York, NY 10027
US
Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Tschofenig & Schulzrinne Expires January 8, 2009 [Page 17]
Internet-Draft Trustworthy Location Information July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Tschofenig & Schulzrinne Expires January 8, 2009 [Page 18]