NSIS Working Group M. Martin Internet-Draft M. Brunner Expires: April 19, 2004 M. Stiemerling NEC C. Aoun Nortel Networks October 20, 2003 A NAT/Firewall NSLP security infrastructure draft-martin-nsis-nslp-security-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/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 April 19, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document proposes a security infrastructure for the NAT/FW traversal NSLP of the NSIS protocol. We begin with a description of the problem, followed by the proposed solution, based on public key infrastructure. The document finally deals with examples that clarify the proposed methods. Martin, et al. Expires April 19, 2004 [Page 1] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problems to solve . . . . . . . . . . . . . . . . . . . . . . 4 3. Solution requirements . . . . . . . . . . . . . . . . . . . . 5 4. Digital signatures: generic pros and cons . . . . . . . . . . 6 4.1 Public key deployment . . . . . . . . . . . . . . . . . . . . 6 4.2 Computational cost . . . . . . . . . . . . . . . . . . . . . . 6 4.3 Incurred overhead . . . . . . . . . . . . . . . . . . . . . . 7 5. Digital signatures on an NSIS scenario . . . . . . . . . . . . 8 5.1 Public key deployment. Known peers . . . . . . . . . . . . . . 8 5.2 Messages changing en route . . . . . . . . . . . . . . . . . . 8 6. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 10 6.1 Implementation of digital signatures in the NAT/FW NSLP . . . 11 7. Solution examples . . . . . . . . . . . . . . . . . . . . . . 13 7.1 Network with firewalls . . . . . . . . . . . . . . . . . . . . 13 7.2 Network with NATs . . . . . . . . . . . . . . . . . . . . . . 14 7.3 Networks with several Middle boxes . . . . . . . . . . . . . . 15 7.4 Middle boxes on foreign networks . . . . . . . . . . . . . . . 15 8. Optional extensions . . . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 Normative References . . . . . . . . . . . . . . . . . . . . . 21 Informative References . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . 25 Martin, et al. Expires April 19, 2004 [Page 2] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 1. Introduction The NAT/Firewall traversal NSLP for the NSIS protocol is a highly sensitive service. Because of its functionality, it can potentially open paths to networks otherwise protected by NAT/FW infrastructures. It also has the potential to render NAT/FW infrastructures inoperative, closing paths or exhausting the resources of the involved boxes. For this reason, a tight security scheme has to be devised, to allow both fine and coarse access control. This draft aims at solving this problem by using cryptographic digital signatures to authenticate the peers. Decisions on whether to allow access or not are based on the authenticity of the requesting peer and the security policy configured in the box. Martin, et al. Expires April 19, 2004 [Page 3] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 2. Problems to solve The NAT/FW traversal NSLP provides the following security sensitive services: 1. Firewall traversal: override specifically set access rules, and allow data transfer through firewall devices, both from the inside out and the outside in. 2. NAT traversal: reach machines in a private network, which were not meant to be accessible from the outside without specific setups. 3. Resource allocation: Install packet filters and NAT bindings on a machine that can only allocate a certain number of them. Misuse of these services can compromise the network and even render it inoperable. The NSIS-Threats document [1] shows a number of ways in which such services can be exploited Martin, et al. Expires April 19, 2004 [Page 4] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 3. Solution requirements Given the problems and its exploit possibilities, our solution will have to cover the following requirements: 1. Nodes must be able to verify the authenticity of the requests 2. Message integrity has to be warranted 3. Nodes must have the last word in deciding whether they accept a session or not The requirements listed can only be met by cryptographic methods, namely, digital signatures. Through its use, nodes could be sure of who is making a request, and what request it is, and match it with an access list, or any other more complex decision mechanism. This approach provides great flexibility, as the decision process can be arbitrarily complex, and based on trustful data. For instance, we might want to authorize certain identities, or allow for only a number of connections per id to be accepted. More open systems with full access would have a chance to black list users. Martin, et al. Expires April 19, 2004 [Page 5] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 4. Digital signatures: generic pros and cons Digital signatures provide a secure way of transmitting messages: they proof that the author is who he says he is, and that what he is saying has not been altered. In other words, authentication and integrity, both strictly necessary if a node has to take security sensitive actions. No other mechanism nowadays provides all the functionalities of public key cryptography, and thus this becomes a perfect candidate to provide security on the NAT/FW NSLP. This, of course, comes at a cost; We will face three main problems: o Signature verification requires the public key of the sender. This key has to be known and trusted before a signature can be validated safely. o Public key cryptography has a high computational cost, in comparison to other cryptography algorithms and authentication systems o Introducing signatures on a message implies a certain overhead 4.1 Public key deployment The NAT/FW NSLP is expected to enable connections between peers that don't necessarily know each other. This of course, collides with the necessity of knowing the public key of the sender to verify it's signatures. Later in this document (Section 6.1) we try to analyze what nodes are likely to know each other, and where we can expect the public keys to have been securely exchanged. On the other hand, the necessity of cyphered, authenticated and non tampered communications seems to set a trend towards proper public key infrastructure deployments. Nowadays, though, no such public global infrastructure exists. 4.2 Computational cost Commonly available public key cryptography provides rather fast algorithms, with verification/signature times around the 13.0/6.8 milliseconds on 450MHz UltraSPARC II processor [4]. This should not be an excessive load when considering a running Martin, et al. Expires April 19, 2004 [Page 6] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 server, but is of special relevance when facing Denial of Service attacks. In this case, the longer it takes to process a request (even if only to reject it), the easier it is to overload the machine into uselessness. Performance analysis should be undertaken to evaluate these risks. We must consider, though, that authentication and integrity will require some form of cryptography, and that will require a certain degree of computational power. 4.3 Incurred overhead Digital signatures, using the DSA algorithm, have a length of about 320 bits, and even shorter algorithms exist [5] The NSLP packet payload proposed in [6] has a size of 23 bytes. Adding a signature of 40 bytes implies a 200% packet length increase. For this reason, we must carefully choose the kind of signature we use, to minimize the introduced overhead. Martin, et al. Expires April 19, 2004 [Page 7] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 5. Digital signatures on an NSIS scenario We have seen the values and the problems involved in digital signatures. In this section we will particularize it to the scenarios we will face in an NSIS NAT/FW NSLP. 5.1 Public key deployment. Known peers If we intend to use digital signatures, we must first inquire on the availability of the public keys. Middle boxes will have a very limited number of them available, due to the difficulty of publishing them securely. Neighbouring peers can not be assumed to have their public keys exchanged. The reason is that, even though, a middle box has a very limited number of one-hop neighbours, it is NSIS NAT/FW NSLP aware neighbours that we are concerned about. As a first approach, we must consider that the border middle boxes of each network on the internet have each other as potential one-nsis-hop peers. This keeps us from using simpler methods, (may be even not based on public key cryptography), and forces us to carefully decide whether border middle boxes will ever know each other, as this is basic for the solution design. 5.2 Messages changing en route Let us assume a create message, as defined in [6]. It contains a source address for the pinhole specification. Let us now suppose it goes through a NAT. Ideally, an external address and port will be reserved, and the create message will be modified accordingly. This step, necessary for the basic protocol functionality, also means that any previous packet signature will be broken, since the message changes. Specifically, the source or target address can change when traversing a NAT, as shown in Figure 1: Martin, et al. Expires April 19, 2004 [Page 8] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 +------+ +------+ | NAT1 |-------------------------------| NAT2 | +------+ +------+ | | +------+ +------+ | DS | | DR | +------+ +------+ DS: Data Sender DR: Data Receiver Figure 1: Message alterations when traversing NATs When a create message from DS to DR traverses NAT1, the pinhole source address must change, since the potential data packets that will use the pinhole, will appear to come from the NAT1 external address. Similarly, when the create packet reaches NAT2, it matches a reservation, and redirects it to DR. Any other boxes between NAT2 and DR would see the potential data packets as heading towards DR and not NAT2 any more; for this reason, the destination address of the pinhole in the create message has to be altered accordingly. This basically means we will not be able to protect the source and destination addresses in the NAT/FW NSLP messages, since they change on the way. Because of that, other mechanisms will have to be devised, as we will see in Section 6.1 Martin, et al. Expires April 19, 2004 [Page 9] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 6. Proposed solution At this point, we are left with the necessity of digital signatures, but also with several restrictions: o Too many signatures involve excessive overhead, computational cost, etc.. o We have to consider signature validity, be it because the message changed, or because the public key is not available If we manage to use them properly, we will be able to provide authentication and integrity. But we are also interested in authorization. The step from authenticating to authorizing is often policy based. It is then reasonable to assume an arbitrarily complex decision engine to issue verdicts based on the data we can provide it. Note then, that whether an NSIS NAT/FW NSLP request is honored or not, will depend on the decision engine, which, may or may not take into consideration the authentication information we provide it. A first approach to this engine is given in Figure 2. Session ID ---\ Verified (yes/no) ----\ +----------+ /-- Honored \ | | / Pinhole source ------>--| Decision |---<----- Remembered Verified (yes/no) ------>--| Engine | \ / | | \-- Rejected Pinhole destination ----/ +----------+ Verified (yes/no) ---/ Figure 2: The decision engine interface Based on the Session ID and pinhole specification, and whether that data has is trustworthy because it has been verified with a known signature, the decision engine decides from three options: o Honored: The request is accepted, and the required rules installed o Remembered: The request is not trusted, and thus not installed, but is kept awaiting for a certain time, expecting later validations. Martin, et al. Expires April 19, 2004 [Page 10] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 o Rejected: The petition is ignored completely Note that if the decision engine returns a reject, the communication will not be possible at all. Possible policies on the decision engines are: o The basic one: authorize certain sources or destinations to use certain pinholes o Allow a certain request rate or amount and deny the rest. For instance, the node next to an ISP, will allow as many connections as the ISP contracts o Allow requests for internal IP's, independently of their signatures o Allow all but perform accounting operations We are now left with the problem of using digital signatures wisely to provide adequate input to the Decision Engine 6.1 Implementation of digital signatures in the NAT/FW NSLP What and where we sign is greatly related to trust relationships between middle boxes. A detailed description of the different kinds of trust can be found in [1]. In our approach, we expect end to end trust, and hope for peer to peer trust in some of the hops. For end to end trust, we will have DS sign the Session ID and include it in the object. For peer to peer, we will sign the whole object on each hop. In other words, the object will include: 1. Session ID signature: Session ID signed by DS except for Path Succeeded messages, where it is signed by the previous hop on the return path. 2. Previous hop signature: Pinhole source and destination (if applicable), Session ID and Session ID signed by DS, plus other objects, all of it signed by the previous hop The first signature will be added by the NSLP. The second one, though, since it refers to the whole packet , might be implemented on the transport layer (NTLP). In the case that the NTLP didn't include this service, it could be pushed up on the NSLP. Note that the specific syntax and algorithms used to sign the messages are not specified here. A standardized flexible option such Martin, et al. Expires April 19, 2004 [Page 11] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 as CMS [2] could be used, but might be too cumbersome. A simple DSA signature might suffice. We recommend looking at the examples in Section 7 for detailed working flows that help understand this specific use of digital signatures. Martin, et al. Expires April 19, 2004 [Page 12] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 7. Solution examples 7.1 Network with firewalls In this basic network, we have two hosts, on their respective networks, each behind a firewall that needs to be signaled for the path to be open. The FW1 belongs to DS's network, and FW2 belongs to DR's, as the hierarchical structure suggests in Figure 3 +-----+ +-----+ | FW1 |-------------------------------| FW2 | +-----+ +-----+ | | +-----+ +-----+ | DS | | DR | +-----+ +-----+ FW: Firewall DS: Data Sender DR: Data Receiver Figure 3: Firewall network When the signaling begins, DS sends a create message to FW1. We expect FW to honour the request for one of these reasons: o It allows end hosts inside it's network to open pinholes (perhaps only a given range) o It knows DS's public key and thus verifies the request using the previous hop signature, and it's policies allow this transaction FW2 gets the forwarded packet, but is not likely to honor it, because it probably does not know FW1's public key, and can not validate it's origin. We expect it to remember the rule and forward the NSIS packet. DR gets it next. It does know DS, and can verify the Session ID signature. It can also verify the target address, because it is itself, and it is expecting this signaling (probably because of some other application layer communication DR replies then with a Path Succeeded message, that includes the Session ID signature signed by DR. Martin, et al. Expires April 19, 2004 [Page 13] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 This message gets to FW2, who does know DR, and so verifies the Session ID signature. That verifies for him the destination of the pinhole, and the Session ID, which it was remembering. It is re-entered into the decision engine, which this time, honours the request. It then gets to FW1 which already honoured that Session ID, and to DS, who starts data transfer on the newly created pinhole path Note that in this example, the message does not change en route, but this is only true because there are no NATs on the data path. Note also that DR and FW2 can not verify the source address. This is a weakness indeed, but it is not of extreme importance, since any malicious node that is able to change the nsis packet source address, is also capable of dropping the data packets afterwards. 7.2 Network with NATs This network is analogous to the example Section 7.1 but has NATs instead of firewalls, as shown in Figure 4. +------+ +------+ | NAT1 |-------------------------------| NAT2 | +------+ +------+ | | +-----+ +-----+ | DS | | DR | +-----+ +-----+ DS: Data Sender DR: Data Receiver Figure 4: NAT network Note how exactly the same signaling (security wise) as in the previous example would also work here. That is meant to be so, because DS and DR do not need to know the topology of the data path. We can see though, how the pinhole source changes after NAT1, and the pinhole destination changes after NAT2, which means we can not sign the whole packet at DS, for instance. From now on, we will refer to the nodes as middle boxes, since, in what concerns security, there is no change in how we deal with them. Martin, et al. Expires April 19, 2004 [Page 14] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 7.3 Networks with several Middle boxes We now increase complexity to show the signaling through more than one middle box per network, as shown in Figure 5. +-----+ +-----+ | MB2 |-----------------------------------| MB3 | +-----+ +-----+ | | +-----+ +-----+ | MB1 | | MB4 | +-----+ +-----+ | | +-----+ +-----+ | DS | | DR | +-----+ +-----+ MB: Middle box (NAT or Firewall or a combination) DS: Data Sender DR: Data Receiver Figure 5: Several middle boxes per network DS sends a create message, which is honored by MB1, for the same reasons as in Section 7.1. We expect MB2 to accept it as well, because it knows MB1 (peer to peer trust) and the policy allows it. MB3 and MB4, again as in Section 7.1 will remember the rule, but not install it. When DR gets it and validates it, MB4 will honor the request, and will sign the session ID itself. This is what makes MB3 trust the request and honor it. Again, notice how we can not protect the source address. 7.4 Middle boxes on foreign networks We now face the problem of middle boxes somewhere on the Internet, that do not belong to DS's or DR's network, as shown inFigure 6. Martin, et al. Expires April 19, 2004 [Page 15] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 +-----+ +------+ +-----+ | MB1 |-------------| MB 2 |--------------| MB3 | +-----+ +------+ +-----+ | | +-----+ +-----+ | DS | | DR | +-----+ +-----+ MB: Middle box (NAT or Firewall or a combination) DS: Data Sender DR: Data Receiver Figure 6: Middle boxes on the Internet This scenario is rather rare, and presents the problem that MB2 is unlikely to have a peer to peer trust relationship with any of the other middle boxes. In this case, either the decision engine has a rather loose policy that accepts unverified requests, or the communication does not succeed. Martin, et al. Expires April 19, 2004 [Page 16] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 8. Optional extensions The proposed combination of signatures and handling is expected to provide authorization in most of the cases. There is a special case which might provide an extra level of security by securely establishing the source of the pinhole in DS's network. This is achieved by adding an extra signature in the NSLP, next to the Session ID signature. The data to be signed is the Session ID and the source of the pinhole. It is to be signed by DS or the last nat to have modified the source address. The relevant scenario is shown on Figure 7: +-----+ +-----+ | FW1 |-----------------------------------| MB2 | +-----+ +-----+ | | +-----+ +-----+ | DS | | DR | +-----+ +-----+ MB: Middle box (NAT or Firewall or a combination) DS: Data Sender DR: Data Receiver Figure 7: End to middle authorization Assume that MB2 does not know FW1, but it does know DS. Such a case would be that of a company (MB2) allowing it's employees working abroad to install pinholes even if connecting through an ISP (which runs a firewall, FW1). The special signature we added would allow MB2 to authenticate DS as the source. Something that FW1 could not do, because it is not known byMB2. This would be a case of end to middle trust. Martin, et al. Expires April 19, 2004 [Page 17] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 9. Security Considerations This entire memo discusses the security implications of using an NSIS NAT/FW NSLP. Martin, et al. Expires April 19, 2004 [Page 18] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 10. Conclusions The proposed method provides a reasonable way to decide wheter to honor or not NSIS NAT/FW NSLP requests. Peer to peer trust is expected within the network, and a certain degree of flexibility is also expected in the pinhole source. Further field research is required to determine if we are actually covering most of the real life scenarios. Martin, et al. Expires April 19, 2004 [Page 19] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 11. Contributors We would like to acknowledge the excellent contributions of Hannes Tschofenig to this draft. Martin, et al. Expires April 19, 2004 [Page 20] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 Normative References [1] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", DRAFT draft-ietf-nsis-threats-01.txt, January 2003. [2] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, August 2002. Martin, et al. Expires April 19, 2004 [Page 21] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 Informative References [3] Tschofenig, H., Buechli, M., Van den Bosch, S. and H. Schulzrinne, "NSIS Authentication, Authorization and Accounting Issues", draft-tschofenig-nsis-aaa-issues-01 (work in progress), March 2003. [4] Gupta, V., Gupta, S. and S. Chang, "Performance analysis of Elliptic Curve Cryptography for SSL", September 2002. [5] Boneh, D., Lynn, B. and H. Schacham, "Short Signatures from the Weil Pairing", 2001. [6] Stiemerling, M., Tschofenig, H., Martin, M. and C. Aoun, "A NAT/ Firewall NSIS Signaling Layer Protocol (NSLP)", DRAFT draft-ietf-nsis-nslp-natfw-00.txt, October 2003. Authors' Addresses Miquel Martin Network Laboratories, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 905 11 16 EMail: miquel.martin@ccrle.nec.de URI: Marcus Brunner Network Laboratories, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 905 11 29 EMail: brunner@ccrle.nec.de URI: http://www.brubers.org/marcus Martin, et al. Expires April 19, 2004 [Page 22] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 Martin Stiemerling Network Laboratories, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 905 11 13 EMail: stiemerling@ccrle.nec.de URI: Cedric Aoun Nortel Networks France EMail: cedric.aoun@nortelnetworks.com Martin, et al. Expires April 19, 2004 [Page 23] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 Appendix A. Acknowledgments We would like to acknowledge and thank the valuable input Joao Girao provided for this draft. Martin, et al. Expires April 19, 2004 [Page 24] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Martin, et al. Expires April 19, 2004 [Page 25] Internet-Draft NAT/FW NSLP Security infrastructure October 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Martin, et al. Expires April 19, 2004 [Page 26]