Internet Engineering Task Force M. Kaeo Internet-Draft Double Shot Security Expires: August 6, 2006 P. Savola CSC/FUNET February 2, 2006 Distributed Security Framework draft-kaeo-distsec-framework-00.txt Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 6, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Security policy enforcement is becoming increasingly challenging as the trend to utilize mobile and nomadic nodes in networked communications continues to grow. This document will enumerate the problem statement and threat model and will describe how a distributed security framework can address the threats related to these problems. Kaeo & Savola Expires August 6, 2006 [Page 1] Internet-Draft Distributed Security Framework February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Network versus Host-Based Security Models . . . . . . . . . . 4 4.1. Topology Constraints . . . . . . . . . . . . . . . . . . . 4 4.2. Flexibility . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Operational Deployment . . . . . . . . . . . . . . . . . . 5 4.4. Verifiability . . . . . . . . . . . . . . . . . . . . . . 5 5. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Unauthorized Control or Unacceptable Use . . . . . . . . . 5 5.2. Host Vulnerability Detection . . . . . . . . . . . . . . . 6 6. Threat Model Considerations . . . . . . . . . . . . . . . . . 6 6.1. Users Bypassing Corporate Security Policies . . . . . . . 6 6.2. Physical Access to Hosts . . . . . . . . . . . . . . . . . 7 6.3. L2/L3 Network Authorization . . . . . . . . . . . . . . . 7 6.4. Host Identification and Blocking . . . . . . . . . . . . . 8 6.5. Correct Policy Implementation . . . . . . . . . . . . . . 8 6.6. Distributed Information Security . . . . . . . . . . . . . 9 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. Informative References . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Kaeo & Savola Expires August 6, 2006 [Page 2] Internet-Draft Distributed Security Framework February 2006 1. Introduction Security policy enforcement is becoming increasingly challenging as the trend to utilize mobile and nomadic nodes in networked communication continues to grow. Whereas initially many network architectures revolved around network-based security solutions, end- nodes are now becoming as important in enforcing security policies as the network devices. Home automation devices, PDA's, laptops, and mobile phones are all IP-enabled and capable of connecting dynamically between different networks. Additionally, more peer-to- peer and GRID applications are becoming available that rely on an end-to-end paradigm that is made possible by IPv6. The nomadic capabilities for end-nodes make it difficult to effectively upgrade filtering and monitoring rules on devices that have no standards- based mechanisms to dynamically exchange, distribute and/or enforce their policies. This document will enumerate the problem statement and threat model and will describe how a distributed security framework can address the threats related to these problems. 2. Scope The main focus of a distributed security solution is on reducing the risk of a security breach, minimizing any damage in the local network environment should a security breach occur, and to isolate the misbehaving or vulnerable nodes from the network. Additionally, the scope of this work will include bi-directional, auditable policy enforcement. Take for example a user who installs a web server package yet port 80 is not open on the host. It should be possible to query the user as to which policy he/she would want to apply. Additionally, appropriate authentication may be required to apply the policy - i.e. appropriate credentials need to be supplied to authorize applying the policy. As mobile nodes move to different networks, this could effectively help in creating an auditable self- enforcement policy. Rather than dividing this work into separate problem sets (i.e. distributed firewall, distributed IDS, etc), the problem solution needs to encompass all aspects of distributed security to provide a comprehensive interoperable solution that relates to the overall goal of communicating and possibly modifying security rules between varying host-based and network-based security components. What is specifically out of scope is how to "merge" policy when a visiting host and the local network have individual and conflicting Kaeo & Savola Expires August 6, 2006 [Page 3] Internet-Draft Distributed Security Framework February 2006 policy views. Also out of scope is protecting devices such as routers and switches which, although they may need to participate in the enforcement of the distributive security framework, have existing tools that already provide appropriate security measures. 3. Problem Statement There are four distinct problems that a distributive security solution will address: 1. As mobile nodes move on and off varying networks, there is no consistent policy enforcement, i.e. having a capability to push a specific policy down to a node and having the node be responsible for enforcing it, both on local and remote networks. 2. There is no standardized mechanism for distributed feedback from IDSs [1] as input to centralized policy / decision making policy. 3. There is no standardized mechanism to isolate misbehaving nodes from the network once the node has already been connected. 4. There is no standardized mechanism for using policies which can't be enforced by network elements, for example which application versions are used by a specific host. 4. Network versus Host-Based Security Models Security models used to be based more on network-centric solutions where firewalls and intrusion detection systems were placed in varying places in the network separating the trusted from the un- trusted segments. However, as the distinction between trusted and un-trusted networks became more blurred, host-based firewalls and intrusion detection systems started becoming more prevalent. The tradeoffs between the two models are largely based on granularity of control versus simplicity in management, and a distributed security solution will try to find a balance between the models. We summarize some of the most important differences below. 4.1. Topology Constraints In network-centric solutions, the host is constrained to the security policy that is enforced for the network segment that it is connected on and there is no protection between hosts that are on the same LAN segment. A host-based security solution does not have any topology constraints. Kaeo & Savola Expires August 6, 2006 [Page 4] Internet-Draft Distributed Security Framework February 2006 4.2. Flexibility Because of the topology constraints, a network based security enforcement has limited flexibility. Host-based security solutions can more effectively enforce end-to-end security policies based on a combination of user identity, network location and specific application. In some instance where nodes are more trusted (perhaps because they are static), they may have a less restrictions than a general policy applied to nomadic nodes attached to the same network segment. 4.3. Operational Deployment A 'per-network' security policy is often easier to administrate than a 'per- host' security policy because there are fewer elements involved. While the same security policy may be enforced on all nodes of each network connected to a firewall, it may also be possible to have separate policies for all hosts. If the latter is warranted, then the operational considerations are similar for a network versus host based enforcement system. 4.4. Verifiability The network administration must know the policy that should be used in the network, and must also be able to verify whether the policy is being correctly enforced. This is relatively straightforward with network-only security mechanisms, while this is challenging with a host-based mechanism. 5. Threat Model At a generic level, most threat models pertain to how data systems can be maliciously compromised such that they become under unauthorized control, how information is susceptible to modification, re-direction, corruption, spoofing or how critical networked services are rendered unavailable. This section describes the threats that are relevant to a distributed security environment. 5.1. Unauthorized Control or Unacceptable Use There are many cases where unbeknownst to the user, their host has been compromised, and the host is at least partially out of control. For example, a host could be: o participating in a remotely-controlled malicious activity (e.g., as part of a 'botnet'), such as DDoS attacks, sending unsolicited email messages, performing port scanning, etc. Kaeo & Savola Expires August 6, 2006 [Page 5] Internet-Draft Distributed Security Framework February 2006 o participating in an uncontrolled improper activity (e.g., spreading a worm or a virus). There is a need to be able to better detect when a host has been compromised and to ensure that the compromised host can be taken off the network to avoid further malicious behavior. Today this is typically done in a manual fashion where, if a network administrator learns of a botnet participant, the relevant people are notified to fix the problem. This can sometimes take days and/or weeks since the administrators who may detect the problem could belong to different organizations. 5.2. Host Vulnerability Detection Many host operating systems are susceptible to attacks which take advantage of known implementation bugs or protocol deficiencies to cause inappropriate behavior. It is necessary to be able to detect whether a particular operating system is susceptible to known vulnerabilities and whether hosts require upgrades or downgrades of their operating system to mitigate the risk of being susceptible to the attacks. While network-based security scanners can detect some amount of these vulnerabilities, a more accurate and complete set of information could be obtained from the host itself. 6. Threat Model Considerations While network perimeter protection via firewalls has evolved to include host-based protection (anti-spam, anti-virus, and anti- spyware software, software version control, personal firewalls, host- based intrusion detection systems, etc.), there is limited interoperable coordination between the varying systems. Some proprietary implementations exist which attempt to coordinate the policy distribution and communication between varying security components in a network. The issues related to the threat model are addressed and NOT addressed by this coordinated effort as shown below. 6.1. Users Bypassing Corporate Security Policies Users are often keen (and even instructed by helpdesks) to turn off firewalls, virus scanners, etc. when debugging a problem or when such behavior is deemed undesirable (e.g., hampering playing a network- based game or running a peer-to-peer software). In enterprise scenarios, or where this is recognized as a problem, a Kaeo & Savola Expires August 6, 2006 [Page 6] Internet-Draft Distributed Security Framework February 2006 solution typically is to withhold administrator privileges from ordinary users preventing them from performing these actions. If the user has administrator access to the system, it is not possible to prevent these actions, short of more extensive security framework (e.g., "trusted computing"). Therefore we assume that the users are either knowledgeable enough or must not have the privileges to turn off the required security services. XXX: "How well do these policies get enforced now with stuff like HIDS or AV?" 6.2. Physical Access to Hosts In case of laptops and workstations, the users are expected to have physical access to the systems. In some environments, the IT support will have password-protected BIOS setups or other countermeasures to prevent users from, e.g., rebooting a system and performining administrative password recovery. While these countermeasures and policies might mitigate the threat of misbehaving users, we cannot assume the hosts would be physically safe from user's actions. If a host falls into the wrong hands (e.g., a stolen laptop), we assume that the system would be sufficiently encrypted. Alternatively, configurations must not include secrets which would be of significant information value in assisting a security breach. 6.3. L2/L3 Network Authorization It is assumed that the security of network access has been chosen according to the requirements of a site. For example, one could use 802.1x and EAP to control network access, using certificates and/or usernames and passwords. Some sites might view this as an overkill in their environment (e.g., where there is deemed to be sufficient physical security) and have no protections, or just perform MAC-address locking in the switch equipment. Other sites might require no or only minimal L2 authorizationm but require encrypted VPNs from all the hosts to VPN gateways to eliminate eavesdropping and hijacking. Sites may also have different requirements for layer 3 network access control, i.e., which IP address the user gets and whether the address can be changed/spoofed by the user if need be. In some rare cases, DHCP authentication may be in use, though it does not prevent manual configuration of another address. In IPv6, SEND [2] may be Kaeo & Savola Expires August 6, 2006 [Page 7] Internet-Draft Distributed Security Framework February 2006 applicable. Other solutions may exist. Distributed security should be able to work within any of these scenarios according to the site's security requirements. 6.4. Host Identification and Blocking XXX: "This is, of course, a standard technique in modern 802 networks." When security policy is communicated and applied, the hosts need to be reliably identified. The mechanisms by which this is done depend on the security requirements of the site. IP address, hostname, MAC-address, etc. or some combination thereof may or may not be sufficient; sometimes certificates may need to be used; if 802.1x and EAP were used for L2 network access or VPNs for L3 access, the user identification credentials used there could be used here as well. We also need to consider how access to the host can be blocked reliably (e.g., because its security is not at a sufficiently high level, because it has been compromised or because it hasn't been checked yet). o The most reliable way would be using strong identification (XXX: need spelling out?), but that cannot be expected to be readily available (and inspecting it on the wire would probably require that each host would use VPNs). o The easiest way is to use IP addresses. However, the user could just change an IP address and try again; presumably, all IP addresses (until verified) would need to be blocked by default. Then the user could try to hijack another, already-authorized user's IP address. However, this can often be noticed and even prevented, depending on the security requirements of the site. 6.5. Correct Policy Implementation Distributed security uses policies and checks to verify that the host should be secure enough. There are a couple of assumptions associated with this requirement: o The host (even if infected) will not lie about the checks, or there are other (e.g., network-based) mechanisms to detect the most blatant lies or other anomalous behaviour. In the absence of "trusted computing", for example kernel vulnerabilities could allow an attacker to hide their presence or activities. Kaeo & Savola Expires August 6, 2006 [Page 8] Internet-Draft Distributed Security Framework February 2006 o The policy language and mechanisms are expressive enough. For example, it may not always be possible to identify "good" and "bad" versions just by looking at a version string (especially as may be the case for "backported" updates). The implementations would need to include more extensive mechanisms for noticing and reporting problems. There are potential managerial problems in ensuring that, for example, the correct checksums of software are known. There are also potential combinatorial problems: it may not just be a matter of having specific versions of software but ensuring that the correct combination of versions are present. 6.6. Distributed Information Security Distributed security mechanisms need to be able to block the hosts at policy enforcement points. If there is communication between the IDSs or other mechanisms detecting anomalous behaviour, the communication should be at least authenticated and integrity- protected. The communication of a host and policy controllers should be sufficiently secure that the information cannot be altered by man-in- the-middle or other attackers. Typically this calls for encryption, integrity protection and sufficient authentication. 7. Conclusion A more coordinated effort between the network-based and host-based security components would provide a more effective and auditable security policy enforcement. 8. Acknowledgements This document combines and obsoletes an earlier, more detailed framework document [3] and a separate threat model document [4]. The most notable contributions to the earlier documents were made by Jari Arkko, Elwyn Davies, Sam Hartman, Eric Rescorla, and Hannes Tschofenig. 9. Security Considerations This memo is all about the distributed security and its threat models. The most important thing to note is that distributed security is not a perfect solution; as it needs to rely on (to some degree) the Kaeo & Savola Expires August 6, 2006 [Page 9] Internet-Draft Distributed Security Framework February 2006 users' and the host OS's correct behavior. In cases where this assumption does not hold stricter measures will be necessary. 10. IANA Considerations This memo does not require any IANA action. 11. Informative References [1] Wood, M. and M. Erlinger, "Intrusion Detection Mesage Exchange Requirements", draft-ietf-idwg-requirements-10 (work in progress), October 2002. [2] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [3] Vives, A., "Distributed Security Framework", draft-vives-distsec-framework-00 (work in progress), August 2005. [4] Savola, P., "Distributed Security Threat Model", draft-savola-distsec-threat-model-01 (work in progress), October 2005. Authors' Addresses Merike Kaeo Double Shot Security 520 Washington Blvd. #363 Marina Del Rey, CA 90292 USA Email: kaeo@merike.com Pekka Savola CSC/FUNET Espoo Finland Email: psavola@funet.fi Full Copyright Statement Kaeo & Savola Expires August 6, 2006 [Page 10] Internet-Draft Distributed Security Framework February 2006 Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kaeo & Savola Expires August 6, 2006 [Page 11]