draft-ietf-ecrit-security-threats-05.txt   rfc5069.txt 
ECRIT T. Taylor, Ed. Network Working Group T. Taylor, Ed.
Internet-Draft Nortel Request for Comments: 5069 Nortel
Expires: February 22, 2008 H. Tschofenig Category: Informational H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
M. Shanmugam M. Shanmugam
Detecon Detecon
August 21, 2007 January 2008
Security Threats and Requirements for Emergency Call Marking and Mapping
draft-ietf-ecrit-security-threats-05.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 February 22, 2008. Security Threats and Requirements for
Emergency Call Marking and Mapping
Copyright Notice Status of This Memo
Copyright (C) The IETF Trust (2007). This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract Abstract
This document reviews the security threats associated with the This document reviews the security threats associated with the
marking of signalling messages to indicate that they are related to marking of signalling messages to indicate that they are related to
an emergency, and the process of mapping from locations to Universal an emergency, and with the process of mapping locations to Universal
Resource Identifiers (URIs) pointing to Public Safety Answering Resource Identifiers (URIs) that point to Public Safety Answering
Points (PSAPs). This mapping occurs as part of the process of Points (PSAPs). This mapping occurs as part of the process of
routing emergency calls through the IP network. routing emergency calls through the IP network.
Based on the identified threats, this document establishes a set of Based on the identified threats, this document establishes a set of
security requirements for the mapping protocol and for the handling security requirements for the mapping protocol and for the handling
of emergency-marked calls. of emergency-marked calls.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Marking, Mapping, and the Emergency Call Routing Process . . . 5 3. Marking, Mapping, and the Emergency Call Routing Process . . . 3
3.1. Call Marking . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Call Marking . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Objectives of Attackers . . . . . . . . . . . . . . . . . . . 6 4. Objectives of Attackers . . . . . . . . . . . . . . . . . . . 4
5. Potential Attacks . . . . . . . . . . . . . . . . . . . . . . 7 5. Potential Attacks . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Attacks Involving the Emergency Identifier . . . . . . . . 7 5.1. Attacks Involving the Emergency Identifier . . . . . . . . 5
5.2. Attacks Against or Using the Mapping Process . . . . . . . 7 5.2. Attacks Against or Using the Mapping Process . . . . . . . 5
5.2.1. Attacks Against the Emergency Response System . . . . 8 5.2.1. Attacks Against the Emergency Response System . . . . 6
5.2.2. Attacks To Prevent a Specific Individual From 5.2.2. Attacks to Prevent a Specific Individual from
Receiving Aid . . . . . . . . . . . . . . . . . . . . 9 Receiving Aid . . . . . . . . . . . . . . . . . . . . 7
5.2.3. Attacks To Gain Information About an Emergency . . . . 9 5.2.3. Attacks to Gain Information about an Emergency . . . . 7
6. Security Requirements Relating To Emergency Marking and 6. Security Requirements Relating to Emergency Marking and
Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction 1. Introduction
Legacy telephone network users can summon help for emergency services Legacy telephone network users can summon help for emergency services
such as ambulance, fire and police using a well known number (e.g., (such as an ambulance, the fire department, and the police) using a
911 in North America, 112 in Europe). A key factor in the handling well known number (e.g., 911 in North America, 112 in Europe). A key
of such calls is the ability of the system to determine caller factor in the handling of such calls is the ability of the system to
location and to route the call to the appropriate Public Safety determine caller location and to route the call to the appropriate
Answering Point (PSAP) based on that location. With the introduction Public Safety Answering Point (PSAP) based on that location. With
of IP-based telephony and multimedia services, support for emergency the introduction of IP-based telephony and multimedia services,
calling via the Internet also has to be provided. As one of the support for emergency calling via the Internet also has to be
steps to achieve this, an emergency marker is being defined that can provided. Two core components of IP-based emergency calling include
be attached to call signalling to indicate that the call relates to an emergency service identifier and a mapping protocol. The
an emergency. In addition, a protocol is being developed to allow a emergency service identifier indicates that the call signaling
client entity to submit a location and receive a URI pointing to the establishes an emergency call, while the mapping protocol translates
applicable PSAP for that location. the emergency service identifier and the caller's geographic location
into an appropriate PSAP URL.
Attacks against the PSTN have taken place for decades. The Internet Attacks against the Public Switched Telephone Network (PSTN) have
is seen as an even more hostile environment. Thus it is important to taken place for decades. The Internet is seen as an even more
understand the types of attacks that might be mounted against the hostile environment. Thus, it is important to understand the types
infrastructure providing emergency services, and to develop security of attacks that might be mounted against the infrastructure providing
mechanisms to counter those attacks. While this can be a broad emergency services and to develop security mechanisms to counter
topic, the present document restricts itself to attacks on the those attacks. While this can be a broad topic, the present document
mapping of locations to PSAP URIs and attacks based on emergency restricts itself to attacks on the mapping of locations to PSAP URIs
marking. Verification of the truthfulness of a reported incident by and attacks based on emergency marking. Verification by the PSAP
the PSAP operator and various other attacks against the PSAP operator of the truthfulness of a reported incident and various other
infrastructure related to the usage of faked location information are attacks against the PSAP infrastructure related to the usage of faked
outside the scope of the document. location information are outside the scope of the document.
This document is organized as follows: Section 2 describes basic This document is organized as follows: Section 2 describes basic
terminology. Section 3 briefly describes how emergency marking and terminology. Section 3 briefly describes how emergency marking and
mapping fit within the process of routing emergency calls. Section 4 mapping fit within the process of routing emergency calls. Section 4
describes some motivations of attackers in the context of emergency describes some motivations of attackers in the context of emergency
calling, Section 5 describes and illustrates the attacks that might calling, Section 5 describes and illustrates the attacks that might
be used, and Section 6 lists the security-related requirements that be used, and Section 6 lists the security-related requirements that
must be met if these attacks are to be mitigated. must be met if these attacks are to be mitigated.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119], with the document are to be interpreted as described in [RFC2119], with the
qualification that unless otherwise stated they apply to the design qualification that unless otherwise stated, they apply to the design
of the mapping protocol, not its implementation or application. of the mapping protocol, not its implementation or application.
The terms call taker, mapping service, emergency caller, emergency The terms "call taker", "mapping service", "emergency caller",
identifier, mapping, mapping client, mapping server, mapping "emergency identifier", "mapping", "mapping client", "mapping
protocol, and Public Safety Answering Point (PSAP) are taken from server", "mapping protocol", and "Public Safety Answering Point
[I-D.ietf-ecrit-requirements]. (PSAP)" are taken from [RFC5012].
The term "location information" is taken from RFC 3693 [RFC3693]. The term "location information" is taken from RFC 3693 [RFC3693].
The term "emergency caller's device" designates the IP host closest The term "emergency caller's device" designates the IP host closest
to the emergency caller in the signalling path between the emergency to the emergency caller in the signalling path between the emergency
caller and the PSAP. Examples include an IP phone running SIP, caller and the PSAP. Examples include an IP phone running SIP,
H.323, or a proprietary signalling protocol, a PC running a soft H.323, or a proprietary signalling protocol, a PC running a soft
client, or an analogue terminal adapter or a residential gateway client or an analogue terminal adapter, or a residential gateway
controlled by a softswitch. controlled by a softswitch.
3. Marking, Mapping, and the Emergency Call Routing Process 3. Marking, Mapping, and the Emergency Call Routing Process
This memo deals with two topics relating to the routing of emergency This memo deals with two topics relating to the routing of emergency
calls to their proper destination: call marking and mapping. calls to their proper destination: call marking and mapping.
3.1. Call Marking 3.1. Call Marking
Marking of call signalling enables entities along the signalling path Marking of call signalling enables entities along the signalling path
to recognize that a particular signalling message is associated with to recognize that a particular signalling message is associated with
an emergency call. Signalling containing the emergency identifier an emergency call. Signalling containing the emergency identifier
may be given priority treatment, special processing, and/or special may be given priority treatment, special processing, and/or special
routing. routing.
3.2. Mapping 3.2. Mapping
An important goal of emergency call routing is to ensure that any An important goal of emergency call routing is to ensure that any
emergency call is routed to a PSAP. Preferably the call is routed to emergency call is routed to a PSAP. Preferably, the call is routed
the PSAP responsible for the caller's location, since misrouting to the PSAP responsible for the caller's location, since misrouting
consumes valuable time while the call taker locates and forwards the consumes valuable time while the call taker locates and forwards the
call to the right PSAP. As described in call to the right PSAP. As described in [RFC5012], mapping is part
[I-D.ietf-ecrit-requirements], mapping is part of the process of of the process of achieving this preferable outcome.
achieving this preferable outcome.
In brief, mapping involves a mapping client, a mapping server, and In brief, mapping involves a mapping client, a mapping server, and
the protocol that passes between them. The protocol allows the the protocol that passes between them. The protocol allows the
client to pass location information to the mapping server and to client to pass location information to the mapping server and to
receive back a URI which can be used to direct call signalling to a receive back a URI, which can be used to direct call signalling to a
PSAP.
Since mapping requires location information for input, when and where
the location information is acquired imposes constraints upon when
mapping can be done and which devices can act as mapping clients.
The key distinction in "when" is before the emergency or during the
emergency. The key distinction in "where" is at the emergency
caller's device or at another device in the signalling path between
the emergency caller and the PSAP. The mapping client can be the
device that acquires the location information or any device
downstream of that point. It is even possible for a PSAP itself to
initiate mapping, to determine whether an arriving call should be
handled by a call taker at that PSAP or should be proxied to another
PSAP. PSAP.
4. Objectives of Attackers 4. Objectives of Attackers
Attackers may direct their efforts either against a portion of the Attackers may direct their efforts either against a portion of the
emergency response system or against an individual. Attacks against emergency response system or against an individual. Attacks against
the emergency response system have three possible objectives: the emergency response system have three possible objectives:
o to deny system services to all users in a given area. The o to deny system services to all users in a given area. The
motivation may range from thoughtless vandalism, to wide-scale motivation may range from thoughtless vandalism, to wide-scale
criminality, to terrorism. One interesting variant on this criminality, to terrorism. One interesting variant on this
motivation is the case where a victim of a large emergency hopes motivation is the case where a victim of a large emergency hopes
to gain faster service by blocking others' competing calls for to gain faster service by blocking others' competing calls for
help. help.
o to gain fraudulent use of services, by using an emergency o to gain fraudulent use of services, by using an emergency
identifier to bypass normal authentication, authorization, and identifier to bypass normal authentication, authorization, and
accounting procedures; accounting procedures.
o to divert emergency calls to non-emergency sites. This is a form o to divert emergency calls to non-emergency sites. This is a form
of denial of service attack similar to the first item but quite of a denial-of-service attack similar to the first item, but quite
likely more confusing for the caller itself since it expects to likely more confusing for the caller himself or herself since the
talk to a PSAP operator but instead gets connected to someone caller expects to talk to a PSAP operator but instead gets
else. connected to someone else.
Attacks against an individual fall into two classes: Attacks against an individual fall into two classes:
o attacks to prevent an individual from receiving aid; o attacks to prevent an individual from receiving aid.
o attacks to gain information about an emergency that can be applied o attacks to gain information about an emergency that can be applied
either against an individual involved in that emergency or to the either against an individual involved in that emergency or to the
profit of the attacker. profit of the attacker.
5. Potential Attacks 5. Potential Attacks
5.1. Attacks Involving the Emergency Identifier 5.1. Attacks Involving the Emergency Identifier
The main attack possibility involving the emergency identifier is to The main possibility of attack involves use of the emergency
use it to bypass normal procedures in order to achieve fraudulent use identifier to bypass the normal procedures in order to achieve
of services. An attack of this sort is possible only if the fraudulent use of services. An attack of this sort is possible only
following conditions are true: if the following conditions are true:
a. The attacker is the emergency caller. a. The attacker is the emergency caller.
b. The call routing system assumes that the emergency caller's b. The call routing system assumes that the emergency caller's
device signals the correct PSAP URI for the caller's location. device signals the correct PSAP URI for the caller's location.
c. The call enters the domain of a service provider, which accepts c. The call enters the domain of a service provider, which accepts
it without applying normal procedures for authentication and it without applying normal procedures for authentication and
authorization because the signalling carries the emergency authorization because the signalling carries the emergency
identifier. identifier.
d. The service provider routes it according to the called address d. The service provider routes the call according to the called
(e.g., SIP Request-URI), without verifying that this is the address (e.g., SIP Request-URI), without verifying that this is
address of a PSAP (noting that a URI by itself does not indicate the address of a PSAP (noting that a URI by itself does not
the nature of the entity it is pointing to). indicate the nature of the entity it is pointing to).
If these conditions are satisfied, the attacker can bypass normal If these conditions are satisfied, the attacker can bypass normal
service provider authorization procedures for arbitrary destinations, service provider authorization procedures for arbitrary destinations,
simply by reprogramming the emergency caller's device to add the simply by reprogramming the emergency caller's device to add the
emergency identifier to non-emergency call signalling. Most probably emergency identifier to non-emergency call signalling. In this case,
in this case, the call signalling will not include any location the call signalling most likely will not include any location
information, or there could be location information, but it is false. information, or there could be location information, but it is false.
An attacker wishing to disrupt the emergency call routing system may An attacker wishing to disrupt the emergency call routing system may
use a similar technique to target components of that system for a use a similar technique to target components of that system for a
denial of service attack. The attacker will find this attractive to denial-of-service attack. The attacker will find this attractive to
reach components that handle emergency calls only. Flooding attacks reach components that handle emergency calls only. Flooding attacks
are the most likely application of the technique, but it may also be are the most likely application of the technique, but it may also be
used to identify target components for other attacks by analyzing the used to identify target components for other attacks by analyzing the
content of responses to the original signalling messages. content of responses to the original signalling messages.
5.2. Attacks Against or Using the Mapping Process 5.2. Attacks Against or Using the Mapping Process
This section describes classes of attacks involving the mapping This section describes classes of attacks involving the mapping
process that could be used to achieve the attacker goals described in process that could be used to achieve the attacker goals described in
Section 4. Section 4.
5.2.1. Attacks Against the Emergency Response System 5.2.1. Attacks Against the Emergency Response System
This section considers attacks intended to reduce the effectiveness This section considers attacks intended to reduce the effectiveness
of the emergency response system for all callers in a given area. If of the emergency response system for all callers in a given area. If
the mapping operation is disabled, then the emergency caller's device the mapping operation is disabled, then the emergency caller's device
might not have the correct PSAP URI. As a consequence, the might not have the correct PSAP URI. As a consequence, the
probability that emergency calls are routed to the wrong PSAP is probability that emergency calls will be routed to the wrong PSAP
increased. In the worst case the emergency caller's device might not increases. In the worst case, the emergency caller's device might
be able to obtain a PSAP URI at all. Routing to the wrong PSAP has a not be able to obtain a PSAP URI at all. Routing to the wrong PSAP
double consequence: emergency response to the affected calls is has a double consequence: emergency response to the affected calls is
delayed, and PSAP call taker resources outside the immediate area of delayed, and PSAP call taker resources outside the immediate area of
the emergency are consumed due to the extra effort required to the emergency are consumed due to the extra effort required to
redirect the calls. Alternatively, attacks that cause the client to redirect the calls. Alternatively, attacks that cause the client to
receive a URI that does not lead to a PSAP have the immediate effect receive a URI that does not lead to a PSAP have the immediate effect
of causing emergency calls to fail. of causing emergency calls to fail.
Three basic attacks on the mapping process can be identified: denial Three basic attacks on the mapping process can be identified: denial
of service, impersonation of the mapping server, or corruption of the of service, impersonation of the mapping server, or corruption of the
mapping database. Denial of service can be achieved in several ways: mapping database. Denial of service can be achieved in several ways:
o by a flooding attack on the mapping server; o by a flooding attack on the mapping server;
o by taking control of the mapping server and either preventing it o by taking control of the mapping server and either preventing it
from responding or causing it to send incorrect responses; or from responding or causing it to send incorrect responses; or
o by taking control of any intermediary node (for example, a router) o by taking control of any intermediary node (for example, a router)
through which the mapping queries and responses pass and using through which the mapping queries and responses pass, and then
that control to block them. An adversary may also attempt to using that control to block them. An adversary may also attempt
modify the mapping protocol signaling messages. Additionally, the to modify the mapping protocol signalling messages. Additionally,
adversary may be able to replay past communication exchanges to the adversary may be able to replay past communication exchanges
fool an emergency caller by returning incorrect results. to fool an emergency caller by returning incorrect results.
In an impersonation attack, the attacker induces the mapping client In an impersonation attack, the attacker induces the mapping client
to direct its queries to a host under the attacker's control rather to direct its queries to a host under the attacker's control rather
than the real mapping server or the attacker suppress the response than the real mapping server, or the attacker suppresses the response
from the real mapping server, and send a spoofed response. from the real mapping server and sends a spoofed response.
The former type of impersonation attack itself is an issue of mapping The former type of impersonation attack itself is an issue of mapping
server discovery rather than for the mapping protocol directly. server discovery rather than the mapping protocol directly. However,
However, the mapping protocol may allow impersonation to be detected, the mapping protocol may allow impersonation to be detected, thereby
thereby preventing acceptance of responses from an impersonating preventing acceptance of responses from an impersonating entity and
entity and possibly triggering a more secure discovery procedure. possibly triggering a more secure discovery procedure.
Corruption of the mapping database cannot be mitigated directly by Corruption of the mapping database cannot be mitigated directly by
mapping protocol design. The mapping protocol may have a role to mapping protocol design. Once corruption has been detected, the
play in analysis of which records have been corrupted, once that mapping protocol may have a role to play in determining which records
corruption has been detected. have been corrupted.
Beyond these attacks on the mapping operation itself, it is possible Beyond these attacks on the mapping operation itself, it is possible
to use mapping to attack other entities. One possibility is that to use mapping to attack other entities. One possibility is that
mapping clients are misled into sending mapping queries to the target mapping clients are misled into sending mapping queries to the target
of the attack instead of the mapping server. Prevention of such an of the attack instead of the mapping server. Prevention of such an
attack is an operational issue rather than one of protocol design. attack is an operational issue rather than one of protocol design.
Another possible attack is one where the the mapping server is Another possible attack is where the mapping server is tricked into
tricked into sending responses to the target of the attack through sending responses to the target of the attack through spoofing of the
spoofing of the source address in the query. source address in the query.
5.2.2. Attacks To Prevent a Specific Individual From Receiving Aid 5.2.2. Attacks to Prevent a Specific Individual from Receiving Aid
If an attacker wishes to deny emergency service to a specific If an attacker wishes to deny emergency service to a specific
individual the mass attacks described in Section 5.2.1 will obviously individual, the mass attacks described in Section 5.2.1 will
work provided that the target individual is within the affected obviously work provided that the target individual is within the
population. Except for the flooding attack on the mapping server, affected population. Except for the flooding attack on the mapping
the attacker can in theory limit these attacks to the target, but server, the attacker can in theory limit these attacks to the target,
this requires extra effort that the attacker is unlikely to expend. but this requires extra effort that the attacker is unlikely to
It is more likely, if the attacker is using a mass attack but does expend. If the attacker is using a mass attack but does not wish to
not wish it to have too broad an effect, that it is used for a have too broad an effect, it is more likely to attack for a carefully
carefully limited period of time. limited period of time.
If the attacker wants to be selective, however, it may make more If the attacker wants to be selective, however, it may make more
sense to attack the mapping client rather than the mapping server. sense to attack the mapping client rather than the mapping server.
This is particularly so if the mapping client is the emergency This is particularly so if the mapping client is the emergency
caller's device. The choices available to the attacker are similar caller's device. The choices available to the attacker are similar
to those for denial of service on the server side: to those for denial of service on the server side:
o a flooding attack on the mapping client; o a flooding attack on the mapping client;
o taking control of any intermediary node (for example, a router) o taking control of any intermediary node (for example, a router)
through which the mapping queries and responses pass and using through which the mapping queries and responses pass, and then
that control to block or modify them. using that control to block or modify them.
Taking control of the mapping client is also a logical possibility, Taking control of the mapping client is also a logical possibility,
but raises no issues for the mapping protocol. but raises no issues for the mapping protocol.
5.2.3. Attacks To Gain Information About an Emergency 5.2.3. Attacks to Gain Information about an Emergency
This section discusses attacks used to gain information about an This section discusses attacks used to gain information about an
emergency. The attacker may be seeking the location of the caller emergency. The attacker may be seeking the location of the caller
(e.g., to effect a criminal attack). Alternatively, the attacker may (e.g., to effect a criminal attack). Alternatively, the attacker may
be seeking information that could be used to link an individual (the be seeking information that could be used to link an individual (the
caller or someone else involved in the emergency) with embarrassing caller or someone else involved in the emergency) with embarrassing
information related to the emergency (e.g., "Who did the police take information related to the emergency (e.g., "Who did the police take
away just now?"). Finally, the attacker could be seeking to profit away just now?"). Finally, the attacker could be seeking to profit
from the emergency, perhaps by offering his or her services (e.g., from the emergency, perhaps by offering his or her services (e.g., a
news reporter, lawyer aggressively seeking new business). news reporter, or a lawyer aggressively seeking new business).
The primary information that interceptions of mapping requests and The primary information that interceptions of mapping requests and
responses will reveal are a location, a URI identifying a PSAP, the responses will reveal are a location, a URI identifying a PSAP, the
emergency service identifier, and the addresses of the mapping client emergency service identifier, and the addresses of the mapping client
and server. The location information can be directly useful to an and server. The location information can be directly useful to an
attacker if the attacker has high assurance that the observed query attacker if the attacker has high assurance that the observed query
is related to an emergency involving the target. The type of is related to an emergency involving the target. The type of
emergency (fire, police or ambulance) might also be revealed by the emergency (fire, police, or ambulance) might also be revealed by the
emergency service identifier in the mapping query. The other pieces emergency service identifier in the mapping query. The other pieces
of information may provide the basis for further attacks on emergency of information may provide the basis for further attacks on emergency
call routing, but because of the time factor, are unlikely to be call routing, but because of the time factor, are unlikely to be
applicable to the routing of the current call. However, if the applicable to the routing of the current call. However, if the
mapping client is the emergency caller's device, the attacker may mapping client is the emergency caller's device, the attacker may
gain information that allows for interference with the call after it gain information that allows for interference with the call after it
has been set up or for interception of the media stream between the has been set up or for interception of the media stream between the
caller and the PSAP. caller and the PSAP.
6. Security Requirements Relating To Emergency Marking and Mapping 6. Security Requirements Relating to Emergency Marking and Mapping
This section describes the security requirements which must be This section describes the security requirements that must be
fulfilled to prevent or reduce the effectiveness of the attacks fulfilled to prevent or reduce the effectiveness of the attacks
described in Section 5. The requirements are presented in the same described in Section 5. The requirements are presented in the same
order as the attacks. order as the attacks.
From Section 5.1: From Section 5.1:
Attack A1: fraudulent calls. Attack A1: fraudulent calls.
Requirement R1: for calls which meet conditions a) to c) of Requirement R1: For calls that meet conditions a) to c) of
Section 5.1, the service provider's call routing entity MUST verify Section 5.1, the service provider's call routing entity MUST verify
that the destination address (e.g., SIP Request-URI) presented in the that the destination address (e.g., SIP Request-URI) presented in the
call signalling is that of a PSAP. call signalling is that of a PSAP.
Attack A2: use of emergency identifier to probe in order to identify Attack A2: Use of emergency identifier to probe in order to identify
emergency call routing entities for attack by other means. emergency call routing entities for attack by other means.
Requirement: none identified, beyond the ordinary operational Requirement: None identified, beyond the ordinary operational
requirement to defend emergency call routing entities by means such requirement to defend emergency call routing entities by means such
as firewalls and, where possible, authentication and authorization. as firewalls and, where possible, authentication and authorization.
From Section 5.2.1: From Section 5.2.1:
Attack A3: flooding attack on the mapping client, mapping server, or Attack A3: Flooding attack on the mapping client, mapping server, or
a third entity. a third entity.
Requirement R2: The mapping protocol MUST NOT create new Requirement R2: The mapping protocol MUST NOT create new
opportunities for flooding attacks, including amplification attacks. opportunities for flooding attacks, including amplification attacks.
Attack A4: insertion of interfering messages. Attack A4: Insertion of interfering messages.
Requirement R3: The protocol MUST permit the mapping client to verify Requirement R3: The protocol MUST permit the mapping client to verify
that the response it receives is responding to the query it sent out. that the response it receives is responding to the query it sent out.
Attack A5: man-in-the-middle modification of messages. Attack A5: Man-in-the-middle modification of messages.
Requirement R4: The mapping protocol MUST provide integrity Requirement R4: The mapping protocol MUST provide integrity
protection of requests and responses. protection of requests and responses.
Requirement R5: The mapping protocol or the system within which the Requirement R5: The mapping protocol or the system within which the
protocol is implemented MUST permit the mapping client to protocol is implemented MUST permit the mapping client to
authenticate the source of mapping responses. authenticate the source of mapping responses.
Attack A6: impersonation of the mapping server. Attack A6: Impersonation of the mapping server.
Requirement R6: the security considerations for any discussion of Requirement R6: The security considerations for any discussion of
mapping server discovery MUST address measures to prevent mapping server discovery MUST address measures to prevent
impersonation of the mapping server. impersonation of the mapping server.
Requirement R5 also follows from this attack. Requirement R5 also follows from this attack.
Attack A7: corruption of the mapping database. Attack A7: Corruption of the mapping database.
Requirement R7: the security considerations for the mapping protocol Requirement R7: The security considerations for the mapping protocol
MUST address measures to prevent database corruption by an attacker. MUST address measures to prevent database corruption by an attacker.
Requirement R8: the protocol SHOULD include information in the Requirement R8: The protocol SHOULD include information in the
response that allows subsequent correlation of that response with response that allows subsequent correlation of that response with
internal logs that may be kept on the mapping server, to allow internal logs that may be kept on the mapping server, to allow
debugging of mis-directed calls. One example of a way to meet this debugging of mis-directed calls.
requirement would be by means of an opaque parameter in the returned
URI.
From Section 5.2.2: no new requirements. From Section 5.2.2: No new requirements.
From Section 5.2.3: From Section 5.2.3:
Attack A8: snooping of location and other information. Attack A8: Snooping of location and other information.
Requirement R9: the protocol and the system within which it is Requirement R9: The protocol and the system within which it is
implemented MUST maintain confidentiality of the request and implemented MUST maintain confidentiality of the request and
response. response.
7. Security Considerations 7. Security Considerations
This document addresses security threats and security requirements. This document addresses security threats and security requirements.
Therefore, security is considered throughout this document. Therefore, security is considered throughout this document.
8. IANA Considerations 8. Acknowledgements
This document does not require actions by the IANA.
9. Acknowledgements
The writing of this document has been a task made difficult by the The writing of this document has been a task made difficult by the
temptation to consider the security concerns of the entire personal temptation to consider the security concerns of the entire personal
emergency calling system, not just the specific pieces of work within emergency calling system, not just the specific pieces of work within
the scope of the ECRIT Working Group. Hannes Tschofenig performed the scope of the ECRIT Working Group. Hannes Tschofenig performed
the initial security analysis for ECRIT, but it has been shaped since the initial security analysis for ECRIT, but it has been shaped since
then by the comments and judgement of the ECRIT WG at large. At an then by the comments and judgement of the ECRIT WG at large. At an
earlier stage in the evolution of this document, Stephen Kent of the earlier stage in the evolution of this document, Stephen Kent of the
Security Directorate was asked to review it and provided extensive Security Directorate was asked to review it and provided extensive
comments which led to a complete rewriting of it. Brian Rosen, Roger comments, which led to a complete rewriting of it. Brian Rosen,
Marshall, Andrew Newton, and most recently, Spencer Dawkins, Kamran Roger Marshall, Andrew Newton, and most recently, Spencer Dawkins,
Aquil, and Ron Watro have also provided detailed reviews of this Kamran Aquil, and Ron Watro have also provided detailed reviews of
document at various stages. The authors thank them. this document at various stages. The authors thank them.
We would like to thank the Donald Eastlake for his review on behalf We would like to thank Donald Eastlake for his review on behalf of
of the Security Area Directorate and Christian Vogt for his review as the Security Area Directorate and Christian Vogt for his review as
part of the General Area Review Team. part of the General Area Review Team.
Finally, we would like to think Jari Arkko, Jon Peterson, and Russ Finally, we would like to thank Jari Arkko, Jon Peterson, and Russ
Housley for their IETF Last Call comments. Housley for their IETF Last Call comments.
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References 9.2. Informative References
[I-D.ietf-ecrit-requirements]
Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-13 (work in progress),
March 2007.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for
Emergency Context Resolution with Internet Technologies",
RFC 5012, January 2008.
Authors' Addresses Authors' Addresses
Tom Taylor (editor) Tom Taylor (editor)
Nortel Nortel
1852 Lorraine Ave 1852 Lorraine Ave
Ottawa, Ontario K1H 6Z8 Ottawa, Ontario K1H 6Z8
Canada Canada
Email: tom.taylor@rogers.com EMail: tom.taylor@rogers.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Hannes.Tschofenig@nsn.com EMail: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
New York, NY 10027 New York, NY 10027
US US
Phone: +1 212 939 7004 Phone: +1 212 939 7004
Email: hgs+ecrit@cs.columbia.edu EMail: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu URI: http://www.cs.columbia.edu
Murugaraj Shanmugam Murugaraj Shanmugam
Detecon International GmbH Detecon International GmbH
Oberkasseler str 2 Oberkasseler str 2
Bonn, NRW 53227 Bonn, NRW 53227
Germany Germany
Email: murugaraj.shanmugam@detecon.com EMail: murugaraj.shanmugam@detecon.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 18, line 44 skipping to change at line 525
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 65 change blocks. 
204 lines changed or deleted 157 lines changed or added

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