[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
ECRIT                                                      H. Tschofenig
Internet-Draft                                                   Siemens
Expires: November 10, 2005                                H. Schulzrinne
                                                             Columbia U.
                                                            M. Shanmugam
                                                                    TUHH
                                                             May 9, 2005


        Security Threats and Requirements for Emergency Calling
             draft-tschofenig-ecrit-security-threats-00.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 November 10, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   With the increasing interest to replace parts of the public switched
   telephone network (PSTN) with its IP-based counterpart the
   functionality of emergency services also needs to be offered using
   IP-based technologies.  Since the PSTN and the Internet follow
   different design principles, their architecture is quite different.



Tschofenig, et al.      Expires November 10, 2005               [Page 1]


Internet-Draft       Threats and Req. for Emergency             May 2005


   This fact has to be considered and security threats for an IP-based
   emergency environment have to be re-evaluated.  This document
   investigates the potential threats for the end hosts and the
   infrastructure that aims to support emergency services.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Basic Actors . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Security Threats . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1   Denial of Service Attacks  . . . . . . . . . . . . . . . .  8
     4.2   Call Identity Spoofing . . . . . . . . . . . . . . . . . .  8
     4.3   Location Spoofing  . . . . . . . . . . . . . . . . . . . .  9
     4.4   Impersonating a PSAP . . . . . . . . . . . . . . . . . . .  9
     4.5   Signaling Message Modification . . . . . . . . . . . . . . 10
     4.6   Modification of the Emergency Call . . . . . . . . . . . . 10
     4.7   Loss of confidentiality  . . . . . . . . . . . . . . . . . 10
     4.8   Replay Attack  . . . . . . . . . . . . . . . . . . . . . . 10
     4.9   Corrupting Configuration Information . . . . . . . . . . . 11
   5.  Security Requirements  . . . . . . . . . . . . . . . . . . . . 12
     5.1   Denial of Service Attacks  . . . . . . . . . . . . . . . . 12
     5.2   Call Identity Spoofing . . . . . . . . . . . . . . . . . . 13
     5.3   Location Spoofing  . . . . . . . . . . . . . . . . . . . . 13
     5.4   Impersonating a PSAP . . . . . . . . . . . . . . . . . . . 15
     5.5   Signaling Message Modification . . . . . . . . . . . . . . 15
     5.6   Replay Attack  . . . . . . . . . . . . . . . . . . . . . . 16
     5.7   Loss of confidentiality  . . . . . . . . . . . . . . . . . 16
     5.8   Modification of the Emergency Call . . . . . . . . . . . . 16
     5.9   Corrupting Configuration Information . . . . . . . . . . . 16
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     7.1   Normative References . . . . . . . . . . . . . . . . . . . 19
     7.2   Informative References . . . . . . . . . . . . . . . . . . 19
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
       Intellectual Property and Copyright Statements . . . . . . . . 20















Tschofenig, et al.      Expires November 10, 2005               [Page 2]


Internet-Draft       Threats and Req. for Emergency             May 2005


1.  Introduction

   This document provides an overview of security mechanisms and
   motivations for using them in the VoIP-based emergency services.
   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 in Europe).  With the introduction of IP-based
   telephony support for emergency service also has to be provided.  A
   number of protocols and protocol extensions need to interwork in
   order to provide emergency functionality.

   Since the Internet is hostile place, it is important to understand
   the security threats for emergency services.  Otherwise, an adversary
   can use the infrastructure to place fraudulent calls, mount denial of
   service attacks, etc.

   This document focuses on the security threats and security
   requirements for the IP-based emergency service infrastructure only
   without interaction with PSTN infrastructure elements.

   A few discussions within this document are related to emergency
   handling but solutions will not be developed as part of the ECRIT
   working group.  Hence, the are included mainly for completeness and
   to point to the need to investigate additional aspects.  Depending on
   the chosen protocols (for the emergency call itself, for directory
   access related to emergency call routing, for obtaining location
   information from the network, etc.) various solutions might also
   already be available to fulfill these security requirements and to
   address the threats appropriately.

   This document is organized as follows: Section 2 describes basic
   terminology, Section 4 illustrates security threats and Section 5
   lists security requirements.


















