ECRIT                                                      H. Tschofenig
Internet-Draft                                                   Siemens
Expires: August 18, 2006                                  H. Schulzrinne
                                                             Columbia U.
                                                            M. Shanmugam
                                                                 Siemens
                                                               T. Taylor
                                                                  Nortel
                                                       February 14, 2006


      Security Threats and Requirements for Emergency Call Mapping
               draft-taylor-ecrit-security-threats-02.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 August 18, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document reviews the security threats to the process of mapping
   locations to URIs pointing to Public Safety Answering Points (PSAPs).
   This mapping occurs as part of the process of routing emergency calls



Tschofenig, et al.       Expires August 18, 2006                [Page 1]


Internet-Draft         ECRIT Security Requirements         February 2006


   through the IP network.  Based on the threats, this document
   establishes a set of security requirements for the mapping protocol,
   which is being developed by the ECRIT Working Group.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Mapping and the emergency call routing process . . . . . . . .  5
   4.  Motivations of attackers . . . . . . . . . . . . . . . . . . .  6
   5.  Potential attacks  . . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Attacks to prevent a specific individual from
           receiving aid  . . . . . . . . . . . . . . . . . . . . . .  7
     5.2.  Attacks to gain information about an emergency . . . . . .  7
     5.3.  Attacks to gain fraudulent use of ASP/VSP services . . . .  8
     5.4.  Attacks against the emergency response system  . . . . . .  9
   6.  Security requirements relating to emergency call routing . . . 10
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     10.2. Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16

























Tschofenig, et al.       Expires August 18, 2006                [Page 2]


Internet-Draft         ECRIT Security Requirements         February 2006


1.  Introduction

   Legacy telephone network (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.  With the
   introduction of IP-based telephony and multimedia services, support
   for emergency calling via the Internet also has to be provided.  As
   one of the steps to achieve this, a protocol must be developed
   allowing a client entity to submit a location and receive a URI
   pointing to the applicable PSAP for that location.

   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 mapping of
   locations to PSAP URIs.

   This document is organized as follows: Section 2 describes basic
   terminology.  Section 3 briefly describes how mapping fits within the
   process of routing emergency calls.  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 August 18, 2006                [Page 3]


Internet-Draft         ECRIT Security Requirements         February 2006


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], with the
   qualification that unless otherwise stated they apply to the design
   of the mapping protocol, not its implementation or application.

   Application (Voice) Service Provider (ASP/VSP), mapping service,
   emergency address, emergency caller, emergency identifier, mapping,
   mapping client, mapping server, mapping protocol, and Public Safety
   Answering Point (PSAP) are taken from [I-D.ecrit-requirements].

   Location information is 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 a residential gateway
   controlled by a softswitch.






























Tschofenig, et al.       Expires August 18, 2006                [Page 4]


Internet-Draft         ECRIT Security Requirements         February 2006


3.  Mapping and the emergency call routing process

   The first goal of emergency call routing is to ensure that any
   emergency call is routed to a PSAP.  Preferably the call is routed to
   the PSAP responsible for the caller's location, since misrouting
   consumes valuable time while the call taker locates and forwards the
   call to the right PSAP.  As described in [I-D.ecrit-requirements],
   mapping is part of the process of achieving this preferable outcome.

   In brief, mapping involves a mapping client, a mapping server, and
   the protocol that passes between them.  The protocol allows the
   client to pass location information to the mapping server and 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 constrains 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 device that acquires the
   location information can be the mapping client, and so can 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.

























Tschofenig, et al.       Expires August 18, 2006                [Page 5]


Internet-Draft         ECRIT Security Requirements         February 2006


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.  One interesting variant on
   the "system denial" motivation is the case where a victim of a large
   emergency hopes to gain faster service by blocking others' competing
   calls for help.




























Tschofenig, et al.       Expires August 18, 2006                [Page 6]


Internet-Draft         ECRIT Security Requirements         February 2006


5.  Potential attacks

   This section describes classes of attacks on the mapping process 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 operate against the
   operation of the mapping protocol, or through impersonation of the
   mapping server.  It is also possible that the mapping protocol is
   used indirectly to interfere with other aspects of the emergency call
   process.

   The basic attacks available against protocol operation are denial of
   service, interference through message insertion, and interference
   through man-in-the middle alteration of messages.  Denial of service
   can be achieved in several ways: by flooding attacks on the client or
   server, by taking control of the mapping client, by installing
   filters on the channel, or by installing filters at the mapping
   server.  Man-in-the-middle attacks also involve taking control of the
   channel or the mapping server.

   The attacks based on control of the mapping server can also be
   carried out using impersonation of the mapping server.  This may be
   an easier attack to execute in some circumstances.

   The mapping protocol may also be used to support a reflection attack
   on the mapping client or on some other component of the routing
   chain.  To execute this attack, the attacker impersonates the target
   when sending requests to the mapping server.

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



Tschofenig, et al.       Expires August 18, 2006                [Page 7]


