draft-ietf-ecrit-security-threats-04.txt   draft-ietf-ecrit-security-threats-05.txt 
ECRIT T. Taylor ECRIT T. Taylor, Ed.
Internet-Draft (Editor) Nortel Internet-Draft Nortel
Expires: October 18, 2007 H. Tschofenig Expires: February 22, 2008 H. Tschofenig
Siemens Nokia Siemens Networks
H. Schulzrinne H. Schulzrinne
Columbia U. Columbia University
M. Shanmugam M. Shanmugam
Siemens Detecon
April 16, 2007 August 21, 2007
Security Threats and Requirements for Emergency Call Marking and Mapping Security Threats and Requirements for Emergency Call Marking and Mapping
draft-ietf-ecrit-security-threats-04.txt draft-ietf-ecrit-security-threats-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 18, 2007. This Internet-Draft will expire on February 22, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document reviews the security threats associated with: This document reviews the security threats associated with the
marking of signalling messages to indicate that they are related to
o the marking of signalling messages to indicate that they are an emergency, and the process of mapping from locations to Universal
related to an emergency; and Resource Identifiers (URIs) pointing to Public Safety Answering
Points (PSAPs). This mapping occurs as part of the process of
o the process of mapping from locations to Universal Resource routing emergency calls through the IP network.
Identifiers (URIs) pointing to Public Safety Answering Points
(PSAPs). This mapping occurs as part of the process of 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Marking, Mapping, and the Emergency Call Routing Process . . . 5 3. Marking, Mapping, and the Emergency Call Routing Process . . . 5
skipping to change at page 3, line 28 skipping to change at page 3, line 28
client entity to submit a location and receive a URI pointing to the client entity to submit a location and receive a URI pointing to the
applicable PSAP for that location. applicable PSAP for that location.
Attacks against the PSTN have taken place for decades. The Internet Attacks against the PSTN have taken place for decades. The Internet
is seen as an even more hostile environment. Thus it is important to is seen as an even more hostile environment. Thus it is important to
understand the types of attacks that might be mounted against the understand the types of attacks that might be mounted against the
infrastructure providing emergency services, and to develop security infrastructure providing emergency services, and to develop security
mechanisms to counter those attacks. While this can be a broad mechanisms to counter those attacks. While this can be a broad
topic, the present document restricts itself to attacks on the topic, the present document restricts itself to attacks on the
mapping of locations to PSAP URIs and attacks based on emergency mapping of locations to PSAP URIs and attacks based on emergency
marking. marking. Verification of the truthfulness of a reported incident by
the PSAP operator and various other attacks against the PSAP
infrastructure related to the usage of faked 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, emergency
identifier, mapping, mapping client, mapping server, mapping identifier, mapping, mapping client, mapping server, mapping
protocol, and Public Safety Answering Point (PSAP) are taken from protocol, and Public Safety Answering Point (PSAP) are taken from
[I-D.ecrit-requirements]. [I-D.ietf-ecrit-requirements].
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.
skipping to change at page 5, line 24 skipping to change at page 5, line 24
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 to
the PSAP responsible for the caller's location, since misrouting 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 [I-D.ecrit-requirements], call to the right PSAP. As described in
mapping is part of the process of achieving this preferable outcome. [I-D.ietf-ecrit-requirements], mapping is part of the process of
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. PSAP.
Since mapping requires location information for input, when and where Since mapping requires location information for input, when and where
the location information is acquired imposes constraints upon when the location information is acquired imposes constraints upon when
mapping can be done and which devices can act as mapping clients. mapping can be done and which devices can act as mapping clients.
skipping to change at page 6, line 22 skipping to change at page 6, line 22
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 responders to non-emergency sites. This memo o to divert emergency calls to non-emergency sites. This is a form
has not identified any attacks within its intended scope that of denial of service attack similar to the first item but quite
achieve this objective, so it will not be mentioned further. likely more confusing for the caller itself since it expects to
talk to a PSAP operator but instead gets 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
skipping to change at page 12, line 27 skipping to change at page 12, line 27
debugging of mis-directed calls. One example of a way to meet this debugging of mis-directed calls. One example of a way to meet this
requirement would be by means of an opaque parameter in the returned requirement would be by means of an opaque parameter in the returned
URI. 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 or 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. IANA Considerations
skipping to change at page 16, line 5 skipping to change at page 15, line 20
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, Roger
Marshall, Andrew Newton, and most recently, Spencer Dawkins, Kamran Marshall, Andrew Newton, and most recently, Spencer Dawkins, Kamran
Aquil, and Ron Watro have also provided detailed reviews of this Aquil, and Ron Watro have also provided detailed reviews of this
document at various stages. The authors thank them. document at various stages. The authors thank them.
We would like to thank the Donald Eastlake for his review on behalf
of the Security Area Directorate and Christian Vogt for his review as
part of the General Area Review Team.
Finally, we would like to think Jari Arkko, Jon Peterson, and Russ
Housley for their IETF Last Call comments.
10. References 10. References
10.1. Normative References 10.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 10.2. Informative References
[I-D.ecrit-requirements] [I-D.ietf-ecrit-requirements]
Schulzrinne, H. and R. Marshall, "Requirements for Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies", Emergency Context Resolution with Internet Technologies",
March 2006. 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.
Authors' Addresses Authors' Addresses
Tom Taylor Tom Taylor (editor)
Nortel Nortel
1852 Lorraine Ave 1852 Lorraine Ave
Ottawa, Ontario K1H 6Z8 Ottawa, Ontario K1H 6Z8
Canada Canada
Email: taylor@nortel.com Email: tom.taylor@rogers.com
Hannes Tschofenig Hannes Tschofenig
Siemens Nokia Siemens Networks
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bayern 81739 Munich, Bavaria 81739
Germany Germany
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@nsn.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
USA US
Phone: +1 212 939 7042 Phone: +1 212 939 7004
Email: schulzrinne@cs.columbia.edu Email: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs URI: http://www.cs.columbia.edu
Murugaraj Shanmugam Murugaraj Shanmugam
Siemens Detecon International GmbH
Otto-Hahn-Ring 6 Oberkasseler str 2
Munich, Bayern 81739 Bonn, NRW 53227
Germany Germany
Email: murugaraj.shanmugam@siemens.com Email: murugaraj.shanmugam@detecon.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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
 End of changes. 23 change blocks. 
41 lines changed or deleted 53 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/