Tschofenig, et al.      Expires November 10, 2005               [Page 3]


Internet-Draft       Threats and Req. for Emergency             May 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].

   Emergency Caller, Public Safety Answering Point (PSAP), Access
   Infrastructure Provider, Application (Voice) Service Provider,
   Emergency Call Taker, etc. is taken from [I-D.schulzrinne-ecrit-
   requirements].

   Additionally, we use the following terms throughout the document:

   Emergency Call Routing Support: This term refers to entities that
      route the emergency call to the appropriate PSAP based on
      information like location information, language, etc.  If SIP is
      used as a protocol for session setup and call routing, for
      example, then this entity would correspond to a SIP proxy.

   Directory: This entity refers to a distributed directory protocol.
      DNS is one example of such as distributed directory but there are
      other protocols that might fulfill the requirements listed in
      [I-D.schulzrinne-ecrit-requirements] for such a protocol.

   Asserted Location Information: The term asserted location information
      refers to the property that the recipient of such an object is
      able to verify that it was generated by a particular party that is
      authorized todo so.























Tschofenig, et al.      Expires November 10, 2005               [Page 4]


Internet-Draft       Threats and Req. for Emergency             May 2005


3.  Basic Actors

   In order to support emergency services covering a large physical area
   various infrastructure elements are necessary: Access Infrastructure
   Providers, Application (Voice) Service Provider, PSAPs as endpoints
   for emergency calls, directory services or other infrastructure
   elements that assist in during the call routing and potentially many
   other entities.

   This section outlines which entities will be considered in the threat
   analysis and shows the high level architecture.


      Location
      Information     +-----------------+
          |(1)        |Access           |   +-----------+
          v           |Infrastructure   |   |           |
     +-----------+    |Provider         |   | Directory |
     |           |    | (3)             |   |           |
     | Emergency |<---+-----------------+-->|           |
     | Caller    |    | (2)             |   +-----------+
     |           |<---+-------+         |          ^
     +-----------+    |  +----|---------+------+   |
          ^           |  |   Location   |      |   |
          |           |  |   Information<-+    |   |
          |           +--+--------------+ |(8) |   | (5)
          |              |    +-----------v+   |   |
          |   (4)        |    |Emergency   |   |   |
          +--------------+--->|Call Routing|<--+---+
          |              |    |Support     |   |
          |              |    +------------+   |
          |              |       ^             |
          |              |   (6) |        +----+--+
          |    (7)       |       +------->|       |
          +--------------+--------------->| PSAP  |
                         |                |       |
                         |Application     +----+--+
                         |(Voice)              |
                         |Service              |
                         |Provider             |
                         +---------------------+

                            Figure 1: Framework

   Figure 1 shows the interaction between the entities involved in the
   call.  There are a number of different deployment choices, as it can
   be easily seen from the figure.  The following deployment choices
   need to be highlighted:



Tschofenig, et al.      Expires November 10, 2005               [Page 5]


