NSIS H. Tschofenig Internet-Draft Siemens Expires: January 10, 2005 July 12, 2004 Path-coupled NAT/Firewall Signaling Security Problems draft-tschofenig-nsis-natfw-security-problems-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 10, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This draft raises some of the open issues in dealing with path-coupled NAT/Firewall signaling and tries to raise awareness of the security issues beyond the NSIS working group. These issues need to be addressed in order to proceed with the security architecture for NAT/Firewall signaling. Tschofenig Expires January 10, 2005 [Page 1] Internet-Draft NATFW Signaling Security Problems July 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. High-level Protocol Overview . . . . . . . . . . . . . . . . . 6 2.1 GIMPS . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 NAT/Firewall NSLP . . . . . . . . . . . . . . . . . . . . 9 3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1 Security for NAT vs. Firewall Traversal . . . . . . . . . 12 3.2 Which Security Protection at Which Layer? . . . . . . . . 13 3.3 Different Requirements for Different Parts of the Network . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4 Mobility, Sender Invariance, and Authorization Problems . 14 3.5 Dependencies among QoS, NAT, and Firewall Signaling . . . 15 3.6 End-to-end security . . . . . . . . . . . . . . . . . . . 16 3.7 Asymmetry of Security Protocols . . . . . . . . . . . . . 18 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 24 8.2 Informative References . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . 27 Tschofenig Expires January 10, 2005 [Page 2] Internet-Draft NATFW Signaling Security Problems July 2004 1. Introduction The NSIS working group is currently working on three protocols: a lower-layer transport mechanism (NTLP) and two signaling applications (NSLPs). The first signaling application deals with QoS signaling and the other one with NAT/Firewall signaling. The lower-layer transport only carries application-specific payloads between a number of NSIS aware nodes along the path in the forward and the backward direction. The work on path-coupled QoS signaling is the result of efforts on RSVP. The work on path-coupled NAT/Firewall signaling has its origin in the Midcom working group where NAT and Firewall signaling has to cope with network topology problems. The TIST [refs.tist] proposal led to a BOF and the work was moved to the NSIS working group. The approach taken by the Midcom working group assumes that the NAT/ Firewall is known when the signaling protocol starts and that it can be addressed by the entity controlling the midddlebox. A strong trust relationship between the middlebox and the entity controlling the middlebox is assumed. In more complex topologies with multiple NATs and Firewalls the order of these devices need to be considered with respect to the data flow traversing them. Additionally, the entity controlling these devices need to know which device will be hit by which data flow. This often requires some knowledge of the topology. The NSIS approach is different in the sense that this knowledge about the topology is moved to a discovery mechanism, and it becomes the responsibility of the end host to start signaling. This document is organized as follows: Section 1 describes what problem the NAT/Firewall NSLP is going to solve. Section 2 presents a basic protocol model and a high-level description of the messages transmitted, as suggested in [I-D.iab-model]. Section 3 lists challenges and open issues. The approach of path-coupled signaling has some implications: o First, some application logic needs to be added to the end host to control the creation of the NAT binding or Firewall pinholing on a per-flow basis. NSIS allows a proxy in the network to be used to perform this operation on behalf of the end host, but some additional security considerations need to be taken into account. o Due to the soft-state principle it is necessary to refresh the state continual. Otherwise, the established state would be deleted. o Path-coupled signaling for each direction is required to deal with routing asymmetry. Tschofenig Expires January 10, 2005 [Page 3] Internet-Draft NATFW Signaling Security Problems July 2004 o Changes to the routing path (e.g., due to mobility) require periodic re-discovery. The refresh partially addresses this issue, but the effect on the communication in the NAT/Firewall signaling case is more devastating, since data cannot flow to one of the end hosts if packet filters are not established at Firewalls along the path. o The impression exists that Firewalls and NATs are commonly used today and in a way that requires path-coupled signaling. With NATs, a number of protocols deal with creating NAT bindings. but mostly without incorporating security mechanisms between the signaling end points and the NAT(s). With Firewalls the situation is quite different, since deployment heavily depends on the scenario and on the environment. Furthermore, with increasing end-to-end encryption and with protocols heavily overloading HTTP and SIP, it is difficult to estimate the future of traditional, packet-filter-based firewalls (and also for stateful packet filtering firewalls). Security considerations for NAT and Firewall traversal need to be treated separately. In the past, mainly two approaches have been used for establishing NAT bindings: These NAT bindings are typically used to allow data traffic from the outside to be forwarded to a specific host on the inside. Dynamic NAT creation can be categorized into one of the following three categories: * Implicit creation by outbound-initiated communications whereby the translated address and port is selected from a configured address and port pool. * Explicit creation by the Application Layer Gateway(ALG) either via an API call if the NAT and the ALG are co-located or otherwise via a separate protocol. * Separate signaling protocols that requests the creation of a NAT binding An alternative classification is by the trigger for the creation of a NAT binding. In many cases an outbound data packet itself is used to cause the allocation of a NAT binding. Alternatively, a signaling protocol can be used to accomplish the same goal by directly addressing the NAT itself. The Midcom and the NSIS working groups are trying to develop protocols of the latter category. There is little doubt that a user needs to have sufficient rights (or be authorized) to create packet filters at a Firewall. The Midcom working group addressed this aspect in a convenient way, since trust between the middlebox and the entity controlling the middlebox is Tschofenig Expires January 10, 2005 [Page 4] Internet-Draft NATFW Signaling Security Problems July 2004 assumed. In most scenarios these two entities belong to the same administrative domain. Another common 'firewall' uses cryptographic data protection with IPsec. Protocols for establishing IPsec security associations already exists with IKE [RFC2409], KINK [I-D.ietf-kink-kink] and IKEv2 [I-D.ietf-ipsec-ikev2], and hence there is little motivation to focus on these cases. Tschofenig Expires January 10, 2005 [Page 5] Internet-Draft NATFW Signaling Security Problems July 2004 2. High-level Protocol Overview NSIS decided to use a two-layer architecture with one lower-layer transport (NTLP) and multiple upper-layer application signaling protocols (NSLPs). The NTLP itself is meaningless if it is not used in conjunction with an upper-layer NSLP. An upper layer protocol, such as the NAT/Firewall NSLP, cannot work without the lower layer. The layering provides a functional split and has to ensure that future applications can be easily integrated without modifying other parts of the protocol. This two-layer architecture is explained and the relationship between the GIMPS and the NTLP is described in [I-D.ietf-nsis-fw]. For this document the difference between the GIMPS and the NTLP is not too important. This section addresses the protocol functionality of the NAT/Firewall NSLP and also the NTLP, since the former depends on the latter. 2.1 GIMPS GIMPS (see [I-D.draft-ietf-nsis-ntlp]) establishes installed NTLP "routing" state, which allows signaling messages to be routed backwards along the same path. This is not possible without installed state (or similar mechanisms such as record route) due to routing asymmetry. This state is different from application-specific state (such as QoS reservations). GIMPS provides two ways to send signaling messages: o The first is an RSVP-like signaling style with end-to-end addressed messages. The end-to-end addressed message contains the source and the destination IP addresses of the data flow. The messages are intercepted along the path by NSIS nodes interested in these messages (by using Router Alert Options). The GIMPS specification refers to this as the Datagram mode (D-mode). o The second mode (called Connection mode or C-mode) is used when NSIS nodes are directly addressed. This mode assumes that the discovery procedure has already finished (or the address of the receiving node is known via other means) and information about the node is already available. From the previous description it might be apparent that an important part of the NTLP is its discovery mechanism. Without knowing the next NSIS aware node discovery (either implicit or explicit) is necessary. Providing security for a discovery message is difficult, particularly if standard security protocols should be used. Combining discovery with signaling message delivery is, from a Tschofenig Expires January 10, 2005 [Page 6] Internet-Draft NATFW Signaling Security Problems July 2004 signaling point of view, faster, but security protection is a lot harder. Currently, the GIMPS specification says that D-Mode does not provide security protection. TLS and IPsec are suggested for C-Mode message protection. Figure 1 shows the explicit discovery mechanism. Because it is assumed that an NSIS node is unaware of the topology, it is difficult to protect the discovery procedure against all threats. For example, the querying node might not be able to tell whether a responding node is truly the next NSIS node along the path. Furthermore, the querying node might not know the identity of the responding node and hence authentication cannot provide a sufficient guarantee that this node is an authorized NSIS node. Hence, some authorization mechanism has to exist in the routing infrastructure and in the entire system to ensure that nodes along the path act according to their prescribed roles. Such mechanisms might not exist in ad hoc networks. Unauthorized entities located along the path are able to harm NSIS signaling and some NSIS applications, such as NAT/Firewall NSLP and QoS NSLP. As an example, an adversary along the path not authorized to participate in NSIS signaling observes the NSIS signaling messages and the subsequent data traffic. The adversary is able to learn which IP traffic is allowed to pass the firewall and might learn which QoS treatment a given flow will receive. Tschofenig Expires January 10, 2005 [Page 7] Internet-Draft NATFW Signaling Security Problems July 2004 +----------+ +----------+ | Querying | |Responding| | Node | | Node | +----------+ +----------+ GIMPS-query ----------------------> (Query Cookie) GIMPS-response <---------------------- (Query Cookie, Responder Cookie) Final handshake ----------------------> (Responder Cookie) Figure 1: GIMPS discovery mechanism The discovery mechanism shown in Figure 1 only presents the high-level details. It allows the querying node to learn the IP address of the responding node. Additional functionality, such as discovering NSIS-unaware NATs between these two nodes is under discussion. The usage of two cookies is somewhat unusual and requires explanation. The responder cookie is used to prevent denial of service attacks in the classical sense as used by other protocols, such as SCTP or IKE. The query cookie has to ensure that an adversary does not redirect the discovery message to another NSIS node. This is guaranteed by providing a cookie by the querying node and by returning the same cookie in the response. This mechanism prevents off-path adversaries from flooding the querying node with GIMPS-responses. The querying node uses this cookie to match a request with a pending response. Furthermore, transmitting the query cookie from the responding node to the querying node after a security association is established between the two ensures that the responder has actually participated in the discovery exchange (i.e., the discovery procedure is bound to the subsequent exchange). Once the next NSIS node is known, a messaging association can be established between these two nodes using C-mode. The same procedure is repeated again and again for the C-Mode until the last GIMPS node is reached. Note that the NSIS signaling does not necessarily need to terminate at the data flow receiver. The data flow receiver might not be NSIS capable, and some other node along the path (e.g., the access router) might act on his behalf. Tschofenig Expires January 10, 2005 [Page 8] Internet-Draft NATFW Signaling Security Problems July 2004 The GIMPS protocol itself is only executed between NSIS peers, and they also implement the signaling application. There are no GIMPS nodes along the path that do not contain an upper layer signaling application. This is, both an architectural principle and a technical protocol design simplification. As with other protocols, such as Diameter, security mechanisms at the "lower-layer" prevent certain attacks at both layers between two NSIS nodes and allow standard channel security mechanisms to be used. 2.2 NAT/Firewall NSLP Currently, the NAT/Firewall NSLP description (see [I-D.ietf-nsis-nslp-natfw]) mostly analyses the different problems and challenges, describes trust relationships and motivates the different scenarios where the protocol is used. Unlike other protocols, little information is actually carried in the NSLP beyond the information carried at the NTLP: information about a created NAT binding, as well as lifetime and signaling information (such as protocol headers and error messages). Information about the flow identifier and the session identifier is carried in the NTLP. Currently no additional security payloads at the NSLP layer are specified. The most valuable part of these information elements is the flow identifier (in most cases a 5-tuple but in some cases not completely known to the sender and/or the receiver at the time of transmitting a message). As an example, a data sender might indicate which source port, protocol type and source IP address has to be used, but it cannot know the public IP address, of the NAT binding yet since it is up to the protocol execution to establish and learn this NAT binding. It is useful to distinguish between two signaling modes: The first mode (CREATE) is the traditional way of creating a NAT binding by sending a message from the data sender along the path to the data receiver. Figure 2 shows a message exchange for this signaling mode. The second mode (RESERVE) is used when a data receiver is behind a NAT and wants to establish a NAT binding to allow incoming data traffic. Figure 3 shows this mode. It was necessary to introduce this mode, because path-coupled signaling in the traditional sense is not immediately applicable. Tschofenig Expires January 10, 2005 [Page 9] Internet-Draft NATFW Signaling Security Problems July 2004 Private Address Public Address +----------+ Space +----------+ Space +----------+ | Data | | NAT | | Data | | Sender | | | | Receiver | +----------+ +----------+ +----------+ | | | | Create | Create | |----------------------------->+--------------------------->| | | | | Succeeded/Error | Succeeded/Error | |<-----------------------------+<---------------------------| | | | ============================================================> Direction of data traffic Figure 2: CREATE Mode With the CREATE mode shown in Figure 2 the data sender (which happens to be the NSIS initiator in this case) sends a message to request a NAT binding to be created. The message is targeted to the data receiver (or even to any node in the Internet), which returns a success or failure message. The data sender learns about the new NAT binding, as a consequence. Public Internet Private Address +----------+ +----------+ Space +----------+ | Data | | NAT | | Data | | Sender | | | | Receiver | +----------+ +----------+ +----------+ | | | | | Reserve Reserve | | |<---------------------------| | | | | | Return ext addr/Error | | |--------------------------->| | | | ============================================================> Direction of data traffic Figure 3: RESERVE Mode With the RESERVE mode shown in Figure 3 the data receiver behind a NAT creates a NAT binding. This allows data traffic from a node on the Internet to be received. Please note that the RESERVE message is sent in the opposite direction of the data traffic. The RESERVE mode is, in some sense, not path-coupled, since the data receiver starts Tschofenig Expires January 10, 2005 [Page 10] Internet-Draft NATFW Signaling Security Problems July 2004 signaling but, on the other hand, the data sender will send the data traffic to the IP address (and port) allocated at the NAT. It should be noted that in [I-D.ietf-nsis-fw] the RESERVE mode currently requires an additional CREATE message from the data sender to the NAT to activate the binding. This issue is still in discussion. Tschofenig Expires January 10, 2005 [Page 11] Internet-Draft NATFW Signaling Security Problems July 2004 3. Challenges This section highlights some of the challenges discovered. Further details can be found in NAT/Firewall NSlP [I-D.ietf-nsis-nslp-natfw]. 3.1 Security for NAT vs. Firewall Traversal As we tried to motivate in Section 1, the creation of NAT bindings is security sensitive but not to the same degree as firewall traversal. Existing proposals for NAT traversal typically do not use a signaling protocol. Instead regular data traffic from the internal to the external network is used. This is also true for IPv4/IPv6 transition mechanisms in case of automatic tunneling. A typical threat against a NAT device is flooding by an adversary that allocates a large number of NAT bindings. If the dynamically allocated NAT bindings are selected from a limited pool of available bindings (in particular if a NAT instead of a NAPT is used) then this might be a real threat. For a NAPT this threat does not seem to be dangerous enough to require special purpose signaling protocols. As a minor note, STUN [RFC3489] and TURN [I-D.rosenberg-midcom-turn] are signaling protocols, but they do not provide additional security for the NAT device when allocating NAT bindings. If security should be provided for creating NAT bindings, then authentication might be useful in cases of misuse (e.g., allocation of too many NAT bindings). More interesting is, however, authorization. In most networks today every node is automatically authorized to create NAT bindings. To support mobility it is possible either to allocate a new NAT binding (approach used today) or to update the state. Updating a NAT binding is security sensitive, since an adversary can modify an existing NAT binding in order to redirect traffic to a third-party victim, to the adversary itself, or even to a black hole. Flooding a third-party entity might be particularly dangerous if the data sender is streaming a large amount of data (possibly over a wireless interface). Since a NAT binding has a life-time, it is necessary to refresh it continually. This mechanism provides a self-healing property, since a new data packet (or a new signaling message) causes either the creation of a new binding or the refresh of the old one. In contrast, firewall pinholing is more security sensitive. Creating or deleting packet filters might easily violate the security policy of a network and might allow an adversary to mount a number of attacks. Only authorized entities are typically allowed to modify packet filters. This requires proper authorization. Authentication will also most like be required, since typically the authenticated identity is used for computing the authorization decision. As Tschofenig Expires January 10, 2005 [Page 12] Internet-Draft NATFW Signaling Security Problems July 2004 described in Figure 5, this might lead to problems with path-coupled signaling. 3.2 Which Security Protection at Which Layer? An obvious question is which security mechanisms should be provided at which layers. The choice impacts the performance and deployment. The working group is currently in the stage of investigating the threats, trust relationships, and security properties of the two NSLPs to evaluate the impact on the NTLP. Figure 4 shows the different layers. Providing security protection at both layers between the neighboring entities is not valuable if no additional functionality is provided. Note that if the protection is provided between different entities (non-neighboring NSIS nodes) then such protection is justified. Recent developments in Diameter with regard to CMS [I-D.ietf-aaa-diameter-cms-sec] have shown that there is a tendency not to use additional upper-layer security mechanisms if lower-layer security mechanisms are provided, even if the security properties are different. The same can also be observed in other protocols, such as SIP or even in RSVP where the preferred choice is the Integrity Object and not the mechanisms provided with the Identity Objects. Public-key-based authentication, for example, offered with the Identity Object is not used. +------+ +------+ | NE | | NE | |+----+| |+----+| ||NSLP|| NSLP Security ||NSLP|| || 1 || - - - - - - - - - - - - - || 1 || |+----+| |+----+| | || | | || | |+----+| NTLP Security |+----+| ====||NTLP||============================||NTLP||==== |+----+| |+----+| +------+ +------+ Figure 4: Security at Different Layers 3.3 Different Requirements for Different Parts of the Network Since NSIS protocols are executed in an end-to-end fashion with some (and possibly many) NSIS nodes along the path, it is important to consider a large number of usage environments. These environments might impose different requirements on the security protection. At a high level, we can distinguish between intra-domain communication Tschofenig Expires January 10, 2005 [Page 13] Internet-Draft NATFW Signaling Security Problems July 2004 (communication within an administrative domain), inter-domain communication (communication between administrative domains) and finally the communication with the end hosts and the attached network. NSIS, unlike RSVP, does not necessarily need to be executed between the true data sender and data receiver. It is possible to use NSIS within a single administrative domain only. The impact on security of using NSIS in such diverse environments is that different security protocols, not just one, need to be supported. Some architectures use Kerberos, others rely on special authentication and key exchange protocols, and again others rely on public-key-based mechanisms. It is highly desirable to provide some flexibility for the authentication and key exchange protocol. For some NSLPs, such as a quality of service signaling protocol, it is desireable to execute the authorization procedure at an entity where the user is known (typically its home network). This typically implies that the authentication and key exchange protocol is also terminated at the same entity. 3.4 Mobility, Sender Invariance, and Authorization Problems The NAT/Firewall NSLP establishes state at possibly several entities between the NSIS initiator and the NSIS responder. Providing authentication of the signaling initiator to each individual node along the path might be possible but not particularly useful, since the initiator is most likely unknown to some middlebox along the path. Hence, authentication per se does not solve the security problem. If authentication is only provided to some entities along the path (most likely to the neighboring NSIS nodes), then information about the initiator of the session is known to some NSIS nodes (except for the session identifier, which does not change along the path and over the lifetime of a session). Now, with the introduction of mobility it might be possible that intermediate NSIS nodes need some assurance that a particular sender is the owner of a session. No other entity should be allowed to modify state since this would allow certain attacks. In some respect this issue is similar to the authorization property in Mobile IP where the mobility binding needs to be protected against unauthorized modifications. It seems that the property of "sender Invariance" is required in this case: "A party is assured that the source of the communication has remained the same as the one that started the communication, although the actual identity of the source is not important to the recipient." Tschofenig Expires January 10, 2005 [Page 14] Internet-Draft NATFW Signaling Security Problems July 2004 The interactions among security, mobility, session ownership, and authorization are subject to ongoing discussions in [I-D.manyfolks-signaling-protocol-mobility]. 3.5 Dependencies among QoS, NAT, and Firewall Signaling Routing asymmetry has to be considered for firewalls but is not applicable to NAT-only signaling. In the presence of NATs, we are always sure that the forward path and the backward path are same with regard to the NAT boxes, since the NAT forces the IP packets to flow through these devices. But, in the presence of firewalls, the forward and the backward routes may be different. A solution needs to focus on the more difficult case where the routes are different. In the forward direction some rules are established in the traversed firewalls. In the reverse direction, if a different route is taken, the packets might be blocked by some other firewall. It is important to study the relationship between NSIS signaling and other application protocols (such as SIP) and also between different NSIS signaling applications themselves. Different NATs and firewalls can be found along the path, and the worst case needs to be assumed. As we argue in NAT-FW [I-D.ietf-nsis-nslp-natfw], it is always possible with mobility that an end host finds itself located behind a NAT. Before NSIS can start, the NSIS initiator needs to know the destination IP address, since this is an integral part of path-coupled signaling. This might, however, already assume some application layer signaling exchange. The IP address information exchanged during this exchange might, however, be wrong due to the presence of a NAT. In some scenarios (e.g., receiver behind a NAT) NSIS signaling might need to start beforehand. With NSIS QoS signaling it is also necessary to avoid breaking this type of signaling application. The NSIS NAT/Firewall NSLP does not aim to learn topology information but rather to create NAT bindings and firewall pinholes and to make information about the NAT binding available to the end host. In a short memo on NAT handling in NSIS (see [nat-memo]) we argue that it is necessary to incorporate a mechanisms for learning the presence of NSIS unaware nodes into the GIMPS discovery procedure. Additionally, it is necessary to modify the flow identifier of the QoS signaling message at the corresponding NAT device along the path to reflect the address change. An NSIS initiator should not need to know where this address translation takes place; this would require topology information. Providing the necessary flow identifier modification in addition to the installation of a QoS reservation would be useful. One question is therefore how much NAT handling needs to be incorporated into the NTLP and into every NSLP to support proper signaling behavior. If NAT handling is added to the QoS signaling, Tschofenig Expires January 10, 2005 [Page 15] Internet-Draft NATFW Signaling Security Problems July 2004 then it automatically inherits the authorization applied to QoS signaling. Should this procedure be extended to Firewall signaling? Does the right to make a QoS reservation imply the right to traverse the firewall? 3.6 End-to-end security Securing the communication between neighboring NAT/FW NSLPs with a chain of trust is a convenient assumption that allows simplified signaling message processing. However, it might not always be applicable, especially between two arbitrary networks. We assume that NATs and firewalls are typically located in the access networks and are typically not found in the core network. Hence, two observations follow: o The two access networks (and the firewalls/NATs in these networks) do not trust each other or they might not even know of each other. o The end host might have a trust relationship with the local access network that allows it to create firewall pinholes. However, it cannot be assumed that the end host of one network is able to create packet filters at another network. In the example of Figure 5 Host A is not authorized to create pinholes at Middlebox 2. A trust relationship exists only between Host B and Middlebox 2. This scenario represents a scenario in which two employees of two companies want to communicate through their corporate network firewalls. Company B trusts it own employees but not employees of company A. In [I-D.ietf-nsis-nslp-natfw] we describe three possible approaches to tackle this problem. None of these three approaches is without drawbacks. We have chosen the one approach that assumes the signaling message is sent end-to-end and each end host contributes its part to the authorization decision. Furthermore, we have to assume that the NSIS signaling message is allowed to bypass the firewall (without installing a packet filter at this stage of the protocol) to reach the other end host. Based on Figure 5 the authorization steps can be described as follows: Host A starts with the NSIS signaling message exchange and has to authenticate itself to Middlebox 1. Middlebox 1 authorizes Host A to create a pinhole based on the existing trust relationship. Then the signaling message is forwarded along the path and intercepted by Middlebox 2. No trust relationship between Middleboxes 1 and 2 or between Host A and Middlebox 2 exists. Hence, Middlebox 2 does not authorize the pinhole creation. For more restrictive firewalls an error message is returned to Host A, but in our scenario the NSIS signaling message is forwarded to Host B ( the final destination of the signaling message exchange). Host B Tschofenig Expires January 10, 2005 [Page 16] Internet-Draft NATFW Signaling Security Problems July 2004 verifies that the signaling message is provided from a trusted device, might already expect an incoming message based on some application layer signaling exchange with Host A, and returns a response message. Middlebox 2 authorizes Host B's request for pinhole creation due to the existing trust relationship. The message travels back to Host A, which receives a positive confirmation that the signaling message exchange is successful. Host A can start transmitting data packets. Please note that if Middlebox 2 is actually a NAT (instead of a firewall) then the scenario for a receiver behind a NAT is applicable, which allows Host B to perform signaling locally without the above-described complications. This is one of the other solutions described in [I-D.ietf-nsis-nslp-natfw]. +---------------------+ +-----------------------+ | Network A | Internet | Network B | | +---------+ +---------+ | | +---->+ Middle- +<------------>+ Middle- +<----+ | | | ...>| box 1 | | box 2 |<....| | | | . +---------+ +---------+ .| | | | . | | .| | | | . | | .| | | | . | | .| | | v v | | vv | | +--+-+-+ | | +--+---+ | | | Host | | | | Host | | | | A | | | | B | | | +------+ | | +------+ | +---------------------+ +-----------------------+ -----: NSIS Communication .....: Trust Relationship Figure 5: Authorization Problems Without a proper binding of the NSIS to application signaling , Host B might suddenly receive an NSIS signaling message that indicates a firewall pinhole has to be created. Host B does not know which end host requested this NAT binding nor for which reason. Hence it might be reasonable to think about providing end-to-end security (via a binding between NSIS signaling and the application signaling) as an option to provide the receiving node stronger guarantees about the entity requesting certain actions. It has to be noted that other NSIS signaling scenarios in which intermediate nodes start (or terminate) NSIS signaling on behalf of the end hosts might be much more difficult to deploy along with end-to-end security. Tschofenig Expires January 10, 2005 [Page 17] Internet-Draft NATFW Signaling Security Problems July 2004 The main questions raised by this section are whether the described observations are correct and whether it seems possible to make the assumption that an NSIS signaling message be allowed to traverse the packet filter firewall. Furthermore, it needs to be studied whether end-to-end security provides better properties. It is worth noting that the observation such a need of this application layer signaling to NSIS signaling binding is raised in [I-D.aoun-nsis-nslp-natfw-migration]. 3.7 Asymmetry of Security Protocols Some security protocols operate asymmetrically, which leads to unpleasant consequences for the NSIS protocol suite. The Transport Layer Security protocol (TLS) [RFC2246], IKEv2 [I-D.ietf-ipsec-ikev2], and also custom security protocols (such as those provided with RSVP Identity Representation and, for example, Kerberos [RFC3182]). NAT/Firewall NSLP signaling messages travel along a path between the NSIS initiator and the NSIS responder containing a number of entities that act in different roles. Due to the routing asymmetry it is necessary to start signaling from both end hosts (one signaling exchange for each data flow direction). In IKEv2 the security properties of the initiator and the responder are different with respect to denial of service protection and support for the Extensible Authentication Protocol (EAP) [I-D.ietf-eap-rfc2284bis]. This is also the case if an end host wants run TLS with unilateral authentication (NSIS entity in the network to the end host) with upper layer client-side authentication. This type of exchange might be typical for QoS signaling, since authorization has to be executed at entities other than those executing the security protocol. From a deployment point of view it is simpler to have public key based authentication of the network to the user than to support a client-side PKI. Such a client-side PKI is, however, necessary when the roles are reversed. Figure 6 shows this problem graphically. Unfortunately, TLS cannot reverse its roles and cannot reuse the session cache for the reverse direction. This problem was also observed in the context of SIP, where [I-D.ietf-sip-connect-reuse] provides a solution to reuse an established TCP or TLS connection that was established based on a SIP REGISTER before a SIP INVITE (or similar message) is used. NSIS, however, has no provision to support separate 'registration' and a 'end-to-end' signaling message exchanges due to the path-coupled property. Tschofenig Expires January 10, 2005 [Page 18] Internet-Draft NATFW Signaling Security Problems July 2004 +---------------------+ +-----------------------+ | Network A | Internet | Network B | | +---------+ +---------+ | | +---->+ NSIS +------------->+ NSIS +-----+ | | | | Entity | | Entity | | | | | | B | | C | | | | | +---------+ +---------+ | | | | | | | | | | | | | | | | | | v | | +--+---+ | | +--+---+ | | | NSIS | | | | NSIS | | +--+Entity+-----------+ +------------+Entity+---+ | A | TLS server TLS client| D | +--+---+ +--+---+ ^ | | v +-----+-------+ +-----+-------+ | NSIS | TLS TLS | NSIS | | Initiator X | client server | Responder Y | +-------------+ +-------------+ Figure 6: Problems with Asymmetric Protocols Tschofenig Expires January 10, 2005 [Page 19] Internet-Draft NATFW Signaling Security Problems July 2004 4. Conclusion This section summarizes and reiterates a few questions addressed in this document: o Is it useful to separate the security aspects for NAT and firewall signaling? o To what extend is end-to-end security important? o How can specific authorization problems be addressed? o What can be done with regard to the properties of asymmetric security protocols? o Are the proposals in [I-D.tschofenig-nsis-sid] adequate to address the sender-invariance property for mobility scenarios? This document, for example describes how to reuse concepts like hash-chains and the Purpose-Built Key mechanism [I-D.bradner-pbk-frame] to provide a mobility solution without a global PKI. Tschofenig Expires January 10, 2005 [Page 20] Internet-Draft NATFW Signaling Security Problems July 2004 5. Security Considerations This entire document addresses security issues of path-coupled NAT/ Firewall signaling. The main intention is to solicit feedback and comments from the community at an early stage of the protocol development. Tschofenig Expires January 10, 2005 [Page 21] Internet-Draft NATFW Signaling Security Problems July 2004 6. Contributors The author would like to thank Richard Graveman for his detailed review. Tschofenig Expires January 10, 2005 [Page 22] Internet-Draft NATFW Signaling Security Problems July 2004 7. Acknowledgements The author would like to thank Cedric Aoun, Marcus Brunner, Srinath Thiruvengadam, Martin Stiemerling and Miquel Martin for their time to discuss many NAT/Firewall related issues. Tschofenig Expires January 10, 2005 [Page 23] Internet-Draft NATFW Signaling Security Problems July 2004 8. References 8.1 Normative References [I-D.draft-ietf-nsis-ntlp] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet Messaging Protocol for Signaling", draft-draft-ietf-nsis-ntlp-00 (work in progress), October 2003, . [I-D.ietf-nsis-nslp-natfw] Stiemerling, M., Tschofenig, H., Martin, M. and C. Aoun, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-02 (work in progress), May 2004, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [draft-tschofenig-nsis-sid] Tschofenig, H., Schulzrinne, H., Hancock, R., McDonald, A. and X. Fu, "Security Implications of the Session Identifier", June 2003. 8.2 Informative References [I-D.aoun-nsis-nslp-natfw-migration] Aoun, C., Brunner, M., Stiemerling, M., Martin, M. and H. Tschofenig, "NAT/Firewall NSLP Migration Considerations", draft-aoun-nsis-nslp-natfw-migration-01 (work in progress), February 2004, . [I-D.bradner-pbk-frame] Bradner, S., Mankin, A. and J. Schiller, "A Framework for Purpose-Built Keys (PBK)", draft-bradner-pbk-frame-06 (work in progress), June 2003, . [I-D.iab-model] Rescorla, E., "Writing Protocol Models", draft-iab-model-01 (work in progress), May 2004, . [I-D.ietf-aaa-diameter-cms-sec] Calhoun, P., Farrell, S. and W. Bulley, "Diameter CMS Security Application", draft-ietf-aaa-diameter-cms-sec-04 (work in progress), March 2002, Tschofenig Expires January 10, 2005 [Page 24] Internet-Draft NATFW Signaling Security Problems July 2004 . [I-D.ietf-eap-rfc2284bis] Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J. and H. Levkowetz, "Extensible Authentication Protocol (EAP)", draft-ietf-eap-rfc2284bis-07 (work in progress), December 2003. [I-D.ietf-ipsec-ikev2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-12 (work in progress), January 2004, . [I-D.ietf-kink-kink] Thomas, M. and J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", draft-ietf-kink-kink-05 (work in progress), January 2003, . [I-D.ietf-nsis-fw] Hancock, R., "Next Steps in Signaling: Framework", draft-ietf-nsis-fw-05 (work in progress), October 2003, . [I-D.ietf-nsis-qos-nslp] Bosch, S., "NSLP for Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-01 (work in progress), October 2003, . [I-D.ietf-sip-connect-reuse] Mahy, R., "Connection Reuse in the Session Initiation Protocol (SIP)", draft-ietf-sip-connect-reuse-01 (work in progress), February 2004, . [I-D.manyfolks-signaling-protocol-mobility] Bless, R., "Mobility and Internet Signaling Protocols", draft-manyfolks-signaling-protocol-mobility-00 (work in progress), January 2004, . [I-D.rosenberg-midcom-turn] Rosenberg, J., "Traversal Using Relay NAT (TURN)", draft-rosenberg-midcom-turn-04 (work in progress), February 2004, . [I-D.tschofenig-nsis-sid] Tschofenig, H., "Security Implications of the Session Tschofenig Expires January 10, 2005 [Page 25] Internet-Draft NATFW Signaling Security Problems July 2004 Identifier", draft-tschofenig-nsis-sid-00 (work in progress), June 2003, . [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999, . [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998, . [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S. and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001, . [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003, . [nat-memo] Tschofenig, H., "Memo about NSIS NAT Handling, available at: http://www.tschofenig.com/drafts/NSIS-NAT-Handling.txt (Feb. 2004)", February 2004, . [refs.tist] Shore, M., "The TIST (Topology-Insensitive Service Traversal) Protocol", DRAFT draft-shore-tist-prot-00.txt, May 2002. Author's Address Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany EMail: Hannes.Tschofenig@siemens.com Tschofenig Expires January 10, 2005 [Page 26] Internet-Draft NATFW Signaling Security Problems July 2004 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Tschofenig Expires January 10, 2005 [Page 27]