Internet-Draft         ECRIT Security Requirements         February 2006


   reporter, "ambulance chaser").

   The primary information that interceptions of mapping requests and
   responses will reveal are a location, a URI identifying a PSAP, and
   the addresses of the mapping client and server.  The location
   information can be directly useful to an attacker if the attacker has
   high assurance that the observed query is related to an emergency
   involving the target.  The other pieces of information may provide
   the basis for further attacks on emergency call routing, but because
   of the time factor, are unlikely to be applicable to the routing of
   the current call.  However, if the mapping client is the emergency
   caller's device, the attacker may gain information that allows for
   interference with the call after it has been set up or interception
   of the media stream between the caller and the PSAP.

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.
   An attack of this sort is possible only if the following conditions
   are true:

   a.  The attacker is the emergency caller.

   b.  The attacker has control over the addressing of the emergency
       call request either as a result of or subsequent to the mapping
       operation.

   c.  The call enters the domain of an ASP/VSP, which accepts it
       without applying normal requirements for an authenticated
       subscriber identity because it is marked as an emergency call.

   d.  The ASP/VSP routes it according to the called address (e.g., SIP
       Request-URI), without verifying that this is the address of a
       PSAP.

   The key condition is the second one.  The attacker has two
   possibilities for controlling the addressing of the call.  One is to
   insert a false entry into the mapping database for the caller's
   location, allowing the caller free calls to wherever the entry points
   to.  The second possibility comes if the emergency caller's device is
   the mapping client.  In this case, if the caller reprograms the
   device to accept an arbitrary input in place of the URI returned by
   the mapping process, the caller is able to complete a call to that
   URI while bypassing the ASP/VSP's normal authentication procedures.






Tschofenig, et al.       Expires August 18, 2006                [Page 8]


Internet-Draft         ECRIT Security Requirements         February 2006


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 possible attacks on the mapping process to achieve this have
   already been described; they simply have to be less targeted.  The
   attacks are denial of service or misdirection through provision of
   incorrect responses to mapping queries.  The mechanisms are flooding
   attacks (for denial of service only), control of the Mapping Server,
   or impersonation of the Mapping Server.






































Tschofenig, et al.       Expires August 18, 2006                [Page 9]


Internet-Draft         ECRIT Security Requirements         February 2006


6.  Security requirements relating to emergency call routing

   This section describes the security requirements which must be
   fulfilled in the mapping protocol to prevent or blunt the
   effectiveness of the attacks described in the previous section.

   Attack: flooding attack on the mapping client, mapping server, or a
   third entity.

   Requirement: The mapping protocol MUST NOT create new opportunities
   for flooding attacks, including amplification attacks.

   Attack: insertion of interfering messages.

   Requirement: The protocol MUST permit the mapping client to verify
   that the response is a response to the query it sent out.

   Attack: man-in-the-middle alteration of messages.

   Requirement: The protocol MUST permit the application of the
   integrity service to requests and responses as an implementation
   option.

   Attack: impersonation of the mapping server.

   Requirement: the protocol MUST permit the mapping client to
   authenticate the mapping server as an implementation option.

   Attack: snooping of location and other information.

   Requirement: the protocol MUST permit the use of the confidentiality
   service as an implementation option.

   Attack: fraudulent calls.

   Requirement: the protocol MUST permit the reverse lookup of URIs to
   verify that a URI corresponds to a PSAP in the mapping database.

      Note - the necessity to use this capability depends on whether the
      system architecture satisfies the conditions listed in
      Section 5.3.  If the emergency caller's device is not the mapping
      client, the opportunity for fraud is very much limited.









Tschofenig, et al.       Expires August 18, 2006               [Page 10]


Internet-Draft         ECRIT Security Requirements         February 2006


7.  Security Considerations

   This document addresses security threats and security requirements.
   Therefore, security is considered throughout this document.















































Tschofenig, et al.       Expires August 18, 2006               [Page 11]


Internet-Draft         ECRIT Security Requirements         February 2006


8.  Acknowledgements

   Hannes Tschofenig performed the initial security analysis for ECRIT.
   The authors would like to thank Stephen Kent for his extensive
   comments on previous issues of this document, which led to a complete
   rewriting of it.













































Tschofenig, et al.       Expires August 18, 2006               [Page 12]


Internet-Draft         ECRIT Security Requirements         February 2006


9.  IANA Considerations

   This document does not require actions by the IANA.
















































Tschofenig, et al.       Expires August 18, 2006               [Page 13]


Internet-Draft         ECRIT Security Requirements         February 2006


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",
              February 2006.

   [RFC3693]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
              J. Polk, "Geopriv Requirements", RFC 3693, February 2004.



































Tschofenig, et al.       Expires August 18, 2006               [Page 14]


Internet-Draft         ECRIT Security Requirements         February 2006


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 August 18, 2006               [Page 15]


Internet-Draft         ECRIT Security Requirements         February 2006


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 (2006).  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 August 18, 2006               [Page 16]