Internet-Draft       Threats and Req. for Emergency             May 2005


   o  How is location information provided to the end host?  It might
      either be known to the end host itself (due to manual
      configuration or provided via GPS) or available via a third party.
      Even if location information is known to the network it might be
      made available to the end host.  Alternatively, location
      information is used as part of call routing and inserted by
      intermediaries.

   o  Is the Access Infrastructure Provider also the Application (Voice)
      Service Provider?  In the Internet today these roles are typically
      provided by different entities.  As a consequence, the Application
      (Voice) Service Provider is typically not able to learn the
      physical location of the Emergency Caller.

   Please note that the overlapping squares aim to indicate that certain
   functionality can be collapsed into a single entity.  As an example,
   the Application (Voice) Service Provider might be the same entity as
   the Access Infrastructure Provider and they might also operate the
   PSAP.  There is, however, no requirement that this must be the case.
   Additionally it is worth pointing out that end systems might be its
   own VoSP, e.g., for enterprises or residential users.

   Below, we describe various interactions between the entities shown in
   Figure 1 are described:

   o  (1) Location information might be available to the end host
      itself.

   o  (2) Location information might, however, also be obtained from the
      Access Infrastructure Provider (e.g., using DHCP or application
      layer signaling protocols).

   o  (3) The Emergency Caller might need to consult a directory to
      determine the PSAP that is appropriate for the physical location
      of the emergency caller (and considering other attributes such as
      a certain language support by the Emergency Call Takers).

   o  (4) The Emergency Caller might get assistance for emergency call
      routing by infrastructure elements (referred as Emergency Call
      Routing Support entities).  In case of SIP these enities are
      proxies.

   o  (5) Individual Emergency Call Routing Support entities might need
      to consult a directory to determine where to route the emergency
      call.

   o  (6) The Emergency Call Routing Support entities need to finally
      forward the call, if infrastructure based emergency call routing



Tschofenig, et al.      Expires November 10, 2005               [Page 6]


Internet-Draft       Threats and Req. for Emergency             May 2005


      is used.

   o  (7) The emergency caller might interact directly with the PSAP
      without any Emergency Call Routing Support entities.















































Tschofenig, et al.      Expires November 10, 2005               [Page 7]


Internet-Draft       Threats and Req. for Emergency             May 2005


4.  Security Threats

   This section discusses various security threats related to emergency
   call handling.

4.1  Denial of Service Attacks

   A (distributed) denial-of-service attack (DoS attack) on a PSAP, for
   example, might make the PSAP unreachable for emergency calls.  Since
   a particular PSAP is responsible for a certain geopraphical area, the
   entire area might be affected (if no other backup PSAP is available).
   DoS attacks might appear in many different flavors ranging from
   standard SYN flooding attacks to attacks where a human operator is
   involved and needs to determine whether a call is in fact a true
   emergency call.  In some cases this might lead the case where the
   emergency staff (police, ambulance, etc.) might need to rush to the
   indicated emergency scene (potentionally an arbitrary location) and
   will therefore not be available for other rescue assignments during
   that time.

   As such, PSAPs can be seen as a particularly valuable target since
   the consequences of an unreachable PSAP has severe consequences.

   Attacks against the routing infrastructure enables an adversary to
   prevent all nodes attached to this network to sent emergency calls.
   Attacks against entities that assist in the call routing (such as
   attacks against the directory service) might make it difficult or
   impossible for emergency call to reach its intended PSAP.

4.2  Call Identity Spoofing

   If an adversary is able to make emergency calls without the need to
   disclose its identity (such as a SIP URI or NAI) then prank calls
   cannot be traced back.  If the call is proxy-routed, the PSAP will
   not see the IP address of the caller in signaling.  Additionally, it
   might be necessary for the Emergency Call Taker to initiate a voice,
   video or instant messaging exchange towards the Emergency Caller.

   Trying to find an adversary that placed a crank call is difficult if
   somebody uses an open 802.11 access point, even if you can find the
   owner of that access point.  This problem is no different than
   somebody placing an emergency call from a payphone.

   If the adversary is never authenticated (neither to the PSAP nor to
   the Access Infrastructure Provider) then it is possible to trace the
   call back to a make a particular entity accountable.

   A standard requirement for emergency systems is that emergency calls



Tschofenig, et al.      Expires November 10, 2005               [Page 8]


Internet-Draft       Threats and Req. for Emergency             May 2005


   must also be placed in absence of any authentication.  An adversary
   will typically exploit these weaknesses and he will always find
   networks that do not perform network access authentication of the
   user prior to providing network access.  As such, the emergency
   infrastructure cannot neither rely on network access authentication
   nor on authentication of the caller towards the PSAP or the
   Application (Voice) Service Provider.

   It is necessary to point to the fact that authentication in the
   emergency case might require the authorization procedure to be
   skipped.  For example, in an emergency case it is still possible to
   authenticate the user of an emergency call but without considering
   that its credits are exhausted.

