[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   Distribution of this memo is unlimited.


   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]

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]

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]

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

   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]

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

   * 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

   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]

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]

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 to
    pass out proto 50 from to
    pass in on enc0 from to

   (The first two rules allow all ESP traffic between the firewall of
   the satellite site ( and the firewall of the main site
   (  The third rule allows traffic between subnets in
   the remote and the local sites provided it has been protected by

Blaze, et al.                Internet Draft                      [Page 7]

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:

               RAS_ADMIN_Key_A = "rsa-base64:MDgCMQDMiEBn89VCSR3ajxr0bNRC\
    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 == "";

   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:

            RAS_ADMIN_KEY_A = "rsa-base64:MDgCMQDMiEBn89VCSR3ajxr0bNRC\
            JIK = "x509-base64:MIICGDCCAYGgAwIBAgIBADANBgkqhkiG9w0BAQQ\
    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\

Blaze, et al.                Internet Draft                      [Page 8]

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

   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]

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

   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]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/