Internet DRAFT - draft-tschofenig-ecrit-security-threats
draft-tschofenig-ecrit-security-threats
ECRIT H. Tschofenig
Internet-Draft Siemens
Expires: January 19, 2006 H. Schulzrinne
Columbia U.
M. Shanmugam
TUHH
July 18, 2005
Security Threats and Requirements for Emergency Calling
draft-tschofenig-ecrit-security-threats-01.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 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
With the increasing interest to replace parts of the public switched
telephone network (PSTN) with the IP-based network, the core
functionality of PSTN such as emergency services, has to be offered
when using IP-based technologies. Since the PSTN and the Internet
follow different design principles their architecture is quite
Tschofenig, et al. Expires January 19, 2006 [Page 1]
Internet-Draft Threats and Req. for Emergency July 2005
different. This fact has to be considered and security threats for
an IP-based emergency environment have to be re-evaluated. This
document investigates the potential threats against the IP based
emergency architecture. It focuses on some analysis of threats for
both the end hosts and the infrastructure that aims to support
emergency services.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivations of Attackers of ECRIT . . . . . . . . . . . . . 5
4. Basic Actors . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Threats . . . . . . . . . . . . . . . . . . . . . . 9
5.1 Denial of Service Attacks . . . . . . . . . . . . . . . . 9
5.2 Call Identity Spoofing . . . . . . . . . . . . . . . . . . 9
5.3 Location Spoofing . . . . . . . . . . . . . . . . . . . . 10
5.4 Impersonating a PSAP . . . . . . . . . . . . . . . . . . . 10
5.5 Signaling Message Modification . . . . . . . . . . . . . . 11
5.6 Modification of the Emergency Call . . . . . . . . . . . . 11
5.7 Loss of confidentiality . . . . . . . . . . . . . . . . . 11
5.8 Replay Attack . . . . . . . . . . . . . . . . . . . . . . 11
5.9 Corrupting Configuration Information . . . . . . . . . . . 12
5.10 Corrupting Database Information . . . . . . . . . . . . 12
6. Security Requirements . . . . . . . . . . . . . . . . . . . 13
6.1 Denial of Service Attacks . . . . . . . . . . . . . . . . 13
6.2 Call Identity Spoofing . . . . . . . . . . . . . . . . . . 14
6.3 Location Spoofing . . . . . . . . . . . . . . . . . . . . 14
6.4 Impersonating a PSAP . . . . . . . . . . . . . . . . . . . 16
6.5 Signaling Message Modification . . . . . . . . . . . . . . 16
6.6 Replay Attack . . . . . . . . . . . . . . . . . . . . . . 17
6.7 Loss of confidentiality . . . . . . . . . . . . . . . . . 17
6.8 Modification of the Emergency Call . . . . . . . . . . . . 17
6.9 Corrupting Configuration Information . . . . . . . . . . . 17
6.10 Corrupting Database Information . . . . . . . . . . . . 18
6.11 Location Validation and Verification . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1 Normative References . . . . . . . . . . . . . . . . . . . 22
9.2 Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . 23
Tschofenig, et al. Expires January 19, 2006 [Page 2]
Internet-Draft Threats and Req. for Emergency July 2005
1. Introduction
This document provides an overview of security mechanisms and
motivations for using them in the VoIP-based emergency services.
PSTN users can summon help for emergency services such as ambulance,
fire and police using a well known unique number (e.g., 911 in North
America, 112 in in Europe). With the introduction of IP-based
telephony support for emergency service also has to be provided. A
number of protocols and protocol extensions need to interwork in
order to provide emergency functionality.
Since the Internet is hostile place, it is important to understand
the security threats for emergency services. Otherwise, an adversary
can use the infrastructure to place fraudulent calls, mount denial of
service attacks, etc.
This document focuses on the security threats and security
requirements for the IP-based emergency service infrastructure only
without interaction with PSTN infrastructure elements.
A few discussions within this document are related to emergency
handling but solutions will not be developed as part of the ECRIT
working group. Hence, the are included mainly for completeness and
to point to the need to investigate additional aspects. Depending on
the chosen protocols (for the emergency call itself, for directory
access related to emergency call routing, for obtaining location
information from the network, etc.) various solutions might also
already be available to fulfill these security requirements and to
address the threats appropriately.
This document is organized as follows: Section 2 describes basic
terminology, Section 5 illustrates security threats and Section 6
lists security requirements.
Tschofenig, et al. Expires January 19, 2006 [Page 3]
Internet-Draft Threats and Req. for Emergency July 2005
2. Terminology
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].
Emergency Caller, Public Safety Answering Point (PSAP), Access
Infrastructure Provider, Application (Voice) Service Provider,
Emergency Call Taker, etc. is taken from [I-D.schulzrinne-ecrit-
requirements].
Additionally, we use the following terms throughout the document:
Emergency Call Routing Support: This term refers to entities that
route the emergency call to the appropriate PSAP based on
information like location information, language, etc. If SIP is
used as a protocol for session setup and call routing, for
example, then this entity would correspond to a SIP proxy.
Directory: This entity refers to a distributed directory protocol.
DNS is one example of such as distributed directory but there are
other protocols that might fulfill the requirements listed in
[I-D.schulzrinne-ecrit-requirements] for such a protocol.
Asserted Location Information: The term asserted location information
refers to the property that the recipient of such an object is
able to verify that it was generated by a particular party that is
authorized todo so.
Tschofenig, et al. Expires January 19, 2006 [Page 4]
Internet-Draft Threats and Req. for Emergency July 2005
3. Motivations of Attackers of ECRIT
The most obvious motivation for an attacker, in the context of
emergency, is to hinder user(s) not to avail the emergency service.
This can be done by variety of means such as impersonating a PSAP,
directory server, forging or spoofing location, identity etc.,
However,there are several other potential motivations that cause
concern. Attackers might also wish to learn the nature emergency
information by eavesdropping an emergency call in order to reuse or
extract the relevant information that might cause potential problems
to the end hosts such as replay attacks, revealing the identity of
the user.
Attackers may want to prevent or delay an emergency caller by
modifying some information in the message typically modifying the
loation of the caller, while placing the emergency call. In some
cases, this will lead the emergency repsonders to dispatch the
services to the spoofed ara and might not be available to the other
callers. It might also be possible for an attacker to impede the
users not to reach an appropriate PSAP by corrupting or modifying the
location of an end host or the information returned from the mapping
protocol. Since the regulatory aspects of the emergency call often
does not manadate authentication of the caller, it is easy for an
attacker to forge some data(location information) to an PSAP, thereby
forcing the emergency responders to dispatch the services, which
might cause a denial of service to its legitimate users.
Finally, some attackers may simply want to halt the operation of an
entire emergency architecture through denial-of-service attacks.
Tschofenig, et al. Expires January 19, 2006 [Page 5]
Internet-Draft Threats and Req. for Emergency July 2005
4. Basic Actors
In order to support emergency services covering a large physical area
various infrastructure elements are necessary: Access Infrastructure
Providers, Application (Voice) Service Provider, PSAPs as endpoints
for emergency calls, directory services or other infrastructure
elements that assist in during the call routing and potentially many
other entities.
This section outlines which entities will be considered in the threat
analysis and shows the high level architecture.
Location
Information +-----------------+
|(1) |Access | +-----------+
v |Infrastructure | | |
+-----------+ |Provider | | Directory |
| | | (3) | | |
| Emergency |<---+-----------------+-->| |
| Caller | | (2) | +-----------+
| |<---+-------+ | ^
+-----------+ | +----|---------+------+ |
^ | | Location | | |
| | | Information<-+ | |
| +--+--------------+ |(8) | | (5)
| | +-----------v+ | |
| (4) | |Emergency | | |
+--------------+--->|Call Routing|<--+---+
| | |Support | |
| | +------------+ |
| | ^ |
| | (6) | +----+--+
| (7) | +------->| |
+--------------+--------------->| PSAP |
| | |
|Application +----+--+
|(Voice) |
|Service |
|Provider |
+---------------------+
Figure 1: Framework
Figure 1 shows the interaction between the entities involved in the
call. There are a number of different deployment choices, as it can
be easily seen from the figure. The following deployment choices
need to be highlighted:
Tschofenig, et al. Expires January 19, 2006 [Page 6]
Internet-Draft Threats and Req. for Emergency July 2005
o How is location information provided to the end host? It might
either be known to the end host itself (due to manual
configuration or provided via GPS) or available via a third party.
Even if location information is known to the network it might be
made available to the end host. Alternatively, location
information is used as part of call routing and inserted by
intermediaries.
o Is the Access Infrastructure Provider also the Application (Voice)
Service Provider? In the Internet today these roles are typically
provided by different entities. As a consequence, the Application
(Voice) Service Provider is typically not able to learn the
physical location of the Emergency Caller.
Please note that the overlapping squares aim to indicate that certain
functionality can be collapsed into a single entity. As an example,
the Application (Voice) Service Provider might be the same entity as
the Access Infrastructure Provider and they might also operate the
PSAP. There is, however, no requirement that this must be the case.
Additionally it is worth pointing out that end systems might be its
own VoSP, e.g., for enterprises or residential users.
Below, we describe various interactions between the entities shown in
Figure 1 are described:
o (1) Location information might be available to the end host
itself.
o (2) Location information might, however, also be obtained from the
Access Infrastructure Provider (e.g., using DHCP or application
layer signaling protocols).
o (3) The Emergency Caller might need to consult a directory to
determine the PSAP that is appropriate for the physical location
of the emergency caller (and considering other attributes such as
a certain language support by the Emergency Call Takers).
o (4) The Emergency Caller might get assistance for emergency call
routing by infrastructure elements (referred as Emergency Call
Routing Support entities). In case of SIP these enities are
proxies.
o (5) Individual Emergency Call Routing Support entities might need
to consult a directory to determine where to route the emergency
call.
o (6) The Emergency Call Routing Support entities need to finally
forward the call, if infrastructure based emergency call routing
Tschofenig, et al. Expires January 19, 2006 [Page 7]
Internet-Draft Threats and Req. for Emergency July 2005
is used.
o (7) The emergency caller might interact directly with the PSAP
without any Emergency Call Routing Support entities.
Tschofenig, et al. Expires January 19, 2006 [Page 8]
Internet-Draft Threats and Req. for Emergency July 2005
5. Security Threats
This section discusses various security threats related to emergency
call handling.
5.1 Denial of Service Attacks
A (distributed) denial-of-service attack (DoS attack) on a PSAP, for
example, might isolate the PSAP from the Internet, for a while, thus
unable to receive the emergency calls at that time. Since a
particular PSAP is responsible for a certain geopraphical boundary,
attacking a single PSAP means denying the service to the entire area
(if no other backup PSAP is available). DoS attacks might appear in
many different flavors ranging from standard SYN floodings to attacks
where a human operator is involved then he has to determine whether
a call is in fact a true emergency call. In some cases this might
lead the case where the emergency staff (police, ambulance, etc.,)
might need to rush to the indicated emergency scene (potentionally an
arbitrary location) and will therefore not be available for other
rescue assignments during that time.
As such, PSAPs can be seen as a particularly valuable target since
the consequences of an unreachable PSAP has severe consequences.
Attacks against the routing infrastructure enables an adversary to
prevent all nodes attached to this network to sent emergency calls.
Attacks against entities that assist in the call routing (such as
attacks against the directory service) might make it difficult or
impossible for emergency call to reach its intended PSAP.
5.2 Call Identity Spoofing
If an adversary is able to make emergency calls without the need to
disclose its identity (such as a SIP URI or NAI) then prank calls
cannot be traced back. If the call is proxy-routed, the PSAP will
not see the IP address of the caller in signaling. Additionally, it
might be necessary for the Emergency Call Taker to initiate a voice,
video or instant messaging exchange towards the Emergency Caller.
Trying to find an adversary that placed a crank call is difficult if
somebody uses an open 802.11 access point, even if you can find the
owner of that access point. This problem is no different than
somebody placing an emergency call from a payphone.
If the adversary is never authenticated (neither to the PSAP nor to
the Access Infrastructure Provider) then it is possible to trace the
call back to a make a particular entity accountable.
Tschofenig, et al. Expires January 19, 2006 [Page 9]
Internet-Draft Threats and Req. for Emergency July 2005
A standard requirement for emergency systems is that emergency calls
must also be placed in absence of any authentication. An adversary
will typically exploit these weaknesses and he will always find
networks that do not perform network access authentication of the
user prior to providing network access. As such, the emergency
infrastructure cannot neither rely on network access authentication
nor on authentication of the caller towards the PSAP or the
Application (Voice) Service Provider.
It is necessary to point to the fact that authentication in the
emergency case might require the authorization procedure to be
skipped. For example, in an emergency case it is still possible to
authenticate the user of an emergency call but without considering
that its credits are exhausted.
5.3 Location Spoofing
An adversary might want to made-up faked location information in
order to fool the emergency personnel. This is made particularly
easy if the location information is provided by the Emergency Caller
either via manual configuration or via GPS. Spoofing is more
difficult if an entity proving Emergency Call Routing Support inserts
location information into emergency call signaling. In this case the
adversary needs to route the call via some intermediaries. This is
possible since these devices are often, by their nature as IP
devices, addressable from an arbitary physical location. The usage
of VPN (or other tunneling mechanisms) and proxies further
complicates the ability to infer the physical location from the IP
address seen by the PSAP.
5.4 Impersonating a PSAP
An adversary might pretend to operate a PSAP. When either an end
host or an intermediate device wants to determine the PSAP that is
responsible for a particular geographical area by sending a query to
the directory an adversary might return a faked response. Returning
an incorrect response message does not require the adversary to be
somewhere along the path. It is sufficient for an adversary to be
located in a broadcast medium and the adversary has to reply as soon
as a query is observed (if no security protection is utilized). If
the response indicates a legitimate but inappropriate (i.e., a PSAP
that is authoritive for a different geographical area) then the
emergency call interaction will be able to continue but will suffer
from delays until the emergency call can be forwarded to the correct
PSAP, potentially involving human interaction (by the Emergency Call
Taker).
Tschofenig, et al. Expires January 19, 2006 [Page 10]
Internet-Draft Threats and Req. for Emergency July 2005
5.5 Signaling Message Modification
An adversary that is located along the signaling path might modify
the content of emergency calls, such as location information or
identity information. This might lead to a denial of service attack
against the emergency personell, disruption of the emergency call,
delayed call setup, etc.
An adversary might want to inject signaling messages to terminate or
redirect the call to another location. Dropping or delaying
signaling messages is also possible for an on-path adversary.
Depending on the capability of the signaling protocol the range of
possible attacks might have been documented already.
5.6 Modification of the Emergency Call
An adversary along the media path might want to modify the data
traffic part of the emergency call (voice, video or instant message).
An attacker can change the message on-the-fly and fool the PSAP to
receive meaningless or bogus messages. The response messages to
Emergency Caller might also be subject to change, for example by
injecting a recorded failure message.
5.7 Loss of confidentiality
An adversary might eavesdrop an emergency call and use the
information to future sessions as part of replay attacks. The
ability to eavesdrop also allows to learn details about the emergency
situation which might be of interest for the press or other media
organizations. Please note that the location of the adversary is
important regarding the eavesdropped area. For example, an adversary
in a WLAN is typically able to see a small amount of traffic due to
the coverage area of typical WLAN network.
Reavealing the true identity of the user as part of the privacy
override mechanism might conflict with the users privacy settings.
5.8 Replay Attack
An adversary might want to use eavesdropped information to mount
attacks in the future. This might be necessary if information cannot
be re-created by the adversary (for example, asserted location
information). The ability to replay messages or individual objects
the specific property of these messages and objects is important.
For example, asserted location information might bind location
information and a timestamp with a digital signature together that
makes it difficult to reuse this object beyonds its lifetime.
Tschofenig, et al. Expires January 19, 2006 [Page 11]
Internet-Draft Threats and Req. for Emergency July 2005
[Editor's Note: It is sometimes hard to tell what are real threats
and what security threats are addressed already by certain solutions
outside the scope of the working group. Addressing all standard
security threats is a long process if certain mechanisms are required
in an case that largely or completely mitigate against these
threats.]
5.9 Corrupting Configuration Information
An adversary might override all locally configured emergency numbers.
This might be particular problematic if these emergency numbers are
dynamically retrieved using some mechanisms. As such, an Emergency
Caller would start a call that either leads to a blackhole (as such
it is a DoS attack), the Emergency Caller connects to a rogue PSAP or
to an inappropriate PSAP.
5.10 Corrupting Database Information
An attacker might want to provide emergency callers with wrong
information about emergency service contact URIs. An adversary can
accomplish this goal in various ways, including message modification,
spoofing or corrupting the database. Since the database provides a
pointer(e.g., SIP URI) to an appropriate PSAP, care must be taken
when retrieving emergency URI. A succesfull forging will lead the
user to reach either a false PSAP or to a black hole.
Tschofenig, et al. Expires January 19, 2006 [Page 12]
Internet-Draft Threats and Req. for Emergency July 2005
6. Security Requirements
[Editor's Note: A few requirements below are already addressed by a
number of requirements and solution specific documents today. In
order to keep the document short it would be reasonable to focus only
on the difficult security threats and requiremens for emergency calls
rather than enumerating everything that could happen to an emergency
call. The working group should decide how to proceed with this
particular issue and what threats and requirements should be
elaborated in more detail.]
Compiling security requirements to address the threats listed in the
previous section might is impacted by several constraints:
Security mechanisms may lead to a certain performance overhead
(e.g., several roundtrips).
A certain security infrastructure is required that might lead to
deployment problems. For example, end user certificates,
certificates for networks, usage of authorization certificate,
etc. might need to be deployed before any of these mechanisms are
useful.
Many of these aspects are related to regulatory and legal
requirements that may vary from country to country. Typically,
these mechanisms cannot be mandated by an IETF specification.
Some of the requirements impose solutions that are out-of-scope of
the ECRIT working group.
Given the above-listed constraints the requirements that have to be
addressed by work that is done within ECRIT have to be highlighted.
Other requirements have to be read as 'if you would like to address
this threat, then you might want to consider this requirement' rather
than 'any solution must address fulfill this requirement'.
6.1 Denial of Service Attacks
It is difficult to address all possible denial of service attacks
that might lead to disruption of an emergency call since a number of
IETF protocols are used in order to provide this functionality.
Hence, care must be taken when protocol extensions are developed that
the chance for a denial of service attack is not increased. Even
without using any security mechanisms (such as authentication and key
exchange protocols) some degree of security has to be provided.
It is important to understand that the ability to mount DoS attacks
must also be considered as part of the architecture work when legal
Tschofenig, et al. Expires January 19, 2006 [Page 13]
Internet-Draft Threats and Req. for Emergency July 2005
and regulatory requirements are known and need to be fulfilled.
6.2 Call Identity Spoofing
A standard requirement to prevent identity spoofing is to
authenticate the Emergency Caller. Authentication mechanisms that
require multiple roundtrips and as such might delay the call are
often not desirable or cannot be mandated.
6.3 Location Spoofing
An Emergency Caller might in many cases know its own location
information because it was obtained via civic or geospatial location
extensions for DHCP, via manual configuration or via GPS.
Unfortunately, information provided by the end host is untrustworthy
particularly when it is as important as location information. Two
approaches have been discussed in the past that place lead to a few
requirements:
o Location Information is asserted by the Access Infrastructure
Provider. As such, the end host might use GPS but uses a protocol
to allow the network to assert the location information. This
approach also has its limitations if the coverage area of the
wireless network is fairly large.
o Location Information is added to the emergency call via an
Emergency Call Routing Support entity. Depending on the protocol
used for call routing and on the properties of this protocol it
might be necessary to return the asserted location information to
the end host since intermediate nodes might not be allowed to
insert objects into the call setup messages (at least not in all
parts of the messages, such as bodies). These signaling entities,
in general, do not know the physiscal location of the user. Thus,
they have to rely on somebody else to actually provide the
location, e.g., the Access Infrastructure Provider.
As it can be seen from these two options the main difference is based
on the type of protocol that is used in the message communication.
This has an impact on the semantic and on the availability of certain
attributes (such as identities that are used by these protocols) and
on deployment constraints. Based on the observation that the Access
Infrastructure Provider is closest to the end host and is therefore
the most likely entity that knows something about the physical
location of the end host it seems to be reasonable to assume that
some entity that asserts the location information is actually
available in this particular network.
In the context of emergency, spoofing can be loosely divided into
Tschofenig, et al. Expires January 19, 2006 [Page 14]
Internet-Draft Threats and Req. for Emergency July 2005
o wide-area spoofing - users pretend to be in Germany but actually
in US.
o local-area spoofing - users spoof location information to an
extend (few miles).
o local-area cloning - users pretend to be in place X if they were
actually there, a while ago.
The following requirements need to be provided in order for asserted
location information to accomplish its goals:
o Location Information MUST be integrity protected to prevent
modifications by third parties.
o The recipient of the asserted location information object MUST be
able to determine the party that asserted the location information
in order to verify the assertion. As such, authentication of the
asserting party (the entity that created the assertion) MUST be
provided.
o The asserted location information MUST include a timestamp to
limit its validity in order to reduce replay attacks.
o The recipient of the asserted location information MUST have a way
to verify that the asserting party is indeed authorized to create
such an assertion. As such, authentication is insufficient if not
further authorization decision can be associated to the
authenticated identity.
o The recipient of the asserted location information SHOULD have a
mechanism to determine the Emergency Caller based on the provided
assertion.
The last bullet deserves further discussion: If some information
about the Emergency Caller identity has to be included, which is only
for the purpose of traceability then this functionality might not be
of general use. This is because an adversary will always find
networks that do not authenticate the user prior to providing network
access. Furthermore, the goal of a number of network access
authentication protocols is to prevent disclosure of the user
identity to entities other than to the user's home network. Note
that the term 'user idenity' does not require that this identity
directly points to the 'real' identity of a user. A court might want
to require this identity to be resolved and to determine the user
behind this identity. Even if the access network would like to
assertain the user's identity as part of the asserted location
information it is, in many cases, not even possible for the Access
Tschofenig, et al. Expires January 19, 2006 [Page 15]
Internet-Draft Threats and Req. for Emergency July 2005
Infrastructure Provider.
If the authenticated user identity is not available to the Access
Infrastructure Provider then only a few other identities might be
useful, such as the IP address or the MAC address. Other identities,
such as the Host Identity, might not be available since they are only
used by very few protocols. An assertion that indicates the network
in combination with the IP and/or MAC address (together with a
timestamp) might provide some limited degree of traceability only if
the user was authenticated directly to this particular network.
Providing the IP address allows some obvious attempts to cheat to be
caught. Hence, there is the question whether some identity should be
added at all given the potential limitations and the potential small
amounts of cut-and-paste attacks. Using end user based
authentication in addition to the asserted location information would
be helpful (e.g., using end user certificates) but will impose a
serious deployment problem. Given the fact that emergency calls must
still be allowed even without end user authentication certainly
defeats the purpose of these mechanisms. A partical attempt to
address some prank calls is to classify emergency calls based on the
availability of the provided attributes. If suspicious information
is being provided that may well be wrong then additional verification
steps need to be taken. For example, if a report of a large fire on
a Manhattan street is received then the PSAP may wait to dispatch
until it gets a second person to call in. This approach obviously
has some limitations as well.
6.4 Impersonating a PSAP
The Emergency Caller SHOULD be able to determine conclusively that he
has reached an accredited emergency call center. This requirement is
meant to address the threat that a rogue, possibly criminal, entity
pretends to accept emergency calls and disrupts the emergency
infrastructure.
o A user agent must be able to authenticate a PSAP.
Unlike in the PSTN case IP based networks provide a better
opportunity to spoof a PSAP since physical access to the cable plant
is required in the PSTN case, while this may not true for the IP
case.
6.5 Signaling Message Modification
To protect signaling messages against modifications either individual
attributes SHOULD be protected (such as location objects) or the
entire signaling message communication SHOULD experience end-to-end
protection. This requires integrity and replay protection to be
Tschofenig, et al. Expires January 19, 2006 [Page 16]
Internet-Draft Threats and Req. for Emergency July 2005
applied. Authentication of the data sender and the data receiver
SHOULD be provided to prevent a man-in-the-middle attack.
6.6 Replay Attack
In order to protect signaling messages (or individual attributes) to
be replayed in future protocol sessions integrity and replay
protection mechanisms SHOULD be provided.
6.7 Loss of confidentiality
In order to prevent leakage of information exchanged during the
emergency call (both signaling and data traffic) confidentiality
protection SHOULD be provided. The mechanisms to accomplish this
functionality are typically different for the data traffic and for
the signaling messages and various scenarios, such as hop-by-hop,
end-to-middle, middle-to-middle and end-to-end security, need to be
considered. Particularly the key management aspects for end-to-end
security mechansisms imposes a deployment burden and hence need to be
critically analysed in order to determine its applicability in the
given context.
6.8 Modification of the Emergency Call
To protect a man-in-the-middle attack i.e disallow the adversary to
modify or to inject data traffic into the communication between the
Emergency Caller and the PSAP, the mechanisms like integrity, replay
and data origin authentication SHOULD be provided. Since the
signaling messages are used to authenticate the end points and to
distribute the required keying material it is necessary that either
the key exchange protocol itself and the signaling messages
experience appropriate security protection. The term 'appropriate'
refers to the given context, the used signaling protocol and the key
exchange protocol.
Please note that the interactive nature of a voice communication
already provides a some degree of protection. However, with the
introduction of instant messaging the freshness of the Emergency Call
needs to be provided by other means.
6.9 Corrupting Configuration Information
Devices SHOULD be assured of the correctness of the local emergency
numbers that are automatically configured. If we assume a fixed,
global emergency service identifier that requires no configuration
and only configure local "traditional" emergency numbers, users are
not likely to suddenly dial some random number if a rogue
configuration server introduces this as an additional emergency
Tschofenig, et al. Expires January 19, 2006 [Page 17]
Internet-Draft Threats and Req. for Emergency July 2005
number. The ability to override all locally configured emergency
number is of more concern. If the Emergency Caller does not use the
infrastructure to route the call to the appropriate PSAP then the
security of the directory service is of importance for security.
6.10 Corrupting Database Information
If the mapping client i.e., the entity that requests location
information using a mapping protocol accepts the emergency contact
information from an unauthenticated mapping server i.e., the entity
that provides location information, it is highly possible to receive
bogus or prank emergency contact URIs. Particularly the caching
properties of a distributed directory might be exploited. To ensure
the secure retrieval of information, the following properties are
assumed:
o The maping client MUST be able to authenticate the mapping server.
o The interaction between the mapping client and the mapping server
MUST be integrity and replay protected.
o The mapping server MUST be provide data origin authentication
thereby ensuring that the provided data items are indeed from the
claimed source.
o The mapping server MUST provide information to ensure that it is
authoritive for the provided information.
6.11 Location Validation and Verification
location validation ensures that an address exists and is mappable to
a PSAP. A valid address, however, does not imply that the call
actually originated from that location. We refer to location
verification as the assurance that the call was placed at the
location claimed, including any error margins provided.
Verifying a location is generally more difficult than location
validation as there is currently no generally trusted service that
can vouch for the location of the caller. In some cases, AIPs or
ISPs may be able to indicate the location of the caller with high
confidence and they may possess cryptographic certificates that are
trusted by the PSAP. This may not require a global certification
authority (CA), as a regional PSAP typically only deals with a modest
number of larger enterprises and thus could obtain their public keys
even if self-signed.
However, even if the AIP or ISP provides a signed location, it is
Tschofenig, et al. Expires January 19, 2006 [Page 18]
Internet-Draft Threats and Req. for Emergency July 2005
difficult to ensure that such a signed location object is only used
for calls from that location, as it will have to be copied from a
location delivery protocol to the call signaling protocol. For
example, a third party could obtain such a signed location object and
use it elsewhere. Naturally, timestamps will restrict such usage to
the order of minutes or hours, depending on how often location
information is updated. A PSAP may want to be able to answer the
following questions:
o Who originally provided this particular location information?
o Did the call originate from that particular geospatial or civic
address and who says so and how do they know?
Tschofenig, et al. Expires January 19, 2006 [Page 19]
Internet-Draft Threats and Req. for Emergency July 2005
7. Security Considerations
This document addresses security threats and security requirements.
Therefore, security is considered throughout this document.
Tschofenig, et al. Expires January 19, 2006 [Page 20]
Internet-Draft Threats and Req. for Emergency July 2005
8. IANA Considerations
This document does not require actions by the IANA.
Tschofenig, et al. Expires January 19, 2006 [Page 21]
Internet-Draft Threats and Req. for Emergency July 2005
9. References
9.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
9.2 Informative References
[I-D.schulzrinne-ecrit-requirements]
Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies",
May 2005.
Authors' Addresses
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
Email: Hannes.Tschofenig@siemens.com
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
USA
Phone: +1 212 939 7042
Email: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Murugaraj Shanmugam
Technische Universitat Hamburg-Harburg
Department of Security in Distributed applications
Harburger Schlossstrasse 20
Hamburg-Harburg 21079
Germany
Email: murugaraj.shanmugam@tuhh.de
Tschofenig, et al. Expires January 19, 2006 [Page 22]
Internet-Draft Threats and Req. for Emergency July 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Tschofenig, et al. Expires January 19, 2006 [Page 23]
