Internet Engineering Task Force J. Palet Internet-Draft A. Vives Expires: August 24, 2005 Consulintel G. Martinez A. Gomez University of Murcia (UMU) February 20, 2005 IPv6 Distributed Security Requirements draft-palet-v6ops-ipv6security-02.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 August 24, 2005. Copyright Notice Copyright (C) The Internet Society (2005). 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 August 24, 2005 [Page 1] Internet-Draft IPv6 Distributed Security Requirements February 2005 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]. All these points and others are discussed in [2] as a reason of concern for the security administrator when operating IPv6 networks. In this document the problem is accepted and a step forward is done defining the requirements for a possible solution. How these requirements are satisfied by a possible solution is out of the scope of the present document. Palet, et al. Expires August 24, 2005 [Page 2] Internet-Draft IPv6 Distributed Security Requirements February 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Security Definition . . . . . . . . . . . . . . . . . . . . 4 3. Distributed Security Model . . . . . . . . . . . . . . . . . 5 4. The Host . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1 Interior Security . . . . . . . . . . . . . . . . . . . . 6 4.2 The Visiting Node . . . . . . . . . . . . . . . . . . . . 6 4.3 Default Security . . . . . . . . . . . . . . . . . . . . . 7 4.4 Other Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Policy Server and Protocol . . . . . . . . . . . . 8 6. Non-security-capable Nodes and Security Workload Distribution . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Location of the Security Policy Server . . . . . . . . . . . 9 8. Security Mechanism Modules . . . . . . . . . . . . . . . . . 10 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . 11 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1 Normative References . . . . . . . . . . . . . . . . . . 11 12.2 Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . 14 Palet, et al. Expires August 24, 2005 [Page 3] Internet-Draft IPv6 Distributed Security Requirements February 2005 1. Introduction 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 don't work in all the situations, for example, they don't consider the internal threats. Additionally, the network-based security 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 abd the nomadic host. 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, it is also true and perfectly understandable that there is a need to enforce security in the networks, in such way that the security 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 August 24, 2005 [Page 4] Internet-Draft IPv6 Distributed Security Requirements February 2005 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 should 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 As described in [2], a possible security scheme is the distributed one [1], as an alternative to the network-based 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 security administrator hands, while the individual nodes can take advantage of end-to-end and secure end-to-end communications. The basic idea is simple: the Security Policy is centrally defined using the Policy Specification Language and distributed to each host by means of a Policy Exchange Protocol. The Network Entities need to be authenticated in order to be trusted. See [2] for more details. These hosts 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 one or a few firewalls, each one being a point of failure for the complete network(s), that could be attacked or fail, creating a bottleneck for all the communications, there will be a number of firewalls (at every host) configured according to 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, they may not have those resources, and still need to rely on other devices for performing security functions on their behalf. Palet, et al. Expires August 24, 2005 [Page 5] Internet-Draft IPv6 Distributed Security Requirements February 2005 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. The Host With IPv6 and the distributed security model the host play a crucial role in the network security, in other words, the security mechanisms are moved to each host. As said above the entities, in this case the hosts, should authenticate themselves in order to be trusted. This will be a requirement of a possible solution. 4.1 Interior Security With this approach, the security of each host 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. 4.2 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 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 the visited network. When a node is attached to a visited network and receives the visited Network's security policy, basically there are two possible situations: Palet, et al. Expires August 24, 2005 [Page 6] Internet-Draft IPv6 Distributed Security Requirements February 2005 1. The network security policy is equivalent or less restrictive than the node configuration. In this case, the node could not change its security policy configuration or relax its restrictions if needed for some applications, always following the received security policy. For this some degree of granularity in the security policy specification and enforcement should be given. 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. 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 not 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, ...). 4.3 Default Security The 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, for example, in hot-spots, public networks, ad-hoc networks or even networks temporarily setup for conferences. The distributed security model addresses this case because the host will have all the necessary means to protect itself. A Possible solution must take this into account and have an appropriated mechanism to detect the connection to a foreign network and apply the correspondent security policy, previously defined by the host security administrator. This security Policy applied in foreign networks and/or in case of not having connectivity with the Policy Enforcement Point will be called the Default Security Policy. 4.4 Other Considerations A requirement will be to offer Policy Change Facilities allowing the user or the host security administrator to change security settings. Also the switching between two or more allowed security policies Palet, et al. Expires August 24, 2005 [Page 7] Internet-Draft IPv6 Distributed Security Requirements February 2005 could be implemented. 5. 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 dynamic 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 security administrator will define the security rules required by all the networks and/or individual nodes. A requirement will be to have a reliable Security Policy distribution mechanism. For example, the different nodes could 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. 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 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 Policy definicion Language and a Policy Exchange protocol are required 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. Following this approach, the security administrator will use a PMT (Policy Management Tool), to edit the policies and distribute them via PXP (Policy Exchange Protocols) to the PEP (Policy Enforcement Points), in this case the end nodes. For the interaction with IPsec policies, it seems appropriate the Palet, et al. Expires August 24, 2005 [Page 8] Internet-Draft IPv6 Distributed Security Requirements February 2005 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. 6. 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. Another requirement will be to take into account this, what we will call non-security-capable nodes. The possible solution could fragment the security enforcement in different levels establishing a ligh set of security requirements for those kind of nodes. Another alternative is that the noces could be partitioned from the network 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. How to address this requirement is out of the scope of this document. Despite the adopted solution, it seems only possible if minimum security verification can be done by those nodes, i.e. digital signature verification. It could be even considered a system to provide a kind of security workload-balancing. 7. 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. Palet, et al. Expires August 24, 2005 [Page 9] Internet-Draft IPv6 Distributed Security Requirements February 2005 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. 8. Security Mechanism Modules As said above, the security mechanism implemented could address several security problems by means of a number of tools. The basic ones should be firewall, IDS (Intrusion Detection System), Anti-virus and software version checker. These different tools could be thought as modules for both the policy definition and enforcement and the solution implementation. 9. Conclusions In this document it was accepted that a problem will arise with the network-based security scheme and the deployment of IPv6. Also the security scheme that was in mind during the requirements definition was the host-based or the distributed one [2]. Possible solutions to addresses the requirements outlined in this document is out of the scope and will be defined elsewhere. The Distributed Security Scheme has been described as the one that best fits as a solution to the Security Problem Stated [2]. This doesn't mean that the solution must follow this scheme strictly but seems to be useful at least as a guideline. The purpose of this document is to give some abstract requirements of a possible solution. As a summary of what has been seen above, we can outline the following requirements: 1. The solution must try to address as much as possible, in the sense of being able to protect against different threats using a number of mechanisms. The recommended ones are firewall, IDS, Anti-virus and software version control. 2. There must be a control mechanism to detect if a node is not following the appropriate security policy. This allows the solution to be prepared to receive foreign hosts. 3. The solution must allow the hosts to move to other networks under the same security policy, under a different one or under no security at all. Palet, et al. Expires August 24, 2005 [Page 10] Internet-Draft IPv6 Distributed Security Requirements February 2005 4. The security policy and its enforcement must be given with a certain degree of granularity in order to ease the different policies comparison and use. 5. A Security Policy Specification tool must be provided. This tool should use a single standard Security Policy Specification Language. 6. A reliable Security Policy Distribution mechanism must be provided. This mechanism should use a single standard Policy Exchange Protocol. 7. A reliable Security Policy Enforcement mechanism must be provided. 8. A reliable entity identity's authentication mechanism must be provided. 9. The solution must be dynamic in the sense of being able to respond to security events and adapt the policies accordingly. 10. Related to the previous one, a mechanism of "alarm distribution" is recommended, allowing the hosts to report security events to other hosts even in the case of, for example, problems in the Security Policy Server. The idea is that a distributed system could be more robust than a client-server one. 11. The solution must ease the security administrator's work allowing, for example, the centralized Security Policy management, i.e., definition, distribution and updating. 10. Security Considerations This document is concerned entirely with security. TBD. 11. 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. 12. References 12.1 Normative References Palet, et al. Expires August 24, 2005 [Page 11] Internet-Draft IPv6 Distributed Security Requirements February 2005 12.2 Informative References [1] Bellovin, S., "Distributed Firewalls", November 1999, . [2] Vives, A. and J. Palet, "IPv6 Security Problem Statement", Internet-Draft draft-vives-v6ops-ipv6-security-ps-02, October 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", Internet-Draft draft-morelli-v6ops-ipv6-ix-00, July 2004. [7] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)", Internet-Draft draft-ietf-send-ndopt-06, 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 Palet, et al. Expires August 24, 2005 [Page 12] Internet-Draft IPv6 Distributed Security Requirements February 2005 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 August 24, 2005 [Page 13] Internet-Draft IPv6 Distributed Security Requirements February 2005 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 (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Palet, et al. Expires August 24, 2005 [Page 14]