Internet Engineering Task Force A. Vives Internet-Draft J. Palet Expires: January 12, 2006 Consulintel P. Savola CSC/FUNET July 11, 2005 Distributed Security Framework draft-vives-v6ops-distributed-security-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 January 12, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Current Internet trends in several fields have brought some security concerns with regards to what will happen with the current security paradigms and mechanisms. This document analyzes two security paradigms, the network-based and the host-based. The former refers to what is being used nowadays out Vives, et al. Expires January 12, 2006 [Page 1] Internet-Draft Distributed Security Framework July 2005 there and the latter is based on the distributed firewall concept [2]. From the point of view of these security concerns it is stated that there is a problem that must be addressed. Some insights are given with respect to the host-based security paradigm. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Security Models . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Network-based . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Host-based . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9 4. Framework for Distributed Security . . . . . . . . . . . . . . 11 4.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 11 4.2 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.1 Enterprise . . . . . . . . . . . . . . . . . . . . . . 13 4.2.2 Home-User . . . . . . . . . . . . . . . . . . . . . . 14 4.2.3 Public Hot-Spot . . . . . . . . . . . . . . . . . . . 14 4.3 Functions of the Elements . . . . . . . . . . . . . . . . 14 4.3.1 Policy Specification Language (PSL) . . . . . . . . . 14 4.3.2 Security Policy (SP) . . . . . . . . . . . . . . . . . 15 4.3.3 Security Status (SS) . . . . . . . . . . . . . . . . . 15 4.3.4 Security Domain (SD) . . . . . . . . . . . . . . . . . 16 4.3.5 Policy Enforcement Agent (PEA) . . . . . . . . . . . . 16 4.4 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.4.1 Node Addition/Deletion . . . . . . . . . . . . . . . . 16 4.4.2 Authentication . . . . . . . . . . . . . . . . . . . . 17 4.4.3 Policy Exchange Protocol . . . . . . . . . . . . . . . 17 4.4.4 Data Integrity and Authenticity . . . . . . . . . . . 18 4.4.5 Moving between security domains . . . . . . . . . . . 18 5. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1 Normative References . . . . . . . . . . . . . . . . . . . 19 9.2 Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . 21 Vives, et al. Expires January 12, 2006 [Page 2] Internet-Draft Distributed Security Framework July 2005 1. Introduction There are a lot of emerging technologies that lead to scenarios where the current security paradigms, mechanisms and practices are not capable to protect against current threats, which have increased in type and number. These have raised some security concerns with regard to what will happen in a medium/short term. Nowadays we are seeing how IP-enabled devices are more common each day, so we don�t just see laptops but also PDAs and mobile phones walking around and connecting/roaming to/between different networks. This comes together with the use of P2P and GRID applications which are based on the end-to-end paradigm. In line with the end-to-end paradigm is the new Internet Protocol version (IPv6) [3] because of the provision of enough globally routable addresses as required. For example Mobile IP needs several addresses for each moving host [4]. IPv6 also adds the availability of IPsec [5] [7] in the stack, what could be used for end-to-end encrypted communications, with all the problems that this imply to the security infrastructures currently deployed. Another kind of IP devices that are appearing are home automation devices which have its own IP stack and applications but few computing resources. These devices are susceptible of being compromised and used for malicious things but have almost no resources to be used for being self-protected. From this perspective, this document analyzes the most (currently) used security paradigm, which from now will be referred as network- based security scheme. The objective is to identify its drawbacks and advantages against the new foreseen scenarios. Based on the distributed firewall concept [2] we introduce the host- based security scheme, which extends the security mechanisms used from only firewalling to a number of them (IDS, firewalling, anti- virus, version control, etc.). Not only its drawbacks and advantages against the new foreseen scenarios are identified but also it is presented as a possible direction to follow to solve the above- mentioned security concerns. Once these two security models are described we state that a security problem will arise if no new techniques are used to address the coming technologies. In order to provide some insights about the distributed security Vives, et al. Expires January 12, 2006 [Page 3] Internet-Draft Distributed Security Framework July 2005 model some definitions and scenarios are given along with some concrete issues analysis. 2. Security Models 2.1 Network-based To secure a network one or more Firewalls (FW) are used depending on the network topology and size. The FW can perform security tasks over the traffic that goes through/to its interfaces. The security administrator will be in charge of putting the firewalls where it considers and to configure them to accomplish the organization&# 65533;s network security policy. /-------\ / \ | Internet | \ / \---+---/ | (*) Policy Enforcement Point +---+---+ /---\ +-------+ | | | \ / | | | ---+-----(*)+ FW1 +(*)---+----+ X +---(*)+ FW2 +(*)-----+-----+-- | | | | | / \ | | | | | +-+--+ +---+---+ +--+-+ \-+-/ +---+---+ +--+-+ +-+--+ | S1 | (*) | H2 | | (*) | H5 | | H6 | +----+ | +----+ | +----+ | +----+ +----+ +----+ | +--+ H3 | +--+ H4 | +----+ | | +----+ | +----+ | H1 +--+ +----+ | Figure 1: Network-based Security As an example we can see in Figure 1 a network with one connection to Internet and several LANs. With this configuration the FW1 could inspect all the traffic coming in/out from/to Internet. This means that FW1 will be the first node that an outside attack will see. As can be seen the security policy in enforced in all FWs interfaces. Note that, for example, traffic between H2 and H3 or between H5 and H6 is not noticed by any FW. This is the most used scheme, where the security of a host depends on the point of the network it is connected to, i.e., depends on the topology of the network. Vives, et al. Expires January 12, 2006 [Page 4] Internet-Draft Distributed Security Framework July 2005 The complexity of the security infrastructure will be proportional to the size of the network and the decisions taken by the security administrator who will decide the number and type of FWs. There are mechanisms to propagate the configuration among different firewalls, from the same manufacturer and for big appliances, in order to simplify the administration in case of large networks. This model is based on the following assumptions to work properly: o The threats come from "outside" the protected network, basically the Internet. o Everybody from the same LAN segment is trusted. o The protected nodes won't go "outside" the protected network where the security infrastructure won't be able to protect them. o There are no backdoors on the network (modem, WLAN, other connections). o The hosts will not need to be accessed directly from outside (at least in a general manner, i.e., potentially all ports on all hosts). o The security policy could be applied in one or more of the following levels: network, transport and application. The advantages of this model are: o It is a mature technology which have been used for a long time. o Its simplicity and easiness as the elements and points of configuration are reduced to the minimum. The drawbacks of this model are: o This is a firewall-dependant model, i.e., if a FW fails, then all the networks connected to it will loose network connectivity unless specific fail-over techniques are applied. o A big percentage of the threats come from inside the protected network. To protect all the inter-LAN communications in a large network the number and cost of the needed FWs could be too much. In any case the hosts are not protected within its own LAN segment. o The most dangerous threats, in the sense that one may not be able to protect from them, come from inside the protected network. Vives, et al. Expires January 12, 2006 [Page 5] Internet-Draft Distributed Security Framework July 2005 o The FW usually acts as NAT and/or proxy box, interfering or even disallowing end-to-end communications. In complex configurations, even more than one level of NAT/proxy could appear. o Transport mode secured communications (using IPsec ESP for example) need special solutions ([1]). o The same security policy may be enforced for all the nodes of each network connected to the FW, but it is also possible to have separate policies for all hosts. In any case, an error in a FW will equally expose all hosts on networks connected to that FW. o Virtual organizations, for example those using GRID models, don't work with traditional centralized security models. o The lack of secure end-to-end prevents deployment of innovative applications. 2.2 Host-based We will call Host-based security model an evolution of the concept of distributed firewall already introduced by [2]. It is based on the idea of enforcing the security policy in each network host from a central control point. The biggest challenge is trusting that the hosts comply to the rules they've received, for example that the user can't just disable the firewall if (s)he dislike the policy. Of course, this only can happen in the case (s)he has administrative rights for that (often not the case in non-personal systems, those not owned by the end- user, such as corporate PCs or laptops). It seems that one or more network entities would have to keep watch over the hosts in order to detect if they are not following the received policy. From a security point of view this model somehow eases the work to the "enemies", putting the Policy Enforcement Point in their hands. So, not only mechanisms to prevent direct attacks to the security solution must be developed but mechanisms to minimize the consequences as well. Vives, et al. Expires January 12, 2006 [Page 6] Internet-Draft Distributed Security Framework July 2005 /-------\ / \ | Internet | +------+ \ / |Secur.| \---+---/ |Policy| | +--+---+ | (*) /-+-\ | | \ / | LAN-3 -+---+------+ x +-------+-- LAN-1(*) | / \ | (*) Policy Enforcement Point +--+-+ \-+-/ +-+--+ | H1 | | LAN-2 | H3 | +----+ | +----+ (*) +--+-+ | H2 | +----+ Figure 2: Host-based Security This model is based on the following assumptions: o Each host can be uniquely and securely identified. o The security policy could be applied in one or more of the following levels: network, transport and application. o Threats come from anywhere in the network. o "Outside" hosts may be able to access all hosts "Inside", depending on the policies. o No assumptions are made about where the host can be connected. The advantages of this model are: o The flexibility in the definition of security policies, as it is based on the assumption of an available Policy Specification Language which can be used for high-level definitions of all the needed policies. o A host can take better decisions as it knows what it is doing or trying to do, that means it can better detect strange packets. For example, it could allow mail traffic to only one application on the system. Vives, et al. Expires January 12, 2006 [Page 7] Internet-Draft Distributed Security Framework July 2005 o Enables the usage of end-to-end applications level security (e.g., web services security standards). o Enables better protection from attacks by the "internal" users, and possibly even to a degree from those in the local segment. For example address spoofing can be detected and avoided coming from the same LAN segment, without router participation, because a host in a LAN can detect packets from other host with source addresses that are not used in that LAN. o Can protect a host independent of the topology, i.e., wherever the host is connected. o Does not need specific devices to secure a host. Consider the case of a single host with a CPE (Customer Premises Equipment), if the CPE has no (user-controllable) firewall functions. o Can control the outgoing attempts from each host, avoiding local network misbehavior or malicious practices. o The collection of audit information could be more complete in a distributed model, despite the processing of that information is done in a distributed or centralized fashion. o It maintains the centralized control of the security policies, from where they are distributed to each host (central decisions, local enforcement), despite the size of the network to protect. In general it scales well. o It enables new distributed and cooperative solutions to improve the network security. The drawbacks of this model are: o It is more complex than the Network-based one as more elements are needed, some of them need to be defined or even designed. o The uniqueness and secured identification of hosts is not trivial (for example, [2] proposes the use of certificates). o The hosts must be trusted (or designed appropriately) so that they will operate according to the policy. For example, it must be impossible to disable the firewall functions or if the policy is not followed network communication is not allowed. o A host that becomes compromised or infected with a worm or virus in any case can't be trusted to operate according to the policies, as the worms/viruses probably first create holes or disable the Vives, et al. Expires January 12, 2006 [Page 8] Internet-Draft Distributed Security Framework July 2005 protections if they can. o It may be challenging to design the system so that policy updates are made available to the nodes which may not be network-reachable all the time. o It may be difficult to distinguish a misbehaving application from a legitimate application (for example, many email worms may be channeled through the MUA which must be authorized to send the mails to operate correctly). o Because of having a centralized Policy Decision Point (PDP) from where the Security Policies are distributed a weakness is introduced in form of a central point of failure unless more complexity is added, for example with a distributed/replicated system. o The host security is in some sense 'server-dependant'. It must be able to detect the lost of connectivity with the PDP and act in consequence. It also seems that being disconnected from the PDP for a long period could be dangerous because updated security information raise the security level. 3. Problem Statement The starting points are the new technologies we mentioned above and the network-based security model. We will demonstrate that things like IPv6 deployment or P2P applications impose a problem to the most common security models. Finally we will outline how the host-based security model is able to address a number of those problems. Not only new technologies but also new threats have appeared that use security holes in the software. Viruses, spyware, adware, spam, worms and (D)DoS attacks have made necessary to use several security tools to fight these threats. This is the reason of the appearance of different software pieces that are installed on both the servers (anti-spam and anti-virus) and the user hosts (software version control, anti-virus and anti-spyware). The trend seems to be to direct the attacks against user hosts, the attacks directed to servers are decreasing. We can summarize the consequences of the appearance of new technologies (IPv6, P2P, GRID, mobile IP, etc.), new behaviors and new threats as: Vives, et al. Expires January 12, 2006 [Page 9] Internet-Draft Distributed Security Framework July 2005 1. The need/use of end-to-end communications. 2. The availability/use of IPsec on all IP devices. For example, all IPv6 stacks have IPsec capability that can be used if required. 3. Nomadic IP devices that will move between different networks under different security administration. 4. A number of different security mechanisms are needed in order to protect a network/host. The network-based security model has problems addressing the above points. This can be summarized in: 1. It difficults/avoids end-to-end communications because of the FWs acting as NAT and/or proxy. 2. Transport mode secured communications (using IPsec ESP for example) need special solutions ([1]). The basic idea is that the encrypted payload can�'t be inspected. 3. It is not able to protect nomadic nodes that move out of the protected network. In foreign network the nodes are exposed to threats and can be infected when they come back to their "home" network. In the other hand the host-based security model could address the following points from the above-mentioned: 1. It assumes end-to-end connectivity of all nodes, so the end-to- end communications are the natural way of doing things. 2. As the security rules could be applied before encrypting the payload, the encrypting does not affect the security mechanism which could work in a straightforward way. 3. Nodes will be protected wherever they are as always will have security mechanisms on the hosts. It should be taken into account that the security policy update must be done as frequently as possible. In any case it should be clearly stated that the network-based security model is a mature technology which have been used for a long time. The host-based security model is basically just this, a model, and several issues must be solved before it takes place. Security improvements in both the network-based and the host-based Vives, et al. Expires January 12, 2006 [Page 10] Internet-Draft Distributed Security Framework July 2005 security models are required, for example to be able to cope with all the actual security threats. The idea is to try to integrate in a unique solution as much mechanisms as possible, and tune them to follow the security policy within a protected network and its hosts, in case they move to a foreign network. Following this idea a hybrid model could be used where both the network-based and host-based models are used. The tasks could be distributed among both or be activated depending of where the host is connected to, if there is a security alert situation, etc. Insights over the problems that host-based security model must resolve before being deployed in real life are outlined in following sections. 4. Framework for Distributed Security 4.1 Definitions To describe the distributed security model several terms will be used. They are defined here as follows: o SD (Security Domain): Network portion under the administration of the same Security Administrator/Organization. o SP (Security Policy): We refer to the information that is distributed to each policy enforcement point within a SD in order to achieve the desired level of security. This information will follow the whole protected network security policy defined by the Security Administrator of that network. This information will be converted to specific rules for each platform by the Policy Enforcement Agent. o SS (Security Status): Information about host different aspects that could be used to measure how secure it is. o PSL (Policy Specification Language): Language used to define SP and SS. o PDP (Policy Decision Point): The node where the SPs for a SD are defined. From the PDP the SPs are distributed to PEPs. o PEP (Policy Enforcement Point): The place where a SP is applied. o PEA (Policy Enforcement Agent): The entity in charge of applying the SP at the PEP. Vives, et al. Expires January 12, 2006 [Page 11] Internet-Draft Distributed Security Framework July 2005 o PXP (Policy Exchange Protocol): The protocol used for distribution of the SP to the PEA. /-------\ / \ ( Internet ) \ / +-----+ \---+---/ | PDP | | +--+--+ (*) (*) /--+--\ | | \ / | LAN-3 -+---+---(*)+ PEA4 +(*)----+-- LAN-1 (*) | / \ | (*) +--+-+ \--+--/ +-+--+ |PEA1| (*) |PEA3| +----+ | +----+ | | (*) LAN-2 +--+-+ |PEA2| (*) Policy Enforcement Point +----+ Figure 3: Definitions: Basic Scheme The basic idea is simple: the Security Policy is centrally defined using the Policy Specification Language and distributed to each Policy Enforcement Agent by means of the Policy Exchange Protocol. The PEA will apply the SP to each Policy Enforcement Point it is responsible for. The network entities need to be authenticated in order to be trusted, for example to allow an incoming connection or to trust on the received Security Policy. 4.2 Scenarios In order to gain some insights in the distributed security analysis some scenarios are depicted to be considered when drawbacks and advantages are outlined. The idea is to address some general scenarios which already exist and where new technologies, devices, users and behaviors take place. For example the deployment of the new Internet Protocol, IPv6, the use of P2P and GRID applications and new nomadic IP devices could be seen as some of the issues that bring new security scenarios that should be Vives, et al. Expires January 12, 2006 [Page 12] Internet-Draft Distributed Security Framework July 2005 analyzed. One important issue that must be taken into account is the movement of a host between different scenarios/networks. This point will be addressed in section 4.4.5 of this document. Basically three possible scenarios have to be addressed, all of them interconnected through Internet: o Enterprise. o ISP-Client. o Public. /\ /-------------------------\ \ / / \ / INTERNET \ \/ / \ / /-\ \ +--+ +---+ *---------* / | X +-|---|AP| ))) |PEA| | | | /--------\ \-/ | +--+ +---+ | +---+| | | /-\ ISP| | Public | |PEA++-|--+-+ X | | | Hot-Spot |+-+ +---+| | | \+/ | | || | | | | | | | ++-+------+ | | +-+-+ | /--------\ | Home-User | | |PDP| | | /-\ ISP| | | \+---+---/ | | X | | | | | \+/ | / \ | | | / \ \---+----/ / \------------------+-----/ | /-\ Enterprise -+-----+ X +-----+- | \+/ | +-+-+ | +-+-+ |PEA| +-+-+ |PEA| +---+ |PDP| +---+ +---+ Figure 4: Scenarios 4.2.1 Enterprise This scenario considers the case of an organization with its own infrastructure containing both PDP(s) and PEP(s). This means that Vives, et al. Expires January 12, 2006 [Page 13] Internet-Draft Distributed Security Framework July 2005 all the security infrastructure elements will be within the organization premises under the same administration. All the hosts connected to the protected network will also be administered by the above-mentioned administration. So, it is highly probable that they use some kind of distributed security software that would collaborate to increase the security. 4.2.2 Home-User This scenario considers the case of an Residential Customer which has its PEP as part of the security solution. The user has several choices as PDP. The user could even not have a PDP and define by himself the Security Policy. Also could use one provided as a paid service from a company located somewhere in Internet. The ISP could also offer a PDP service for its customers. In case of a user connecting to his/her enterprise VPN the PDP used should be the one from that network. Even in the case of not using a VPN the PDP could be the one from the user company. Other hosts in the same network will be in charge of the Home-User, so they could use some kind of distributed security software that would collaborate to increase the security. 4.2.3 Public Hot-Spot This scenario considers the case of the host being connected to a pubic Internet connection (not neccesarily only the case of a Wi-Fi Hot-Spot). In this case the PEP will be located at the host but could not be sure to trust/have connectivity to a foreign PDP. Other hosts in the same network can not be trusted at all to be using some kind of distributed security software that would collaborate to increase the security. 4.3 Functions of the Elements 4.3.1 Policy Specification Language (PSL) The host-based model is based on the assumption of the use of a number of security mechanisms, for example firewall, IDS, anti-virus and software version control. This requirement means that the PSL must be flexible enough to specify the information about different objects and rules to behave depending on the value of that information. Vives, et al. Expires January 12, 2006 [Page 14] Internet-Draft Distributed Security Framework July 2005 Also the PSL must be able to specify security policies for new mechanism that could be added or appear in the future. The flexibility in the PSL will allow the coordinated use of the different security mechanisms by the PEA. For example it could be defined that if the version of the mail user agent is not a safe one (version control security mechanism) the mail traffic is not allowed (firewall security mechanism). The syntax and semantics of the PSL must be clearly defined in a standard way. 4.3.2 Security Policy (SP) Thanks to the flexibility of the PSL the SP will include all the needed rules to follow the Security Administrator needs. The security policy should have rules to define configuration for all the security mechanisms used, based on the Security Status of the host. The SP could be specified with different granularity and using conditional statements. Granularity refers to the ability of referencing, at each layer, to all the possible elements. For example, TCP/UDP ports or any IP header element�s value. It is a matter of the implementation to reach a compromise between granularity and complexity. Conditional statements refers to the ability of taking decisions based on the values of different elements, as detailed as the granularity allows. Even different complete sets of rules could be defined for different situations, like changing to a different SD (see Scenarios section above). For example, in case of the change of a value the PEA could already have a rule on the received SP for the new value, avoiding the need of communicating it to the PDP, which would have to define a new SP and send it to the PEA. The SP also will be used to manage the update of elements in the host in order to increase the security, for example, a new anti-virus signature file or a new patched version of a piece of software with a known security breach. 4.3.3 Security Status (SS) Security Status is the list of the defined properties of the system, to be used for checking the conformance to the Security Policy. For example: "firefox", "1.0.2"; where the security policy might mandate Vives, et al. Expires January 12, 2006 [Page 15] Internet-Draft Distributed Security Framework July 2005 that version 1.0.3 would be required. 4.3.4 Security Domain (SD) The concept of Security Domain is of capital importance in order to clarify where a SP must be applied. Also the concept of changing from one SD to another one is important and will be addressed leter in this document in detail. A host that connects to a SD must accept the SP it receives and apply it. In case of not following this rule the host could not be sure to have network connectivity. It is matter of the security solution how to manage the hosts that don't apply the received policy. 4.3.5 Policy Enforcement Agent (PEA) The PEA will have a key role in the whole system as it will be the one in charge of assuring that the received SP is applied. To accomplish this task several issues must be addressed: o Verification of Authenticity and integrity of the received SP. o Verification of the Security Status (SS) of the PEP. o Comparison between the SS and the received SP and application of the specified rules depending on the comparison results. o Running the different security mechanisms. o Being able to communicate with other PEAs in order to allow distributed security mechanisms. o Being proactive in order to detect and respond to any security event. 4.4 Issues 4.4.1 Node Addition/Deletion We refer to addition to both: o The process of configuring a totally new node, installing the PEA and its first message exchange with the PDP or other PEAs. o The addition of a node to the process launched when a node that has been off-line get reconnected again and tries to communicate with one PDP to get the last available SP. Vives, et al. Expires January 12, 2006 [Page 16] Internet-Draft Distributed Security Framework July 2005 This dual approach applies also for the deletion process. During the process of a node addition the host must be able to find the correct PDP which should authenticate itself as must do the host as well. The solution must support the addition and deletion of hosts from the SD dynamically with no degradation of the functionality and performance. When a new node is connected to the SD network it should follow the required steps in order to be authenticated and configured following the appropriated SP. It will be a matter of the solution to assure that the hosts are following the received SP during the time they are connected to the SD network. 4.4.2 Authentication It is required that new hosts connected to the network demonstrate their identity for both receiving a useful SP and to communicate with other hosts within the same SD. This way, a host needs to authenticate itself first. After that, the host may or may not be authorized to have connectivity with other networks through a switch/router or to be able to communicate with other hosts. As a guideline, cryptographic certificates could be used for this purpose, in order to guarantee the identity of the sender of a message. As the identity will be used within the SD a SD-wide PKI could be used. 4.4.3 Policy Exchange Protocol The PXP is in charge of the distribution of the corresponding SP(s) to the PEAs. This protocol should assure the delivery and update of the SP even in the case of possible problems, like the chance of a PDP failure or some kind of unreachability, for example in case of network segmentation. Also either the PEA or the PDP could launch an event that results in a SP update or change. The PDP will update the SP in case of new security information is received for one or more of the used security mechanisms. The PEA could also inform the PDP of a new Security Status because of some change in the PEP configuration. Based in this new status the PDP could update the SP. Vives, et al. Expires January 12, 2006 [Page 17] Internet-Draft Distributed Security Framework July 2005 There could be some active mechanisms, like IDS, that could lead to some SP change. 4.4.4 Data Integrity and Authenticity There are several pieces of information that will be passed among entities within the security solution that would be a good target for an attack. This information should be protected both while stored in a host and while transmitted from one host to another. As a guideline, cryptographic certificates could be used for this purpose, in order to guarantee the integrity and origin of the information. As the identity will be used within the SD a SD-wide PKI could be used. 4.4.5 Moving between security domains As have been seen above a host, with its PEA, could move between different SD or between different scenarios, some of them with no security guarantees at all and no PDP available. If all network devices are globally reachable there will be no problem on reaching other hosts belonging to the same security solution cluster, including the PDP, which could be inside the corporate network. The solution must be able to manage this situation both being able to detect a network/SD change and responding in consequence, for example establishing a default SP in foreign networks (presumably a restrictive SP). 5. Other Issues Further elaboration is required (TBD) on: o Malicious users: We can't protect the network from malicious users that have physical access to network hosts in the protected network. The objective is to minimize the danger they can cause. o In the host-based security, the host that stores and distributes the security policies seems to be the best option to be the one that acts as IDS information collector. 6. Conclusions New technologies (IPv6, P2P, GRID, Mobile IP, etc.), behaviors (use of small devices like PDAs and moving to different networks) and Vives, et al. Expires January 12, 2006 [Page 18] Internet-Draft Distributed Security Framework July 2005 threats (Virus, spam, spyware, adware, etc.) require improving the security mechanisms actually being used. By one side the integration of different mechanisms and by other side the movement of the security policy enforcement point towards the hosts interfaces are recommended in order to improve the security of the hosts and in consequence of the network. Also a centralized control over the policy definition and enforcement is of importance in order to have a scalable solution. The network-based security model has problems addressing the new technologies and threats. The host-based model has been described as a reference for a possible solution. The latter model is presented as complementary to the former one. 7. Security Considerations This document is concerned entirely with security. 8. Acknowledgements The authors would like to acknowledge the inputs of Brian Carpenter, Satoshi Kondo, Shinsuke Suzuki, Peter Bieringer and the European Commission support in the co-funding of the Euro6IX project, where this work is being developed. 9. References 9.1 Normative References 9.2 Informative References [1] "IETF midcom WG", . [2] Bellovin, S., "Distributed Firewalls", November 1999, . [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [5] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [6] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, Vives, et al. Expires January 12, 2006 [Page 19] Internet-Draft Distributed Security Framework July 2005 November 1998. [7] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. Authors' Addresses 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 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 Pekka Savola CSC/FUNET Espoo Finland Email: psavola@funet.fi Vives, et al. Expires January 12, 2006 [Page 20] Internet-Draft Distributed Security Framework July 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. Vives, et al. Expires January 12, 2006 [Page 21]