NSIS Internet Draft H. Tschofenig D. Kroeselberg Siemens Document: draft-ietf-nsis-threats-04.txt Expires: August 2004 February 2004 Security Threats for NSIS 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]