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
<draft-blaze-ipsp-trustmgt-00.txt>
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
<ftp://ftp.research.att.com/dist/mab/policymaker.ps>
[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
<ftp://ftp.research.att.com/dist/mab/pmcomply.ps>
[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]