ECRIT H. Tschofenig
Internet-Draft Siemens
Expires: June 22, 2006 H. Schulzrinne
Columbia U.
M. Shanmugam
Siemens
T. Taylor
Nortel
December 19, 2005
Security Threats and Requirements for Emergency Calling
draft-taylor-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 June 22, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document reviews the security threats to routing of emergency
calls through the IP network to Public Safety Answering Points
(PSAPs). It establishes a set of security requirements for the
Tschofenig, et al. Expires June 22, 2006 [Page 1]
Internet-Draft ECRIT Security Requirements December 2005
entities and processes involved in performing this call routing.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Emergency call routing system overview . . . . . . . . . . . . 5
4. Motivations of attackers . . . . . . . . . . . . . . . . . . . 8
5. Potential attacks . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Attacks to prevent a specific individual from
receiving aid . . . . . . . . . . . . . . . . . . . . . . 9
5.1.1. Attacks against the Emergency Caller's device . . . . 9
5.1.2. Attacks against call signalling and the initial
call routing entity . . . . . . . . . . . . . . . . . 10
5.1.3. Attacks against the process of location acquisition . 10
5.1.4. Attacks against the process of Mapping the
location to an Emergency Address . . . . . . . . . . . 11
5.2. Attacks to gain information about an emergency . . . . . . 11
5.3. Attacks to gain fraudulent use of ASP/VSP services . . . . 12
5.4. Attacks against the emergency response system . . . . . . 12
6. Security requirements relating to emergency call routing . . . 14
6.1. Requirements for interface (1), self-provided Location
Information . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Requirements for interface (2), configuration by
Location Server . . . . . . . . . . . . . . . . . . . . . 14
6.3. Requirements for interface (3), Emergency Caller's
Device as Mapping Client . . . . . . . . . . . . . . . . . 15
6.4. Requirements for interface (4), outbound call
signalling to call routing entities . . . . . . . . . . . 16
6.5. Requirements for interface (5), call routing element
as Mapping Client . . . . . . . . . . . . . . . . . . . . 16
6.6. Requirements for interface (6), between the final call
routing entity and the PSAP . . . . . . . . . . . . . . . 16
6.7. Requirements for interface (7), direct routing to PSAP . . 17
6.8. Requirements for interface (8), acquisition of
Location Information by a call routing entity . . . . . . 17
6.9. Additional requirements on the Directory . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
Tschofenig, et al. Expires June 22, 2006 [Page 2]
Internet-Draft ECRIT Security Requirements December 2005
1. Introduction
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 Europe). A key factor in the handling of such calls
is the ability of the system to determine caller location and to
route the call to the appropriate Public Safety Answering Point
(PSAP) based on that location. In addition, the system must,
whenever possible, deliver the caller's location and the calling
number to the PSAP. With the introduction of IP-based telephony and
multimedia services, support for emergency calling via the Internet
also has to be provided. To achieve this, a number of protocols and
protocol extensions need to interwork successfully.
Attacks against the PSTN (many focussing on free calling) have taken
place for decades. The Internet is seen as an even more hostile
environment. Thus it is important to understand the types of attacks
that might be mounted against the infrastructure providing emergency
services, and to develop security mechanisms to counter those
attacks. In view of the mandate of the ECRIT Working Group, the
present document restricts itself to attacks on the routing of
emergency calls. The analysis assumes IP connectivity from the
emergency caller's device all the way through to the PSAP.
This document is organized as follows: Section 2 describes basic
terminology. Section 3 describes the different components involved
in routing an emergency call, how they may be organized, and how the
system operates if fully secured from the attacks described in
subsequent parts of the document. Section 4 describes some
motivations of attackers in the context of ECRIT, Section 5 describes
and illustrates the attacks that might be used, and Section 6 lists
the security-related requirements that must be met if these attacks
are to be mitigated.
Tschofenig, et al. Expires June 22, 2006 [Page 3]
Internet-Draft ECRIT Security Requirements December 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].
Application (Voice) Service Provider (ASP/VSP), Call Taker, Directory
Service, Emergency Address, Emergency Caller, Emergency Identifier,
Emergency Services Routing Proxy (ESRP), Internet Attachment Provider
(IAP), Mapping, Mapping Client, Mapping Server, and Public Safety
Answering Point (PSAP) are taken from [I-D.ecrit-requirements].
Location Server and Location Information are taken from RFC 3693
[RFC3693].
The term "Emergency Caller's Device" designates the IP host closest
to the Emergency Caller in the signalling path between the Emergency
Caller and the PSAP. Examples include an IP phone running SIP,
H.323, or a proprietary signalling protocol, a PC running a soft
client, or an analogue terminal adapter or an access gateway
controlled by a softswitch.
The term "configuration time" refers to any point in time prior to
the emergency when configuration data (in particular, Location
Information and possibly the Emergency Address) is added to or
updated within the Emergency Caller's Device.
Tschofenig, et al. Expires June 22, 2006 [Page 4]
Internet-Draft ECRIT Security Requirements December 2005
3. Emergency call routing system overview
As described in [I-D.ecrit-requirements] and schematically shown in
Figure 1, the system for routing an emergency call consists of the
following components:
o the Emergency Caller's Device;
o a source of information regarding the location of the Emergency
Caller's Device (the Location Server);
o the emergency call routing support component, consisting of one or
more call routing elements (e.g., SIP proxies, media gateway
controllers, call signalling protocol interworking units) possibly
including an Emergency Services Routing Proxy (ESRP);
o a Directory Service capable of providing the emergency address
corresponding to a given caller's location, one implementation of
which uses mapping servers with associated mapping databases;
o the Public Safety Answering Point (PSAP) having jurisdiction over
the location associated with the call.
The numbered interfaces shown in Figure 1 are the targets of our
analysis. Some of these interfaces represent alternative
architectures. For example, interface (1) comes into play if the
Location Information is configured manually into the Emergency
Caller's Device or the Emergency Caller's Device can provide location
itself (e.g., because of built-in GPS). Interface (2) allows the
Emergency Caller's Device to acquire Location Information from a
Location Server. Finally, it may be one of the entities in the
emergency call routing support component that acquires the location
over interface (8).
Figure 1 also illustrates the actors and thus the potential trust
relationships involved in the call routing process. The actors
consist of:
o the emergency caller;
o the Emergency Caller's Device, which may be configured by the
Emergency Caller, by the Internet Attachment Provider (IAP),
and/or by some third party, particularly the Application (Voice)
Service Provider (ASP/VSP);
o the Internet Attachment Provider, typically providing some of the
configuration for the Emergency Caller's Device and potentially
the operator of the Location Server;
Tschofenig, et al. Expires June 22, 2006 [Page 5]
Internet-Draft ECRIT Security Requirements December 2005
o one or more Internet Service Providers (not shown), providing IP
connectivity from the internet access point to the PSAP;
o one or more Application (Voice) Service Providers (ASPs/VSPs)
providing the call routing and session setup services requested in
the emergency call;
o the Directory Service provider, potentially a separate entity; and
o the PSAP, which passes calls to the Call Taker.
Location
Information +-----------------+
|(1) | Internet | +-----------+
v | Attachment | | |
+-----------+ | Provider | | Directory |
| | | | | |
| Emergency |<---+-----------------+-->| |
| Caller | | (3) | +-----------+
| |<---+-------+ | ^
+-----------+ (2)| +----|---------+------+ |
^ | | Location | | |
| | | Server <-+ | |
| +--+--------------+ |(8) | | (5)
| | +-----------v+ | |
| (4) | |Emergency | | |
+--------------+--->|Call Routing|<--+---+
| | |Support | |
| | +------------+ |
| | ^ |
| | (6) | +----+--+
| (7) | +------->| |
+--------------+--------------->| PSAP |
| | |
|Application +----+--+
|(Voice) |
|Service |
|Provider |
+---------------------+
Figure 1: Emergency call routing framework
In the absence of an attack, any call for which the signalling is
marked with an Emergency Identifier is successfully routed to a Call
Taker in the PSAP having jurisdiction over the caller's location.
For this to happen, the following individual steps must occur:
Tschofenig, et al. Expires June 22, 2006 [Page 6]
Internet-Draft ECRIT Security Requirements December 2005
1. The caller's location must be acquired. This may happen at
configuration time or at the time of the call. The source of the
Location Information may be the Emergency Caller's Device itself
(e.g., from embedded GPS capability) or the Location Information
may be manually configured into the device. However, this
analysis concerns itself mostly with the case where the source of
the Location Information is a Location Server as defined in RFC
3693 [RFC3693]. Based on that assumption, successful operation
requires that the receiver of the Location Information (either
the Emergency Caller's Device or a call routing element) acquire
that data in timely fashion. The source of the Location
Information received must be an authorized source and the
integrity of the data must be assured in transit.
2. The location must be mapped to an Emergency Address. This will
most likely happen at the time of the call, but may happen at
configuration time if the receiver of the Location Information
was the Emergency Caller's Device. This step again must happen
in timely fashion. The Mapping Client must be able to ensure
that it is receiving the information from a valid Mapping Server,
that the address it receives is in response to its query and not
some other one, and that the information has not been altered in
transit. Moreover, the success of the operation requires that
the integrity of the Mapping database from which the server drew
its response must be maintained.
3. The timeliness, integrity and privacy of call signalling must be
ensured as it passes between the emergency caller's device and
the PSAP.
NOTE - a confidentiality requirement applies to the
association of a location with an emergency (e.g., within call
signalling) or with an individual. The location data per se
is not confidential.
Tschofenig, et al. Expires June 22, 2006 [Page 7]
Internet-Draft ECRIT Security Requirements December 2005
4. Motivations of attackers
Attackers may direct their efforts either against an individual or
against a portion of the emergency response system. Attacks against
an individual fall into three classes:
o attacks to prevent an individual from receiving aid;
o attacks to gain information about an emergency that can be applied
either against an individual involved in that emergency or to the
profit of the attacker;
o attacks by the caller to gain fraudulent use of ASP/VSP services,
by using an Emergency Identifier to bypass normal authentication,
authorization, and accounting procedures.
Attacks against the emergency response system are aimed either at
denying system services to all users in a given area, or at diverting
emergency responders to non-emergency sites. The latter motivation
falls outside the scope of this analysis.
Tschofenig, et al. Expires June 22, 2006 [Page 8]
Internet-Draft ECRIT Security Requirements December 2005
5. Potential attacks
This section describes classes of attacks that could be used to
achieve the attacker goals described in the previous section.
5.1. Attacks to prevent a specific individual from receiving aid
This section discusses blocking attacks directed at a specific
individual. The more general blocking attacks described in
Section 5.4 will also operate to the same effect. They are discussed
separately because the separation may be useful when weighing the
priority for implementing specific defenses.
Blocking attacks against an individual can be directed against the
Emergency Caller's device, against the call signalling, or against
the initial call routing entity (e.g., SIP proxy or B2BUA) handling
that signalling. They may also be directed against the process of
acquisition of Location Information or Mapping of that Location
Information to an Emergency Address, if done at call time. (Attacks
could be directed further along in the call routing chain, closer to
the PSAP, but such attacks are more likely to be deployed against all
users within the area servued by the PSAP, rather than against an
individual.) The possible attacks along all of these lines are
spelled out in the remainder of this section.
5.1.1. Attacks against the Emergency Caller's device
The definition of "Emergency Caller's Device" given in Section 2
covers a variety of cases. Clearly the vulnerability of the
Emergency Caller's Device to specific attacks will vary with the
particular case. What follows should be read with this reservation
in mind.
If the Emergency Caller's Device depends on configuration data to
make an effective emergency call, and the relevant part of that
configuration is acquired from the network, the device may be
vulnerable to corrupting messages (e.g., viruses or worms) sent by
the attacker. Examples of the sort of configuration data that could
be corrupted are the address of the initial call routing entity
(e.g., SIP outbound proxy), the location of the device (if this is
acquired or configured beforehand), or a mapped Emergency Address (if
that is also acquired or configured beforehand).
Alternatively, the attacker might direct a large volume of traffic at
the Emergency Caller's Device in an attempt to overload it.
Tschofenig, et al. Expires June 22, 2006 [Page 9]
Internet-Draft ECRIT Security Requirements December 2005
5.1.2. Attacks against call signalling and the initial call routing
entity
Sending a flood of messages to the Emergency Caller's device could
also have the effect of blocking call signalling by overloading the
link between the device and the network.
The attacker may attempt to block or corrupt the call signalling
along the path to the initial call routing entity by seizing control
of a bridge or an IP router.
The attacker may attempt to seize control of the initial call routing
entity and cause it to ignore or mis-handle signalling from the
Emergency Caller's device.
The attacker could attempt to block the handling of the emergency
call through a flooding attack on the initial call routing entity.
This, of course, would likely affect many people, not just the
Emergency Caller.
Finally, the attacker could cause call signalling to be misdirected
by impersonating the initial call routing entity.
5.1.3. Attacks against the process of location acquisition
Location acquisition could be implemented in a number of ways. The
phrasing of the attack descriptions provided below attempts to focus
on the specific nature of the attacks without getting into the
details of the implementation. Nevertheless, the list which follows
describes several alternative approaches to implementation:
o The Emergency Caller's Device acquires the Location Information at
configuration time and includes it in subsequent call signalling.
o The Emergency Caller's Device acquires the address of the Location
Server at configuration time, acquires the actual Location
Information at call time, and includes it in call signalling.
o The caller's device acquires a reference pointing to the Location
Server at configuration time and includes this reference in call
signalling. The Emergency Service Routing Proxy (which could be
the initial call routing entity) uses this reference to acquire
the Location Information, which it then uses for Mapping and
inserts into call signalling.
o The initial call routing entity is configured with the address of
the Location Server, acquires the Location Information at call
time, and inserts it into call signalling.
Tschofenig, et al. Expires June 22, 2006 [Page 10]
Internet-Draft ECRIT Security Requirements December 2005
Bearing these possibilities in mind, here are some potential attacks:
o If the Emergency Caller's Device receives its location from the
network at configuration time (e.g., via DHCP), the attacker could
try to compromise that process by attacking or impersonating the
Location Server. In general this does not seem likely to be a
very effective attack, since configuration time may come long
before any emergency call, and failures in configuration have a
good chance of being detected and remedied.
o If location acquisition happens at call time, the attacker has
similar choices to those listed against call signalling and the
initial call routing entity. The attacker might intercept the
location query or response, seize control of the Location Server,
flood the Location Server, or impersonate the Location Server.
o Upon detecting a query for location, the attacker can send a
response from a different location query hoping that it will be
received and accepted by the querying entity before the correct
response. Alternatively it can modify the response.
5.1.4. Attacks against the process of Mapping the location to an
Emergency Address
The Mapping could be done at configuration time, and the Emergency
Address configured in the Emergency Caller's device along with its
location. It might be possible for an attacker to interfere with
this process, but the objections are the same as those pertaining to
attacks on the acquisition of location at configuration time.
If Mapping occurs at call time, the attacker has similar choices to
those for interfering with the acquisition of location. The attacker
has one further option: to corrupt the Mapping database so that the
wrong answer is given for the Emergency Caller's location.
5.2. Attacks to gain information about an emergency
This section discusses attacks used to gain information about an
emergency. The attacker may be seeking the location of the caller
(e.g., to effect a criminal attack). The attacker may be seeking
information that could be used to link an individual (the caller or
someone else involved in the emergency) with embarrassing information
related to the emergency (e.g., "Who did the police take away just
now?"). Finally, the attacker could be seeking to profit from the
emergency, perhaps by offering his or her services (e.g., news
reporter, "ambulance chaser").
The primary means of attack during call routing is capture of the
Tschofenig, et al. Expires June 22, 2006 [Page 11]
Internet-Draft ECRIT Security Requirements December 2005
content of signalling information. Depending on the specific
motivation, the capture must happen close to the Emergency Caller or
may happen anywhere along the call routing chain, particularly near
or at the PSAP. In most cases, the attacker will have a greater
interest in the content of the conversation following upon call setup
than in the signalling itself. The exception is the first case cited
above, where the attacker is trying to locate the Emergency Caller.
In this case, the caller's location, any information identifying the
caller, and the call-back address all need to be protected.
It is possible that the Location Server transmits Location
Information along with information (e.g., IP address) identifying the
Emergency Caller's device. In this case, capture of the transmitted
data may provide information that can be combined with information
from other attacks, or the information may be used to carry out other
attacks.
5.3. Attacks to gain fraudulent use of ASP/VSP services
This section discusses attacks whereby the Emergency Caller is hoping
to bypass normal procedures to achieve free use of ASP/VSP services.
A simple example is where the call signalling carries an Emergency
Identifier and thus is allowed to proceed without authentication for
billing. To be attractive to an attacker, the call needs to be
addressed (and connected) to a non-emergency destination of the
attacker's choice. This is especially possible if the system assigns
the responsibility for Mapping to the Emergency Caller's Device and
it is located on subscriber premises.
A more complicated attack would be to insert an entry into the
Mapping database or tamper with the Mapping Server, so that a
particular location gets mapped to a destination of the attacker's
choosing. The attacker could then make unaccounted-for calls to that
destination by including the location in call signalling.
5.4. Attacks against the emergency response system
This section considers attacks intended to reduce the effectiveness
of the emergency response system for all callers in a given area.
The motivation may range from thoughtless vandalism, to wide-scale
criminality, to terrorism. The attacks listed here cover the
"mechanical" possibilities. In addition, one can easily imagine
attacks whereby callers exhaust response resources by describing non-
existent emergencies.
Perhaps the most obvious attack in support of this goal is a flooding
attack directed at the PSAP. The attacker may also impersonate a
PSAP, causing emergency calls to be misdirected, without immediate
Tschofenig, et al. Expires June 22, 2006 [Page 12]
Internet-Draft ECRIT Security Requirements December 2005
detection.
Another effective attack would be to deny the use of the Directory.
This could be done in several ways: by a flooding attack on the
Mapping Servers for the region, by corruption of the Mapping
Database, or by impersonation of a Mapping Server.
Tschofenig, et al. Expires June 22, 2006 [Page 13]
Internet-Draft ECRIT Security Requirements December 2005
6. Security requirements relating to emergency call routing
This section describes the security requirements which must be
fulfilled to prevent or blunt the effectiveness of the attacks
described in the previous chapter. The scope of these requirements
is limited to those specific to emergency calls, that is, the scope
of the ECRIT Working Group. Thus the focus will be on requirements
concerning the Location Information, the Mapping process, the Mapping
database, prevention of disclosure, and prevention of fraud.
Moreover, the focus is on requirements for security mechanisms as
opposed to policies. Other documents may address appropriate
policies for elements of the emergency response system once the
mechanisms are in place.
The organization of this section is based on Figure 1. The
requirements are identified for each successive interface shown in
that figure. This will make for some repetition in the details, but
lead to a more precise analysis of alternative architectures.
6.1. Requirements for interface (1), self-provided Location Information
Interface (1) pertains to the supply of Location Information either
by equipment (e.g., GPS) built directly into the Emergency Caller's
Device, or by manual entry. The security requirements specified for
this interface are those needed to help ensure the the validity of
the Location Information as a basis for emergency call routing.
1. If the Location Information is configured into the Emergency
Caller's Device by manual entry, such entry SHOULD require
authentication and authorization of the person providing the
entry. This helps to deter a class of fraudulent attacks
discussed in Section 5.3.
6.2. Requirements for interface (2), configuration by Location Server
This section considers requirements when Location Information is
acquired by the Emergency Caller's Device from a Location Server.
This could happen either at configuration time or at call time.
OPEN ISSUE: How does the Emergency Caller's Device acquire the
address of the Location Server, and what requirements attend that
acquisition process?
1. The protocol for obtaining the Location Information from the
Location Server MUST offer authentication of the Location Server
entity, integrity protection of the Location Information, and
protection against replay. These requirements address attacks
described in Section 5.1.3.
Tschofenig, et al. Expires June 22, 2006 [Page 14]
Internet-Draft ECRIT Security Requirements December 2005
2. If Location Information is transmitted in conjunction with
information which would allow a third party to identify the
caller's device, the transmission of that data MUST offer
confidentiality. This requirement addresses an attack described
in Section 5.1.3.
3. If the Location Information is acquired at configuration time, an
automatic audit or refresh of that information SHOULD also be
performed at regular intervals to prevent the corruption of the
configured data (and to ensure that the device has up-to-date
information). This requirement addresses the device data
corruption attack in Section 5.1.1.
4. Particularly if Location Information is acquired at call time,
the protocol used for location acquisition MUST NOT create new
opportunities for flooding attacks associated with this
application. This requirement addresses an attack mentioned in
Section 5.1.3.
6.3. Requirements for interface (3), Emergency Caller's Device as
Mapping Client
This section considers requirements when the Emergency Caller's
Device acts as a Mapping Client to map the Location Information to
the corresponding Emergency Address. This could happen either at
configuration time or at call time.
OPEN ISSUE: How does the Emergency Caller's Device acquire the
address of the Mapping Server, and what requirements attend that
acquisition process?
1. The mapping protocol MUST include authentication of the Mapping
Server entity, integrity protection of the mapping query and
response, and protection against replay of the response. These
requirements address attacks described in Section 5.1.4 and
Section 5.4.
2. The Mapping protocol MUST NOT create new opportunities for
flooding attacks. This addresses an attack mentioned in
Section 5.1.4 and Section 5.4.
3. If the Mapping is done at configuration time, it SHOULD be
repeated at regular intervals to prevent the corruption of the
configured data (and to ensure that the device has up-to-date
information). This requirement addresses the device data
corruption attack in Section 5.1.1.
Tschofenig, et al. Expires June 22, 2006 [Page 15]
Internet-Draft ECRIT Security Requirements December 2005
6.4. Requirements for interface (4), outbound call signalling to call
routing entities
This section considers the requirements for the transfer of call
signalling between the Emergency Caller's Device and a call routing
element as opposed to the PSAP directly.
1. Emergency call signalling on this interface MUST be provided with
confidentiality. This addresses attacks described in
Section 5.2.
2. Emergency call signalling on this interface MUST be provided with
integrity protection. This addresses an attack described in
Section 5.1.2.
6.5. Requirements for interface (5), call routing element as Mapping
Client
This section considers the requirements when a call routing element
between the Emergency Caller's Device and the PSAP invokes the
Mapping service. The requirements are very similar to those where
Mapping is done at the Emergency Caller's Device.
1. The mapping protocol MUST include authentication of the Mapping
Server entity, integrity protection of the mapping query and
response, and protection against replay of the response. These
requirements address attacks described in Section 5.1.4 and
Section 5.4.
2. The Mapping protocol MUST NOT create new opportunities for
flooding attacks. This addresses an attack mentioned in
Section 5.1.4 and Section 5.4.
6.6. Requirements for interface (6), between the final call routing
entity and the PSAP
This section considers requirements on the final call signalling hop,
between a call routing entity and the PSAP. It also includes
requirements that, strictly speaking, may apply to intermediate call
routing entities preceding the final one before the PSAP.
1. Emergency call signalling on this interface MUST be provided with
confidentiality. This addresses attacks described in
Section 5.2.
2. It MUST be possible for the final call routing entity to
authenticate the PSAP entity. This addresses an impersonation
attack described in Section 5.4.
Tschofenig, et al. Expires June 22, 2006 [Page 16]
Internet-Draft ECRIT Security Requirements December 2005
3. If any call routing entity would normally authenticate the call
for billing or authorization but does not do so because the
Emergency Identifier is present in the signalling, the call
routing entity MUST ensure that the call is routed to a PSAP.
This requirement is already captured in [I-D.ecrit-requirements].
It addresses attacks described in Section 5.3.
6.7. Requirements for interface (7), direct routing to PSAP
This section considers requirements on the call signalling interface
when the Emergency Caller's Device routes the call directly to the
PSAP. These requirements are a blend of the requirements for
interfaces (3) and (5).
1. Emergency call signalling on this interface MUST be provided with
confidentiality. This addresses attacks described in
Section 5.2.
2. Emergency call signalling on this interface MUST be provided with
integrity protection. This addresses an attack described in
Section 5.1.2.
3. It MUST be possible for the Emergency Caller's Device to
authenticate the PSAP entity. This addresses an impersonation
attack described in Section 5.4.
6.8. Requirements for interface (8), acquisition of Location
Information by a call routing entity
This section considers the requirements when a call routing entity in
the emergency call routing support acquires the Location Information,
rather than the Emergency Caller's Device. The requirements are
similar to those on interface (2).
1. The protocol for obtaining the Location Information from the
Location Server MUST offer authentication of the Location Server
entity, integrity protection of the Location Information, and
protection against replay. These requirements address attacks
described in Section 5.1.3.
2. If Location Information is transmitted in conjunction with
information which would allow a third party to identify the
caller's device, the transmission of that data MUST offer
confidentiality. This requirement addresses an attack described
in Section 5.1.3.
3. The protocol used for location acquisition MUST NOT create new
opportunities for flooding attacks associated with this
Tschofenig, et al. Expires June 22, 2006 [Page 17]
Internet-Draft ECRIT Security Requirements December 2005
application. This requirement addresses an attack mentioned in
Section 5.1.3.
6.9. Additional requirements on the Directory
This section addresses requirements on the "back-end" interface into
the directory, by means of which the Mapping Database is populated
and updated. The interface is not shown separately in Figure 1.
1. If a protocol is specified for performing updates to the Mapping
Database, that protocol MUST include integrity protection, MUST
permit authentication and authorization of the source of the
update, and MUST NOT create new opportunities for flooding
attacks. These requirements address attacks on the Mapping
Database described in Section 5.1.4, Section 5.3 and Section 5.4.
Tschofenig, et al. Expires June 22, 2006 [Page 18]
Internet-Draft ECRIT Security Requirements December 2005
7. Security Considerations
This document addresses security threats and security requirements.
Therefore, security is considered throughout this document.
Tschofenig, et al. Expires June 22, 2006 [Page 19]
Internet-Draft ECRIT Security Requirements December 2005
8. Acknowledgements
Hannes Tschofenig performed the initial security analysis for ECRIT.
The authors would like to thank Stephen Kent for his extensive
comments on the previous issue of this document, which led to a
complete rewriting of it.
Tschofenig, et al. Expires June 22, 2006 [Page 20]
Internet-Draft ECRIT Security Requirements December 2005
9. IANA Considerations
This document does not require actions by the IANA.
Tschofenig, et al. Expires June 22, 2006 [Page 21]
Internet-Draft ECRIT Security Requirements December 2005
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[I-D.ecrit-requirements]
Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies",
October 2005.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
Tschofenig, et al. Expires June 22, 2006 [Page 22]
Internet-Draft ECRIT Security Requirements December 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
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
Email: murugaraj.shanmugam@siemens.com
Tom Taylor
Nortel
1852 Lorraine Ave
Ottawa, Ontario K1H 6Z8
Canada
Email: taylor@nortel.com
Tschofenig, et al. Expires June 22, 2006 [Page 23]
Internet-Draft ECRIT Security Requirements December 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 June 22, 2006 [Page 24]
