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

Versions: (draft-tschofenig-nsis-threats) 00 01 02 03 04 05 06 RFC 4081

   NSIS
   Internet Draft                                         H. Tschofenig
                                                          D. Kroeselberg
                                                                 Siemens
   Document:
   draft-ietf-nsis-threats-04.txt
   Expires: August 2004                                   February 2004


                         Security Threats for NSIS
                     <draft-ietf-nsis-threats-04.txt>


Status of this Memo


   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Abstract

   This threats document provides a detailed analysis of the security
   threats relevant for the NSIS protocol. It calls attention to and
   helps with understanding of various security considerations in the
   NSIS Requirements, Framework, and Protocol proposals. This document
   does not describe vulnerabilities of specific NSIS protocols.










Tschofenig, Kroeselberg    Expires - August 2004              [Page 1]

                      Security Threats for NSIS         February 2004


Table of Contents

   1. Introduction..................................................2
   2. Relevant Communications Models................................3
      2.1 First-Peer Communications.................................5
      2.2 End-to-Middle Communications..............................6
      2.3 Intra-Domain Communications...............................6
      2.4 Inter-Domain Communications...............................6
      2.5 End-to-End Communications.................................7
      2.6 Middle-to-Middle Communications...........................8
   3. Generic Threats...............................................8
      3.1 Man-in-the-Middle Attacks.................................8
      3.2 Replay of Signaling Messages.............................10
      3.3 Injecting or Modifying Messages..........................11
      3.4 Insecure Parameter Exchange and Negotiation..............11
   4. NSIS-Specific Threat Scenarios...............................11
      4.1 NSIS SA Usage............................................12
      4.2 Combining Signaling and SA Establishment.................12
      4.3 Eavesdropping and Traffic Analysis.......................13
      4.4 Identity Spoofing........................................13
      4.5 Unprotected Authorization Information....................15
      4.6 Missing Non-Repudiation..................................16
      4.7 Malicious NSIS Entity....................................17
      4.8 Denial of Service Attacks................................17
      4.9 Disclosing the Network Topology..........................18
      4.10 Unprotected Session or Reservation Ownership............19
      4.11 Attacks against the Transport Mechanism.................20
   5. Security Considerations......................................21
   6. Normative References.........................................21
   7. Informative References.......................................22
   Author's Addresses..............................................23
   Full Copyright Statement........................................23


1. Introduction

   Whenever a new protocol has to be developed or existing protocols
   have to be modified, threats to their security should be evaluated.
   The process of securing protocols is broken down into discrete
   steps. To address security in the NSIS working group, a number of
   steps have been taken:

   - NSIS Analysis Activities (e.g., RSVP Security Properties)
   - Security Threats for NSIS
   - NSIS Requirements
   - NSIS Framework
   - NSIS Protocol Proposals




Tschofenig, Kroeselberg    Expires - August 2004              [Page 2]

                      Security Threats for NSIS         February 2004


   This document identifies the basic security threats that need to be
   addressed during the NSIS signaling protocol design. This document
   cannot provide detailed threats for all possible NSIS NSLPs. QoS,
   NAT/Firewall and other NSLPs documents need to provide a description
   of their trust models and a threat description for their specific
   application domain. In addition, although the base protocol might be
   secure, certain extensions may cause problems when used in a
   particular environment. Furthermore, it is necessary to investigate
   the context in which a signaling protocol is used and the
   architecture into which it is integrated. As an example of such
   interaction, accounting and charging are taken into account in this
   document, because without an appropriate integration of the two, it
   is difficult to deploy any NSIS solution. This interaction is also a
   subject of discussion within the NSIS Framework.

   We use the NSIS terms defined in [Brun03].


2. Relevant Communications Models

   Signaling messages traverse different parts of a network, demand
   different security protection, and raise different security
   problems. The different needs for security protection are mainly due
   to the fact that NSIS signaling messages cross trust boundaries into
   domains where different trust relationships exist. Often, one may
   describe this by categorizing communications as first-peer, last-
   peer, intra-domain, or inter-domain (see Figure 1).

   The main properties of the parts of a network listed here are
   briefly described in this section, and the threats against them in
   Sections 3 and 4 are classified as generic and NSIS specific. Figure
   1 depicts a typical end-to-end communication scenario including
   access parts between the NSIS end-entities and their nearest NSIS
   hops. This "first-peer communications" commonly comes with specific
   security requirements (as described below) that are especially
   important for properly addressing security in mobile scenarios.
   Differences in the trust relationship and the required security for
   first-peer communication, compared with other parts of the signaling
   path, might exist.

   To refine the above differentiation based on the network parts that
   NSIS signaling may traverse, we consider trust relationships between
   different network parts.

   Additional threats may apply to NSIS communications in which one
   entity involved is an end-entity (Initiator or Responder) and the
   other entity is any intermediate hop except the immediately adjacent
   peer. This is typically called the end-to-middle scenario (see
   Figure 2 for a description of relevant trust relations).