4.3  Location Spoofing

   An adversary might want to made-up faked location information in
   order to fool the emergency personnel.  This is made particularly
   easy if the location information is provided by the Emergency Caller
   either via manual configuration or via GPS.  Spoofing is more
   difficult if an entity proving Emergency Call Routing Support inserts
   location information into emergency call signaling.  In this case the
   adversary needs to route the call via some intermediaries.  This is
   possible since these devices are often, by their nature as IP
   devices, addressable from an arbitary physical location.  The usage
   of VPN (or other tunneling mechanisms) and proxies further
   complicates the ability to infer the physical location from the IP
   address seen by the PSAP.

4.4  Impersonating a PSAP

   An adversary might pretend to operate a PSAP.  When either an end
   host or an intermediate device wants to determine the PSAP that is
   responsible for a particular geographical area by sending a query to
   the directory an adversary might return a faked response.  Returning
   an incorrect response message does not require the adversary to be
   somewhere along the path.  It is sufficient for an adversary to be
   located in a broadcast medium and the adversary has to reply as soon
   as a query is observed (if no security protection is utilized).  If
   the response indicates a legitimate but inappropriate (i.e., a PSAP
   that is authoritive for a different geographical area) then the
   emergency call interaction will be able to continue but will suffer
   from delays until the emergency call can be forwarded to the correct
   PSAP, potentially involving human interation (by the Emergency Call
   Taker).






Tschofenig, et al.      Expires November 10, 2005               [Page 9]


Internet-Draft       Threats and Req. for Emergency             May 2005


4.5  Signaling Message Modification

   An adversary that is located along the signaling path might modify
   the content of emergency calls, such as location information or
   identity information.  This might lead to a denial of service attack
   against the emergency personell, disruption of the emergency call,
   delayed call setup, etc.

   An adversary might want to inject signaling messages to terminate or
   redirect the call to another location.  Dropping or delaying
   signaling messages is also possible for an on-path adversary.

   Depending on the capability of the signaling protocol the range of
   possible attacks might have been documented already.

4.6  Modification of the Emergency Call

   An adversary along the media path might want to modify the data
   traffic part of the emergency call (voice, video or instant message).
   An attacker can change the message on-the-fly and fool the PSAP to
   receive meaningless or bogus messages.  The response messages to
   Emergency Caller might also be subject to change, for example by
   injecting a recorded failure message.

4.7  Loss of confidentiality

   An adversary might eavesdrop an emergency call and use the
   information to future sessions as part of replay attacks.  The
   ability to eavesdrop also allows to learn details about the emergency
   situation which might be of interest for the press or other media
   organizations.  Please note that the location of the adversary is
   important regarding the eavesdropped area.  For example, an adversary
   in a WLAN is typically able to see a small amount of traffic due to
   the coverage area of typical WLAN network.

   Reavealing the true identity of the user as part of the privacy
   override mechanism might conflict with the users privacy settings.

4.8  Replay Attack

   An adversary might want to use eavesdropped information to mount
   attacks in the future.  This might be necessary if information cannot
   be re-created by the adversary (for example, asserted location
   information).  The ability to replay messages or individual objects
   the specific property of these messages and objects is important.
   For example, asserted location information might bind location
   information and a timestamp with a digital signature together that
   makes it difficult to reuse this object beyonds its lifetime.



Tschofenig, et al.      Expires November 10, 2005              [Page 10]


Internet-Draft       Threats and Req. for Emergency             May 2005


   [Editor's Note: It is sometimes hard to tell what are real threats
   and what security threats are addressed already by certain solutions
   outside the scope of the working group.  Addressing all standard
   security threats is a long process if certain mechanisms are required
   in an case that largely or completely mitigate against these
   threats.]

