INTERNET-DRAFT Fernando Cuervo Expires : January 2001 Abdallah Rayhan Nortel Networks July 2000 IPSEC Policy Architecture Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working docu- ments 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document proposes an architecture for IPSec policy. The proposed architecture follows the functional decomposition of the policy frame- work [1]. The architecture addresses the mechanisms to facilitate the dynamic exchange of policy between the various architectural components. The issues discussed here covers the mechanisms for establishing IPSec route across multiple policy gateways through policy negotiation. This draft shall serve as a guideline for further development of IPSec Pol- icy. 1 Introduction Cuervo, Rayhan [Page 1] Internet draft IPSEC Policy Architecture July 2000 This document describes an architecture for IPSec policy. The architec- ture uses the functional decomposition of the policy framework [1] and the framework presented in [8]. The architecture addresses the mecha- nisms that facilitate the exchange of policy between the various archi- tectural components. The concepts presented here may apply to a range of policy applications beyond IPSec. For example, media gateways, network access servers and SIP servers may be policy- enabled to provide addi- tional policy based services such as user access control, QoS, etc. Applications that have dynamic policy configuration requirements such as remote access [9] and mobile IP-hosts [10] would particularly benefit from the use of the proposed architecture. This draft provides the infrastructure needed to facilitate dynamic policy configuration in an extensible, scalable and secure manner. 1.1 Motivation IPSec security associations between two end points can be accomplished using IKE [4] and IPSec [3] . The policy that IKE establishes does not go beyond that particular association. In other words, it does not affect the policy capabilities of the Policy Enforcement Points (we call it a Policy Gateways from now on) which have to be enabled to allow IKE and IPSec flows to pass through. Additionally, for IKE/IPSec to enable policy based communication between endpoints to work properly, the endpoints need to be aware of each others identities. This raises scalability concerns for IKE/IPSec when mirror image policies have to be provisioned for all possible associations. Furthermore, the policy attributes of SPD/SADB are limited to IPSec selectors falling short of representing comprehensive and extensible policies for other policy applications that are complementary to IPSec. We will elaborate on types of policies supported by a policy gateway in Section 2.1. and their dynamic characteristics, especially for interdomain applications. Dynamic policy requires that a number of mechanisms be defined to install, signal, and modify the Policy in the policy gateway dynamically based on domain policies controlled by distributed policies servers. Remote access clients who access private networks from the public Inter- net are a prime target for dynamic policy services that are primarily supported by IPSec and additional corporate networking policies. Remote access clients have personalized policy requirements based on user pro- files and corporate access policies. The remote clients would need to go through at least one policy gateway on the private network side and an ISP gateway on the nternet side. If the client is located in a private network, he would have to traverse that site policy gateway. In either case, unless the access policy of the policy gateways in both ends of the flow is dynamically configurable in order for the user to have access to his home network resources and comply to the corporate access policies, it would be difficult to enforce a corporate policy in an efficient and scalable manner. The corporate policy refers to access Cuervo, Rayhan [Page 2] Internet draft IPSEC Policy Architecture July 2000 policy of the remote client and the corporate policy gateway. When the user traffic is tunneled to access home resources or access the Internet via the policy gateway, the corporate policy can be easily enforced. However, when the user is to access the Internet via the ISP gateway, the same corporate policy should be possible to implement on the user's machine. This can be accomplished by downloading the corporate policy into the user machine powering it as a policy gateway without the user intervention, on one hand. On the other hand, if there is a trust rela- tionship between the corporate policy gateway and the ISP policy gate- way, the user policy can be downloaded into the ISP gateway to achieve more restricted policy enforcement on the remote clients. Another inter- esting scenario occurs when the user access his home network from a dif- ferent private network. In this case, policies for the access device and the user are required. Such policies include but not limited to device and user authentication, address assignment in the home network, and tunneling policies on the home and foreign gateways. The latter is an interesting problem by itself. The user needs to access the home resources via the home gateway while the gateway needs to protect its resources from the public as well as from being over exposed to the for- eign gateway. At the same time the foreign gateway has policies of its own that it must enforce. Policies that are dynamically configurable and scalable need to be put in place to allow such applications to be imple- mented. An important issue in the above scenarios that needs to be addressed is the trust relationship between the foreign and the home gateways (realised at least in part by the existence of a security asso- ciation). Further details of such scenarios and requirements can be found at [9]. Installing policies is not a one-time process but requires frequent updates based on user access and profile. This mandates that what used to be static to be dynamic and interim in nature resulting in a complex process of policy provisioning. Interim policies which remote access clients need to gain access to a VPN may change frequently using for example user profiles and installed on a "need-to-access" basis. Auto- mated mechanisms play a crucial role here in discovering the gateways and negotiating policies. Applications that have 2 separate flows, one for signaling and another for media, are clear candidates for this type of policies. For example, a SIP gateway which initiates and terminates sessions need to traverse the policy gateway. The media streams, such RTP, need to traverse the gateway based on the success of the signaling session established by SIP [15]. The complexity arises here from the fact that the policies for the media streams are dynamic and their parameters are controlled by a for- eign protocol to the gateway. Therefore, a flexible and secure mechanism must be deployed to allow such SIP gateways to communicate with the pol- icy gateway through a policy server and install policies for the various media streams necessary to complete the SIP sessions. Such a mechanism Cuervo, Rayhan [Page 3] Internet draft IPSEC Policy Architecture July 2000 is possible with the proposed architecture. Mobile hosts operating in cellular IP networks are another application that can take advantage of this architecture [10]. A mobile host would have access to the Internet through a cellular IP gateway via cellular IP nodes. Since the mobile host is in a foreign home, the cellular IP gateway would have to import the proper policy for the user from the home gateway where the user belongs. Mobile tunneling may be uni- direc- tional [12] as opposed to the remote access example mentioned in the previous paragraph. In this case, the cellular IP gateway needs to learn the policy the host needs to comply to in order to protect the cellular IP network wireless resources as well as enforcing the corporate poli- cies at the traffic source. A similar interesting scenario occurs when the mobile host moves from one cellular IP network into another result- ing in cellular IP gateway hand over. The policy which was learned and applied by the first gateway to the mobile host should be transferable to the new one without causing disrupt in service. Further details about Mobile IP and Cellular IP can be found at [10,12]. A major requirement in writing policies is to learn the entities involved. This knowledge can be obtained by examining ICMP error mes- sages. It is a common practice to filter ICMP error messages by fire- walls to protect the network resources against possible attacks. How- ever, dynamic policy would not be possible without learning the two end entities engaged in implementing the security policy. Hence, a discovery protocol is needed to address this problem properly and be part of the IPSec policy architecture. 1.2 Terminology This section describes the terminology used in this draft. The terms described here builds upon the concepts found in [1], however we will redefine some of the terms to suite the purpose of this draft. The reader is encouraged to familiarize him self with the terms and concepts presented in [1,2]. Policy Repository (PR): is used for storage and retrieval of persistent policy rules. Policy Server (PS): is a network device responsible for acquiring policy from a repository or other PSs and deploying it into policy gateways. It handles policy caching which refers to instantiated policy rules based on traffic conditions or downloaded policies from the repository. PS is referred to as policy consumer in [1]. It acts as a policy decision point as well. Policy gateway (PG): is a network device that has a security requirement and implements a security policy, e.g., IPSec Policy and requires Cuervo, Rayhan [Page 4] Internet draft IPSEC Policy Architecture July 2000 establishing secure communication between two peers. PG can be anything from a router, firewall, or gateway to an end-host device. PG is referred to as a policy target in [1]. Security Domain (SD): is a set of communication entities and resources that share a common security policy enforced by one or more policy gate- ways. SD draws a boundary of security between the secure and insecure Internet. SD can share its policy with another SD through one common policy domain. The security domain refers to node-base model in [4]. Policy Domain (PD): is a set of security domains that share a common policy. If PD contains one SD, then PD and SD refer to the same domain. The policy domain refers to domain-based model in [4] and administrative domain in [1]. 1.3 Requirement Terminology The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [11]. 2 Security Policy Architecture 2.1 Types of Policies Policies can be classified based on their representation into high level policies and low level policies. The high level policies can be applica- tion-based, user-based, domain-based or a combination of those. Such policies define a set of enforceable actions when certain conditions are met. The are represented by high level description language or a GUI and are implementation and device independent. Conditions can be what appli- cations users are allowed to run, time of day, policies enforced on inter-domain applications such as URL filtering, content inspection, etc. Low level policies are device dependent and represent the actual behavior for certain conditions, for example, filter packets based on destination address and port, source address and port, protocol, QoS or IPSec parameters. Such policies are based on inspecting the packet header and their representation and capabilities are device dependent. Automated mechanisms are needed to map the high level policies into low level policies and creating mirror images across domains. Also, policies can be classified according to the policies they enforce into access policies and domain policies. Access policies refer to what users are allowed to run, when and where. It defines the conditions and actions to grant access to resources. The domain policies refer to con- ditions and actions associated with traversing different domains or inter-domain policies. Cuervo, Rayhan [Page 5] Internet draft IPSEC Policy Architecture July 2000 2.1.1 Requirements of Policy Representation Policy needs to be defined in a concise non-ambiguous notation capable of specifying security requirements for network services. This notation shall provide the mechanisms needed to interpret the policies by the policy gateways. The following list addresses the issues and requirements that should to be taken into account when a security policy language is designed. This list is not comprehensive, but it does cover a number of important issues and considerations. -Policy is to be represented in an independent language capable of cap- turing the requirements stated below. -The language should be flexible and support standard policies and extensible to support experimental and proprietary extensions. -The language should be capable of expressing and facilitate interoperability of IPSec/IKE based policies. -The lan- guage must have mechanisms to support authentication, authorization and integrity to publish and configure policy rules. -It should be extensi- ble to express stateless and stateful filtering covering L2-L7. -The language must support authorization and obligation policies. The autho- rization policies would define who can change the policies while the obligation policies would define what the policy is about. There must be forms for binding the two. -Policies must be defined as conditional constructs in order to express well defined conditions and actions to be enforced when conditions are satisfied. The order of conditional clauses is important and should depend on the local state of the instantiated rules. -A set of policy rules is scoped per security domain. If con- flicts arise due to intersection of domains or conflicts arising with existing ones, well-defined mechanisms should be applied to address and resolve such problems properly. -It should support binding security and policy domains. -It should be scalable and flexible to support dis- tributed decision and enforcement architecture. -The rules used to rep- resent policy must support prioritization and coupling of conditions and actions. -The actions' representation must support filtering actions in addition to mechanisms to more sophisticated interfaces, e.g., forward to designated device, perform content inspection, URL filtering, audit- ing, logging. -Actions should be predefined and could be as simple as filtering or as complex as content inspection which can have polices and actions of their own. 2.2 Architecture The functional decomposition of the security policy architecture Cuervo, Rayhan [Page 6] Internet draft IPSEC Policy Architecture July 2000 consists of three main components, namely, policy repository, policy server and policy gateway. The repository holds the information the server requires to make decisions on policy associations across one or more policy domains. The server can make decisions based on dynamic information provided by the gateway. The gateway enforces the decisions made by the server. In addition to that, it requests dynamic policy from the server based on collected data through the process of discovery and negotiation with other gateways. The information exchanged is captured in the form of a policy language [3]. The repository stores the security policy and responsible for, at least an initial level of policy integrity verification. Policy verification is a two-fold operation. First, new or updated policy must not be in conflict with existing ones when stored. The other type of verification is when the policy server establishes a dynamic policy based on policy negotiation between policy gateways. The latter is needed to ensure that no conflicts arise due to interim or permanent policies. When conflicts arise at either case, resolution mechanisms are utilized to achieve a secure implementable policy. More information of such mechanisms can be found at [5,6,7]. +------+ +------+ / Policy \ / Policy \ /Repository\ /Repository\ +------------+ +------------+ ^ ^ | LDAP LDAP | | | v v +--------+ +--------+ | Policy | GP-DNP | Policy | | Server | <---------------> | Server | +--------+ +--------+ ^ ^ | COPS-PR COPS-PR | | | v v +------+ +---------+ +---------+ +------+ |host A|<--->| Policy | | Policy |<--->|host A| +------+ | Gateway | | Gateway | +------+ +---------+ +---------+ The policy server acts as a policy consumer in the model described in [1]. It performs policy decision as well. It distributes policy to the various policy gateways subscribed to its policy domain. Its responsi- bility includes policy caching and verification. When the policy gateway requests a policy not found in the policy server, the policy server retrieves it from the repository if it is available. Otherwise, access Cuervo, Rayhan [Page 7] Internet draft IPSEC Policy Architecture July 2000 is either denied or the policy gateway goes into policy discovery and negotiation process. Policy is cached if it is temporary resulting from the discovery and negotiation process or retrieved from the repository and has not expired yet. The policy server must support three inter- faces, such as an LDAP interface to the repository, COPS-PR [14] to the policy gateway and a third interface to other policy servers. We will refer to the third interface as Gateway Policy-Discovery and Negotiation Protocol (GP-DNP). We will discuss this interface next. GP-DNP is a policy signaling protocol across policy domains. It operates in two signaling modes; direct-domain signaling and broker- domain sig- naling. In the direct mode, the policy server negotiates its policy directly with the policy server of other domains. In the broker mode, the policy server negotiates its policy with the next policy server which in turns negotiates the policy with the next policy server in the path to the destination. In the latter mode, there is a trust relation- ship between policy server across the domains. We will address this issue shortly. For example, assume that a host in Domain-A needs to communicate with a host in Domain-C and PS-A does not have policy for end-to-end flow between the local host and remote host. In the broker mode, PS-A runs GP-DNP with PS-B-1 to establish a common policy between the two domains. Then the policy server in Domain-B distributes the negotiated policy to all gateways protecting the domain using COPS-PR. Next, Domain-B would run GP-DNP to establish a common policy between PS-B-2 and PS-C which is common to PS-A and PS-B-1. The end result is that Domain-A and Domain-C are able to communicate through Domain-B since there is a common policy across the multiple domains. In the direct mode, Domain-A negotiates a policy with Domain-B. Now that Domain-A is allowed to use Domain-B as a hop domain, it negotiates another set of policies with Domain-C. In this scenario, Domain-B does not intervene in the common policy between Domain-A and Domain-C and unable to enforce the Domain-A-Domain-C policy. In the broker mode, Domain-B has a say in the negotiated policy and able to enforce it. In the direct mode, the Domain-A-Domain-B policy is different than Domain- A-Domain-C since the earlier serves a different purpose than the latter. Also, since Domain-B is a hop domain, its policies which PS-A negotiated should by bi-directional to allow Domain-C traffic to pass through. +-----------+ +-----------+ +-----------+ | Domain | 1) GP-DNP | Domain | 2) GP-DNP | Domain | | +-----+ +-----+ +-----+ +-----+ | Cuervo, Rayhan [Page 8] Internet draft IPSEC Policy Architecture July 2000 | |PS-A | <---> |PS-B1| |PS-B2| <---> |PS-C | | | +-----+ +-----+ +-----+ +-----+ | | A | | B | | C | +-----------+ +-----------+ +-----------+ Broker-Domain signaling mode 2) GP-DNP <-----------------------------> +-----------+ +-----------+ +-----------+ | Domain | 1) GP-DNP | Domain | | Domain | | +-----+ +-----+ +-----+ +-----+ | | |PS-A | <---> |PS-B1| |PS-B2| <---> |PS-C | | | +-----+ +-----+ +-----+ +-----+ | | A | | B | | C | +-----------+ +-----------+ +-----------+ Direct-Domain signaling mode In either mode of signaling, the policy gateway can act as a proxy to the policy server if the server does not wish to reveal its identity or if the identity of the peer server is unknown prior to signaling. In this case, the identity used in the proxy is of the gateway rather than the server. We will refer to the first case as proxy-messaging and the latter as direct-messaging. 2.3 Requirements of GP-DNP Policy servers communicate and exchange information using GP-DNP. In order for servers to engage in policy negotiation, either the identity of the peer server needs to be known in the case of the direct- messag- ing or the identity of the peer gateway which implements the mirror image policy in the case of proxy-messaging. Direct-Messaging: In this mode of operation, we assume that the servers are aware of each other identities. The policy server initiates GP-DNP based on an event triggered internally or through a policy request message from the policy gateway through COPS-PR. The request that the gateway makes includes the conditions needed to resolve any policy conflicts that may arise if nec- essary. The policy server issues proposal through GP-DNP to the peer policy server. The peer server either accepts or rejects the proposal based on policy control and resource availability. When the peer server receives the proposal, it passes it to the gateway which to implement Cuervo, Rayhan [Page 9] Internet draft IPSEC Policy Architecture July 2000 the policy after examining the policy itself. If the gateway accepts the policy then the peer server issues a proposal accept message to the server which initiated the request and in its turn passes an install message through COPS-PR to the gateway which implements the policy. If the peer gateway rejects the proposal then negotiation terminates between the two domains. 2) Propose Policy +--------+ ----------------> +--------+ | Policy | | Policy | | Server | 5) Accept Policy | Server | +--------+ <---------------- +--------+ | ^ 3) Install Policy | ^ | | | | 6)Install Policy | | 1) Request Policy | | 4) Accept Policy v | v | +---------+ +---------+ | Policy | | Policy | | Gateway | | Gateway | +---------+ +---------+ Domain A Domain B In order to ensure authenticity and protection of GP-DNP, IKE/IPSEC should be deployed between the peer servers. The policy servers may dis- tribute the negotiated policies to all gateways of concern using COPS-PR to ensure implementing a domain wide policy. Proxy-Messaging: In this mode of operation, the policy gateway runs GP-DNP in the proxy mode for the policy server. In this case, the identities of the policy server or the peer policy gateway are not known prior to negotiation. Three major functions need to take place in this mode. First, the peer gateways must learn each other identifies. This is accomplished by issu- ing a discovery request message through GP-DNP. The receiver gateway captures the discovery message and learns the identity of the initiator. When the receiver gateway issues a response, the initiator will get to learn the identity of the peer gateway with which negotiation is taking place. To ensure authenticity and protection of further communication, a security association tunnel is established through IKE/IPSEC. Once that takes place, the two gateways can negotiate the policy to be installed at each end of the tunnel. The policy servers other than running in the proxy mode through policy gateways, negotiation process takes place as in the direct-messaging case discussed earlier. Cuervo, Rayhan [Page 10] Internet draft IPSEC Policy Architecture July 2000 +--------+ +--------+ | Policy | GP-DNP | Policy | | Server | <-.-.-.-.-.-.-.-> | Server | +--------+ +--------+ ^ ^ 3.A)approve | 3.B) approve | negotiated | negotiated | policy | policy | v v +---------+ 1) Discovery Probe +---------+ | | <----------------> | | | Policy | 2) IKE | Policy | | Gateway | <----------------> | Gateway | | | 3) Negotiate | | +---------+ <----------------> +---------+ Domain A Domain B When end-to-end policy is achieved, distribution takes place using COPS- PR to all gateways of concern according to network design. During nego- tiation, the policy servers resolve the differences in their policy requirements. The policy requirements could be symmetric or asymmetric. The negotiated policies can apply to one host in the policy domain, the whole domain or to all domains the server has access to. Also, the nego- tiated policies can be permanent or temporary based on time or traffic volume. 2.4 Requirements of COPR-PR The policy server, in addition to being the decision point for the pol- icy gateway, performs a number of functions in pushing and distributing policies into the gateways as well as adding and removing the gateway from its policy domain. In this section, we will address the design requirements that the COPS-PR must consider. It should be used by the policy gateways to register themselves with their designated servers. Following registration, the policy server downloads the policies it has for the security domain that the gateway keeps. If a gateway uploads a policy obtained through manual provision- ing, it must be accepted by the server before putting it in action. A gateway can go out of service and in this case, the default policy becomes deny all unless another gateway is taking over. The protocol should allow for policy server hand over in case the server is going out of service. When a policy is downloaded it is cached at the gateway with an expiry-stamp. The stamp can be time, volume or permanent. When the policy server accepts a policy uploaded by the gateway, it could dis- tribute it to other gateways to globalize the policy using this protocol Cuervo, Rayhan [Page 11] Internet draft IPSEC Policy Architecture July 2000 if applicable. Also, the protocol should allow the policy server to com- mission the policy gateway out of service if a need rises. IKE/IPSEC should be used to ensure protection of communication between servers and gateways. Cuervo, Rayhan [Page 12] Internet draft IPSEC Policy Architecture July 2000 4 References: [1] M Stevens, H. Mahon, J Strassner, G. Waters, A. Westeriner, "Policy Framework", Internet Draft, work in progress. [2] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", RFC2401, November 1998. [3] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC2409 November 1998. [4] M. Condell, C. Lynn, J. Zao, "Security Policy Specification Language", Internet Draft, work in progress. [5] J. Zao, "Semantic Model for IPSec Policy Interaction", Internet Draft, work in progress. [6] M. Blaze, J. Ioannidis, A. Keromytis, "Compliance Checking and IPSec Policy Management", Internet Draft, work in progress. [7] M. Blaze, J. Feigenbaum, J. Ioannidis, A. Keromytis, "The KeyNote Trust-Management System Version 2", RFC2704, September 1999. [8] R. Yavatkar and D. Pendarakis, R. Guerin "A Framework for Policy- based Admission Control", RFC2753, January 2000. [9] S. Kelly, S. Ramamoorthi "Requirements for IPSec Remote Access Scenarios", Internet Draft, work in progress. [10] A. Campbell, J. Gomez, C-Y. Wan, Z. Turanyi, A. Valko, "Cellular IP", Internet Draft, work in progress. [11] S. Bradner, "Key Words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997. [12] C. Perkins, "IP Mobility Support for Ipv4, revised", Internet Draft, work in progress. [13] B. Patel, B. Aboba, W. Dixon, S. Booth, "Securing L2TP using IPSec", Internet Draft, work in progress. [14] F. Reichmeyer, S. Herzog, K. Chan, D. Durham, R. Yavatkar, S. Gai, K. McCloghrie, A. Smith, "COPS Usage for Policy Provisioning," Internet Draft, work in progress. Cuervo, Rayhan [Page 13] Internet draft IPSEC Policy Architecture July 2000 Author's Addresses Fernando Cuervo Nortel Networks P.O. Box 3511 Stn C Ottawa, ON, Canada K1Y 4H7 Phone: (613) 763-4628 EMail: cuervo@nortelnetworks.com Abdallah Rayhan Nortel Networks P.O. Box 3511 Stn C Ottawa, ON, Canada K1Y 4H7 Phone: (613) 763-9611 EMail: arayhan@nortelnetworks.com Cuervo, Rayhan [Page 14]