rfc2704.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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 == "[e-mail]"));
      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:

       <AttributeID>:: {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} ;