4.9  Corrupting Configuration Information

   An adversary might overide all locally configured emergency numbers.
   This might be particular problematic if these emergency numbers are
   dynamically retrieved using some mechanisms.  As such, an Emergency
   Caller would start a call that either leads to a blackhole (as such
   it is a DoS attack), the Emergency Caller connects to a rogue PSAP or
   to an inappropriate PSAP.




































Tschofenig, et al.      Expires November 10, 2005              [Page 11]


Internet-Draft       Threats and Req. for Emergency             May 2005


5.  Security Requirements

   [Editor's Note: A few requirements below are already addressed by a
   number of requirements and solution specific documents today.  In
   order to keep the document short it would be reasonable to focus only
   on the difficult security threats and requiremens for emergency calls
   rather than enumerating everything that could happen to an emergency
   call.  The working group should decide how to proceed with this
   particular issue and what threats and requirements should be
   elaborated in more detail.]

   Compiling security requirements to address the threats listed in the
   previous section might is impacted by several constraints:

      Security mechanisms may lead to a certain performance overhead
      (e.g., several roundtrips).

      A certain security infrastructure is required that might lead to
      deployment problems.  For example, end user certificates,
      certificates for networks, usage of authorization certificate,
      etc. might need to be deployed before any of these mechanisms are
      useful.

      Many of these aspects are related to regulatory and legal
      requirements that may vary from country to country.  Typically,
      these mechanisms cannot be mandated by an IETF specification.

      Some of the requirements impose solutions that are out-of-scope of
      the ECRIT working group.

   Given the above-listed constraints the requirements that have to be
   addressed by work that is done within ECRIT have to be highlighted.
   Other requirements have to be read as 'if you would like to address
   this threat, then you might want to consider this requirement' rather
   than 'any solution must address fulfill this requirement'.

5.1  Denial of Service Attacks

   It is difficult to address all possible denial of service attacks
   that might lead to disruption of an emergency call since a number of
   IETF protocols are used in order to provide this functionality.
   Hence, care must be taken when protocol extensions are developed that
   the chance for a denial of service attack is not increased.  Even
   without using any security mechanisms (such as authentication and key
   exchange protocols) some degree of security has to be provided.

   It is important to understand that the ability to mount DoS attacks
   must also be considered as part of the architecture work when legal



Tschofenig, et al.      Expires November 10, 2005              [Page 12]


Internet-Draft       Threats and Req. for Emergency             May 2005


   and regulatory requirements are known and need to be fulfilled.

5.2  Call Identity Spoofing

   A standard requirement to prevent identity spoofing is to
   authenticate the Emergency Caller.  Authentication mechanisms that
   require multiple roundtrips and as such might delay the call are
   often not desirable or cannot be mandated.

5.3  Location Spoofing

   An Emergency Caller might in many cases know its own location
   information because it was obtained via civic or geospatial location
   extensions for DHCP, via manual configuration or via GPS.
   Unfortunately, information provided by the end host is untrustworthy
   particularly when it is as important as location information.  Two
   approaches have been discussed in the past that place lead to a few
   requirements:

   o  Location Information is asserted by the Access Infrastructure
      Provider.  As such, the end host might use GPS but uses a protocol
      to allow the network to assert the location information.  This
      approach also has its limitations if the coverage area of the
      wireless network is fairly large.

   o  Location Information is added to the emergency call via an
      Emergency Call Routing Support entity.  Depending on the protocol
      used for call routing and on the properties of this protocol it
      might be necessary to return the asserted location information to
      the end host since intermediate nodes might not be allowed to
      insert objects into the call setup messages (at least not in all
      parts of the messages, such as bodies).  These signaling entities,
      in general, do not know the physiscal location of the user.  Thus,
      they have to rely on somebody else to actually provide the
      location, e.g., the Access Infrastructure Provider.

   As it can be seen from these two options the main difference is based
   on the type of protocol that is used in the message communication.
   This has an impact on the semantic and on the availability of certain
   attributes (such as identities that are used by these protocols) and
   on deployment constraints.  Based on the observation that the Access
   Infrastructure Provider is closest to the end host and is therefore
   the most likely entity that knows something about the physical
   location of the end host it seems to be reasonable to assume that
   some entity that asserts the location information is actually
   available in this particular network.

   The following requirements need to be provided in order for asserted



