Network Working Group Matt Blaze Internet Draft John Ioannidis Expires in sixth months AT&T Labs -- Research Angelos D. Keromytis University of Pennsylvania March 2000 Compliance Checking and IPSEC Policy Management Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Please direct comments to one of the authors (for the authors contact information, see the end of this document), and/or to the trustmgt@east.isi.edu mailing list. 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 draft documents are 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. Distribution of this memo is unlimited. Abstract This draft describes an architecture for security policy management for IPSEC based on the principle of ``compliance checking.'' We describe a two-level policy hierarchy, in which security association policy is managed by a highly flexible policy language, which in turn provides input to packet policies that are managed by a fast packet filtering language. We provide a sample SA policy language, based on KeyNote, and describe interoperability issues for this architecture. 1. Introduction One of the most important advantages of network-layer security, and Blaze, et al. Internet Draft [Page 1] ^L Compliance Checking and IPSEC Policy Management March 2000 IPSEC [RFC-2401] in particular, is the remarkable range of applications for which it can be used. IPSEC offers a remarkable flexibility not possible at higher- or lower- layer abstractions: security can be configured end-to-end (protecting traffic between two hosts), route-to-route (protecting traffic passing over a particular set of links), edge-to-edge (protecting traffic as it passes between ``trusted'' networks via an ``untrusted'' one, subsuming many of the current functions performed by network firewalls), or in any other configuration in which network nodes can be identified as appropriate security endpoints. For all this flexibility, IPSEC does not itself address the problem of controlling what kinds of traffic are allowed in to or out of a host running the protocol. By itself, the IPSEC protocol can protect packets from external tampering and eavesdropping, but does nothing to enforce a policy as to which hosts are authorized for particular kinds of sessions or to exchange particular kinds of traffic. In many configurations, especially when network-layer security is used to build firewalls and virtual private networks, such polices can be quite complex. There is no standard interface or protocol for controlling IPSEC tunnel creation, and most IPSEC platforms provide only rudimentary, packet-filter- and ACL-based policy mechanisms. Let us examine the security policy decisions an IPSEC processor must make. (When we discuss ``policy'' in this paper, we refer specifically to the network-layer security policies that govern the flow of traffic among networks, hosts, and applications). Observe that policy must be enforced whenever packets arrive at or are about to leave a network security endpoint (which could be an end host, a gateway, a router, or a firewall). The first policy-related problem that IPSEC must manage is key agreement. IPSEC key agreement is straightforward in the simplest case. Two hosts can use any key-agreement protocol to negotiate keys with one another; the result is used as key material for the encapsulating and decapsulating packet transforms. IKE [RFC-2409] provides standard key agreement protocol for IPSEC. However, a key agreement protocol does not itself suffice as a mechanism for controlling IPSEC policy. 2. IPSEC Policy Controls 2.1 Packet-Level Policy Controls Let us examine the policy decisions that a host must make when processing IPSEC traffic. On input: Blaze, et al. Internet Draft [Page 2] ^L Compliance Checking and IPSEC Policy Management March 2000 * If the packet is not IPSEC protected, should it be accepted? This is essentially the ``traditional'' packet filtering problem, as performed, e.g., by network firewalls. * If the packet was encapsulated under IPSEC: - Is there correct key material (obtained by dereferencing the Security Association (SA)) required to decapsulate it? - Should the resulting packet (after decapsulation) be accepted? A second stage of packet filtering occurs at this point. Notice that a packet may be successfully decapsulated and still not be accepted (e.g., a decapsulated packet might contain an unexpected network source IP address). Output processing is analogous: * Is there an SA that should be applied to this packet? If there are several applicable SAs, which one should be selected? * If there is no SA available, how should the packet be handled? - Should it be forwarded (unencrypted) to some network interface? - Should it be dropped? - Should it be queued? - Should it trigger some automated key management mechanism? Observe that because these questions are asked on a packet-by-packet basis, any packet-based policy filtering must be performed, and any related security transforms applied, quickly enough to keep up with network data rates. This implies that in all but the slowest network environments there is insufficient time to process elaborate security languages, perform public key operations, consult large tables, or resolve rule conflicts in any sophisticated manner. IPSEC implementations (and most other network-layer entities that enforce security policy, such as firewalls), therefore, must employ very simple, filter-based languages for configuring their packet-handling policies. In general, these languages specify ``routing'' rules for handling packets that match bit patterns in packet headers, based on such parameters as incoming and outgoing addresses and ports, services, packet options, etc. The opportunity for IPSEC policy control is not limited only to what can be expressed as packet filters, however. A great deal of flexibility is available in the control of when security associations are created and what packet filters are associated with them. 2.2 SA Policy Controls Blaze, et al. Internet Draft [Page 3] ^L Compliance Checking and IPSEC Policy Management March 2000 Fortunately, the problem of policy management for security associations can be distinguished in several important ways from the problem of filtering individual packets. In particular: * SAs tend to be rather long-lived; there is ``locality of reference'' insofar as hosts that have exchanged one packet are very likely to also exchange others in the near future. * It is usually acceptable for policy controls on SA creation to require substantially more resources than can be expended on processing every packet (e.g., public key operations, multiple packet exchanges, policy evaluation, etc.). * The ``output'' of negotiating an SA between two hosts can provide (among other things) parameters for lower-level packet policy (filtering) operations. A ``compliance checking'' interface that tests whether a proposed filter conforms to security policy provides exactly the abstraction required here. 3. A Compliance Checking Architecture for IPSEC Policy The notion of ``compliance checking'' was introduced with the PolicyMaker [BFL96,BFS98] trust management system. A trust-management system provides a standard interface that tests whether potentially dangerous actions comply with local security policies. More formally, a trust management system consists of: * A method for describing ``actions,'' which are operations with security consequences that are to be controlled by the system. * A mechanism for identifying ``principals,'' which are entities that can be authorized to perform actions. * A language for specifying application ``policies,'' which govern the actions that principals are authorized to perform. * A language for specifying ``credentials,'' which allow principals to delegate authorization to other principals * A ``compliance checker,'' which provides a service for determining whether actions requested by principals should be allowed, given a policy and a set of credentials. The problem of controlling IPSEC SAs is easy to formulate as a trust-management problem: The SA creation process (usually a daemon running IKE) needs to check for compliance whenever an SA is to be Blaze, et al. Internet Draft [Page 4] ^L Compliance Checking and IPSEC Policy Management March 2000 created. Here, the ``actions'' represent the packet filtering rules required to allow two hosts to conform to one another's higher-level policies. This leads naturally to a simple framework for trust management for IPSEC: * Hosts have two compliance-checking engines: the first is a Packet Policy Engine (a fast packet filter, required by the IPSEC architecture), while the second is an SA Policy Engine (a more sophisticated language for testing filters proposed at SA-creation time). * Each host has its own policy governing SA creation. This policy describes the classes of packets and under what circumstances the host will initiate SA creation with other hosts, and also what types of SAs it is willing to allow other hosts to establish. * When two hosts discover that they require an SA, they each propose to one another the ``least powerful'' packet-filtering rules that would enable them to accomplish their communication objective. Each host sends proposed packet filter rules, along with credentials (certificates) that support the proposal. The trust structure of these credentials is entirely implementation dependent, and might include the arbitrary web-of-trust, globally trusted third-parties, or anything in between. * At SA creation time each host queries its SA Policy Engine to determine whether the filters and SAs proposed by the other host comply with local policy and, if they do, creates an SA containing the specified filters. Other SA properties can also be subject to the control of the SA Policy Engine. For example, an SA policy might specify acceptable cryptographic algorithms and key sizes, the lifetime of the SA, logging and accounting requirements, etc. Thus we divide the problem of policy management into two natural components: packet filtering, based on simple rules applied to every packet, and more sophisticated trust management, based on negotiating and deciding which such rules are trustworthy enough to install. This distinction makes it possible to perform the per-packet policy operations at high data rates while effectively establishing more sophisticated policy controls over the overall traffic passing through a secure endpoint. If a credential management system is integrated with the SA Policy Engine, this provides a natural way to control security policy for a large network, especially when used to implement automated policy distribution mechanisms. Blaze, et al. Internet Draft [Page 5] ^L Compliance Checking and IPSEC Policy Management March 2000 3.1 Negotiation and Credentials. In the framework given above, when two hosts want to establish an SA, they must negotiate with the SA Policy Engine to establish an appropriate packet filter for the Packet Policy Engine. Typically, from a protocol point of view, one host will initiate a request to another, in a ``client-server'' relationship. As part of that request, the client host will typically have to present some kind of credentials to the server host to support the request, in accordance with the server's SA Policy as enforce by its SA Policy Engine. One of the advantages of using a trust management language for SA policy is the flexible nature of policies and credentials. In particular, trust management languages allow very simple policies that defer authority to the signing key of a third party (say, a network administrator). The details of the actual policy would be embedded in the credentials signed by that administrator. Part of the SA negotiation protocols should include the exchange of credentials. IKE, for example, provides limited support for transferring X.509 certificates. The same functionality may be used to transfer trust-management credentials. A more general policy negotiation protocol should allow for the transfer of arbitrary kinds of credentials as part of the SA creation process. 4. Example System In this section, we describe a sample IPSEC policy architecture that uses the KeyNote Trust Management system [BIK99] for the SA Policy Engine and and IPF-based packet filters for the Packet Policy Engine. KeyNote is a simple and flexible trust-management system designed to work well for a variety of large- and small-scale Internet-based applications. KeyNote application policies and credentials are written in the same language. The basic unit of KeyNote programming is the assertion. Assertions contain programmable predicates that operate on the requested attribute set and describe to limit the actions that principals are allowed to perform. KeyNote assertions are essentially small, highly-structured programs. Authority can be delegated to others; a digitally signed assertion can be sent over an untrusted network and serve the same role as traditional certificates. When a ``dangerous'' action is requested of a KeyNote-based application, the application submits a description of the action along with a copy of its local security policy to the KeyNote interpreter. Applications describe actions to KeyNote with a set Blaze, et al. Internet Draft [Page 6] ^L Compliance Checking and IPSEC Policy Management March 2000 of attribute/value pairs (called an ``action attribute set'' in KeyNote jargon) that describe the context and consequences of security-critical operations. KeyNote then ``approves'' or ``rejects'' the action according to the rules given in the application's local policy. The problem of controlling IPSEC SAs is easy to formulate as a KeyNote compliance checking problem: The SA creation process (usually a daemon running IKE) needs to check for compliance whenever an SA is to be created. Here, the KeyNote ``actions'' represent the packet filtering rules required to allow two hosts to conform to one another's higher-level policies. For details on the KeyNote language, see RFC-2704. We have implemented a version of this architecture, based on KeyNote and a Unix implementation of IPSEC. It is distributed with OpenBSD version 2.6. 4.1 Example KeyNote Policies This section provides some examples of KeyNote-based policies, and is intended only to illustrate the flexibility of this approach. 4.1.1 Multi-site VPN In this example, several satellite sites are to be connected over encrypted tunnels to a main site. Each satellite has a public signature key. The following KeyNote policy is present on the firewall of the main site, for each satellite. Authorizer: "POLICY" Licensees: [public key of the satellite node] Conditions: app_domain == "IPsec_policy" && doi == "ipsec" && pfs == "yes" && esp_present == "yes" && esp_enc_alg != "null"; Each satellite edge router initiates a request to the main site's firewall that requests a set of filter rules to be installed for it, e.g.: pass in proto 50 from 198.1.4.1 to 135.207.1.1 pass out proto 50 from 135.207.1.1 to 198.1.4.1 pass in on enc0 from 198.1.4.0/24 to 135.207.0.0/19 (The first two rules allow all ESP traffic between the firewall of the satellite site (198.1.4.1) and the firewall of the main site (135.207.1.1). The third rule allows traffic between subnets in the remote and the local sites provided it has been protected by IPSEC.) Blaze, et al. Internet Draft [Page 7] ^L Compliance Checking and IPSEC Policy Management March 2000 4.1.2 Remote Access Authority to allow remote access through the site firewall is controlled by several security officers, each one of whom is identified by a public key. A policy entry such as the following exists for each individual security officer, and is stored in the firewall's configuration file: Local-Constants: RAS_ADMIN_Key_A = "rsa-base64:MDgCMQDMiEBn89VCSR3ajxr0bNRC\ Audlz5724fUaW0uyi4r1oSq8PaSC2v9QGS+phGEahJ8CAwEAAQ==" Authorizer: "POLICY" Licensees: RAS_ADMIN_Key Conditions: app_domain == "IPsec policy" && doi == "ipsec" && pfs == "yes" && ah_present == "no" && esp_present == "yes" && esp_enc_alg == "3des" && esp_auth_alg == "hmac-sha" && esp_encapsulation == "tunnel" && remote_ike_address == "135.207.001.010"; Each portable machine that is to be allowed in must hold a credential signed by a security administrator, which also limits what the user can do to reading and sending e-mail for weak encryption, and everything for strong encryption: Local-Constants: RAS_ADMIN_KEY_A = "rsa-base64:MDgCMQDMiEBn89VCSR3ajxr0bNRC\ Audlz5724fUaW0uyi4r1oSq8PaSC2v9QGS+phGEahJ8CAwEAAQ==" JIK = "x509-base64:MIICGDCCAYGgAwIBAgIBADANBgkqhkiG9w0BAQQ\ FADBSMQswCQYDVQQGEwJHQjEOMAwGA1UEChMFQmVuQ28xETAPBg\ NVBAMTCEJlbkNvIENBMSAwHgYJKoZIhvcNAQkBFhFiZW5AYWxnc\ m91cC5jby51azAeFw05OTEwMTEyMzA2MjJaFw05OTExMTAyMzA2\ MjJaMFIxCzAJBgNVBAYTAkdCMQ4wDAYDVQQKEwVCZW5DbzERMA8\ GA1UEAxMIQmVuQ28gQ0ExIDAeBgkqhkiG9w0BCQEWEWJlbkBhbG\ dyb3VwLmNvLnVrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg\ QDaCs+JAB6YRKAVkoi1NkOpE1V3syApjBj0Ahjq5HqYAACo1JhM\ +QsPwuSWCNhBT51HX6G6UzfY3mOUz/vou6MJ/wor8EdeTX4nucx\ NSz/r6XI262aXezAp+GdBviuJZx3Q67ON/IWYrB4QtvihI4bMn5\ E55nF6TKtUMJTdATvs/wIDAQABMA0GCSqGSIb3DQEBBAUAA4GBA\ MaQOSkaiR8id0h6Zo0VSB4HpBnjpWqz1jNG8N4RPN0W8muRA2b9\ 85GNP1bkC3fK1ZPpFTB0A76lLn11CfhAf/gV1iz3ELlUHo5J8nx\ Pu6XfsGJm3HsXJOuvOog8Aean4ODo4KInuAsnbLzpGl0d+Jqa5u\ TZUxsyg4QOBwYEU92H" Conditions: app_domain == "IPsec policy" && doi == "ipsec" && pfs == "yes" && esp_present == "yes" && ah_present == "no" && ( ( esp_enc_alg == "des" && esp_auth_alg == "hmac-md5" && remote_filter_proto == "tcp" && local_filter_proto == "tcp" && ( remote_filter_port == "25" || remote_filter_port == "110" ) ) || ( esp_enc_alg == "3des" && esp_aut_alg == "hmac-sha" ) ) ; Signature: "sig-rsa-sha1-base64:KhKUeJ6m1zF7kehwHb7W0xAQ8EkPNKbUqNhf/i+f\ ymBqjbzMy13OmH1itijbFLQJ" Blaze, et al. Internet Draft [Page 8] ^L Compliance Checking and IPSEC Policy Management March 2000 5. Interoperability Issues Surprisingly little ``standardization'' is required to make a compliance-checking architecture work for IPSEC. No change is required in the fundamental IPSEC protocols, and the basic key agreement protocols also do not require substantial modification. In fact, it is probably best to add a simple ``policy negotiation'' protocol to the IPSEC suite, for transferring various kinds of credentials. For two hosts to successfully establish IPSEC SAs under this framework, they need to share only the ability to translate and manage the SA and Packet Policy Engine credentials presented by and required by one another. It is even possible to derive simple SA policies from X.509 credentials. Things are simplified considerably if the two hosts share a common language for their SA and Packet Policy engines, however. Here, the two hosts can simply present their SA credentials and Packet filters directly to one another, without translation. 6. Acknowledgements This architecture was originally presented in [BIK99]. This work was sponsored by the DARPA Information Assurance & Survivability program, under BAA 98-34. 7. References [BFL96] Blaze, M., Feigenbaum, J. and J. Lacy, "Decentralized Trust Management", Proceedings of the 17th IEEE Symp. on Security and Privacy. pp 164-173. IEEE Computer Society, 1996. Available at [BFS98] Blaze, M., Feigenbaum, J. and M. Strauss, "Compliance-Checking in the PolicyMaker Trust-Management System", Proc. 2nd Financial Crypto Conference. Anguilla 1998. LNCS #1465, pp 251-265, Springer-Verlag, 1998. Available at [BIK99] Blaze, M., Ioannidis, J. and A. Keromytis, "Trust Management and Network Layer Security Protocols", Proceedings of the 1999 Security Protocols International Workshop, April 1999. [RFC-2401] Kent, S., Atkinson, R., "Security Architecture for the Internet protocol", RFC-2401, November 1998 Blaze, et al. Internet Draft [Page 9] ^L Compliance Checking and IPSEC Policy Management March 2000 [RFC-2409] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC-2409, November 1998 [RFC-2704] Blaze, M., Feigenbaum, J., Ioannidis, J. and A. Keromytis, "The KeyNote Trust-Management System Version 2", RFC 2704, September 1999. 8. Authors' Addresses Comments about this document should be discussed on the IPSP mailing list at ipsec-policy@vpnc.org Questions about this document can also be directed to the authors at: Matt Blaze AT&T Labs - Research 180 Park Avenue Florham Park, New Jersey 07932-0971 EMail: mab@research.att.com John Ioannidis AT&T Labs - Research 180 Park Avenue Florham Park, New Jersey 07932-0971 EMail: ji@research.att.com Angelos D. Keromytis Distributed Systems Lab CIS Department, University of Pennsylvania 200 S. 33rd Street Philadelphia, Pennsylvania 19104-6389 EMail: angelos@cis.upenn.edu Blaze, et al. Internet Draft [Page 10]