Tschofenig, Kroeselberg    Expires - August 2004              [Page 3]

                      Security Threats for NSIS         February 2004



     +------------------+   +---------------+   +------------------+
     |                  |   |               |   |                  |
     |  Administrative  |   | Intermediate  |   |  Administrative  |
     |     Domain A     |   |   Domains     |   |     Domain B     |
     |                  |   |               |   |                  |
     |                 (Inter-domain Communication)                |
     |        +---------+---+---------------+---+---------+        |
     |  (Intra-domain   |   |               |   | (Intra-domain    |
     |   Communication) |   |               |   |  Communication)  |
     |        |         |   |               |   |         |        |
     |        |         |   |               |   |         |        |
     +--------+---------+   +---------------+   +---------+--------+
              ^                                           v
              |                                           |
     First Peer Communication               Last Peer Communication
              |                                           |
        +-----+-----+                               +-----+-----+
        |   NSIS    |                               |   NSIS    |
        | Initiator |                               | Responder |
        +-----------+                               +-----------+

                       Figure 1: NSIS Network Parts

   The motivation for including this scenario stems, for example, from
   the SIP [RFC3261] protocol. To counter a number of specific security
   threats, any intermediate SIP hop may request a SIP end-entity (UA)
   to authenticate. Such functionality seems generally useful for
   intermediaries at the borders of trust domains that signaling
   messages need to traverse.

   Intermediate NSIS hops may have to deal as well with specific
   security threats not (directly) involving any end-entities. This
   scenario is called middle-to-middle. A typical example of middle-to-
   middle communication is between two NSIS hops at the borders of
   their respective trust domains (i.e., inter-domain communications).
   NSIS messages may have to traverse one or more untrusted hops
   between these NSIS entities.

   Figure 2 illustrates these additional scenarios. The first-peer and
   last-peer cases discussed above are covered by the peer-to-peer
   trust relationships between end-entity and closest hop.









Tschofenig, Kroeselberg    Expires - August 2004              [Page 4]

                      Security Threats for NSIS         February 2004



                 ****************************************
                 *                                      *
            +----+-----+       +----------+        +----+-----+
      +-----+  NSIS    +-------+  NSIS    +--------+  NSIS    +-----+
      |     |  Node 1  |       |  Node 2  |        |  Node 3  |     |
      |     +----------+       +----+-----+        +----------+     |
      |                             ~                               |
      |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~                               |
      |  ~                                                          |
   +--+--+-----+                                          +---------+-+
   |   NSIS    +//////////////////////////////////////////+   NSIS    |
   | Initiator |                                          | Responder |
   +-----------+                                          +-----------+

    Legend:
     -----: Peer-to-Peer Trust Relationship
     /////: End-to-End Trust Relationship
     *****: Middle-to-Middle Trust Relationship
     ~~~~~: End-to-Middle Trust Relationship

                    Figure 2: NSIS Trust Relationships

2.1 First-Peer Communications

   First-peer communications refers to the peer-to-peer interaction
   between a signaling message originator, the NSIS Initiator (NI), and
   the first NSIS-aware entity along the path. Making assumptions about
   the threats, security requirements, and available trust
   relationships may be difficult here.

   To illustrate this, in public mobile environments it is difficult to
   assume the existence of a pre-established security association
   directly available for NSIS peers involved in first-peer
   communications, because these peers cannot be assumed to have any
   pre-existing relationship between each other. For enterprise
   networks, in contrast, the situation is different. Usually there is
   a fairly strong (pre-established) trust relationship between the
   peers. Enterprise network administrators usually have some degree of
   freedom to select the appropriate security protection and to enforce
   it. The choice of selecting a security mechanism is therefore often
   influenced by the already available infrastructure, and per-session
   negotiation of security mechanisms is often not required (which, in
   contrast, is required for the public mobile case).

   For first-peer communications, especially, threats related to
   initial security association setup, or threats due to replay
   attacks, lack of confidentiality, denial of service, integrity



Tschofenig, Kroeselberg    Expires - August 2004              [Page 5]

                      Security Threats for NSIS         February 2004


   violation, or identity spoofing are relevant, and potentially lead
   to theft of service,  fraud, or violations of privacy.

2.2 End-to-Middle Communications

   End-to-middle interaction in signaling may be required, e.g., to
   grant end-entities access to specific services in trust domains
   different from the one to which the first peer belongs. Threats
   specific to this scenario may be introduced by untrusted
   intermediate NSIS hops that maliciously alter NSIS signaling. These
   threats are still relevant if security mechanisms are in place
   between the NSIS hops, but terminate at each hop (e.g., IPsec hop-
   by-hop protection).

2.3 Intra-Domain Communications

   After having been verified at the first peer, an NSIS signaling
   message traverses the network within the same administrative domain
   to which the first peer belongs. Because the request has already
   been authenticated and authorized, the threats are different from
   those described in the previous sections. To differentiate first-
   peer communications from intra-domain communications (i.e.,
   communications internally within one administrative domain) we
   assume that no external end hosts have direct access to the internal
   network nodes, except to the first peer. We furthermore assume that
   NSIS peers within the same administrative domain have at least some
   sort of trust relationship.

2.4 Inter-Domain Communications

   The threat assumptions between the borders of different
   administrative domains largely depend on the authorization
   procedures. If one domain forges QoS reservations, then this domain
   may also have to pay for the reservation. Hence, in this case, there
   is no real benefit for this domain to forge a QoS reservation. If an
   end host is directly charged by intermediate domains (i.e., by a
   domain different from the malicious domain), such an attack may be a
   quite realistic threat.

   Security protection of messages transmitted between different
   administrative domains is necessary to tackle attacks like spoofing,
   integrity violation, or denial of service between these domains,
   e.g., to allow proper accounting. The number of neighboring domains
   is usually rather limited (compared with first-peer communications),
   which substantially reduces the key management considerations for
   securing inter-domain NSIS signaling.

   Signaling information other than QoS service parameters, such as
   policy rules in the case of middlebox communications, places


Tschofenig, Kroeselberg    Expires - August 2004              [Page 6]

                      Security Threats for NSIS         February 2004


   different assumptions on inter-domain communications. Business
   relationships and trust assumptions are of particular importance as
   a basis for securing these communications.

   If signaling messages are conveyed transparently in the core network
   (i.e., they are neither intercepted nor processed in the core
   network), then the signaling message communications effectively
   takes place between potentially distant access networks. This might
   place a burden on the key management infrastructure required between
   these access networks, which might not know of each other in
   advance. This might lead to an inability to secure signaling
   messages for direct communications between the access networks.
   Hence, this can be seen as a serious deployment problem, because it
   might be unacceptable for an access network service provider to
   perform processing (e.g., QoS reservations or policy rule
   installation at firewalls) triggered by unprotected,
   unauthenticated, and possibly unauthorized incoming signaling
   messages.