Tschofenig, et al.      Expires November 10, 2005              [Page 13]


Internet-Draft       Threats and Req. for Emergency             May 2005


   location information to accomplish its goals:

   o  Location Information MUST be integrity protected to prevent
      modifications by third parties.

   o  The recipient of the asserted location information object MUST be
      able to determine the party that asserted the location information
      in order to verify the assertion.  As such, authentication of the
      asserting party (the entity that created the assertion) MUST be
      provided.

   o  The asserted location information MUST include a timestamp to
      limit its validity in order to reduce replay attacks.

   o  The recipient of the asserted location information MUST have a way
      to verify that the asserting party is indeed authorized to create
      such an assertion.  As such, authentication is insufficient if not
      further authorization decision can be associated to the
      authenticated identity.

   o  The recipient of the asserted location information SHOULD have a
      mechanism to determine the Emergency Caller based on the provided
      assertion.

   The last bullet deserves further discussion: If some information
   about the Emergency Caller identity has to be included then only for
   the purpose of tracability and this functionality might not of
   general use since an adversary will always find networks that do not
   authenticate the user prior to providing network access.
   Furthermore, the goal of a number of network access authentication
   protocols is to prevent disclosure of the user identity to entities
   other than to the user's home network.  Note that the term 'user
   idenity' does not require that this identity directly points to the
   'real' identity of a user.  A court might want to require this
   identity to be resolved and to determine the user behind this
   identity.  Even if the access network would like to assertain the
   user's identity as part of the asserted location information it is,
   in many cases, not even possible for the Access Infrastructure
   Provider.

   If the authenticated user identity is not available to the Access
   Infrastructure Provider then only a few other identities might be
   useful, such as the IP address or the MAC address.  Other identities,
   such as the Host Identity, might not be available since they are only
   used by very few protocols.  An assertion that indicates the network
   in combination with the IP and/or MAC address (together with a
   timestamp) might provide some limited degree of traceability only if
   the user was authenticated directly to this particular network.



Tschofenig, et al.      Expires November 10, 2005              [Page 14]


Internet-Draft       Threats and Req. for Emergency             May 2005


   Providing the IP address allows some obvious attempts to cheat to be
   caught.  Hence, there is the question whether some identity should be
   added at all given the potential limitations and the potential small
   amounts of cut-and-paste attacks.  Using end user based
   authentication in addition to the asserted location information would
   be helpful (e.g., using end user certificates) but will impose a
   serious deployment problem.  Given the fact that emergency calls must
   still be allowed even without end user authentication certainly
   defeats the purpose of these mechanisms.  A partical attempt to
   address some phrank calls is to classify emergency calls based on the
   availability of the provided attributes.  If suspicious information
   is being provided that may well be wrong then additional verification
   steps need to be taken.  For example, if a report of a large fire on
   a Manhattan street is received then the PSAP may wait to dispatch
   until it gets a second person to call in.  This approach obviously
   has some limitations as well.

5.4  Impersonating a PSAP

   The Emergency Caller SHOULD be able to determine conclusively that he
   has reached an "authorized" or "legitimate" emergency call center.
   This requirement is meant to address the threat that a rogue,
   possibly criminal, entity pretends to accept emergency calls and
   disrupts the emergency infrastructure.  Particularly the caching
   properties of a distributed directy might be expoited.  Typically,
   the following properties are assumed:

   o  The interaction between the directory access client and the
      directory access server MUST be integrity and replay protected.

   o  The directory access server MUST be provide data origin
      authentication thereby ensuring that the provided data items are
      indeed from the claimed source.

   o  The directory server MUST provide information to ensure that it is
      authoritive for the provided information.

   Unlike in the PSTN case IP based networks provide a better
   opportunity to spoof a PSAP since physical access to the cable plant
   is required in the PSTN case, while this may not true for the IP
   case.

