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]
