From RFC 2704:
Trust management, introduced in the PolicyMaker system [BFL96], is a unified approach to specifying and interpreting security policies, credentials, and relationships; it allows direct authorization of security-critical actions. A trust-management system provides standard, general-purpose mechanisms for specifying application security policies and credentials. Trust-management credentials describe a specific delegation of trust and subsume the role of public key certificates; unlike traditional certificates, which bind keys to names, credentials can bind keys directly to the authorization to perform specific tasks.
A trust-management system has five basic components:
- A language 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 to applications for determining how an action requested by principals should be handled, given a policy and a set of credentials.
The trust-management approach has a number of advantages over other mechanisms for specifying and controlling authorization, especially when security policy is distributed over a network or is otherwise decentralized.
Trust management unifies the notions of security policy, credentials, access control, and authorization. An application that uses a trust- management system can simply ask the compliance checker whether a requested action should be allowed. Furthermore, policies and credentials are written in standard languages that are shared by all trust-managed applications; the security configuration mechanism for one application carries exactly the same syntactic and semantic structure as that of another, even when the semantics of the applications themselves are quite different.
Trust-management policies are easy to distribute across networks, helping to avoid the need for application-specific distributed policy configuration mechanisms, access control lists, and certificate parsers and interpreters.
For a general discussion of the use of trust management in distributed system security, see [Bla99].
KeyNote is a simple and flexible trust-management system designed to work well for a variety of large- and small- scale Internet-based applications. It provides a single, unified language for both local policies and credentials. KeyNote policies and credentials, called `assertions', contain predicates that describe the trusted actions permitted by the holders of specific public keys. KeyNote assertions are essentially small, highly-structured programs. A signed assertion, which can be sent over an untrusted network, is also called a `credential assertion'. Credential assertions, which also serve the role of certificates, have the same syntax as policy assertions but are also signed by the principal delegating the trust.
In KeyNote:
- Actions are specified as a collection of name-value pairs.
- Principal names can be any convenient string and can directly represent cryptographic public keys.
- The same language is used for both policies and credentials.
- The policy and credential language is concise, highly expressive, human readable and writable, and compatible with a variety of storage and transmission media, including electronic mail.
- The compliance checker returns an application-configured `policy compliance value' that describes how a request should be handled by the application. Policy compliance values are always positively derived from policy and credentials, facilitating analysis of KeyNote-based systems.
- Compliance checking is efficient enough for high-performance and real-time applications.
This document describes the KeyNote policy and credential assertion language, the structure of KeyNote action descriptions, and the KeyNote model of computation.
If you have any problems uncompressing/viewing these files, drop me a mail. The compression used is the GNU "gzip", which Netscape does not seem to recognize by default.
An implementation of KeyNote version 2 (per RFC 2704) is now available.
You can download a copy of version 2.3 of the KeyNote release from HERE, If you have trouble uncompressing the file, here's the tar-only version. Thanks to Damien Miller for building Redhat RPM packages for releases 2.0 and 2.1. They are available here. You can find a sample (and very simple) application that uses KeyNote here. It is also included on all KeyNote distributions starting from 2.2.
Thanks to Dave Kornbau for providing a pre-compiled Windows 95/98/NT version of KeyNote 2.2 with OpenSSL. It is provided as a zip file for download.
Notice that there are significant differences between KeyNote version 2 and previous versions. Please read the improved and updated specification. The library API has changed as well; the man pages included in the distribution fully document these changes.
If your system does not provide a regular expression library (e.g., Windows), you can download this one (thanks to Dave Clark of Lucent, for sending me a copy).
Patroklos Argyroudis has created
pykeynote, a Python
extension module for KeyNote that provides a high-level, object-oriented
interface to the KeyNote library API. Although pykeynote was developed on
Linux, it should work on most Unix-like systems.
Adam Aviv has
written detailed
instructions for installing pykeynote. He has also written a
simplified
KeyNote evaluator (implementing a subset of the KeyNote
language/features) in Python; the intend is to provide an easily
extensible and modifiable KeyNote-like system for easy
experimentation).