From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4081.txt | 1571 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1571 insertions(+) create mode 100644 doc/rfc/rfc4081.txt (limited to 'doc/rfc/rfc4081.txt') diff --git a/doc/rfc/rfc4081.txt b/doc/rfc/rfc4081.txt new file mode 100644 index 0000000..c3a519b --- /dev/null +++ b/doc/rfc/rfc4081.txt @@ -0,0 +1,1571 @@ + + + + + + +Network Working Group H. Tschofenig +Request for Comments: 4081 D. Kroeselberg +Category: Informational Siemens + June 2005 + + + Security Threats for Next Steps in Signaling (NSIS) + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This threats document provides a detailed analysis of the security + threats relevant to the Next Steps in Signaling (NSIS) protocol + suite. It calls attention to, and helps with the understanding of, + various security considerations in the NSIS Requirements, Framework, + and Protocol proposals. This document does not describe + vulnerabilities of specific parts of the NSIS protocol suite. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Communications Models ...........................................3 + 3. Generic Threats .................................................7 + 3.1. Man-in-the-Middle Attacks ..................................8 + 3.2. Replay of Signaling Messages ..............................11 + 3.3. Injecting or Modifying Messages ...........................11 + 3.4. Insecure Parameter Exchange and Negotiation ...............12 + 4. NSIS-Specific Threat Scenarios .................................12 + 4.1. Threats during NSIS SA Usage ..............................13 + 4.2. Flooding ..................................................13 + 4.3. Eavesdropping and Traffic Analysis ........................15 + 4.4. Identity Spoofing .........................................15 + 4.5. Unprotected Authorization Information .....................17 + 4.6. Missing Non-Repudiation ...................................18 + 4.7. Malicious NSIS Entity .....................................19 + 4.8. Denial of Service Attacks .................................20 + 4.9. Disclosing the Network Topology ...........................21 + 4.10. Unprotected Session or Reservation Ownership .............21 + 4.11. Attacks against the NTLP .................................23 + + + +Tschofenig & Kroeselberg Informational [Page 1] + +RFC 4081 Security Threats for NSIS June 2005 + + + 5. Security Considerations ........................................23 + 6. Contributors ...................................................24 + 7. Acknowledgements ...............................................24 + 8. References .....................................................25 + 8.1. Normative References ......................................25 + 8.2. Informative References ....................................25 + +1. Introduction + + Whenever a new protocol is developed or existing protocols are + modified, threats to their security should be evaluated. To address + security in the NSIS working group, a number of steps have been + taken: + + NSIS Analysis Activities (see [RSVP-SEC] and [SIG-ANAL]) + + Security Threats for NSIS + + NSIS Requirements (see [RFC3726]) + + NSIS Framework (see [RFC4080]) + + NSIS Protocol Suite (see GIMPS [GIMPS], NAT/Firewall NSLP + [NATFW-NSLP] and QoS NSLP [QOS-NSLP]) + + This document identifies the basic security threats that need to be + addressed during the design of the NSIS protocol suite. Even if the + base protocol is secure, certain extensions may cause problems when + used in a particular environment. + + This document cannot provide detailed threats for all possible NSIS + Signaling Layer Protocols (NSLPs). QoS [QOS-NSLP], NAT/Firewall + [NATFW-NSLP], and other NSLP documents need to provide a description + of their trust models and a threat assessment for their specific + application domain. This document aims to provide some help for the + subsequent design of the NSIS protocol suite. Investigations of + security threats in a specific architecture or context are outside + the scope of this document. + + We use the NSIS terms defined in [RFC3726] and in [RFC4080]. + + + + + + + + + + + +Tschofenig & Kroeselberg Informational [Page 2] + +RFC 4081 Security Threats for NSIS June 2005 + + +2. Communications Models + + The NSIS suite of protocols is envisioned to support various + signaling applications that need to install and/or manipulate state + at nodes along the data flow path through the network. As such, the + NSIS protocol suite involves the communication between different + entities. + + This section offers terminology for common communication models that + are relevant to securing the NSIS protocol suite. + + An abstract network topology with its administrative domains is shown + in Figure 1, and in Figure 2 the relationship between NSIS entities + along the path is shown. For illustrative reasons, only end-to-end + NSIS signaling is depicted, yet it might be used in other variations + as well. Signaling can start at any place and might terminate at any + other place within the network. Depending on the trust relationship + between NSIS entities and the traversed network parts, different + security problems arise. + + The notion of trust and trust relationship used in this document is + informal and can best be captured by the definition provided in + Section 1.1 of [RFC3756]. For completeness we include the definition + of a trust relationship, which denotes a mutual a priori relationship + between the involved organizations or parties wherein the parties + believe that the other parties will behave correctly even in the + future. + + An important observation for NSIS is that a certain degree of trust + has to be placed into intermediate NSIS nodes along the path between + an NSIS Initiator and an NSIS Responder, specifically so that they + perform message processing and take the necessary actions. A + complete lack of trust between any of the participating entities will + cause NSIS signaling to fail. + + Note that it is not possible to describe a trust model completely + without considering the details and behavior of the NTLP, the NSLP + (e.g., QoS NSLP), and the deployment environment. For example, + securing the communication between an end host (which acts as the + NSIS Initiator) and the first NSIS node (which might be in the + attached network or even a number of networks away) is impacted by + the trust relationships between these entities. In a corporate + network environment, a stronger degree of trust typically exists than + in an unmanaged network. + + Figure 1 introduces convenient abbreviations for network parts with + similar properties: first-peer, last-peer, intra-domain, or + inter-domain. + + + +Tschofenig & Kroeselberg Informational [Page 3] + +RFC 4081 Security Threats for NSIS June 2005 + + + +------------------+ +---------------+ +------------------+ + | | | | | | + | Administrative | | Intermediate | | Administrative | + | Domain A | | Domains | | Domain B | + | | | | | | + | (Inter-domain Communication) | + | +-------->+---+<------------->+---+<--------+ | + | (Intra-domain | | | | (Intra-domain | + | Communication) | | | | Communication) | + | | | | | | | | + | v | | | | v | + +--------+---------+ +---------------+ +---------+--------+ + ^ ^ + | | + First Peer Communication Last Peer Communication + | | + v v + +-----+-----+ +-----+-----+ + | NSIS | | NSIS | + | Initiator | | Responder | + +-----------+ +-----------+ + + Figure 1: Communication patterns in NSIS + + First-Peer/Last-Peer Communication: + + The end-to-end communication scenario depicted in Figure 1 + includes the communication between the end hosts and their nearest + NSIS hops. "First-peer communications" refers to the peer-to-peer + interaction between a signaling message originator, the NSIS + Initiator (NI), and the first NSIS-aware entity along the path. + This "first-peer communications" commonly comes with specific + security requirements that are especially important for addressing + security issues between the end host (and a user) and the network + it is attached to. + + To illustrate this, in roaming environments, it is difficult to + assume the existence of a pre-established security association + directly available for NSIS peers involved in first-peer + communications, because these peers cannot be assumed to have any + pre-existing relationship with each other. In contrast, in + enterprise networks usually there is a fairly strong + (pre-established) trust relationship between the peers. + Enterprise network administrators usually have some degree of + freedom to select the appropriate security protection and to + enforce it. The choice of selecting a security mechanism is + therefore often influenced by the infrastructure already + + + + +Tschofenig & Kroeselberg Informational [Page 4] + +RFC 4081 Security Threats for NSIS June 2005 + + + available, and per-session negotiation of security mechanisms is + often not required (although, in contrast, it is required in a + roaming environment). + + Last-Peer communication is a variation of First-Peer communication + in which the roles are reversed. + + Intra-Domain Communication: + + After verification of the NSIS signaling message at the border of + an administrative domain, an NSIS signaling message traverses the + network within the same administrative domain to which the first + peer belongs. It might not be necessary to repeat the + authorization procedure of the NSIS initiator again at every NSIS + node within this domain. Key management within the administrative + domain might also be simpler. + + Security protection is still required to prevent threats by + non-NSIS nodes in this network. + + Inter-Domain Communication: + + Inter-Domain communication deals with the interaction between + administrative domains. For some NSLPs (for example, QoS NSLP), + this interaction is likely to take place between neighboring + domains, whereas in other NSLPs (such as the NAT/Firewall NSLP), + the core network is usually not involved. + + If signaling messages are conveyed transparently in the core + network (i.e., if they are neither intercepted nor processed in + the core network), then the signaling message communications + effectively takes place between access networks. This might place + a burden on authorization handling and on the key management + infrastructure required between these access networks, which might + not know of each other in advance. + + To refine the above differentiation based on the network parts that + NSIS signaling may traverse, we subsequently consider relationships + between involved entities. Because a number of NSIS nodes might + actively participate in a specific protocol exchange, a larger number + of possible relationships need to be analyzed than in other + protocols. Figure 2 illustrates possible relationships between the + entities involved in the NSIS protocol suite. + + + + + + + + +Tschofenig & Kroeselberg Informational [Page 5] + +RFC 4081 Security Threats for NSIS June 2005 + + + **************************************** + * * + +----+-----+ +----------+ +----+-----+ + +-----+ NSIS +-------+ NSIS +--------+ NSIS +-----+ + | | Node 1 | | Node 2 | | Node 3 | | + | +----------+ +----+-----+ +----------+ | + | ~ | + | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | + | ~ | + +--+--+-----+ +---------+-+ + | NSIS +//////////////////////////////////////////+ NSIS | + | Initiator | | Responder | + +-----------+ +-----------+ + + Legend: + -----: Peer-to-Peer Relationship + /////: End-to-End Relationship + *****: Middle-to-Middle Relationship + ~~~~~: End-to-Middle Relationship + + Figure 2: Possible NSIS Relationships + + End-to-Middle Communications: + + The scenario in which one NSIS entity involved is an end-entity + (Initiator or Responder) and the other entity is any intermediate + hop other than the immediately adjacent peer is typically called + the end-to-middle scenario (see Figure 2). A motivation for + including this scenario can, for example, be found in SIP + [RFC3261]. + + An example of end-to-middle interaction might be an explicit + authorization from the NSIS Initiator to some intermediate node. + Threats specific to this scenario may be introduced by some + intermediate NSIS hops that are not allowed to eavesdrop or modify + certain objects. + + Middle-to-Middle Communications: + + Middle-to-middle communication refers to the exchange of + information between two non-neighboring NSIS nodes along the path. + Intermediate NSIS hops may have to deal with specific security + threats that do not involve the NSIS Initiator or the NSIS + Responder directly. + + + + + + + +Tschofenig & Kroeselberg Informational [Page 6] + +RFC 4081 Security Threats for NSIS June 2005 + + + End-to-End Communications: + + NSIS aims to signal information from an Initiator to some NSIS + nodes along the path to a data receiver. In the case of + end-to-end NSIS signaling, the last node is the NSIS Responder, as + it is the data receiver. The NSIS protocol suite is not an + end-to-end protocol used to exchange information purely between + end hosts. + + Typically, it is not required to protect NSIS messages + cryptographically between the NSIS Initiator and the NSIS + Responder. Protecting the entire signaling message end-to-end + might not be feasible since intermediate NSIS nodes need to add, + inspect, modify, or delete objects from the signaling message. + +3. Generic Threats + + This section provides scenarios of threats that are applicable to + signaling protocols in general. Note that some of these scenarios + use the term "user" instead of "NSIS Initiator". This is mainly + because security protocols allow differentiation between entities + that are hosts and those that are users (based on the identifiers + used). + + For the following subsections, we use the general distinction in two + cases in which attacks may occur. These are according to the + separate steps, or phases, normally encountered when applying + protocol security (with, e.g., IPsec, TLS, Kerberos, or SSH). + Therefore, this section starts by briefly describing a motivation for + this separation. + + Security protection of protocols is often separated into two steps. + The first step primarily provides entity authentication and key + establishment (which result in a persistent state often called a + security association), whereas the second step provides message + protection (some combination of data origin authentication, data + integrity, confidentiality, and replay protection) using the + previously established security association. The first step tends to + be more expensive than the second, which is the main reason for the + separation. If messages are transmitted infrequently, then these two + steps may be collapsed into a single and usually rather costly one. + One such example is e-mail protection via S/MIME. The two steps may + be tightly bound into a single protocol, as in TLS, or defined in + separate protocols, as with IKE and IPsec. We use this separation to + cover the different threats in more detail. + + + + + + +Tschofenig & Kroeselberg Informational [Page 7] + +RFC 4081 Security Threats for NSIS June 2005 + + +3.1. Man-in-the-Middle Attacks + + This section describes both security threats that exist if two peers + do not already share a security association or do not use security + mechanisms at all, and threats that are applicable when a security + association is already established. + + Attacks during NSIS SA Establishment: + + While establishing a security association, an adversary fools the + signaling message Initiator with respect to the entity to which it + has to authenticate. The Initiator authenticates to the man-in- + the-middle adversary, who is then able to modify signaling + messages to mount DoS attacks or to steal services that get billed + to the Initiator. In addition, the adversary may be able to + terminate the Initiator's NSIS messages and to inject messages to + a peer itself, thereby acting as the peer to the Initiator and as + the Initiator to the peer. As a result, the Initiator wrongly + believes that it is talking to the "real" network, whereas it is + actually attached to an adversary. For this attack to be + successful, pre-conditions that are described in the following + three cases have to hold: + + Missing Authentication: + + In the first case, this threat can be carried out because of + missing authentication between neighboring peers: without + authentication, an NI, NR, or NF is unable to detect an + adversary. However, in some practical cases, authentication + might be difficult to accomplish, either because the next peer + is unknown, because there are misbelieved trust relationships + in parts of the network, or because of the inability to + establish proper security protection (inter-domain signaling + messages, dynamic establishment of a security association, + etc.). If one of the communicating endpoints is unknown, then + for some security mechanisms it is either impossible or + impractical to apply appropriate security protection. + Sometimes network administrators use intra-domain signaling + messages without proper security. This configuration allows an + adversary on a compromised non-NSIS-aware node to interfere + with nodes running an NSIS signaling protocol. Note that this + type of threat goes beyond those caused by malicious NSIS nodes + (described in Section 4.7). + + + + + + + + +Tschofenig & Kroeselberg Informational [Page 8] + +RFC 4081 Security Threats for NSIS June 2005 + + + Unilateral Authentication: + + In the case of unilateral authentication, the NSIS entity that + does not authenticate its peer is unable to discover a man-in- + the-middle adversary. Although mutual authentication of + signaling messages should take place between each peer + participating in the protocol operation, special attention is + given here to first-peer communications. Unilateral + authentication between an end host and the first peer (just + authenticating the end host) is still common today, but it + opens up many possibilities for man-in-the-middle attackers + impersonating either the end host or the (administrative domain + represented by the) first peer. + + Missing or unilateral authentication, as described above, is + part of a general problem of network access with inadequate + authentication, and it should not be considered something + unique to the NSIS signaling protocol. Obviously, there is a + strong need to address this correctly in a future NSIS protocol + suite. The signaling protocols addressed by NSIS are different + from other protocols in which only two entities are involved. + Note that first-peer authentication is especially important + because a security breach there could impact nodes beyond the + entities directly involved (or even beyond a local network). + + Finally, note that the signaling protocol should be considered + a peer-to-peer protocol, wherein the roles of Initiator and + Responder can be reversed at any time. Thus, unilateral + authentication is not particularly useful for such a protocol. + However, some form of asymmetry might be needed in the + authentication process, whereby one entity uses an + authentication mechanism different from that of the other one. + As an example, the combination of symmetric and asymmetric + cryptography should be mentioned. + + Weak Authentication: + + In the case of weak authentication, the threat can be carried + out because information transmitted during the NSIS SA + establishment process may leak passwords or allow offline + dictionary attacks. This threat is applicable to NSIS for the + process of selecting certain security mechanisms. + + Finally, we conclude with a description of a man-in-the-middle (MITM) + attack during the discovery phase. This attack benefits from the + fact that NSIS nodes are likely to be unaware of the network + + + + + +Tschofenig & Kroeselberg Informational [Page 9] + +RFC 4081 Security Threats for NSIS June 2005 + + + topology. Furthermore, an authorization problem might arise if an + NSIS QoS NSLP node pretends to be an NSIS NAT/Firewall-specific node + or vice versa. + + An adversary might inject a bogus reply message, forcing the + discovery message initiator to start a messaging association + establishment with either an adversary or with another NSIS node that + is not along the path. Figure 3 describes the attack in more detail + for peer-to-peer addressed messages with a discovery mechanism. For + end-to-end addressed messages, the attack is also applicable, + particularly if the adversary is located along the path and able to + intercept the discovery message that traverses the adversary. The + man-in-the-middle adversary might redirect to another legitimate NSIS + node. A malicious NSIS node can be detected with the corresponding + security mechanisms, but a legitimate NSIS node that is not the next + NSIS node along the path cannot be detected without topology + knowledge. + + +-----------+ Messaging Association + Message | Adversary | Establishment + Association +--->+ +<----------------+ + Establish- | +----+------+ |(4) + ment | IPx | | + (3)| |Discovery Reply v + | | (IPx) +---+-------+ + v | (2) | NSIS | + +------+-----+ | /----------->+ Node B +-------- + | NSIS +<--+ / Discovery +-----------+ + | Node A +---------/ Request IPr + +------------+ (1) + IPi + + Figure 3: MITM Attack during the Discovery Exchange + + This attack assumes that the adversary is able to eavesdrop on the + initial discovery message sent by the sender of the discovery + message. Furthermore, we assume that the discovery reply message by + the adversary returns to the discovery message initiator faster than + the real response. This represents some race condition + characteristics if the next NSIS node is very close (in IP-hop terms) + to the initiator. Note that the problem is self-healing since the + discovery process is periodically repeated. If an adversary is + unable to mount this attack with every discovery message, then the + correct next NSIS node along the path will be discovered again. A + ping-pong behavior might be the consequence. + + + + + + +Tschofenig & Kroeselberg Informational [Page 10] + +RFC 4081 Security Threats for NSIS June 2005 + + + As shown in message step (2) in Figure 3, the adversary returns a + discovery reply message with its own IP address as the next NSIS- + aware node along the path. Without any additional information, the + discovery message initiator has to trust this information. Then a + messaging association is established with an entity at a given IP + address IPx (i.e., with the adversary) in step (3). The adversary + then establishes a messaging association with a further NSIS node and + forwards the signaling message. Note that the adversary might just + modify the Discovery Reply message to force NSIS Node A to establish + a messaging association with another NSIS node that is not along the + path. This can then be exploited by the adversary. The interworking + with NSIS-unaware NATs in particular might cause additional + unexpected problems. + + As a variant of this attack, an adversary not able to eavesdrop on + transmitted discovery requests could flood a node with bogus + discovery reply messages. If the discovery message sender + accidentally accepts one of those bogus messages, then a MITM attack + as described in Figure 3 is possible. + +3.2. Replay of Signaling Messages + + This threat scenario covers the case in which an adversary + eavesdrops, 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 if there is + replay protection) requires that the adversary crash an NSIS-aware + node, causing it to lose state information (sequence numbers, + security associations, etc.), and then replay old signaling 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) in order 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 + + + + +Tschofenig & Kroeselberg Informational [Page 11] + +RFC 4081 Security Threats for NSIS June 2005 + + + spoofing, it is 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 to mount a downgrading attack to force selection of + mechanisms weaker than those mutually desired. Thus, without binding + the negotiation process to the legitimate parties and protecting it, + an NSIS protocol suite might only be 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 eleven 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, + 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 they are often enabled by one or more deficiencies + described under other scenarios. + + + + + + + +Tschofenig & Kroeselberg Informational [Page 12] + +RFC 4081 Security Threats for NSIS June 2005 + + +4.1. Threats during 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. Flooding + + This section describes attacks that allow an adversary to flood an + NSIS node with bogus signaling messages to cause a denial of service + attack. + + We will discuss this threat at different layers in the NSIS protocol + suite: + + Processing of Router Alert Options: + + The processing of Router Alert Option (RAO) requires that a router + do some additional processing by intercepting packets with IP + options, which might lead to additional delay for legitimate + requests, or even rejection of some of them. A router being + flooded with a large number of bogus messages requires resources + before finding out that these messages have to be dropped. + + If the protocol is based on using interception for message + delivery, this threat cannot be completely eliminated, but the + protocol design should attempt to limit the processing that has to + be done on the RAO-bearing packet so that it is as similar as + possible to that for an arbitrary packet addressed directly to one + of the router interfaces. + + Attacks against the Transport Layer Protocol: + + Certain attacks can be mounted against transport protocols by + flooding a node with bogus requests, or even to finish the + handshake phase to establish a transport layer association. These + types of threats are also addressed in Section 4.11. + + + + + + + + + + +Tschofenig & Kroeselberg Informational [Page 13] + +RFC 4081 Security Threats for NSIS June 2005 + + + Force NTLP to Do More Processing: + + Some protocol fields might allow an adversary to force an NTLP + node to perform more processing. Additionally it might be + possible to interfere with the flow control or the congestion + control procedure. These types of threats are also addressed in + Section 4.11. + + Furthermore, it might be possible to force the NTLP node to + perform some computations or signaling message exchanges by + injecting "trigger" events (which are unprotected). + + Force NSLP to Do More Processing: + + An adversary might benefit from flooding an NSLP node with + messages that must be stored (e.g., due to fragmentation handling) + before verifying the correctness of signaling messages. + + Furthermore, causing memory allocation and computational efforts + might allow an adversary to harm NSIS entities. If a signaling + message contains, for example, a digital signature, then some + additional processing is required for the cryptographic + verification. An adversary can easily create a random bit + sequence instead of a digital signature to force an NSIS node into + heavy computation. + + Idempotent signaling messages are particularly vulnerable to this + type of attack. The term "idempotent" refers to messages that + 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 + state along a new path, where 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 the usage of public-key-based cryptosystems in + protocols are described in [AN97] and in [ALN00]. + + In addition to the threat scenario described above, an incoming + signaling message might trigger communication with third-party + nodes such as policy servers, LDAP servers, or AAA servers. 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. + + + + +Tschofenig & Kroeselberg Informational [Page 14] + +RFC 4081 Security Threats for NSIS June 2005 + + +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. + + 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 those that do not. 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) be able to read certain other objects. + +4.4. Identity Spoofing + + Identity spoofing relevant for NSIS occurs in three forms: First, + identity spoofing can happen during the establishment of a security + association based on a weak authentication mechanism. Second, an + adversary can modify the flow identifier carried within a signaling + message. Third, it can spoof 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 + 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 NAT/FW NSLP). + These identifiers are, among others, IP addresses, transport protocol + type (UDP, TCP), port numbers, and flow labels (see [RFC1809] and + [RFC3697]). Modification of these flow identifiers allows + adversaries to exploit or to render ineffective quality of service + + + + +Tschofenig & Kroeselberg Informational [Page 15] + +RFC 4081 Security Threats for NSIS June 2005 + + + reservations or policy rules at middleboxes. An adversary could + mount an attack by modifying the flow identifier of a signaling + message. + + In the third case, an adversary may spoof data traffic. NSIS + signaling messages contain some sort of flow identifier that 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. + + We will provide an example of the latter threat. After NSIS nodes + along the path between the NSIS initiator and the NSIS receiver + processes a properly protected reservation request, transmitted by + the legitimate user Alice, a QoS reservation is installed at the + corresponding NSIS nodes (for example, the edge router). The flow + identifier is used for flow identification and allows data traffic + originated from a given source to be assigned to this QoS + reservation. The adversary Eve now spoofs Alice's IP address. 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). If Eve is able to perform address spoofing, then 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 flow identifier 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, Alice's absence will not be + detected until a refresh message is required, forcing Eve to respond + with a protected signaling message. Again, this attack is applicable + not only to QoS traffic, but also to a Firewall control protocol, + with a different consequence. + + The ability for an adversary to inject data traffic that matches a + certain flow identifier established by a legitimate user and to get + some benefit from injecting that traffic often also requires the + ability to receive the data traffic or to have one's correspondent + receive it. For example, an adversary in an unmanaged network + observes a NAT/Firewall signaling message towards a corporate + network. After the signaling message exchange was successful, the + user Alice is allowed to traverse the company firewall based on the + establish packet filter in order to contact her internal mail server. + Now, the adversary Eve, who was monitoring the signaling exchange, is + able to build a data packet towards this mail server that will pass + the company firewall. The packet will hit the mail server and cause + some actions, and the mail server will reply with some response + messages. Depending on the exact location of the adversary and the + + + + +Tschofenig & Kroeselberg Informational [Page 16] + +RFC 4081 Security Threats for NSIS June 2005 + + + degree of routing asymmetry, the adversary might even see the + response messages. Note that for this attack to work, Alice does not + need to participate in the exchange of signaling messages. + + We could imagine using attributes of a flow identifier that is not + related to source and destination addresses. For example, we could + think of a flow identifier for which only the 21-bit Flow ID is used + (without source and destination IP address). Identity spoofing and + injecting traffic is much easier since a packet only needs to be + marked and 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 + hit some nodes in the network where NSIS signaling messages installed + state (in the above example, they would have to hit the same + firewall). + + Data traffic marking based on DiffServ is such an example. Whenever + an ingress router uses only marked incoming data traffic for + admission control procedures, 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 pinholes through firewalls. + Authorization information might be delivered to the NSIS- + participating entities in a number of ways. + + Typically, the authenticated identity is used to assist during the + authorization procedure (as described in [RFC3182], for example). + 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) + + + +Tschofenig & Kroeselberg Informational [Page 17] + +RFC 4081 Security Threats for NSIS June 2005 + + + to steal resources. An adversary might also use the token to monitor + 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 to determining authorization or the outcome of the + authorization process itself, then theft of service might be + possible. + +4.6. Missing Non-Repudiation + + Signaling for QoS often involves three parties: the user, a network + that offers QoS reservations (referred to as "service provider") and + a third party that guarantees that the party making the reservation + actually receives a financial compensation (referred to as "trusted + third party"). + + In this context,"repudiation" refers to a problem where either the + user or the service provider later deny the existence or some + parameters (e.g., volume or price) of a QoS reservation towards the + trusted third party. Problems stemming from a lack of non- + repudiation appear in two forms: + + Service provider's point-of-view: + 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. + + User's point-of-view: + A service provider may claim to have received a number of + reservation requests from a particular user. The user in question + may want to show that such reservation requests have never been + issued and may want to see correct service usage records for a + given set of QoS parameters. + + In today's networks, non-repudiation is not provided. Therefore, it + might be difficult to introduce with NSIS signaling. The user has to + trust the network operator to meter the traffic correctly, to collect + and merge accounting data, and to ensure that no unforeseen problems + + + + + +Tschofenig & Kroeselberg Informational [Page 18] + +RFC 4081 Security Threats for NSIS June 2005 + + + occur. If a signaling protocol with the non-repudiation property is + desired for establishing QoS reservations, then it certainly impacts + the protocol design. + + Non-repudiation functionality places additional requirements on the + security mechanisms. Thus, a solution would normally increase the + overhead of a security solution. Threats related to missing non- + repudiation are only considered relevant in certain specific + scenarios and for specific NSLPs. + +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 from that of 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 + and reordering of objects and messages; bundling of messages; + 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 an NSIS + router is also able to get access to security associations and to + 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 only 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 to apply the appropriate security protection. + + + + +Tschofenig & Kroeselberg Informational [Page 19] + +RFC 4081 Security Threats for NSIS June 2005 + + + 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 make it 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, and injection or modification of + signaling messages, etc., are mentioned throughout this document. + + Path Finding: + + Some signaling protocols establish state (e.g., routing state) and + perform some actions (e.g., querying resources) at a number of + NSIS nodes without requiring authorization (or even proper + authentication) based on a single message (e.g., PATH message in + RSVP). + + An adversary can utilize this fact to transmit a large number of + signaling messages to allocate state at nodes along the path and + to cause resource consumption. + + An NSIS responder might not be able to determine the NSIS + initiator and might even tend to respond to such a signaling + message with a corresponding reservation message. + + 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 that is 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. + + + + + + + + + + +Tschofenig & Kroeselberg Informational [Page 20] + +RFC 4081 Security Threats for NSIS June 2005 + + + 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 at the signaling + message protocol layer (NTLP), the layer of each client layer + protocol (e.g., QoS NSLP or NAT/Firewall NSLP), or 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). If 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 with a signaling message exchange protocol. + +4.9. Disclosing the Network Topology + + 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. Thus, the requirement of not disclosing a network + topology might conflict with other requirements to provide means for + discovering NSIS-aware nodes automatically or to provide diagnostic + facilities (used for network monitoring and administration). + +4.10. Unprotected Session or Reservation Ownership + + Figure 4 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. + + + + + + + + + + + + +Tschofenig & Kroeselberg Informational [Page 21] + +RFC 4081 Security Threats for NSIS June 2005 + + + 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 4: Session or Reservation Ownership + + The Session Identifier is included in signaling messages to reference + to the established state. + + 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 4), + 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. + + + +Tschofenig & Kroeselberg Informational [Page 22] + +RFC 4081 Security Threats for NSIS June 2005 + + + If this threat scenario is not addressed, an adversary can launch + DoS, theft of service, and various other attacks. + +4.11. Attacks against the NTLP + + In [2LEVEL], a two-level architecture is proposed, that would split + an NSIS protocol into layers: a signaling message transport-specific + layer and an application-specific layer. This is further developed + in the NSIS Framework [RFC4080]. Most of the threats described in + this threat analysis are applicable to the NSLP application-specific + part (e.g., QoS NSLP). There are, however, some threats that are + applicable to the NTLP. + + Network and 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. + + Threats that address parts of the NTLP that are not related to + attacks against the use of transport layer protocols are covered in + various sections throughout this document, such as Section 4.2. + + If existing transport layer protocols are used for exchanging NSIS + signaling messages, security vulnerabilities known for these + protocols need to be considered. A detailed threat description of + these protocols is outside the scope of this document. + +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 eleven + threat scenarios that are particularly applicable to the NSIS + + + +Tschofenig & Kroeselberg Informational [Page 23] + +RFC 4081 Security Threats for NSIS June 2005 + + + 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 repeatedly points out 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, on a case-by-case basis. To counter these threats, security + requirements have been listed in [RFC3726]. + +6. Contributors + + We especially thank Richard Graveman, who provided text for the + security considerations section, as well as a detailed review of the + document. + +7. Acknowledgements + + 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 document. 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, + Ted Wiederhold, Vishal Sankhla, Mohan Parthasarathy, and Andrew + McDonald provided comments on more recent versions of this document. + Their input helped improve the content of this document. Roland + Bless, Michael Thomas, Joachim Kross, 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 his + detailed comments. + + + + + + + + +Tschofenig & Kroeselberg Informational [Page 24] + +RFC 4081 Security Threats for NSIS June 2005 + + +8. References + +8.1. Normative References + + [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. van + den Bosch, "Next Steps in Signaling (NSIS): Framework", + RFC 4080, June 2005. + + [RFC3726] Brunner, M., "Requirements for Signaling Protocols", + RFC 3726, April 2004. + +8.2. Informative References + + [ALN00] Aura, T., Leiwo, J., 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. + + [AN97] Aura, T. 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. + + [2LEVEL] Braden, R. and B. Lindell, "A Two-Level Architecture + for Internet Signaling", Work in Progress, + November 2002. + + [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. + Deering, "IPv6 Flow Label Specification", RFC 3697, + March 2004. + + [NATFW-NSLP] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer + Protocol (NSLP)", Work in Progress, February 2005. + + [GIMPS] Schulzrinne, H., "GIMPS: General Internet Messaging + Protocol for Signaling", Work in Progress, + February 2005. + + [QOS-NSLP] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for + Quality-of-Service signaling", Work in Progress, + February 2005. + + [RSVP-SEC] Tschofenig, H., "RSVP Security Properties", Work in + Progress, February 2005. + + + + + +Tschofenig & Kroeselberg Informational [Page 25] + +RFC 4081 Security Threats for NSIS June 2005 + + + [SIG-ANAL] Manner, J. and X. Fu, "Analysis of Existing Quality- + of-Service Signaling Protocols", RFC 4094, May 2005. + + [RFC1809] Partridge, C., "Using the Flow Label Field in IPv6", + RFC 1809, June 1995. + + [RFC2745] Terzis, A., Braden, B., Vincent, S., and L. Zhang, + "RSVP Diagnostic Messages", RFC 2745, January 2000. + + [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, + T., Herzog, S., and R. Hess, "Identity Representation + for RSVP", RFC 3182, October 2001. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., + Johnston, A., Peterson, J., Sparks, R., Handley, M., + and E. Schooler, "SIP: Session Initiation Protocol", + RFC 3261, June 2002. + + [RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, + "Session Authorization Policy Element", RFC 3520, + April 2003. + + [RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for + Session Set-up with Media Authorization", RFC 3521, + April 2003. + + [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 + Neighbor Discovery (ND) Trust Models and Threats", + RFC 3756, May 2004. + + + + + + + + + + + + + + + + + + + + + + +Tschofenig & Kroeselberg Informational [Page 26] + +RFC 4081 Security Threats for NSIS June 2005 + + +Authors' Addresses + + Hannes Tschofenig + Siemens + Otto-Hahn-Ring 6 + Munich, Bavaria 81739 + Germany + + EMail: Hannes.Tschofenig@siemens.com + + + Dirk Kroeselberg + Siemens + Otto-Hahn-Ring 6 + Munich, Bavaria 81739 + Germany + + EMail: Dirk.Kroeselberg@siemens.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Tschofenig & Kroeselberg Informational [Page 27] + +RFC 4081 Security Threats for NSIS June 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Tschofenig & Kroeselberg Informational [Page 28] + -- cgit v1.2.3