Internet Engineering Task Force J. Palet Internet-Draft A. Vives Expires: January 17, 2005 Consulintel G. Martinez A. Gomez University of Murcia (UMU) July 19, 2004 IPv6 Distributed Security Requirements draft-palet-v6ops-ipv6security-01.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she 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 17, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The security policies currently applied in Internet with IPv4, doesn't longer apply for end-to-end security models which IPv6 will enable. Palet, et al. Expires January 17, 2005 [Page 1] Internet-Draft IPv6 Distributed Security Requirements July 2004 Today, each network is often secured by one or several devices (i.e. security gateway or border firewall in the simplest configuration), which become a bottleneck for the end-to-end security model with IPv6. In addition, users and devices start to be nomadic, moving between different networks that could have different security policies. A distributed and dynamic approach is consequently required, as already described by [1]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Security Definition . . . . . . . . . . . . . . . . . . . . 3 3. Distributed Security Model . . . . . . . . . . . . . . . . . 4 4. Interior Security . . . . . . . . . . . . . . . . . . . . . 5 5. The Visiting Node . . . . . . . . . . . . . . . . . . . . . 5 6. Default Security . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Policy Server and Protocol . . . . . . . . . . . . 6 8. Single versus Multiple Points of Attack . . . . . . . . . . 8 9. Non-security-capable Nodes and Security Workload Distribution . . . . . . . . . . . . . . . . . . . . . . . . 8 10. Location of the Security Policy Server . . . . . . . . . . . 9 11. Virus . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 12. Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 13. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 10 14. Security Considerations . . . . . . . . . . . . . . . . . . 11 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 16.1 Normative References . . . . . . . . . . . . . . . . . . . 11 16.2 Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . 13 Palet, et al. Expires January 17, 2005 [Page 2] Internet-Draft IPv6 Distributed Security Requirements July 2004 1. Introduction The today's Internet paradigms for security need a revision with the deployment of IPv6, as suggested in [2], offering end-to-end security capabilities. Current security policies based on a centric approach with unique border devices don't longer apply, the so-called network-based security. Often they are based in a firewall or security gateway and statically configured rules, which not work in all the situations, as they don't consider the internal threads. Additionally, the firewall model is deeply incompatible with the model of virtual organizations that is fundamental to Grid computing, where virtual organizations cross all traditional security boundaries. Users and devices start to be nomadic. They often move from one network to another and this needs to be taken in consideration to keep the security of the complete visited network. Keeping today's static security model seems to be the wrong approach, which interferes with the end-to-end features and advantages of IPv6. Enforcing the nomadic users and devices to connect to Internet by means of the security gateway, in tunnel mode, is often equivalent to disable the IPsec protocol on each node, not allowing the use of transport mode and consequently invalidating one of the key IPv6 advantages. The lack of end-to-end secure communication and in general the current network-based security model, specially in enterprise networks, prevents innovation. On the other hand, is also true and perfectly understandable that there is a need to enforce security in the networks, in such way that the security (or network) administrator has always the control over it. 2. Security Definition As this document tries to stablish the security requirements for an IPv6 network, the definition of what is understood as security is of capital importance. We use security in the "big scope" of the word, trying to include as much as possible. In other words, a host, a network or some information, will be secure when no attacks could succeed against Palet, et al. Expires January 17, 2005 [Page 3] Internet-Draft IPv6 Distributed Security Requirements July 2004 them. A success will mean compromise of availability, integrity, confidentiality or authenticity. The realistic objective is to be as much secure as possible in a precise moment. So the security solution will include a number of mechanisms to provide security to network devices. Current mechanisms could be integrated in the solution and defined in the security policy. For example there could be active firewalling together with Intrusion detection, antivirus software and system update mechanisms. Security mechanisms should also include techniques to mitigate the danger in case of a compromised host and/or network. 3. Distributed Security Model The aim is to keep, or even more, be able to increase the security in the network as a whole and simultaneously keep the control of it under the network/security administrator hands, while the individual nodes can take advantage of end-to-end and secure end-to-end communications. This can be achieved with a distributed or host-based model replacing the current network-based one. The distributed security model implies the use of node or host firewalls and the usage of end-to-end application level security (i.e., Web Services security standards). Other security functions, like Intrusion Detection, could also be distributed in a similar fashion. These node or host firewalls must respect the security policy of the network where they are attached. In case of a conflict which is not automatically resoluble, a resolution arbitration mechanism should be established. The effect is simple to understand: instead of a single firewall, a single point of failure for the complete network, or a set of them, that could be easily attacked or fail, and create a single bottleneck for all the communications, there will be a number of firewalls (at every host), configured according a central policy, which increase the scalability, reliability, efficiency and performance of the complete network. This is often becoming possible in most of the nodes because even if IPsec and encryption are enforced for most of the communications, nodes often have powerful CPUs with unused cycles that will easily accommodate the extra required workload. In case of small devices, Palet, et al. Expires January 17, 2005 [Page 4] Internet-Draft IPv6 Distributed Security Requirements July 2004 they may not have those resources, and still need to rely on other devices for performing security functions on their behalf. On the other hand, the central firewalls will be able to dedicate CPU cycles to new functions, or be able to protect bigger networks. 4. Interior Security With this approach, the security of each node is not only towards communications with Internet or other networks, but also with the rest of the nodes in the same network. This means an increase in the overall security and the possibility to isolate individual nodes if required. 5. The Visiting Node This distributed security model is valid not only for fixed nodes, i.e. desktop computers, but specially interesting and important for those nodes like laptops and PDAs, which keep moving among different networks. Vice versa, this model is of key importance for those networks that receive visits from nodes that are not under the control of the network/security administrator. Different visited networks have different security requirements. Consequently is required that those nomadic nodes dynamically accommodate their own security policy to the one defined in the visited network and arbitrate the conflict resolution between the different policies. Nodes attaching to a network via VPNs, RAS, dial-up modems or other similar means can also be considered as visiting nodes, as they can also create a path between the visited network and any other network where they are actually connected. They must also be able to dynamically configure their own security to match the one existing in then visited network. A possible solution should take into account the case of a device attaching to the network and not following the security policy, either because it does not want to or because is no able to. The alternative often used today to accomplish this, is by means of manual changes in the configuration of the visiting node, but they are always prone to errors and dangerous to be considered useful and secure enough, specially considering that the visiting node can be already infected from previous connections to other non-protected networks (home network, hot-spot, ...). Palet, et al. Expires January 17, 2005 [Page 5] Internet-Draft IPv6 Distributed Security Requirements July 2004 6. Default Security Implementing IPsec in the IPv6 stack of the nodes is only a first step for a sophisticated security model. However, a more complete approach is required. These nodes can be attached to a network which doesn't offer any protection means, not only against external attacks, but also those coming from the same network. This is the common case, for example, in hot-spots, public networks, ad-hoc networks or even networks temporarily setup for conferences. In order to keep the appropriate security level, each node should incorporate a kind of node or host firewall. The node or host firewall must be configured by default with a very restrictive set of rules. At this way, the node is self-defended, in any circumstance. The node or host firewall must act as a policy enforcer. The node or host firewall should offer a simple user interface to facilitate to relax the security restrictions, if required by certain applications or services, assuming the lack of expertise of the user. In case the device (i.e. laptop), belongs to an enterprise or similar network, which has its own security policy, it can be enforced to certain degree of protection, even when not attached to the network. 7. Security Policy Server and Protocol In order to achieve the benefits of the distributed security model, and at the same time provide the mean for the adequate and dynamically control of the overall network security by the network/ security administrator, a security policy server is required. The policy server(s) function could replace the main functionality of the central firewall and complement it. The network/security administrator will define the security rules required by all the networks and/or individual nodes. The different nodes should query to the policy server to learn about the network security policy and adapt themselves in order to match it. The policy server could also request information and security status to the nodes. Palet, et al. Expires January 17, 2005 [Page 6] Internet-Draft IPv6 Distributed Security Requirements July 2004 When a node is attached to a visited network and receives the visited network security policy, basically there are two possible situations: 1. The network security policy is equivalent or less restrictive than the node configuration. In this case, the node will not change its security policy configuration. What happens if the new network policy is less restrictive and for example enables a videoconferencing system that was not available in the "default home network" ?. TBD. 2. The network security policy is more restrictive than the actual node configuration. In this case, the node will adapt its security configuration to at least match the one indicated by the security policy. Until the node performs and acknowledge the required security policy configuration update, it must not be allowed to transfer/receive data to/from other nodes either in the network or other connected networks. The security policy server can also dynamically update the security policy for the complete network or specific nodes. This can be done in response to a network/security administrator decision, or other situations, like information received from an external or internal attack, detected by an intrusion detection system, firewall or even by nodes inside the network. The security policy should be administered at a network level or individually for every node, upon decision of the network/security administrator. A single standard language or protocol for the signaling between the nodes, security policy servers, firewalls (including node or host firewalls), intrusion detections systems, honey pots, routers, and any other elements implicated in the overall network and nodes security, is required. For simplicity, the policy server could be integrated in the border router, firewall, or other network elements (AAA, DHCP, COPS, ...). A candidate approach is to align this with the existing COPS [3] and COPS-PR [4] standards. Following this approach, the network/security administrator will use a PMT (Policy Management Tool), to edit the policies and distribute them via PMP (Policy Decision Points) to the PEP (Policy Enforcement Points), in this case the end nodes. Palet, et al. Expires January 17, 2005 [Page 7] Internet-Draft IPv6 Distributed Security Requirements July 2004 For the interaction with IPsec policies, it seems appropriate the existing IPsecCPIM [5]. To guarantee the self-security of this model, the security policy being communicated to the nodes should be digitally signed, in order to provide integrity, origin authentication and non-repudiate authenticity of the source. 8. Single versus Multiple Points of Attack The single security gateway approach is a single point of failure and consequently a bottleneck. At the same time, is easier to attack a single device, so the possibilities of a security threat are higher. On the other hand, the distributed approach reduces the risk of a single point of failure and increases the difficulties for potential attackers to succeed (port scanning is more difficult). The failure of the central firewall could completely disconnect the network from Internet or other networks. In the case of a central policy server failure, the nodes should be configured by the security policy in such way that they continue working, keeping the same trusted security restrictions previously imposed by the policy server. In case of a major breach, the security policy could had been configured in order to partition every node, or to temporarily use the default perimeter firewall. TBD. How about a compromised host that pretends to conform to the central policy but is actually a hacker heaven? TBD. 9. Non-security-capable Nodes and Security Workload Distribution Increase in security often means increase in processing power. Some nodes could not have the required CPU cycles to afford the complete required security policy. These nodes could be partitioned from the network as a simple solution, and treated as non-security-capable nodes. Alternatively, the firewalls or even other security-capable nodes with free resources, could act as trusted security gateways for the non-security-capable nodes. This seems only possible if minimum security verification can be done by those nodes, i.e. digital signature verification. Palet, et al. Expires January 17, 2005 [Page 8] Internet-Draft IPv6 Distributed Security Requirements July 2004 It could be even considered a system to provide a kind of security workload-balancing. Some work is still required to define if the security level that can be achieved by those nodes is good enough, and to avoid possible attacks. This section needs to be completed in further revisions of this document. TBD. 10. Location of the Security Policy Server Firewalls and security gateways are expensive devices and they are required to sit at the border of the network. They also require qualified personal to manage them. In the case of the distributed security model, the security policy server isn't required to be collocated as a border device. This provides the opportunity to have this device not only inside the network, but also at any other point in Internet. This opens the doors to new services and business models that provide very sophisticated security services, especially for Home, SOHO and SMEs. Some possible "ideal" locations for the security policy servers could be Internet Exchanges [6] or in general PoPs, ISPs, and other similar central Internet locations. 11. Virus As part of the services offered by the distributed security model, it could offer means to alleviate the effects of virus. To be completed in next versions of the document. TBD. 12. Spam One more possible service of the distributed security model solution, could be the protection against spam. This could mean for example, extensions to protocols as SMTP, etc. To be completed in next versions of the document. TBD. Palet, et al. Expires January 17, 2005 [Page 9] Internet-Draft IPv6 Distributed Security Requirements July 2004 13. Conclusions Towards achieving an IPv6 distributed security solution, the following requirements should be taken into account: 1. Dynamic security policy specification language, exchange protocol and server. 2. Authentication of entities. 3. Support of SEND protocol ([7]). 4. Support for unmanaged nodes/devices. 5. Control and node/network partition mechanism, to ensure the securization of the rest of the network in case of a thread, even if internal. 6. Alert/notification mechanism to facilitate the inter-node and/or node-policy server communication. 7. Node or host firewall, with a secure enough default configuration, that can be updated by a trusted dynamic security policy server. The node or host firewall should also include functionalities such as: 1. Integral thread protection. 2. Resolution and arbitration of conflicts between different security policies. 3. Support for end-to-end application level security (i.e., Web Services security standards). 4. Intrusion detection. 5. Collection of audit information. 8. Optionally it could also include: 1. Anti-virus. 2. Anti-spam. TBD. Palet, et al. Expires January 17, 2005 [Page 10] Internet-Draft IPv6 Distributed Security Requirements July 2004 14. Security Considerations This document is concerned entirely with security. TBD. 15. Acknowledgements The authors would like to acknowledge the inputs from Cesar Olvera, Brian Carpenter, Satoshi Kondo, Pekka Savola and the European Commission support in the co-funding of the Euro6IX project, where this work is being developed. 16. References 16.1 Normative References 16.2 Informative References [1] Bellovin, S., "Distributed Firewalls", November 1999, . [2] Vives, A. and J. Palet, "IPv6 Security Problem Statement", draft-vives-v6ops-ipv6-security-ps-00 (work in progress), April 2004. [3] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. [4] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001. [5] Jason, J., Rafalow, L. and E. Vyncke, "IPsec Configuration Policy Information Model", RFC 3585, August 2003. [6] Morelli, M., "Advanced IPv6 Internet Exchange model", draft-morelli-v6ops-ipv6-ix-00 (work in progress), July 2004. [7] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05 (work in progress), April 2004. Palet, et al. Expires January 17, 2005 [Page 11] Internet-Draft IPv6 Distributed Security Requirements July 2004 Authors' Addresses Jordi Palet Martinez Consulintel San Jose Artesano, 1 Alcobendas - Madrid E-28108 - Spain Phone: +34 91 151 81 99 Fax: +34 91 151 81 98 EMail: jordi.palet@consulintel.es Alvaro Vives Martinez Consulintel San Jose Artesano, 1 Alcobendas - Madrid E-28108 - Spain Phone: +34 91 151 81 99 Fax: +34 91 151 81 98 EMail: alvaro.vives@consulintel.es Gregorio Martinez University of Murcia (UMU) Campus de Espinardo s/n Murcia E-30071 - Spain Phone: +34 968 364 607 Fax: +34 968 364 151 EMail: gregorio@um.es Antonio F. Gomez Skarmeta University of Murcia (UMU) Campus de Espinardo s/n Murcia E-30071 - Spain Phone: +34 968 364 607 Fax: +34 968 364 151 EMail: skarmeta@um.es Palet, et al. Expires January 17, 2005 [Page 12] Internet-Draft IPv6 Distributed Security Requirements 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. Palet, et al. Expires January 17, 2005 [Page 13]