Network Working Group M. Blaze Request for Comments: 2704 J. Feigenbaum Category: Informational J. Ioannidis AT&T Labs - Research A. Keromytis U. of Pennsylvania September 1999 The KeyNote Trust-Management System Version 2 Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo describes version 2 of the KeyNote trust-management system. It specifies the syntax and semantics of KeyNote `assertions', describes `action attribute' processing, and outlines the application architecture into which a KeyNote implementation can be fit. The KeyNote architecture and language are useful as building blocks for the trust management aspects of a variety of Internet protocols and services. 1. Introduction 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. Blaze, et al. Informational [Page 1] RFC 2704 The KeyNote Trust-Management System September 1999 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 Blaze, et al. Informational [Page 2] RFC 2704 The KeyNote Trust-Management System September 1999 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. We assume that applications communicate with a locally trusted KeyNote compliance checker via a `function call' style interface, sending a collection of KeyNote policy and credential assertions plus an action description as input and accepting the resulting policy compliance value as output. However, the requirements of different applications, hosts, and environments may give rise to a variety of different interfaces to KeyNote compliance checkers; this document does not aim to specify a complete compliance checker API. 2. KeyNote Concepts In KeyNote, the authority to perform trusted actions is associated with one or more `principals'. A principal may be a physical entity, a process in an operating system, a public key, or any other convenient abstraction. KeyNote principals are identified by a string called a `Principal Identifier'. In some cases, a Principal Identifier will contain a cryptographic key interpreted by the Blaze, et al. Informational [Page 3] RFC 2704 The KeyNote Trust-Management System September 1999 KeyNote system (e.g., for credential signature verification). In other cases, Principal Identifiers may have a structure that is opaque to KeyNote. Principals perform two functions of concern to KeyNote: They request `actions' and they issue `assertions'. Actions are any trusted operations that an application places under KeyNote control. Assertions delegate the authorization to perform actions to other principals. Actions are described to the KeyNote compliance checker in terms of a collection of name-value pairs called an `action attribute set'. The action attribute set is created by the invoking application. Its structure and format are described in detail in Section 3 of this document. KeyNote provides advice to applications about the interpretation of policy with regard to specific requested actions. Applications invoke the KeyNote compliance checker by issuing a `query' containing a proposed action attribute set and identifying the principal(s) requesting it. The KeyNote system determines and returns an appropriate `policy compliance value' from an ordered set of possible responses. The policy compliance value returned from a KeyNote query advises the application how to process the requested action. In the simplest case, the compliance value is Boolean (e.g., "reject" or "approve"). Assertions can also be written to select from a range of possible compliance values, when appropriate for the application (e.g., "no access", "restricted access", "full access"). Applications can configure the relative ordering (from `weakest' to `strongest') of compliance values at query time. Assertions are the basic programming unit for specifying policy and delegating authority. Assertions describe the conditions under which a principal authorizes actions requested by other principals. An assertion identifies the principal that made it, which other principals are being authorized, and the conditions under which the authorization applies. The syntax of assertions is given in Section 4. A special principal, whose identifier is "POLICY", provides the root of trust in KeyNote. "POLICY" is therefore considered to be authorized to perform any action. Blaze, et al. Informational [Page 4] RFC 2704 The KeyNote Trust-Management System September 1999 Assertions issued by the "POLICY" principal are called `policy assertions' and are used to delegate authority to otherwise untrusted principals. The KeyNote security policy of an application consists of a collection of policy assertions. When a principal is identified by a public key, it can digitally sign assertions and distribute them over untrusted networks for use by other KeyNote compliance checkers. These signed assertions are also called `credentials', and serve a role similar to that of traditional public key certificates. Policies and credentials share the same syntax and are evaluated according to the same semantics. A principal can therefore convert its policy assertions into credentials simply by digitally signing them. KeyNote is designed to encourage the creation of human-readable policies and credentials that are amenable to transmission and storage over a variety of media. Its assertion syntax is inspired by the format of RFC822-style message headers [Cro82]. A KeyNote assertion contains a sequence of sections, called `fields', each of which specifies one aspect of the assertion's semantics. Fields start with an identifier at the beginning of a line and continue until the next field is encountered. For example: KeyNote-Version: 2 Comment: A simple, if contrived, email certificate for user mab Local-Constants: ATT_CA_key = "RSA:acdfa1df1011bbac" mab_key = "DSA:deadbeefcafe001a" Authorizer: ATT_CA_key Licensees: mab_key Conditions: ((app_domain == "email") # valid for email only && (address == "mab@research.att.com")); Signature: "RSA-SHA1:f00f2244" The meanings of the various sections are described in Sections 4 and 5 of this document. KeyNote semantics resolve the relationship between an application's policy and actions requested by other principals, as supported by credentials. The KeyNote compliance checker processes the assertions against the action attribute set to determine the policy compliance value of a requested action. These semantics are defined in Section 5. An important principle in KeyNote's design is `assertion monotonicity'; the policy compliance value of an action is always positively derived from assertions made by trusted principals. Removing an assertion never results in increasing the compliance value returned by KeyNote for a given query. The monotonicity Blaze, et al. Informational [Page 5] RFC 2704 The KeyNote Trust-Management System September 1999 property can simplify the design and analysis of complex network- based security protocols; network failures that prevent the transmission of credentials can never result in spurious authorization of dangerous actions. A detailed discussion of monotonicity and safety in trust management can be found in [BFL96] and [BFS98]. 3. Action Attributes Trusted actions to be evaluated by KeyNote are described by a collection of name-value pairs called the `action attribute set'. Action attributes are the mechanism by which applications communicate requests to KeyNote and are the primary objects on which KeyNote assertions operate. An action attribute set is passed to the KeyNote compliance checker with each query. Each action attribute consists of a name and a value. The semantics of the names and values are not interpreted by KeyNote itself; they vary from application to application and must be agreed upon by the writers of applications and the writers of the policies and credentials that will be used by them. Action attribute names and values are represented by arbitrary-length strings. KeyNote guarantees support of attribute names and values up to 2048 characters long. The handling of longer attribute names or values is not specified and is KeyNote-implementation-dependent. Applications and assertions should therefore avoid depending on the the use of attributes with names or values longer than 2048 characters. The length of an attribute value is represented by an implementation-specific mechanism (e.g., NUL-terminated strings, an explicit length field, etc.). Attribute values are inherently untyped and are represented as character strings by default. Attribute values may contain any non- NUL ASCII character. Numeric attribute values should first be converted to an ASCII text representation by the invoking application, e.g., the value 1234.5 would be represented by the string "1234.5". Attribute names are of the form: :: {Any string starting with a-z, A-Z, or the underscore character, followed by any number of a-z, A-Z, 0-9, or underscore characters} ; That is, an begins with an alphabetic or underscore character and can be followed by any number of alphanumerics and underscores. Attribute names are case-sensitive. Blaze, et al. Informational [Page 6] RFC 2704 The KeyNote Trust-Management System September 1999 The exact mechanism for passing the action attribute set to the compliance checker is determined by the KeyNote implementation. Depending on specific requirements, an implementation may provide a mechanism for including the entire attribute set as an explicit parameter of the query, or it may provide some form of callback mechanism invoked as each attribute is dereferenced, e.g., for access to kernel variables. If an action attribute is not defined its value is considered to be the empty string. Attribute names beginning with the "_" character are reserved for use by the KeyNote runtime environment and cannot be passed from applications as part of queries. The following special attribute names are used: Name Purpose ------------------------ ------------------------------------ _MIN_TRUST Lowest-order (minimum) compliance value in query; see Section 5.1. _MAX_TRUST Highest-order (maximum) compliance value in query; see Section 5.1. _VALUES Linearly ordered set of compliance values in query; see Section 5.1. Comma separated. _ACTION_AUTHORIZERS Names of principals directly