2.5 End-to-End Communications

   NSIS aims to signal information between the Initiator and the
   Responder. This section refers to the trust relationships required
   between the end points in cases where security protection is
   required. Note that this security protection is likely to be
   required only for certain objects such as those related to pricing
   and charging. Protecting the entire signaling message end to end is
   not normally regarded as feasible, because intermediate NSIS nodes
   need (a) to inspect various objects and (b) to add, modify, or
   delete objects from the signaling message.

   The following example illustrates a possible application of end-to-
   end protection for objects carried within the NSIS signaling
   protocol. Alice, the data sender, wants Bob, the data receiver, to
   pay for a QoS reservation (reverse charging). Bob wants to be
   assured that the QoS signaling message he receives was indeed
   transmitted by Alice, because he is only willing to pay for
   particular users and not for everyone. Hence, Bob wants to verify
   that the request came from Alice (authentication) and that the
   included parameters are unmodified (integrity). Additionally it
   might be necessary to secure a negotiation step and to deliver
   authorization information securely to the parties involved.
   Information required to render an authorization decision (such as
   prices or QoS objects) also needs proper security protection.

   Typical threats in such a scenario range from modification of QoS
   objects or price information (i.e., making Bob pay too much), to
   fraud (i.e., forcing Bob always to pay for the reservations), to
   identity spoofing (i.e., an impostor claiming to be Alice).


Tschofenig, Kroeselberg    Expires - August 2004              [Page 7]

                      Security Threats for NSIS         February 2004



   Regarding end-to-end security, one additional issue needs to be
   addressed: delegation. Whenever signaling is addressed end to end
   and an arbitrary node along the path acts as a proxy on behalf of
   the other endpoint, a delegation mechanism is required to provide
   secure interaction. This might lead to additional complexity.

2.6 Middle-to-Middle Communications

   The middle-to-middle case is not explicitly considered here,
   although it is important, because it is already covered by either
   intra- or inter-domain communications depending on the locations of
   the entities involved.


3. Generic Threats

   This section provides scenarios of threats that are applicable to
   signaling protocols in general. Note that some of these scenarios
   use the term user instead of NSIS Initiator. This is mainly because
   security protocols allow differentiation between entities as hosts
   and as users (based on the identifiers used).

   For the following subsections, we use the general distinction into
   two cases in which attacks may occur. These are according to the
   separate steps, or phases, normally encountered when applying
   protocol security (with, e.g., IPsec, TLS, Kerberos, or SSH).
   Therefore, this section starts with a brief motivation for this
   separation.

   Security protection of protocols is often separated into two steps.
   The first step provides primarily entity authentication and key
   establishment (which result in a persistent state often called a
   security association), whereas the second step provides message
   protection (some combination of data origin authentication, data
   integrity, confidentiality, and replay protection) using the
   previously established security association. The first step tends to
   be more expensive than the second, which is the main reason for the
   separation. If messages are transmitted infrequently, then these two
   steps may be collapsed into a single and usually rather costly one.
   One such example is e-mail protection via S/MIME. The two steps may
   be tightly bound into a single protocol, as in TLS, or defined in
   separate protocols, as with IKE and IPsec. We use this separation to
   cover the different threats in more detail.

3.1 Man-in-the-Middle Attacks

   This section describes both (1) security threats that exist if two
   peers do not already share a security association or do not use


Tschofenig, Kroeselberg    Expires - August 2004              [Page 8]

                      Security Threats for NSIS         February 2004


   security mechanisms at all, and (2) threats that are applicable when
   a security association is already established. Note also that a
   denial of service attack on a signaling protocol exists when no
   separation between SA establishment and signaling protection takes
   place. The discovery procedure, in particular, is vulnerable to a
   number of such attacks.

   - Attacks during NSIS SA Establishment

   While establishing a security association, an adversary fools the
   signaling message Initiator with respect to the entity to which it
   has to authenticate. The Initiator authenticates to the man-in-the-
   middle adversary, who is then able to modify signaling messages to
   mount DoS attacks or steal services that get billed to the
   Initiator. In addition, it may be able to terminate the Initiator's
   NSIS messages of and inject messages to a peer itself, therefore
   acting as the peer to the Initiator and as the Initiator to the
   peer. This results in the Initiator wrongly believing that it is
   talking to the "real" network, whereas it is actually attached to an
   adversary.
   For this attack to be successful, pre-conditions have to hold which
   are described in the following two cases:

   - Missing Authentication

   In the first case, this threat can be carried out because of missing
   authentication between neighboring peers: without authentication a
   NI, NR, or NF is unable to detect an adversary. However, in some
   practical cases authentication might be difficult to accomplish,
   either because the next peer is unknown, because of misbelieved
   trust relationships in parts of the network, or because of the
   inability to establish proper security protection (inter-domain
   signaling messages, dynamic establishment of a security association,
   etc.). If one of the communicating endpoints is unknown, then for
   some security mechanisms it is either impossible or impractical to
   apply appropriate security protection. Sometimes network
   administrators use intra-domain signaling messages without proper
   security. Such a configuration would then allow an adversary on a
   compromised non-NSIS-aware node to interfere with nodes running an
   NSIS signaling protocol. Note that this type of threat goes beyond
   those caused by malicious NSIS nodes (described in Section 4.7).

   - Unilateral Authentication

   In the case of unilateral authentication, the NSIS entity that does
   not authenticate its peer is unable to discover a man-in-the-middle
   adversary. Although mutual authentication of signaling messages
   should take place between each peer participating in the protocol
   operation, special attention is given here to first-peer


