Request for Comments: 4081 D. Kroeselberg
Category: Informational Siemens
June 2005
Security Threats for Next Steps in Signaling (NSIS)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This threats document provides a detailed analysis of the security
threats relevant to the Next Steps in Signaling (NSIS) protocol
suite. It calls attention to, and helps with the understanding of,
various security considerations in the NSIS Requirements, Framework,
and Protocol proposals. This document does not describe
vulnerabilities of specific parts of the NSIS protocol suite.
Table of Contents
1. Introduction ....................................................2
2. Communications Models ...........................................3
3. Generic Threats .................................................7
3.1. Man-in-the-Middle Attacks ..................................8
3.2. Replay of Signaling Messages ..............................11
3.3. Injecting or Modifying Messages ...........................11
3.4. Insecure Parameter Exchange and Negotiation ...............12
4. NSIS-Specific Threat Scenarios .................................12
4.1. Threats during NSIS SA Usage ..............................13
4.2. Flooding ..................................................13
4.3. Eavesdropping and Traffic Analysis ........................15
4.4. Identity Spoofing .........................................15
4.5. Unprotected Authorization Information .....................17
4.6. Missing Non-Repudiation ...................................18
4.7. Malicious NSIS Entity .....................................19
4.8. Denial of Service Attacks .................................20
4.9. Disclosing the Network Topology ...........................21
4.10. Unprotected Session or Reservation Ownership .............21
4.11. Attacks against the NTLP .................................23
5. Security Considerations ........................................23
6. Contributors ...................................................24
7. Acknowledgements ...............................................24
8. References .....................................................25
8.1. Normative References ......................................25
8.2. Informative References ....................................25
1. Introduction
Whenever a new protocol is developed or existing protocols are
modified, threats to their security should be evaluated. To address
security in the NSIS working group, a number of steps have been
taken:
NSIS Analysis Activities (see [RSVP-SEC] and [SIG-ANAL])
Security Threats for NSIS
NSIS Requirements (see [RFC3726])
NSIS Framework (see [RFC4080])
NSIS Protocol Suite (see GIMPS [GIMPS], NAT/Firewall NSLP
[NATFW-NSLP] and QoS NSLP [QOS-NSLP])
This document identifies the basic security threats that need to be
addressed during the design of the NSIS protocol suite. Even if the
base protocol is secure, certain extensions may cause problems when
used in a particular environment.
This document cannot provide detailed threats for all possible NSIS
Signaling Layer Protocols (NSLPs). QoS [QOS-NSLP], NAT/Firewall
[NATFW-NSLP], and other NSLP documents need to provide a description
of their trust models and a threat assessment for their specific
application domain. This document aims to provide some help for the
subsequent design of the NSIS protocol suite. Investigations of
security threats in a specific architecture or context are outside
the scope of this document.
We use the NSIS terms defined in [RFC3726] and in [RFC4080].
2. Communications Models
The NSIS suite of protocols is envisioned to support various
signaling applications that need to install and/or manipulate state
at nodes along the data flow path through the network. As such, the
NSIS protocol suite involves the communication between different
entities.
This section offers terminology for common communication models that
are relevant to securing the NSIS protocol suite.
An abstract network topology with its administrative domains is shown
in Figure 1, and in Figure 2 the relationship between NSIS entities
along the path is shown. For illustrative reasons, only end-to-end
NSIS signaling is depicted, yet it might be used in other variations
as well. Signaling can start at any place and might terminate at any
other place within the network. Depending on the trust relationship
between NSIS entities and the traversed network parts, different
security problems arise.
The notion of trust and trust relationship used in this document is
informal and can best be captured by the definition provided in
Section 1.1 of [RFC3756]. For completeness we include the definition
of a trust relationship, which denotes a mutual a priori relationship
between the involved organizations or parties wherein the parties
believe that the other parties will behave correctly even in the
future.
An important observation for NSIS is that a certain degree of trust
has to be placed into intermediate NSIS nodes along the path between
an NSIS Initiator and an NSIS Responder, specifically so that they
perform message processing and take the necessary actions. A
complete lack of trust between any of the participating entities will
cause NSIS signaling to fail.
Note that it is not possible to describe a trust model completely
without considering the details and behavior of the NTLP, the NSLP
(e.g., QoS NSLP), and the deployment environment. For example,
securing the communication between an end host (which acts as the
NSIS Initiator) and the first NSIS node (which might be in the
attached network or even a number of networks away) is impacted by
the trust relationships between these entities. In a corporate
network environment, a stronger degree of trust typically exists than
in an unmanaged network.
Figure 1 introduces convenient abbreviations for network parts with
similar properties: first-peer, last-peer, intra-domain, or
inter-domain.
+------------------+ +---------------+ +------------------+
| | | | | |
| Administrative | | Intermediate | | Administrative |
| Domain A | | Domains | | Domain B |
| | | | | |
| (Inter-domain Communication) |
| +-------->+---+<------------->+---+<--------+ |
| (Intra-domain | | | | (Intra-domain |
| Communication) | | | | Communication) |
| | | | | | | |
| v | | | | v |
+--------+---------+ +---------------+ +---------+--------+
^ ^
| |
First Peer Communication Last Peer Communication
| |
v v
+-----+-----+ +-----+-----+
| NSIS | | NSIS |
| Initiator | | Responder |
+-----------+ +-----------+
Figure 1: Communication patterns in NSIS
First-Peer/Last-Peer Communication:
The end-to-end communication scenario depicted in Figure 1
includes the communication between the end hosts and their nearest
NSIS hops. "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.
This "first-peer communications" commonly comes with specific
security requirements that are especially important for addressing
security issues between the end host (and a user) and the network
it is attached to.
To illustrate this, in roaming 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 with each other. In contrast, in
enterprise networks 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 infrastructure already
available, and per-session negotiation of security mechanisms is
often not required (although, in contrast, it is required in a
roaming environment).
Last-Peer communication is a variation of First-Peer communication
in which the roles are reversed.
Intra-Domain Communication:
After verification of the NSIS signaling message at the border of
an administrative domain, an NSIS signaling message traverses the
network within the same administrative domain to which the first
peer belongs. It might not be necessary to repeat the
authorization procedure of the NSIS initiator again at every NSIS
node within this domain. Key management within the administrative
domain might also be simpler.
Security protection is still required to prevent threats by
non-NSIS nodes in this network.
Inter-Domain Communication:
Inter-Domain communication deals with the interaction between
administrative domains. For some NSLPs (for example, QoS NSLP),
this interaction is likely to take place between neighboring
domains, whereas in other NSLPs (such as the NAT/Firewall NSLP),
the core network is usually not involved.
If signaling messages are conveyed transparently in the core
network (i.e., if they are neither intercepted nor processed in
the core network), then the signaling message communications
effectively takes place between access networks. This might place
a burden on authorization handling and on the key management
infrastructure required between these access networks, which might
not know of each other in advance.
To refine the above differentiation based on the network parts that
NSIS signaling may traverse, we subsequently consider relationships
between involved entities. Because a number of NSIS nodes might
actively participate in a specific protocol exchange, a larger number
of possible relationships need to be analyzed than in other
protocols. Figure 2 illustrates possible relationships between the
entities involved in the NSIS protocol suite.
****************************************
* *
+----+-----+ +----------+ +----+-----+
+-----+ NSIS +-------+ NSIS +--------+ NSIS +-----+
| | Node 1 | | Node 2 | | Node 3 | |
| +----------+ +----+-----+ +----------+ |
| ~ |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| ~ |
+--+--+-----+ +---------+-+
| NSIS +//////////////////////////////////////////+ NSIS |
| Initiator | | Responder |
+-----------+ +-----------+
Legend:
-----: Peer-to-Peer Relationship
/////: End-to-End Relationship
*****: Middle-to-Middle Relationship
~~~~~: End-to-Middle Relationship
Figure 2: Possible NSIS Relationships
End-to-Middle Communications:
The scenario in which one NSIS entity involved is an end-entity
(Initiator or Responder) and the other entity is any intermediate
hop other than the immediately adjacent peer is typically called
the end-to-middle scenario (see Figure 2). A motivation for
including this scenario can, for example, be found in SIP
[RFC3261].
An example of end-to-middle interaction might be an explicit
authorization from the NSIS Initiator to some intermediate node.
Threats specific to this scenario may be introduced by some
intermediate NSIS hops that are not allowed to eavesdrop or modify
certain objects.
Middle-to-Middle Communications:
Middle-to-middle communication refers to the exchange of
information between two non-neighboring NSIS nodes along the path.
Intermediate NSIS hops may have to deal with specific security
threats that do not involve the NSIS Initiator or the NSIS
Responder directly.
End-to-End Communications:
NSIS aims to signal information from an Initiator to some NSIS
nodes along the path to a data receiver. In the case of
end-to-end NSIS signaling, the last node is the NSIS Responder, as
it is the data receiver. The NSIS protocol suite is not an
end-to-end protocol used to exchange information purely between
end hosts.
Typically, it is not required to protect NSIS messages
cryptographically between the NSIS Initiator and the NSIS
Responder. Protecting the entire signaling message end-to-end
might not be feasible since intermediate NSIS nodes need to add,
inspect, modify, or delete objects from the signaling message.
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
that are hosts and those that are users (based on the identifiers
used).
For the following subsections, we use the general distinction in 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 by briefly describing a motivation for
this separation.
Security protection of protocols is often separated into two steps.
The first step primarily provides 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 security threats that exist if two peers
do not already share a security association or do not use security
mechanisms at all, and threats that are applicable when a security
association is already established.
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 to steal services that get billed
to the Initiator. In addition, the adversary may be able to
terminate the Initiator’s NSIS messages and to inject messages to
a peer itself, thereby acting as the peer to the Initiator and as
the Initiator to the peer. As a result, the Initiator wrongly
believes that it is talking to the "real" network, whereas it is
actually attached to an adversary. For this attack to be
successful, pre-conditions that are described in the following
three cases have to hold:
Missing Authentication:
In the first case, this threat can be carried out because of
missing authentication between neighboring peers: without
authentication, an 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 there are 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. This configuration allows 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 communications. Unilateral
authentication between an end host and the first peer (just
authenticating the end host) is still common today, but it
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 address this correctly in a future NSIS protocol
suite. 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 there could impact nodes beyond the
entities directly involved (or even beyond a local network).
Finally, note that the signaling protocol should be considered
a peer-to-peer protocol, wherein the roles of Initiator and
Responder can be reversed at any time. Thus, unilateral
authentication is not particularly useful for such a protocol.
However, some form of asymmetry might be needed in the
authentication process, whereby one entity uses an
authentication mechanism different from that of the other one.
As an example, the combination of symmetric and asymmetric
cryptography should be mentioned.
Weak Authentication:
In the case of weak authentication, the threat can be carried
out because 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.
Finally, we conclude with a description of a man-in-the-middle (MITM)
attack during the discovery phase. This attack benefits from the
fact that NSIS nodes are likely to be unaware of the network
topology. Furthermore, an authorization problem might arise if an
NSIS QoS NSLP node pretends to be an NSIS NAT/Firewall-specific node
or vice versa.
An adversary might inject a bogus reply message, forcing the
discovery message initiator to start a messaging association
establishment with either an adversary or with another NSIS node that
is not along the path. Figure 3 describes the attack in more detail
for peer-to-peer addressed messages with a discovery mechanism. For
end-to-end addressed messages, the attack is also applicable,
particularly if the adversary is located along the path and able to
intercept the discovery message that traverses the adversary. The