Security Policy

  When discussing security policy, it is often useful to define the term in the appropriate context. For our purposes, security policy in the network layer is the information needed to decide whether a packet should be accepted/forwarded or dropped. Further restricting the definition in the IPsec context, security policy dictates what classes of packets are acceptable over a specific SA. This is all the more important for IPsec, since the encapsulation mechanism used literally allows establishment of arbitrary virtual topologies over the network fabric.

Since there exists no standard mechanism for specifying, disseminating, and processing security policy for IPsec, we have adopted some ongoing research work based on a compliance-checking architecture. The concept behind this architecture is that, at SA establishment time, we utilize some mechanism that validates the suitability of an SA for a particular class of packets and a remote principal at IKE exchange time; all the characteristics of the SA (cryptographic algorithms, key sizes, transform ordering, etc.), along with the packet classes (in effect, a set of packet filter rules) and the remote principal's identity (public key, X.509 certificates, passphrase, etc.) are available at that stage. It is important to realize that this operation is performed only infrequently compared to the number of packets that will use the established SAs. Thus, it is possible to use a mechanism that is more general, powerful, and extensible than a simple packet filter specification language. We would also like to be able to utilize credentials delegating authority, as we have found these to allow easier and more scalable administration.

The higher-level mechanism for security policy compliance-checking we use is a trust-management system. Trust-management systems [5,4] provide a unified approach to specifying security policies, credentials, and relationships between principals in the system. Unlike traditional certification schemes, trust-management credentials bind keys directly to the authorization to perform some task. A trust-management system provides a highly-adaptable general-purpose mechanism for specifying security policies and credentials. A principle of trust management is ``monotonicity.'' This means that policies and credentials can only have a positive effect on the privileges of a principal; it is not possible to revoke privilege by issuing a credential. This may only be done by expiring credentials, or by modifying the relevant policies and credentials. For an extensive overview of trust-management, see [3].

KeyNote is an instantiation of a trust-management system, designed to be simple yet flexible. It provides a single language for both policies and credentials, based on predicates that describe the trusted actions permitted by holders of specific public keys (or other cryptographic identifiers). For more details on KeyNote syntax and processing, see [4]. For more details on the policy architecture itself, see [6]. The following subsection discusses some implementation specifics.