Tschofenig, Kroeselberg    Expires - August 2004              [Page 9]

                      Security Threats for NSIS         February 2004


   communications. Unilateral authentication between an end host and
   the first peer (just authenticating the end host) is still common
   today, but it certainly opens up many possibilities for man-in-the-
   middle attackers impersonating either the end host or the
   (administrative domain represented by the) first peer.

   Missing or unilateral authentication, as described above, is part of
   a general problem of network access with inadequate authentication,
   and it should not be considered something unique to the NSIS
   signaling protocol. Obviously, there is a strong need to correctly
   address this in a future NSIS protocol. The signaling protocols
   addressed by NSIS are different from other protocols, in which only
   two entities are involved. Note that first-peer authentication is
   especially important, because a security breach here could impact
   nodes beyond the entities directly involved (or even beyond a local
   network).

   Finally it should be noted that the signaling protocol should be
   considered as a peer-to-peer protocol, whereby the roles of
   Initiator and Responder can be reversed at any time. Hence,
   unilateral authentication is not particularly useful for such a
   protocol. However, there might be a need to have some form of
   asymmetry in the authentication process, whereby one entity uses a
   different authentication mechanism than the other one. As an
   example, the combination of symmetric and asymmetric cryptography
   should be mentioned.

   - Weak Authentication

   In this case, the threat can be carried out because of weak
   authentication mechanisms whereby information transmitted during the
   NSIS SA establishment process may leak passwords or allow offline
   dictionary attacks. This threat is applicable to NSIS for the
   process of selecting certain security mechanisms.

3.2 Replay of Signaling Messages

   This threat scenario covers the case in which an adversary
   eavesdrops and collects signaling messages and replays them at a
   later time (or at a different place, or uses parts of them at a
   different place or in a different way, e.g., cut-and-paste attacks).
   Without proper replay protection, an adversary might mount man-in-
   the-middle, denial of service, and theft of service attacks.

   A more difficult attack that may cause problems even in case of
   replay protection requires the adversary to crash an NSIS-aware
   node, cause it to lose state information (sequence numbers, security
   associations, etc.), and then be able to replay old signaling



Tschofenig, Kroeselberg    Expires - August 2004             [Page 10]

                      Security Threats for NSIS         February 2004


   messages. This attack takes advantage of re-synchronization
   deficiencies.

