[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 draft-ietf-ecrit-security-threats

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]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/