5.5  Signaling Message Modification

   To protect signaling messages against modifications either individual
   attributes SHOULD be protected (such as location objects) or the
   entire signaling message communication SHOULD experience end-to-end
   protection.  This requires integrity and replay protection to be



Tschofenig, et al.      Expires November 10, 2005              [Page 15]


Internet-Draft       Threats and Req. for Emergency             May 2005


   applied.  Authentication of the data sender and the data receiver
   SHOULD be provided to prevent a man-in-the-middle attack.

5.6  Replay Attack

   In order to protect signaling messages (or individual attributes) to
   be replayed in future protocol sessions integrity and replay
   protection mechanisms SHOULD be provided.

5.7  Loss of confidentiality

   In order to prevent leakage of information exchanged during the
   emergency call (both signaling and data traffic) confidentiality
   protection SHOULD be provided.  The mechanisms to accomplish this
   functionality are typically different for the data traffic and for
   the signaling messages and various scenarios, such as hop-by-hop,
   end-to-middle, middle-to-middle and end-to-end security, need to be
   considered.  Particularly the key management aspects for end-to-end
   security mechansisms imposes a deployment burden and hence need to be
   critically analysed in order to determine its applicability in the
   given context.

5.8  Modification of the Emergency Call

   To protect a man-in-the-middle attack to modify or inject data
   traffic into the communication between the Emergency Caller and the
   PSAP integrity, replay and data origin authentication SHOULD be
   provided.  Since the signaling messages are used to authenticate the
   end points and to distribute the required keying material it is
   necessary that either the key exchange protocol itself and the
   signaling messages experience appropriate security protection.  The
   term 'appropriate' refers to the given context, the used signaling
   protocol and the key exchange protocol.

   Please note that the interactive nature of a voice communication
   already provides a some degree of protection.  However, with the
   introduction of instant messaging the freshness of the Emergency Call
   needs to be provided by other means.

5.9  Corrupting Configuration Information

   Devices SHOULD be assured of the correctness of the local emergency
   numbers that are automatically configured.  If we assume a fixed,
   global emergency service identifier that requires no configuration
   and only configure local "traditional" emergency numbers, users are
   not likely to suddenly dial some random number if a rogue
   configuration server introduces this as an additional emergency
   number.  The ability to override all locally configured emergency



Tschofenig, et al.      Expires November 10, 2005              [Page 16]


Internet-Draft       Threats and Req. for Emergency             May 2005


   number is of more concern.  If the Emergency Caller does not use the
   infrastructure to route the call to the appropriate PSAP then the
   security of the directory service is of importance for security.
















































Tschofenig, et al.      Expires November 10, 2005              [Page 17]


Internet-Draft       Threats and Req. for Emergency             May 2005


6.  Security Considerations

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















































Tschofenig, et al.      Expires November 10, 2005              [Page 18]


Internet-Draft       Threats and Req. for Emergency             May 2005


7.  References

7.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

7.2  Informative References

   [I-D.schulzrinne-ecrit-requirements]
              Schulzrinne, H. and R. Marshall, "Requirements for
              Emergency Context Resolution with Internet Technologies",
              May 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
   Technische Universitat Hamburg-Harburg
   Department of Security in Distributed applications
   Harburger Schlossstrasse 20
   Hamburg-Harburg  21079
   Germany

   Email: murugaraj.shanmugam@tuhh.de





Tschofenig, et al.      Expires November 10, 2005              [Page 19]


Internet-Draft       Threats and Req. for Emergency             May 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 November 10, 2005              [Page 20]