3.3 Injecting or Modifying Messages

   This type of threat involves integrity violations, whereby an
   adversary modifies signaling messages (e.g., by acting as a man-in-
   the-middle) to cause unexpected network behavior. Possible actions
   an adversary might consider for its attack are reordering, delaying,
   dropping, injecting, truncating, and otherwise modifying messages.

   An adversary may inject a signaling message requesting a large
   amount of resources (possibly using a different user's identity).
   Other resource requests may then be rejected. In combination with
   identity spoofing, it is also possible to carry out fraud. This
   attack is only feasible in the absence of authentication and
   signaling message protection.

   Some threats directly related to these are described in Sections
   4.4, 4.7, and 4.8.

3.4 Insecure Parameter Exchange and Negotiation

   First, protocols may be useful in a variety of scenarios with
   different security requirements. Second, different users (e.g., a
   university, a hospital, a commercial enterprise, or a government
   ministry) have inherently different security requirements. Third,
   different parts of a network (e.g., within a building, across a
   public carrier's network, or over a private microwave link) may need
   different levels of protection. It is often difficult to meet these
   (sometimes conflicting) requirements with a single security
   mechanism or fixed set of security parameters, so often a selection
   of mechanisms and parameters is offered. Therefore, a protocol is
   required to agree on certain security mechanisms and parameters. An
   insecure parameter exchange or security negotiation protocol can
   help an adversary mount a downgrading attack to force selection of
   weaker mechanisms than mutually desired. Hence, without binding the
   negotiation process to the legitimate parties and protecting it, an
   NSIS protocol might be only as secure as the weakest mechanism
   provided (e.g., weak authentication), and the benefits of defining
   configuration parameters and a negotiation protocol are lost.


4. NSIS-Specific Threat Scenarios

   This section describes 11 threat scenarios in terms of attacks on
   and security deficiencies in the NSIS signaling protocol. A number
   of security deficiencies might enable an attack. Fraud is an example
   of an attack that might be enabled by missing replay protection,


Tschofenig, Kroeselberg    Expires - August 2004             [Page 11]

                      Security Threats for NSIS         February 2004


   missing protection of authorization tokens, identity spoofing,
   missing authentication, and other deficiencies that help an
   adversary steal resources. Different threat scenarios based on
   deficiencies that could enable an attack are addressed in this
   section.

   The threat scenarios are not independent. Some of them, e.g., denial
   of service, are well-established security terms and, as such, need
   to be addressed, but are often enabled by one or more deficiencies
   described under other scenarios.

4.1 NSIS SA Usage

   Once a security association is established (and used) to protect
   signaling messages, many basic attacks are prevented. However, a
   malicious NSIS node is still able to perform various attacks as
   described in Section 4.7. Replay attacks may be possible when an
   NSIS node crashes, restarts, and performs state re-establishment.
   Proper re-synchronization of the security mechanism must therefore
   be provided to address this problem.

4.2 Combining Signaling and SA Establishment

   This scenario describes attacks that allow an adversary to flood an
   NSIS node with bogus signaling messages to cause a denial of service
   attack.

   When a signaling message arrives at an NSIS-aware network element,
   certain processing is required. If this message contains security
   objects such as digital signatures, and no security association is
   already available, then some additional processing is required for
   the cryptographic verification. Because NSIS signaling should not
   require extra roundtrips between two NSIS peers, it is difficult to
   provide the DoS protection mechanisms commonly found in
   authentication and key agreement protocols. Signaling messages can
   be idempotent, which means that they contain the same amount of
   information as the original message. An example would be a refresh
   message that is equivalent to a create message. This property allows
   a refresh message to create new state along a new path, although no
   previous state is available. For this to work, specific classes of
   cryptographic mechanisms supporting this behavior are needed. An
   example is a scheme based on digital signatures, which, however,
   should be used with care due to possible denial of service attacks.
   Problems with using these types of exchanges with public key based
   protection are described in [AN97] and in [ALN00].

   In addition to the threat scenario described above, an incoming
   signaling message might require time consuming processing
   (computations, state maintenance, timer setting, etc.) and


Tschofenig, Kroeselberg    Expires - August 2004             [Page 12]

                      Security Threats for NSIS         February 2004


   communication with third-party nodes such as policy servers, LDAP
   servers, etc. If an adversary is able to transmit a large number of
   signaling messages (for example, with QoS reservation requests) with
   invalid credentials, then the verifying node may not be able to
   process other reservation messages from legitimate users.

   Further attacks may be enabled by injecting error messages or
   forcing the creation of error messages to extract additional
   information.

4.3 Eavesdropping and Traffic Analysis

   This section covers threats whereby an adversary is able to
   eavesdrop on signaling messages. The signaling packets collected may
   allow traffic analysis or be used later to mount replay attacks, as
   described in Section 3.2. The eavesdropper might learn QoS
   parameters, communication patterns, policy rules for firewall
   traversal, policy information, application identifiers, user
   identities, NAT bindings, authorization objects, network
   configuration and performance information, and more.

   An adversary's capability to eavesdrop on signaling messages might
   violate a user's preference for privacy, particularly if unprotected
   authentication or authorization information (including policies and
   profile information) is exchanged.

   Note that this threat scenario is not mitigated by applying
   integrity protection to the messages, which is often considered
   sufficient for signaling protocols.

   Because the NSIS protocol signals messages through a number of
   nodes, it is possible to differentiate between nodes actively
   participating in the NSIS protocol and others that do not actively
   participate in the NSIS protocol. For certain objects or messages it
   might be desirable to permit actively participating intermediate
   NSIS nodes to eavesdrop. On the other hand, it might be desirable
   that only the intended end points (NSIS Initiator and NSIS
   Responder) are able to read certain other objects.

4.4 Identity Spoofing

   Identity spoofing relevant for NSIS occurs in two forms: first,
   identity spoofing can happen during the establishment of a security
   association based on a weak authentication mechanismn and, second,
   it can consist of spoofing data traffic.

   In the first case, Eve, acting as an adversary, may claim to be the
   registered user Alice by spoofing Alice's identity. Eve thereby
   causes the network to charge Alice for the network resources


Tschofenig, Kroeselberg    Expires - August 2004             [Page 13]

                      Security Threats for NSIS         February 2004


   consumed. This type of attack is possible if authentication is based
   on a simple username identifier (i.e., in absence of cryptographic
   authentication), or if authentication is provided for hosts, and
   multiple users have access to a single host. This attack could also
   be classified as theft of service.

   In the second case, an adversary may be able to exploit the
   established flow identifiers (required for QoS and middlebox
   communication [Midcom] specific signaling protocols). Some
   identifiers, among others, IP addresses, transport protocol
   identifiers, port numbers, and flow labels (see [RFC1809] and
   [RC+03]), are transported in these protocols. Modification of these
   flow identifiers allows adversaries to exploit or to render
   ineffective quality of service reservations or policy rules at
   middleboxes. An adversary could mount an attack by modifying the
   flow identifier of a signaling message.

   NSIS signaling messages contain some sort of flow identifier, which
   is associated with a specified behavior (e.g., a particular flow
   experiences QoS treatment or allows packets to traverse a firewall).
   An adversary might, therefore, use IP spoofing and inject data
   packets to benefit from previously installed flow identifiers.

   The following threat is carried out by spoofing the identity of
   transmitted data traffic. The spoofed identity is the IP source
   address. For this attack to be successful, accounting records are
   collected based on the IP source address and not on a SPI due to
   IPsec protection. After the network receives a properly protected
   reservation request, transmitted by the legitimate user Alice,
   Traffic Selectors are installed at the corresponding devices (for
   example, the edge router). These Traffic Selectors are used for flow
   identification and allow data traffic originated from a given source
   address to be matched and assigned to a particular QoS reservation.
   The adversary Eve now spoofs the IP address of the Alice. In
   addition, Alice's host may be crashed by the adversary with a denial
   of service attack or may lose connectivity, for example, because of
   mobility considerations. If both nodes are located at the same link
   and use the same IP address, then obviously a duplicate IP address
   will be detected. Assuming that only Eve is now present at the link,
   she is able to receive and transmit data (for example RTP data
   traffic) that receives preferential QoS treatment based on the
   previous reservation. Depending on the installed Traffic Selector
   granularity, Eve might have more possibilities to exploit the QoS
   reservation or a pin-holed firewall. Assuming the soft state
   paradigm, whereby periodic refresh messages are required, the
   absence of Alice will not be detected until the next signaling
   message appears and forces Eve to respond with a protected signaling
   message. Again, this attack is applicable not just to QoS traffic,
   but the existence of a QoS reservation increases its impact, because


Tschofenig, Kroeselberg    Expires - August 2004             [Page 14]

                      Security Threats for NSIS         February 2004


   this type of traffic is more expensive. The same attack is also
   applicable to a Middlebox protocol.

   The ability for an adversary to inject data traffic that matches a
   certain flow identifier established by a legitimate user often
   requires the ability also to receive the data traffic. This is,
   however, true only if the flow identifier consists of values that
   contain addresses used for routing. If we imagine using attributes
   of a flow identifier that do not require such a property, then
   identity spoofing and injecting traffic are much easier. An
   adversary can use a nearly arbitrary endpoint identifier to achieve
   the desired result. Obviously, though, the endpoint identifiers are
   not irrelevant, because the messages have to travel the same path
   through the network.

   Data traffic marking based on DiffServ is such an example. Whenever
   an ingress router uses only marked incoming data traffic for
   admission control procedures, then various attacks are possible.
   These problems have been known in the DiffServ community for a long
   time and have been documented in various DiffServ-related documents.
   The IPsec protection of DiffServ Code Points is described in Section
   6.2 of [RFC2745]. Related security issues (for example denial of
   service attacks) are described in Section 6.1 of the same document.

4.5 Unprotected Authorization Information

   Authorization is an important criterion for providing resources such
   as QoS reservations, NAT bindings, and pin-holes through firewalls.
   Authorization information might be delivered to the NSIS
   participating entities in a number of ways.

   Typically the authenticated identifier is used to assist during the
   authorization procedure as, e.g., described in [RFC3812]. Depending
   on the chosen authentication protocol, certain threats may exist.
   Section 3 discusses a number of issues related to this approach when
   the authentication and key exchange protocol is used to establish
   session keys for signaling message protection.

   Another approach is to use some sort of authorization token. The
   functionality and structure of such an authorization token for RSVP
   is described in [RFC3520] and [RFC3521].

   Achieving secure interaction between different protocols based on
   authorization tokens, however, requires some care. By using such an
   authorization token it is possible to link state information between
   different protocols. Returning an unprotected authorization token to
   the end host might allow an adversary (for example an eavesdropper)
   to steal resources. An adversary might also use the token to monitor



Tschofenig, Kroeselberg    Expires - August 2004             [Page 15]

                      Security Threats for NSIS         February 2004


   communication patterns. Finally, an untrustworthy end host might
   also modify the token content.

   The Session/Reservation Ownership problem can also be regarded as an
   authorization problem. Details are described in Section 4.10. In
   enterprise networks, authorization is often coupled with membership
   in a particular class of users or groups. This type of information
   either can be delivered as part of the authentication and key
   agreement procedure or has to be retrieved via separate protocols
   from other entities. If an adversary manages to modify information
   relevant for determining authorization or the outcome of the
   authorization process itself, then theft of service might be
   possible.

4.6 Missing Non-Repudiation

   Repudiation in this context refers to a problem where one party
   later denies having taken a certain action (such as requesting a QoS
   reservation). Problems stemming from a lack of non-repudiation
   appear in two forms:

   On the one hand, from a service provider's point-of-view, the
   following threat may be worth investigation. A user may deny having
   issued a reservation request for which it was charged. The service
   provider may then want to be able to prove that a particular user
   issued the reservation request in question.

   On the other hand, the same threat can be interpreted from a user's
   point-of-view. A service provider may claim to have received a
   number of reservation requests. The user in question thinks that it
   never issued those requests and wants to see a proof of correct
   service usage for a given set of QoS parameters.

   In today's telecommunication networks, non-repudiation is not
   provided. The user has to trust the network operator to meter the
   traffic correctly, collect and merge accounting data, and ensure
   that no unforeseen problems occur. If a signaling protocol with the
   non-repudiation property is desired for establishing QoS
   reservations for authorized resources, this impacts the protocol
   design.

   Non-repudiation poses additional requirements on the security
   mechanisms, because it public-key cryptography is needed to provide
   it. Because this would normally increase the overall cost for
   security, threats related to missing non-repudiation are only
   considered relevant in certain specific cases (e.g., specific
   authorization mechanisms) and not for general NSIS signaling.




Tschofenig, Kroeselberg    Expires - August 2004             [Page 16]

                      Security Threats for NSIS         February 2004


4.7 Malicious NSIS Entity

   Network elements within a domain (intra-domain) experience a
   different trust relationship with regard to the security protection
   of signaling messages compared with edge NSIS entities. It is
   assumed that edge NSIS entities are responsible for performing
   cryptographic processing (authentication, integrity and replay
   protection, authorization, and accounting) for signaling messages
   arriving from the outside. This prevents unprotected signaling
   messages from appearing within the internal network. If, however, an
   adversary manages to take over an edge router, then the security of
   the entire network is compromised. An adversary is then able to
   launch a number of attacks including denial of service; integrity
   violations; replay, reordering, and deletion of data packets; and
   various others. A rogue firewall can harm other firewalls by
   modifying policy rules. The chain-of-trust principle applied in
   peer-to-peer security protection cannot protect against a malicious
   NSIS node. An adversary with access to a NSIS router is also able to
   get access to security associations and transmit secured signaling
   messages. Note that even non-peer-to-peer security protection might
   not be able to prevent this problem fully. Because an NSIS node
   might issue signaling messages on behalf of someone else (by acting
   as a proxy), additional problems need to be considered.

   An NSIS-aware edge router is a critical component that requires
   strong security protection. A strong security policy applied at the
   edge does not imply that other routers within an intra-domain
   network do not need to verify signaling messages cryptographically.
   If the chain-of-trust principle is deployed, then the security
   protection of the entire path (in this case within the network of a
   single administrative domain) is as strong as the weakest link. In
   the case under consideration, the edge router is the most critical
   component of this network, and it may also act as a security gateway
   or firewall for incoming and outgoing traffic. For outgoing traffic
   this device has to implement the security policy of the local domain
   and apply the appropriate security protection.

   For an adversary to mount this attack, either an existing NSIS-aware
   node along the path has to be attacked successfully, or an adversary
   must succeed in convincing another NSIS node to be the next NSIS
   peer (man-in-the-middle attack).

4.8 Denial of Service Attacks

   A number of denial of service (DoS) attacks can cause NSIS nodes to
   malfunction. Other attacks that could lead to DoS, such as man-in-
   the-middle attacks, replay attacks, injection or modification of
   signaling messages, etc., are mentioned throughout this document.



Tschofenig, Kroeselberg    Expires - August 2004             [Page 17]

                      Security Threats for NSIS         February 2004


   - Path Finding

   This threat scenario includes potential DoS attacks that exist when
   the reservation setup is split into two phases, i.e., path and
   reservation (as used, for example, in receiver-based reservation
   setup). In this case, assuming that the node transmitting the path
   message is not charged for the path message itself, it may be able
   to generate a large number of reservation requests (possibly in a
   distributed fashion). Charging is activated only after successful
   verification of the reservation request. The reservations are,
   however, never intended to be successful for various reasons: the
   destination node cannot be reached; it is not responding; or it
   simply rejects the reservation. An adversary can succeed because
   state has already been allocated along the path for various
   processing tasks including path pinning.

   - Discovery Phase

   Conveying signaling information to a large number of entities along
   a data path requires some sort of discovery. This discovery process
   is vulnerable to a number of attacks, because it is difficult to
   secure. An adversary can use the discovery mechanisms to convince
   one entity to signal information to another entity not along the
   data path or to cause the discovery process to fail. In the first
   case, the signaling protocol could appear to continue correctly,
   except that policy rules are installed at the incorrect firewalls or
   QoS resource reservations take place at the wrong entities. For an
   end host, this means that the protocol failed for unknown reasons.

   - Faked Error or Response Messages

   An adversary may be able to inject false error or response messages
      as part of a DoS attack. This could be either at the signaling
      message protocol layer (NTLP), at the layer of each client layer
      protocol (NSLP: QoS, Midcom, etc.), or at the transport protocol
      layer. An adversary might cause unexpected protocol behavior or
      might succeed with a DoS attack. The discovery protocol,
      especially, exhibits vulnerabilities with regard to this threat
      scenario (see the above discussion on discovery). In the case in
      which no separate discovery protocol is used and signaling
      messages are addressed to end hosts only (with a Router Alert
      Option to intercept message as NSIS aware nodes), an error
      message might be used to indicate a path change. Such a design
      combines a discovery protocol together with a signaling message
      exchange protocol.

4.9 Disclosing the Network Topology




Tschofenig, Kroeselberg    Expires - August 2004             [Page 18]

                      Security Threats for NSIS         February 2004


   In some organizations or enterprises there is a desire not to reveal
   internal network structure (or other related information) outside of
   a closed community. An adversary might be able to use NSIS messages
   for network mapping (e.g., discovering which nodes exist, which use
   NSIS, what version, what resources are allocated, what capabilities
   nodes along a path have, etc.). Discovery messages, traceroute,
   diagnostic messages (see [RFC2745] for a description of diagnostic
   message functionality for RSVP), and query messages, in addition to
   record route and route objects, provide potential assistance to an
   adversary. Hence, the requirement of not disclosing a network
   topology might conflict with other requirements to provide means for
   automatically discovering NSIS-aware nodes or to provide diagnostic
   facilities (used for network monitoring and administration).

4.10 Unprotected Session or Reservation Ownership

   Figure 3 shows an NSIS Initiator that has established state
   information at NSIS nodes along a path as part of the signaling
   procedure. As a result, Access Router 1, Router 3, and Router 4 (and
   other nodes) have stored session state information including the
   Session Identifier SID-x.

                                            Session ID(SID-x)
                                       +--------+
                     +-----------------+ Router +------------>
    Session ID(SID-x)|                 |   4    |
                 +---+----+            +--------+
                 | Router |
          +------+   3    +*******
          |      +---+----+      *
          |                      *
          | Session ID(SID-x)    * Session ID(SID-x)
      +---+----+             +---+----+
      | Access |             | Access |
      | Router |             | Router |
      |   1    |             |   2    |
      +---+----+             +---+----+
          |                      *
          | Session ID(SID-x)    * Session ID(SID-x)
     +----+------+          +----+------+
     |  NSIS     |          | Adversary |
     | Initiator |          |           |
     +-----------+          +-----------+

                Figure 3: Session or Reservation Ownership

   The Session Identifier is included in signaling messages to
   reference to the established state.



Tschofenig, Kroeselberg    Expires - August 2004             [Page 19]

                      Security Threats for NSIS         February 2004


   If an adversary were able to obtain the Session Identifier, for
   example by eavesdropping on signaling messages, it would be able to
   add the same Session Identifier SID-x to a new signaling message.
   When the new signaling message hits Router 3 (as shown in Figure 3),
   existing state information can be modified. The adversary can then
   modify or delete the established reservation and cause unexpected
   behavior for the legitimate user.

   The source of the problem is that Router 3 (a cross-over router) is
   unable to decide whether the new signaling message was initiated
   from the owner of the session or reservation.

   In addition, nodes other than the initial signaling message
   originator are allowed to signal information during the lifetime of
   an established session. As part of the protocol, any NSIS-aware node
   along the path (and the path might change over time) could initiate
   a signaling message exchange. It might, for example, be necessary to
   provide mobility support or to trigger a local repair procedure. If
   only the initial signaling message originator were allowed to
   trigger signaling message exchanges, some protocol behavior would
   not be possible.

   If this threat scenario is not addressed, an adversary can launch
   DoS, theft of service, and various other attacks.

4.11 Attacks against the Transport Mechanism

   In [BL01] a two-level architecture is proposed, which suggests
   splitting an NSIS protocol into layers: a signaling message
   transport-specific layer and an application-specific layer. This
   architectural assumption is also considered within the NSIS
   framework [HF+03]. Most of the threats described in this document
   are applicable to the application-specific part (i.e., signaling QoS
   or middlebox-specific information). There are, however, some threats
   that are applicable to the transport of signaling messages.

   Network or transport layer protocols lacking protection mechanisms
   are vulnerable to certain attacks such as header manipulation, DoS,
   spoofing of identities, session hijacking, unexpected aborts, etc.

   Malicious nodes can attack the congestion control mechanism to force
   NSIS nodes into a congestion avoidance state.

   In the case in which existing protocols are used for exchanging NSIS
   signaling messages, known threats scenarios applicable to these
   protocols are relevant.





Tschofenig, Kroeselberg    Expires - August 2004             [Page 20]

                      Security Threats for NSIS         February 2004


5. Security Considerations

   This entire memo discusses security issues relevant for NSIS
   protocol design. It begins by identifying the components of a
   network running NSIS (Initiator, Responder, and different
   Administrative Domains between them). It then considers five cases
   in which communications take place between these components, and it
   examines the trust relationships presumed to exist in each case:
   First-Peer Communications, End-to-Middle Communications, Intra-
   Domain Communications, Inter-Domain Communications, and End-to-End
   Communications. This analysis helps determine the security needs and
   the relative seriousness of different threats in the different
   cases.

   The document points out the need for different protocol security
   measures: authentication, key exchange, message integrity, replay
   protection, confidentiality, authorization, and some precautions
   against denial of service. The threats are subdivided into generic
   ones (e.g., man-in-the-middle attacks, replay attacks, tampering and
   forgery, and attacks on security negotiation protocols) and 11
   threat scenarios particularly applicable to the NSIS protocol.
   Denial of service, for example, is covered in the NSIS-specific
   section, not because it cannot be carried out against other
   protocols, but because the methods used to carry out denial of
   service attacks tend to be protocol specific. Numerous illustrative
   examples provide insight into what can happen if these threats are
   not mitigated.

   This document points out repeatedly that not all of the threats are
   equally serious in every context. It does attempt to identify the
   scenarios in which security failures may have the highest impact.
   However, it is difficult for the protocol designer to foresee all
   the ways in which NSIS protocols will be used or to anticipate the
   security concerns of a wide variety of likely users. Therefore, the
   protocol designer needs to offer a full range of security
   capabilities and ways for users to negotiate and select what they
   need, case by case. To counter these threats, security requirements
   have been listed in [Brun03]. Topics relevant to the NSIS Framework
   have been incorporated into [HF+03].


6. Normative References

   [Brun03] M. Brunner, "Requirements for QoS signaling protocols,"
   Internet Draft, Internet Engineering Task Force, August 2003.  Work
   in progress.





Tschofenig, Kroeselberg    Expires - August 2004             [Page 21]

                      Security Threats for NSIS         February 2004


7. Informative References

   [HF+03] R. Hancock, I. Freytsis, G. Karagiannis, J. Loughney, and S.
   V. den Bosch, "Next steps in signaling: Framework," Internet Draft,
   Internet Engineering Task Force, September 2003.  Work in progress.

   [RFC1809] C. Partridge, "Using the flow label field in IPv6," RFC
   1809, Internet Engineering Task Force, June 1995.

   [RFC2745] A. Terzis, B. Braden, S. Vincent, and L. Zhang, "RSVP
   Diagnostic Messages," RFC 2745, Internet Engineering Task Force,
   Jan. 2000.

   [RFC3182]   Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore,
   T., Herzog, S., Hess, R.: "Identity Representation for RSVP", RFC
   3182, October, 2001.

   [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston,
   J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
   initiation protocol," RFC 3261, Internet Engineering Task Force,
   June 2002.

   [RFC3521]   L. Hamer, B. Gage, and H. Shieh, "Framework for session
   set-up with media authorization," RFC 3521, Internet Engineering
   Task Force, April 2003.

   [RFC3520] L. Hamer, B. Gage, B. Kosinski, and H. Shieh, "Session
   Authorization Policy Element", RFC 3520, Internet Engineering Task
   Force, April 2003.

   [RC+03] J. Rajahalme, A. Conta, B. Carpenter, and S. Deering, "IPv6
   Flow Label Specification," Internet Draft, Internet Engineering Task
   Force, April 2003.  Work in progress.

   [BL01] B. Braden and B. Lindell, "A two-level architecture for
   internet signaling," Internet Draft, Internet Engineering Task
   Force, Nov. 2001. (Expired).

   [AN97] T. Aura and P. Nikander: "Stateless Connections", In
   Proceedings of the International Conference on Information and
   Communications Security (ICICS'97), Lecture Notes in Computer
   Science 1334, Springer, 1997.

   [ALN00] T. Aura, J. Leiwo and P. Nikander: "Towards Network Denial
   of Service Resistant Protocols", In Proceedings of the 15th
   International Information Security Conference (IFIP/SEC 2000),
   Beijing, China, August 2000.




Tschofenig, Kroeselberg    Expires - August 2004             [Page 22]

                      Security Threats for NSIS         February 2004


Author's Addresses

   Hannes Tschofenig
   Siemens AG
   Corporate Technology
   CT IC 3
   Otto-Hahn-Ring 6
   81739 Munich
   Germany
   EMail: Hannes.Tschofenig@siemens.com

   Dirk Kroeselberg
   Siemens AG
   Otto-Hahn-Ring 6
   81739 Munich
   Germany
   EMail: Dirk.Kroeselberg@siemens.com


Appendix A. Contributors

We especially thank Richard Graveman, who provided text for the
security considerations section, besides a detailed review of the
document.

Appendix B. Acknowledgments

   We would like to thank (in alphabetical order) Marcus Brunner, Jorge
   Cuellar, Mehmet Ersue, Xiaoming Fu, and Robert Hancock for their
   comments on an initial version of this draft. Jorge and Robert gave
   us an extensive list of comments and provided information on
   additional threats.

   Jukka Manner, Martin Buechli, Roland Bless, Marcus Brunner, Michael
   Thomas, Cedric Aoun, John Loughney, Rene Soltwisch, Cornelia
   Kappler, and Mohan Parthasarathy provided comments on a recent
   version of this draft. Their input helped improve the content of
   this document. Roland Bless, Michael Thomas, and Cornelia Kappler,
   in particular, provided good proposals for regrouping and
   restructuring the material.

   A final review was given by Michael Richardson. We thank him for the
   detailed comments.


Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.



Tschofenig, Kroeselberg    Expires - August 2004             [Page 23]

                      Security Threats for NSIS         February 2004


   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.






















Tschofenig, Kroeselberg    Expires - August 2004             [Page 24]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/