diff options
Diffstat (limited to 'doc/rfc/rfc2704.txt')
| -rw-r--r-- | doc/rfc/rfc2704.txt | 2075 |
1 files changed, 2075 insertions, 0 deletions
diff --git a/doc/rfc/rfc2704.txt b/doc/rfc/rfc2704.txt new file mode 100644 index 0000000..d41cd3a --- /dev/null +++ b/doc/rfc/rfc2704.txt @@ -0,0 +1,2075 @@ + + + + + + +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: + + <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} ; + + That is, an <AttributeID> 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 + authorizing action in query. + Comma separated. + + In addition, attributes with names of the form "_<N>", where <N> is + an ASCII-encoded integer, are used by the regular expression matching + mechanism described in Section 5. + + The assignment and semantics of any other attribute names beginning + with "_" is unspecified and implementation-dependent. + + The names of other attributes in the action attribute set are not + specified by KeyNote but must be agreed upon by the writers of any + policies and credentials that are to inter-operate in a specific + KeyNote query evaluation. + + + + + + + + +Blaze, et al. Informational [Page 7] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + + By convention, the name of the application domain over which action + attributes should be interpreted is given in the attribute named + "app_domain". The IANA (or some other suitable authority) will + provide a registry of reserved app_domain names. The registry will + list the names and meanings of each application's attributes. + + The app_domain convention helps to ensure that credentials are + interpreted as they were intended. An attribute with any given name + may be used in many different application domains but might have + different meanings in each of them. However, the use of a global + registry is not always required for small-scale, closed applications; + the only requirement is that the policies and credentials made + available to the KeyNote compliance checker interpret attributes + according to the same semantics assumed by the application that + created them. + + For example, an email application might reserve the app_domain + "RFC822-EMAIL" and might use the attributes named "address" (the + email address of a message's sender), "name" (the human name of the + message sender), and any "organization" headers present (the + organization name). The values of these attributes would be derived + in the obvious way from the email message headers. The public key of + the message's signer would be given in the "_ACTION_AUTHORIZERS" + attribute. + + Note that "RFC822-EMAIL" is a hypothetical example; such a name may + or may not appear in the actual registry with these or different + attributes. (Indeed, we recognize that the reality of email security + is considerably more complex than this example might suggest.) + +4. KeyNote Assertion Syntax + + In the following sections, the notation [X]* means zero or more + repetitions of character string X. The notation [X]+ means one or + more repetitions of X. The notation <X>* means zero or more + repetitions of non-terminal <X>. The notation <X>+ means one or more + repetitions of X, whereas <X>? means zero or one repetitions of X. + Nonterminal grammar symbols are enclosed in angle brackets. Quoted + strings in grammar productions represent terminals. + +4.1 Basic Structure + + <Assertion>:: <VersionField>? <AuthField> <LicenseesField>? + <LocalConstantsField>? <ConditionsField>? + <CommentField>? <SignatureField>? ; + + All KeyNote assertions are encoded in ASCII. + + + + +Blaze, et al. Informational [Page 8] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + + KeyNote assertions are divided into sections, called `fields', that + serve various semantic functions. Each field starts with an + identifying label at the beginning of a line, followed by the ":" + character and the field's contents. There can be at most one field + per line. + + A field may be continued over more than one line by indenting + subsequent lines with at least one ASCII SPACE or TAB character. + Whitespace (a SPACE, TAB, or NEWLINE character) separates tokens but + is otherwise ignored outside of quoted strings. Comments with a + leading octothorp character (see Section 4.2) may begin in any + column. + + One mandatory field is required in all assertions: + + Authorizer + + Six optional fields may also appear: + + Comment + Conditions + KeyNote-Version + Licensees + Local-Constants + Signature + + All field names are case-insensitive. The "KeyNote-Version" field, + if present, appears first. The "Signature" field, if present, + appears last. Otherwise, fields may appear in any order. Each field + may appear at most once in any assertion. + + Blank lines are not permitted in assertions. Multiple assertions + stored in a file (e.g., in application policy configurations), + therefore, can be separated from one another unambiguously by the use + of blank lines between them. + +4.2 Comments + + <Comment>:: "#" {ASCII characters} ; + + The octothorp character ("#", ASCII 35 decimal) can be used to + introduce comments. Outside of quoted strings (see Section 4.3), all + characters from the "#" character through the end of the current line + are ignored. However, commented text is included in the computation + of assertion signatures (see Section 4.6.7). + + + + + + +Blaze, et al. Informational [Page 9] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + +4.3 Strings + + A `string' is a lexical object containing a sequence of characters. + Strings may contain any non-NUL characters, including newlines and + nonprintable characters. Strings may be given as literals, computed + from complex expressions, or dereferenced from attribute names. + +4.3.1 String Literals + + <StringLiteral>:: "\"" {see description below} "\"" ; + + A string literal directly represents the value of a string. String + literals must be quoted by preceding and following them with the + double-quote character (ASCII 34 decimal). + + A printable character may be `escaped' inside a quoted string literal + by preceding it with the backslash character (ASCII 92 decimal) + (e.g., "like \"this\"."). This permits the inclusion of the double- + quote and backslash characters inside string literals. + + A similar escape mechanism is also used to represent non-printable + characters. "\n" represents the newline character (ASCII character + 10 decimal), "\r" represents the carriage-return character (ASCII + character 13 decimal), "\t" represents the tab character (ASCII + character 9 decimal), and "\f" represents the form-feed character + (ASCII character 12 decimal). A backslash character followed by a + newline suppresses all subsequent whitespace (including the newline) + up to the next non-whitespace character (this allows the continuation + of long string constants across lines). Un-escaped newline and + return characters are illegal inside string literals. + + The constructs "\0o", "\0oo", and "\ooo" (where o represents any + octal digit) may be used to represent any non-NUL ASCII characters + with their corresponding octal values (thus, "\012" is the same as + "\n", "\101" is "A", and "\377" is the ASCII character 255 decimal). + However, the NUL character cannot be encoded in this manner; "\0", + "\00", and "\000" are converted to the strings "0", "00", and "000" + respectively. Similarly, all other escaped characters have the + leading backslash removed (e.g., "\a" becomes "a", and "\\" becomes + "\"). The following four strings are equivalent: + + "this string contains a newline\n followed by one space." + "this string contains a newline\n \ + followed by one space." + + + + + + + +Blaze, et al. Informational [Page 10] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + + "this str\ + ing contains a \ + newline\n followed by one space." + + "this string contains a newline\012\040followed by one space." + +4.3.2 String Expressions + + In general, anywhere a quoted string literal is allowed, a `string + expression' can be used. A string expression constructs a string + from string constants, dereferenced attributes (described in Section + 4.4), and a string concatenation operator. String expressions may be + parenthesized. + + <StrEx>:: <StrEx> "." <StrEx> /* String concatenation */ + | <StringLiteral> /* Quoted string */ + | "(" <StrEx> ")" + | <DerefAttribute> /* See Section 4.4 */ + | "$" <StrEx> ; /* See Section 4.4 */ + + The "$" operator has higher precedence than the "." operator. + +4.4 Dereferenced Attributes + + Action attributes provide the primary mechanism for applications to + pass information to assertions. Attribute names are strings from a + limited character set (<AttributeID> as defined in Section 3), and + attribute values are represented internally as strings. An attribute + is dereferenced simply by using its name. In general, KeyNote allows + the use of an attribute anywhere a string literal is permitted. + + Attributes are dereferenced as strings by default. When required, + dereferenced attributes can be converted to integers or floating + point numbers with the type conversion operators "@" and "&". Thus, + an attribute named "foo" having the value "1.2" may be interpreted as + the string "1.2" (foo), the integer value 1 (@foo), or the floating + point value 1.2 (&foo). + + Attributes converted to integer and floating point numbers are + represented according to the ANSI C `long' and `float' types, + respectively. In particular, integers range from -2147483648 to + 2147483647, whilst floats range from 1.17549435E-38F to + 3.40282347E+38F. + + Any uninitialized attribute has the empty-string value when + dereferenced as a string and the value zero when dereferenced as an + integer or float. + + + + +Blaze, et al. Informational [Page 11] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + + Attribute names may be given literally or calculated from string + expressions and may be recursively dereferenced. In the simplest + case, an attribute is dereferenced simply by using its name outside + of quotes; e.g., the string value of the attribute named "foo" is by + reference to `foo' (outside of quotes). The "$<StrEx>" construct + dereferences the attribute named in the string expression <StrEx>. + For example, if the attribute named "foo" contains the string "bar", + the attribute named "bar" contains the string "xyz", and the + attribute "xyz" contains the string "qua", the following string + comparisons are all true: + + foo == "bar" + $("foo") == "bar" + $foo == "xyz" + $(foo) == "xyz" + $$foo == "qua" + + If <StrEx> evaluates to an invalid or uninitialized attribute name, + its value is considered to be the empty string (or zero if used as a + numeric). + + The <DerefAttribute> token is defined as: + + <DerefAttribute>:: <AttributeID> ; + +4.5 Principal Identifiers + + Principals are represented as ASCII strings called `Principal + Identifiers'. Principal Identifiers may be arbitrary labels whose + structure is not interpreted by the KeyNote system or they may encode + cryptographic keys that are used by KeyNote for credential signature + verification. + + <PrincipalIdentifier>:: <OpaqueID> + | <KeyID> ; + + 4.5.1 Opaque Principal Identifiers + + Principal Identifiers that are used by KeyNote only as labels are + said to be `opaque'. Opaque identifiers are encoded in assertions as + strings (see Section 4.3): + + <OpaqueID>:: <StrEx> ; + + Opaque identifier strings should not contain the ":" character. + + + + + + +Blaze, et al. Informational [Page 12] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + +4.5.2 Cryptographic Principal Identifiers + + Principal Identifiers that are used by KeyNote as keys, e.g., to + verify credential signatures, are said to be `cryptographic'. + Cryptographic identifiers are also lexically encoded as strings: + + <KeyID>:: <StrEx> ; + + Unlike Opaque Identifiers, however, Cryptographic Identifier strings + have a special form. To be interpreted by KeyNote (for signature + verification), an identifier string should be of the form: + + <IDString>:: <ALGORITHM>":"<ENCODEDBITS> ; + + "ALGORITHM" is an ASCII substring that describes the algorithms to be + used in interpreting the key's bits. The ALGORITHM identifies the + major cryptographic algorithm (e.g., RSA [RSA78], DSA [DSA94], etc.), + structured format (e.g., PKCS1 [PKCS1]), and key bit encoding (e.g., + HEX or BASE64). By convention, the ALGORITHM substring starts with + an alphabetic character and can contain letters, digits, underscores, + or dashes (i.e., it should match the regular expression "[a-zA-Z][a- + zA-Z0-9_-]*"). The IANA (or some other appropriate authority) will + provide a registry of reserved algorithm identifiers. + + "ENCODEDBITS" is a substring of characters representing the key's + bits, the encoding and format of which depends on the ALGORITHM. By + convention, hexadecimal encoded keys use lower-case ASCII characters. + + Cryptographic Principal Identifiers are converted to a normalized + canonical form for the purposes of any internal comparisons between + them; see Section 5.2. + + Note that the keys used in examples throughout this document are + fictitious and generally much shorter than would be required for + security in practice. + +4.6 KeyNote Fields + +4.6.1 The KeyNote-Version Field + + The KeyNote-Version field identifies the version of the KeyNote + assertion language under which the assertion was written. The + KeyNote-Version field is of the form + + <VersionField>:: "KeyNote-Version:" <VersionString> ; + <VersionString>:: <StringLiteral> + | <IntegerLiteral> ; + + + + +Blaze, et al. Informational [Page 13] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + + where <VersionString> is an ASCII-encoded string. Assertions in + production versions of KeyNote use decimal digits in the version + representing the version number of the KeyNote language under which + they are to be interpreted. Assertions written to conform with this + document should be identified with the version string "2" (or the + integer 2). The KeyNote-Version field, if included, should appear + first. + +4.6.2 The Local-Constants Field + + This field adds or overrides action attributes in the current + assertion only. This mechanism allows the use of short names for + (frequently lengthy) cryptographic principal identifiers, especially + to make the Licensees field more readable. The Local-Constants field + is of the form: + + <LocalConstantsField>:: "Local-Constants:" <Assignments> ; + <Assignments>:: /* can be empty */ + | <AttributeID> "=" <StringLiteral> <Assignments> ; + + <AttributeID> is an attribute name from the action attribute + namespace as defined in Section 3. The name is available for use as + an attribute in any subsequent field. If the Local-Constants field + defines more than one identifier, it can occupy more than one line + and be indented. <StringLiteral> is a string literal as described in + Section 4.3. Attributes defined in the Local-Constants field + override any attributes with the same name passed in with the action + attribute set. + + An attribute may be initialized at most once in the Local-Constants + field. If an attribute is initialized more than once in an + assertion, the entire assertion is considered invalid and is not + considered by the KeyNote compliance checker in evaluating queries. + +4.6.3 The Authorizer Field + + The Authorizer identifies the Principal issuing the assertion. This + field is of the form + + <AuthField>:: "Authorizer:" <AuthID> ; + <AuthID>:: <PrincipalIdentifier> + | <DerefAttribute> ; + + The Principal Identifier may be given directly or by reference to the + attribute namespace (as defined in Section 4.4). + + + + + + +Blaze, et al. Informational [Page 14] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + +4.6.4 The Licensees Field + + The Licensees field identifies the principals authorized by the + assertion. More than one principal can be authorized, and + authorization can be distributed across several principals through + the use of `and' and threshold constructs. This field is of the form + + <LicenseesField>:: "Licensees:" <LicenseesExpr> ; + + <LicenseesExpr>:: /* can be empty */ + | <PrincExpr> ; + + <PrincExpr>:: "(" <PrincExpr> ")" + | <PrincExpr> "&&" <PrincExpr> + | <PrincExpr> "||" <PrincExpr> + | <K>"-of(" <PrincList> ")" /* Threshold */ + | <PrincipalIdentifier> + | <DerefAttribute> ; + + <PrincList>:: <PrincipalIdentifier> + | <DerefAttribute> + | <PrincList> "," <PrincList> ; + + <K>:: {Decimal number starting with a digit from 1 to 9} ; + + The "&&" operator has higher precedence than the "||" operator. <K> + is an ASCII-encoded positive decimal integer. If a <PrincList> + contains fewer than <K> principals, the entire assertion is omitted + from processing. + +4.6.5 The Conditions Field + + This field gives the `conditions' under which the Authorizer trusts + the Licensees to perform an action. `Conditions' are predicates that + operate on the action attribute set. The Conditions field is of the + form: + + <ConditionsField>:: "Conditions:" <ConditionsProgram> ; + + <ConditionsProgram>:: /* Can be empty */ + | <Clause> ";" <ConditionsProgram> ; + + <Clause>:: <Test> "->" "{" <ConditionsProgram> "}" + | <Test> "->" <Value> + | <Test> ; + + <Value>:: <StrEx> ; + + + + +Blaze, et al. Informational [Page 15] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + + <Test>:: <RelExpr> ; + + <RelExpr>:: "(" <RelExpr> ")" /* Parentheses */ + | <RelExpr> "&&" <RelExpr> /* Logical AND */ + | <RelExpr> "||" <RelExpr> /* Logical OR */ + | "!" <RelExpr> /* Logical NOT */ + | <IntRelExpr> + | <FloatRelExpr> + | <StringRelExpr> + | "true" /* case insensitive */ + | "false" ; /* case insensitive */ + + <IntRelExpr>:: <IntEx> "==" <IntEx> + | <IntEx> "!=" <IntEx> + | <IntEx> "<" <IntEx> + | <IntEx> ">" <IntEx> + | <IntEx> "<=" <IntEx> + | <IntEx> ">=" <IntEx> ; + + <FloatRelExpr>:: <FloatEx> "<" <FloatEx> + | <FloatEx> ">" <FloatEx> + | <FloatEx> "<=" <FloatEx> + | <FloatEx> ">=" <FloatEx> ; + + <StringRelExpr>:: <StrEx> "==" <StrEx> /* String equality */ + | <StrEx> "!=" <StrEx> /* String inequality */ + | <StrEx> "<" <StrEx> /* Alphanum. comparisons */ + | <StrEx> ">" <StrEx> + | <StrEx> "<=" <StrEx> + | <StrEx> ">=" <StrEx> + | <StrEx> "~=" <RegExpr> ; /* Reg. expr. matching */ + + <IntEx>:: <IntEx> "+" <IntEx> /* Integer */ + | <IntEx> "-" <IntEx> + | <IntEx> "*" <IntEx> + | <IntEx> "/" <IntEx> + | <IntEx> "%" <IntEx> + | <IntEx> "^" <IntEx> /* Exponentiation */ + | "-" <IntEx> + | "(" <IntEx> ")" + | <IntegerLiteral> + | "@" <StrEx> ; + + <FloatEx>:: <FloatEx> "+" <FloatEx> /* Floating point */ + | <FloatEx> "-" <FloatEx> + | <FloatEx> "*" <FloatEx> + | <FloatEx> "/" <FloatEx> + | <FloatEx> "^" <FloatEx> /* Exponentiation */ + + + +Blaze, et al. Informational [Page 16] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + + | "-" <FloatEx> + | "(" <FloatEx> ")" + | <FloatLiteral> + | "&" <StrEx> ; + + <IntegerLiteral>:: {Decimal number of at least one digit} ; + <FloatLiteral>:: <IntegerLiteral>"."<IntegerLiteral> ; + + <StringLiteral> is a quoted string as defined in Section 4.3 + <AttributeID> is defined in Section 3. + + The operation precedence classes are (from highest to lowest): + { (, ) } + {unary -, @, &, $} + {^} + {*, /, %} + {+, -, .} + + Operators in the same precedence class are evaluated left-to-right. + + Note the inability to test for floating point equality, as most + floating point implementations (hardware or otherwise) do not + guarantee accurate equality testing. + + Also note that integer and floating point expressions can only be + used within clauses of condition fields, but in no other KeyNote + field. + + The keywords "true" and "false" are not reserved; they can be used as + attribute or principal identifier names (although this practice makes + assertions difficult to understand and is discouraged). + + <RegExpr> is a standard regular expression, conforming to the POSIX + 1003.2 regular expression syntax and semantics. + + Any string expression (or attribute) containing the ASCII + representation of a numeric value can be converted to an integer or + float with the use of the "@" and "&" operators, respectively. Any + fractional component of an attribute value dereferenced as an integer + is rounded down. If an attribute dereferenced as a number cannot be + properly converted (e.g., it contains invalid characters or is empty) + its value is considered to be zero. + + + + + + + + + +Blaze, et al. Informational [Page 17] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + +4.6.6 The Comment Field + + The Comment field allows assertions to be annotated with information + describing their purpose. It is of the form + + <CommentField>:: "Comment:" <text> ; + + No interpretation of the contents of this field is performed by + KeyNote. Note that this is one of two mechanisms for including + comments in KeyNote assertions; comments can also be inserted + anywhere in an assertion's body by preceding them with the "#" + character (except inside string literals). + +4.6.7 The Signature Field + + The Signature field identifies a signed assertion and gives the + encoded digital signature of the principal identified in the + Authorizer field. The Signature field is of the form: + + <SignatureField>:: "Signature:" <Signature> ; + + <Signature>:: <StrEx> ; + + The <Signature> string should be of the form: + + <IDString>:: <ALGORITHM>":"<ENCODEDBITS> ; + + The formats of the "ALGORITHM" and "ENCODEDBITS" substrings are as + described for Cryptographic Principal Identifiers in Section 4.4.2 + The algorithm name should be the same as that of the principal + appearing in the Authorizer field. The IANA (or some other suitable + authority) will provide a registry of reserved names. It is not + necessary that the encodings of the signature and the authorizer key + be the same. + + If the signature field is included, the principal named in the + Authorizer field must be a Cryptographic Principal Identifier, the + algorithm must be known to the KeyNote implementation, and the + signature must be correct for the assertion body and authorizer key. + + The signature is computed over the assertion text, beginning with the + first field (including the field identifier string), up to (but not + including) the Signature field identifier. The newline preceding the + signature field identifier is the last character included in + signature calculation. The signature is always the last field in a + KeyNote assertion. Text following this field is not considered part + of the assertion. + + + + +Blaze, et al. Informational [Page 18] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + + The algorithms for computing and verifying signatures must be + configured into each KeyNote implementation and are defined and + documented separately. + + Note that all signatures used in examples in this document are + fictitious and generally much shorter than would be required for + security in practice. + +5. Query Evaluation Semantics + + The KeyNote compliance checker finds and returns the Policy + Compliance Value of queries, as defined in Section 5.3, below. + +5.1 Query Parameters + + A KeyNote query has four parameters: + + * The identifier of the principal(s) requesting the action. + + * The action attribute set describing the action. + + * The set of compliance values of interest to the application, + ordered from _MIN_TRUST to _MAX_TRUST + + * The policy and credential assertions that should be included in + the evaluation. + + The mechanism for passing these parameters to the KeyNote evaluator + is application dependent. In particular, an evaluator might provide + for some parameters to be passed explicitly, while others are looked + up externally (e.g., credentials might be looked up in a network- + based distribution system), while still others might be requested + from the application as needed by the evaluator, through a `callback' + mechanism (e.g., for attribute values that represent values from + among a very large namespace). + +5.1.1 Action Requester + + At least one Principal must be identified in each query as the + `requester' of the action. Actions may be requested by several + principals, each considered to have individually requested it. This + allows policies that require multiple authorizations, e.g., `two + person control'. The set of authorizing principals is made available + in the special attribute "_ACTION_AUTHORIZERS"; if several principals + are authorizers, their identifiers are separated with commas. + + + + + + +Blaze, et al. Informational [Page 19] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + +5.1.2 Ordered Compliance Value Set + + The set of compliance values of interest to an application (and their + relative ranking to one another) is determined by the invoking + application and passed to the KeyNote evaluator as a parameter of the + query. In many applications, this will be Boolean, e.g., the ordered + sets {FALSE, TRUE} or {REJECT, APPROVE}. Other applications may + require a range of possible values, e.g., {No_Access, Limited_Access, + Full_Access}. Note that applications should include in this set only + compliance value names that are actually returned by the assertions. + + The lowest-order and highest-order compliance value strings given in + the query are available in the special attributes named "_MIN_TRUST" + and "_MAX_TRUST", respectively. The complete set of query compliance + values is made available in ascending order (from _MIN_TRUST to + _MAX_TRUST) in the special attribute named "_VALUES". Values are + separated with commas; applications that use assertions that make use + of the _VALUES attribute should therefore avoid the use of compliance + value strings that themselves contain commas. + +5.2 Principal Identifier Normalization + + Principal identifier comparisons among Cryptographic Principal + Identifiers (that represent keys) in the Authorizer and Licensees + fields or in an action's direct authorizers are performed after + normalizing them by conversion to a canonical form. + + Every cryptographic algorithm used in KeyNote defines a method for + converting keys to their canonical form and that specifies how the + comparison for equality of two keys is performed. If the algorithm + named in the identifier is unknown to KeyNote, the identifier is + treated as opaque. + + Opaque identifiers are compared as case-sensitive strings. + + Notice that use of opaque identifiers in the Authorizer field + requires that the assertion's integrity be locally trusted (since it + cannot be cryptographically verified by the compliance checker). + +5.3 Policy Compliance Value Calculation + + The Policy Compliance Value of a query is the Principal Compliance + Value of the principal named "POLICY". This value is defined as + follows: + + + + + + + +Blaze, et al. Informational [Page 20] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + +5.3.1 Principal Compliance Value + + The Compliance Value of a principal <X> is the highest order + (maximum) of: + + - the Direct Authorization Value of principal <X>; and + + - the Assertion Compliance Values of all assertions identifying + <X> in the Authorizer field. + +5.3.2 Direct Authorization Value + + The Direct Authorization Value of a principal <X> is _MAX_TRUST if + <X> is listed in the query as an authorizer of the action. + Otherwise, the Direct Authorization Value of <X> is _MIN_TRUST. + +5.3.3 Assertion Compliance Value + + The Assertion Compliance Value of an assertion is the lowest order + (minimum) of the assertion's Conditions Compliance Value and its + Licensee Compliance Value. + +5.3.4 Conditions Compliance Value + + The Conditions Compliance Value of an assertion is the highest-order + (maximum) value among all successful clauses listed in the conditions + section. + + If no clause's test succeeds or the Conditions field is empty, an + assertion's Conditions Compliance Value is considered to be the + _MIN_TRUST value, as defined Section 5.1. + + If an assertion's Conditions field is missing entirely, its + Conditions Compliance Value is considered to be the _MAX_TRUST value, + as defined in Section 5.1. + + The set of successful test clause values is calculated as follows: + + Recall from the grammar of section 4.6.5 that each clause in the + conditions section has two logical parts: a `test' and an optional + `value', which, if present, is separated from the test with the "->" + token. The test subclause is a predicate that either succeeds + (evaluates to logical `true') or fails (evaluates to logical + `false'). The value subclause is a string expression that evaluates + to one value from the ordered set of compliance values given with the + query. If the value subclause is missing, it is considered to be + _MAX_TRUST. That is, the clause + + + + +Blaze, et al. Informational [Page 21] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + + foo=="bar"; + + is equivalent to + + foo=="bar" -> _MAX_TRUST; + + If the value component of a clause is present, in the simplest case + it contains a string expression representing a possible compliance + value. For example, consider an assertion with the following + Conditions field: + + Conditions: + @user_id == 0 -> "full_access"; # clause (1) + @user_id < 1000 -> "user_access"; # clause (2) + @user_id < 10000 -> "guest_access"; # clause (3) + user_name == "root" -> "full_access"; # clause (4) + + Here, if the value of the "user_id" attribute is "1073" and the + "user_name" attribute is "root", the possible compliance value set + would contain the values "guest_access" (by clause (3)) and + "full_access" (by clause (4)). If the ordered set of compliance + values given in the query (in ascending order) is {"no_access", + "guest_access", "user_access", "full_access"}, the Conditions + Compliance Value of the assertion would be "full_access" (because + "full_access" has a higher-order value than "guest_access"). If the + "user_id" attribute had the value "19283" and the "user_name" + attribute had the value "nobody", no clause would succeed and the + Conditions Compliance Value would be "no_access", which is the + lowest-order possible value (_MIN_TRUST). + + If a clause lists an explicit value, its value string must be named + in the query ordered compliance value set. Values not named in the + query compliance value set are considered equivalent to _MIN_TRUST. + + The value component of a clause can also contain recursively-nested + clauses. Recursively-nested clauses are evaluated only if their + parent test is true. That is, + + a=="b" -> { b=="c" -> "value1"; + d=="e" -> "value2"; + true -> "value3"; } ; + + is equivalent to + + (a=="b") && (b=="c") -> "value1"; + (a=="b") && (d=="e") -> "value2"; + (a=="b") -> "value3"; + + + + +Blaze, et al. Informational [Page 22] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + + String comparisons are case-sensitive. + + A regular expression comparison ("~=") is considered true if the + left-hand-side string expression matches the right-hand-side regular + expression. If the POSIX regular expression group matching scheme is + used, the number of groups matched is placed in the temporary meta- + attribute "_0" (dereferenced as _0), and each match is placed in + sequence in the temporary attributes (_1, _2, ..., _N). These + match-attributes' values are valid only within subsequent references + made within the same clause. Regular expression evaluation is case- + sensitive. + + A runtime error occurring in the evaluation of a test, such as + division by zero or an invalid regular expression, causes the test to + be considered false. For example: + + foo == "bar" -> { + @a == 1/0 -> "oneval"; # subclause 1 + @a == 2 -> "anotherval"; # subclause 2 + }; + + Here, subclause 1 triggers a runtime error. Subclause 1 is therefore + false (and has the value _MIN_TRUST). Subclause 2, however, would be + evaluated normally. + + An invalid <RegExpr> is considered a runtime error and causes the + test in which it occurs to be considered false. + +5.3.5 Licensee Compliance Value + + The Licensee Compliance Value of an assertion is calculated by + evaluating the expression in the Licensees field, based on the + Principal Compliance Value of the principals named there. + + If an assertion's Licensees field is empty, its Licensee Compliance + Value is considered to be _MIN_TRUST. If an assertion's Licensees + field is missing altogether, its Licensee Compliance Value is + considered to be _MAX_TRUST. + + For each principal named in the Licensees field, its Principal + Compliance Value is substituted for its name. If no Principal + Compliance Value can be found for some named principal, its name is + substituted with the _MIN_TRUST value. + + The licensees expression (as defined in Section 4.6.4) is evaluated + as follows: + + + + + +Blaze, et al. Informational [Page 23] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + + * A "(...)" expression has the value of the enclosed subexpression. + + * A "&&" expression has the lower-order (minimum) of its two + subexpression values. + + * A "||" expression has the higher-order (maximum) of its two + subexpression values. + + * A "<K>-of(<List>)" expression has the K-th highest order + compliance value listed in <list>. Values that appear multiple + times are counted with multiplicity. For example, if K = 3 and + the orders of the listed compliance values are (0, 1, 2, 2, 3), + the value of the expression is the compliance value of order 2. + + For example, consider the following Licensees field: + + Licensees: ("alice" && "bob") || "eve" + + If the Principal Compliance Value is "yes" for principal "alice", + "no" for principal "bob", and "no" for principal "eve", and "yes" is + higher order than "no" in the query's Compliance Value Set, then the + resulting Licensee Compliance Value is "no". + + Observe that if there are exactly two possible compliance values + (e.g., "false" and "true"), the rules of Licensee Compliance Value + resolution reduce exactly to standard Boolean logic. + +5.4 Assertion Management + + Assertions may be either signed or unsigned. Only signed assertions + should be used as credentials or transmitted or stored on untrusted + media. Unsigned assertions should be used only to specify policy and + for assertions whose integrity has already been verified as + conforming to local policy by some mechanism external to the KeyNote + system itself (e.g., X.509 certificates converted to KeyNote + assertions by a trusted conversion program). + + Implementations that permit signed credentials to be verified by the + KeyNote compliance checker generally provide two `channels' through + which applications can make assertions available. Unsigned, + locally-trusted assertions are provided over a `trusted' interface, + while signed credentials are provided over an `untrusted' interface. + The KeyNote compliance checker verifies correct signatures for all + assertions submitted over the untrusted interface. The integrity of + KeyNote evaluation requires that only assertions trusted as + reflecting local policy are submitted to KeyNote via the trusted + interface. + + + + +Blaze, et al. Informational [Page 24] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + + Note that applications that use KeyNote exclusively as a local policy + specification mechanism need use only trusted assertions. Other + applications might need only a small number of infrequently changed + trusted assertions to `bootstrap' a policy whose details are + specified in signed credentials issued by others and submitted over + the untrusted interface. + +5.5 Implementation Issues + + Informally, the semantics of KeyNote evaluation can be thought of as + involving the construction a directed graph of KeyNote assertions + rooted at a POLICY assertion that connects with at least one of the + principals that requested the action. + + Delegation of some authorization from principal <A> to a set of + principals <B> is expressed as an assertion with principal <A> given + in the Authorizer field, principal set <B> given in the Licensees + field, and the authorization to be delegated encoded in the + Conditions field. How the expression digraph is constructed is + implementation-dependent and implementations may use different + algorithms for optimizing the graph's construction. Some + implementations might use a `bottom up' traversal starting at the + principals that requested the action, others might follow a `top + down' approach starting at the POLICY assertions, and still others + might employ other heuristics entirely. + + Implementations are encouraged to employ mechanisms for recording + exceptions (such as division by zero or syntax error), and reporting + them to the invoking application if requested. Such mechanisms are + outside the scope of this document. + +6. Examples + + In this section, we give examples of KeyNote assertions that might be + used in hypothetical applications. These examples are intended + primarily to illustrate features of KeyNote assertion syntax and + semantics, and do not necessarily represent the best way to integrate + KeyNote into applications. + + In the interest of readability, we use much shorter keys than would + ordinarily be used in practice. Note that the Signature fields in + these examples do not represent the result of any real signature + calculation. + + + + + + + + +Blaze, et al. Informational [Page 25] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + + 1. TRADITIONAL CA / EMAIL + + A. A policy unconditionally authorizing RSA key abc123 for all + actions. This essentially defers the ability to specify + policy to the holder of the secret key corresponding to + abc123: + + Authorizer: "POLICY" + Licensees: "RSA:abc123" + + B. A credential assertion in which RSA Key abc123 trusts either + RSA key 4401ff92 (called `Alice') or DSA key d1234f (called + `Bob') to perform actions in which the "app_domain" is + "RFC822-EMAIL", where the "address" matches the regular + expression "^.*@keynote\.research\.att\.com$". In other + words, abc123 trusts Alice and Bob as certification + authorities for the keynote.research.att.com domain. + + KeyNote-Version: 2 + Local-Constants: Alice="DSA:4401ff92" # Alice's key + Bob="RSA:d1234f" # Bob's key + Authorizer: "RSA:abc123" + Licensees: Alice || Bob + Conditions: (app_domain == "RFC822-EMAIL") && + (address ~= # only applies to one domain + "^.*@keynote\\.research\\.att\\.com$"); + Signature: "RSA-SHA1:213354f9" + + C. A certificate credential for a specific user whose email + address is mab@keynote.research.att.com and whose name, if + present, must be "M. Blaze". The credential was issued by the + `Alice' authority (whose key is certified in Example B + above): + + KeyNote-Version: 2 + Authorizer: "DSA:4401ff92" # the Alice CA + Licensees: "DSA:12340987" # mab's key + Conditions: ((app_domain == "RFC822-EMAIL") && + (name == "M. Blaze" || name == "") && + (address == "mab@keynote.research.att.com")); + Signature: "DSA-SHA1:ab23487" + + + + + + + + + + +Blaze, et al. Informational [Page 26] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + + D. Another certificate credential for a specific user, also + issued by the `Alice' authority. This example allows three + different keys to sign as jf@keynote.research.att.com (each + for a different cryptographic algorithm). This is, in + effect, three credentials in one: + + KeyNote-Version: "2" + Authorizer: "DSA:4401ff92" # the Alice CA + Licensees: "DSA:abc991" || # jf's DSA key + "RSA:cde773" || # jf's RSA key + "BFIK:fd091a" # jf's BFIK key + Conditions: ((app_domain == "RFC822-EMAIL") && + (name == "J. Feigenbaum" || name == "") && + (address == "jf@keynote.research.att.com")); + Signature: "DSA-SHA1:8912aa" + + Observe that under policy A and credentials B, C and D, the + following action attribute sets are accepted (they return + _MAX_TRUST): + + _ACTION_AUTHORIZERS = "dsa:12340987" + app_domain = "RFC822-EMAIL" + address = "mab@keynote.research.att.com" + and + _ACTION_AUTHORIZERS = "dsa:12340987" + app_domain = "RFC822-EMAIL" + address = "mab@keynote.research.att.com" + name = "M. Blaze" + + while the following are not accepted (they return + _MIN_TRUST): + + _ACTION_AUTHORIZERS = "dsa:12340987" + app_domain = "RFC822-EMAIL" + address = "angelos@dsl.cis.upenn.edu" + and + _ACTION_AUTHORIZERS = "dsa:abc991" + app_domain = "RFC822-EMAIL" + address = "mab@keynote.research.att.com" + name = "M. Blaze" + and + _ACTION_AUTHORIZERS = "dsa:12340987" + app_domain = "RFC822-EMAIL" + address = "mab@keynote.research.att.com" + name = "J. Feigenbaum" + + + + + + +Blaze, et al. Informational [Page 27] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + + 2. WORKFLOW/ELECTRONIC COMMERCE + + E. A policy that delegates authority for the "SPEND" application + domain to RSA key dab212 when the amount given in the + "dollars" attribute is less than 10000. + + Authorizer: "POLICY" + Licensees: "RSA:dab212" # the CFO's key + Conditions: (app_domain=="SPEND") && (@dollars < 10000); + + F. RSA key dab212 delegates authorization to any two signers, + from a list, one of which must be DSA key feed1234 in the + "SPEND" application when @dollars < 7500. If the amount in + @dollars is 2500 or greater, the request is approved but + logged. + + KeyNote-Version: 2 + Comment: This credential specifies a spending policy + Authorizer: "RSA:dab212" # the CFO + Licensees: "DSA:feed1234" && # The vice president + ("RSA:abc123" || # middle manager #1 + "DSA:bcd987" || # middle manager #2 + "DSA:cde333" || # middle manager #3 + "DSA:def975" || # middle manager #4 + "DSA:978add") # middle manager #5 + Conditions: (app_domain=="SPEND") # note nested clauses + -> { (@(dollars) < 2500) + -> _MAX_TRUST; + (@(dollars) < 7500) + -> "ApproveAndLog"; + }; + Signature: "RSA-SHA1:9867a1" + + G. According to this policy, any two signers from the list of + managers will do if @(dollars) < 1000: + + KeyNote-Version: 2 + Authorizer: "POLICY" + Licensees: 2-of("DSA:feed1234", # The VP + "RSA:abc123", # Middle management clones + "DSA:bcd987", + "DSA:cde333", + "DSA:def975", + "DSA:978add") + Conditions: (app_domain=="SPEND") && + (@(dollars) < 1000); + + + + + +Blaze, et al. Informational [Page 28] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + + H. A credential from dab212 with a similar policy, but only one + signer is required if @(dollars) < 500. A log entry is made if + the amount is at least 100. + + KeyNote-Version: 2 + Comment: This one credential is equivalent to six separate + credentials, one for each VP and middle manager. + Individually, they can spend up to $500, but if + it's $100 or more, we log it. + Authorizer: "RSA:dab212" # From the CFO + Licensees: "DSA:feed1234" || # The VP + "RSA:abc123" || # The middle management clones + "DSA:bcd987" || + "DSA:cde333" || + "DSA:def975" || + "DSA:978add" + Conditions: (app_domain="SPEND") # nested clauses + -> { (@(dollars) < 100) -> _MAX_TRUST; + (@(dollars) < 500) -> "ApproveAndLog"; + }; + Signature: "RSA-SHA1:186123" + + Assume a query in which the ordered set of Compliance Values is + {"Reject", "ApproveAndLog", "Approve"}. Under policies E and G, + and credentials F and H, the Policy Compliance Value is + "Approve" (_MAX_TRUST) when: + + _ACTION_AUTHORIZERS = "DSA:978add" + app_domain = "SPEND" + dollars = "45" + unmentioned_attribute = "whatever" + and + _ACTION_AUTHORIZERS = "RSA:abc123,DSA:cde333" + app_domain = "SPEND" + dollars = "550" + + The following return "ApproveAndLog": + + _ACTION_AUTHORIZERS = "DSA:feed1234,DSA:cde333" + app_domain = "SPEND" + dollars = "5500" + and + _ACTION_AUTHORIZERS = "DSA:cde333" + app_domain = "SPEND" + dollars = "150" + + + + + + +Blaze, et al. Informational [Page 29] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + + However, the following return "Reject" (_MIN_TRUST): + + _ACTION_AUTHORIZERS = "DSA:def975" + app_domain = "SPEND" + dollars = "550" + and + _ACTION_AUTHORIZERS = "DSA:cde333,DSA:978add" + app_domain = "SPEND" + dollars = "5500" + +7. Trust-Management Architecture + + KeyNote provides a simple mechanism for describing security policy + and representing credentials. It differs from traditional + certification systems in that the security model is based on binding + keys to predicates that describe what the key is authorized by policy + to do, rather than on resolving names. The infrastructure and + architecture to support a KeyNote system is therefore rather + different from that required for a name-based certification scheme. + The KeyNote trust-management architecture is based on that of + PolicyMaker [BFL96,BFS98]. + + It is important to understand the separation between the + responsibilities of the KeyNote system and those of the application + and other support infrastructure. A KeyNote compliance checker will + determine, based on policy and credential assertions, whether a + proposed action is permitted according to policy. The usefulness of + KeyNote output as a policy enforcement mechanism depends on a number + of factors: + + * The action attributes and the assignment of their values must + reflect accurately the security requirements of the application. + Identifying the attributes to include in the action attribute set + is perhaps the most important task in integrating KeyNote into new + applications. + + * The policy of the application must be correct and well-formed. In + particular, trust must be deferred only to principals that should, + in fact, be trusted by the application. + + * The application itself must be trustworthy. KeyNote does not + directly enforce policy; it only provides advice to the + applications that call it. In other words, KeyNote assumes that + the application itself is trusted and that the policy assertions + it specifies are correct. Nothing prevents an application from + submitting misleading or incorrect assertions to KeyNote or from + ignoring KeyNote altogether. + + + + +Blaze, et al. Informational [Page 30] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + + It is also up to the application (or some service outside KeyNote) to + select the appropriate credentials and policy assertions with which + to run a particular query. Note, however, that even if inappropriate + credentials are provided to KeyNote, this cannot result in the + approval of an illegal action (as long as the policy assertions are + correct and the the action attribute set itself is correctly passed + to KeyNote). + + KeyNote is monotonic; adding an assertion to a query can never result + in a query's having a lower compliance value that it would have had + without the assertion. Omitting credentials may, of course, result + in legal actions being disallowed. Selecting appropriate credentials + (e.g., from a distributed database or `key server') is outside the + scope of the KeyNote language and may properly be handled by a remote + client making a request, by the local application receiving the + request, or by a network-based service, depending on the application. + + In addition, KeyNote does not itself provide credential revocation + services, although credentials can be written to expire after some + date by including a date test in the predicate. Applications that + require credential revocation can use KeyNote to help specify and + implement revocation policies. A future document will address + expiration and revocation services in KeyNote. + + Because KeyNote is designed to support a variety of applications, + several different application interfaces to a KeyNote implementation + are possible. In its simplest form, a KeyNote compliance checker + would exist as a stand-alone application, with other applications + calling it as needed. KeyNote might also be implemented as a library + to which applications are linked. Finally, a KeyNote implementation + might run as a local trusted service, with local applications + communicating their queries via some interprocess communication + mechanism. + +8. Security Considerations + + Trust management is itself a security service. Bugs in or incorrect + use of a KeyNote compliance checker implementation could have + security implications for any applications in which it is used. + +9. IANA Considerations + + This document contains three identifiers to be maintained by the + IANA. This section explains the criteria to be used by the IANA to + assign additional identifiers in each of these lists. + + + + + + +Blaze, et al. Informational [Page 31] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + +9.1 app_domain Identifiers + + The only thing required of IANA on allocation of these identifiers is + that they be unique strings. These strings are case-sensitive for + KeyNote purposes, however it is strongly recommended that IANA assign + different capitalizations of the same string only to the same + organization. + +9.2 Public Key Format Identifiers + + These strings uniquely identify a public key algorithm as used in the + KeyNote system for representing keys. Requests for assignment of new + identifiers must be accompanied by an RFC-style document that + describes the details of this encoding. Example strings are "rsa- + hex:" and "dsa-base64:". These strings are case-insensitive. + +9.3 Signature Algorithm Identifiers + + These strings uniquely identify a public key algorithm as used in the + KeyNote system for representing public key signatures. Requests for + assignment of new identifiers must be accompanied by an RFC-style + document that describes the details of this encoding. Example strings + are "sig-rsa-md5-hex:" and "sig-dsa-sha1-base64:". Note that all + such strings must begin with the prefix "sig-". These strings are + case-insensitive. + + + + + + + + + + + + + + + + + + + + + + + + + + +Blaze, et al. Informational [Page 32] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + +A. Acknowledgments + + We thank Lorrie Faith Cranor (AT&T Labs - Research) and Jonathan M. + Smith (University of Pennsylvania) for their suggestions and comments + on earlier versions of this document. + +B. Full BNF (alphabetical order) + + <ALGORITHM>:: {see section 4.4.2} ; + + <Assertion>:: <VersionField>? <AuthField> <LicenseesField>? + <LocalConstantsField>? <ConditionsField>? + <CommentField>? <SignatureField>? ; + + <Assignments>:: "" | <AttributeID> "=" <StringLiteral> <Assignments> + ; + + <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} ; + + <AuthField>:: "Authorizer:" <AuthID> ; + + <AuthID>:: <PrincipalIdentifier> | <DerefAttribute> ; + + <Clause>:: <Test> "->" "{" <ConditionsProgram> "}" + | <Test> "->" <Value> | <Test> ; + + <Comment>:: "#" {ASCII characters} ; + + <CommentField>:: "Comment:" {Free-form text} ; + + <ConditionsField>:: "Conditions:" <ConditionsProgram> ; + + <ConditionsProgram>:: "" | <Clause> ";" <ConditionsProgram> ; + + <DerefAttribute>:: <AttributeID> ; + + <ENCODEDBITS>:: {see section 4.4.2} ; + + <FloatEx>:: <FloatEx> "+" <FloatEx> | <FloatEx> "-" <FloatEx> + | <FloatEx> "*" <FloatEx> | <FloatEx> "/" <FloatEx> + | <FloatEx> "^" <FloatEx> | "-" <FloatEx> + | "(" <FloatEx> ")" | <FloatLiteral> | "&" <StrEx> ; + + <FloatRelExpr>:: <FloatEx> "<" <FloatEx> | <FloatEx> ">" <FloatEx> + | <FloatEx> "<=" <FloatEx> + | <FloatEx> ">=" <FloatEx> ; + + + +Blaze, et al. Informational [Page 33] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + + <FloatLiteral>:: <IntegerLiteral>"."<IntegerLiteral> ; + + <IDString>:: <ALGORITHM>":"<ENCODEDBITS> ; + + <IntegerLiteral>:: {Decimal number of at least one digit} ; + + <IntEx>:: <IntEx> "+" <IntEx> | <IntEx> "-" <IntEx> + | <IntEx> "*" <IntEx> | <IntEx> "/" <IntEx> + | <IntEx> "%" <IntEx> | <IntEx> "^" <IntEx> + | "-" <IntEx> | "(" <IntEx> ")" | <IntegerLiteral> + | "@" <StrEx> ; + + <IntRelExpr>:: <IntEx> "==" <IntEx> | <IntEx> "!=" <IntEx> + | <IntEx> "<" <IntEx> | <IntEx> ">" <IntEx> + | <IntEx> "<=" <IntEx> | <IntEx> ">=" <IntEx> ; + + <K>:: {Decimal number starting with a digit from 1 to 9} ; + + <KeyID>:: <StrEx> ; + + <LicenseesExpr>:: "" | <PrincExpr> ; + + <LicenseesField>:: "Licensees:" <LicenseesExpr> ; + + <LocalConstantsField>:: "Local-Constants:" <Assignments> ; + + <OpaqueID>:: <StrEx> ; + + <PrincExpr>:: "(" <PrincExpr> ")" | <PrincExpr> "&&" <PrincExpr> + | <PrincExpr> "||" <PrincExpr> + | <K>"-of(" <PrincList> ")" | <PrincipalIdentifier> + | <DerefAttribute> ; + + <PrincipalIdentifier>:: <OpaqueID> | <KeyID> ; + + <PrincList>:: <PrincipalIdentifier> | <DerefAttribute> + | <PrincList> "," <PrincList> ; + + <RegExpr>:: {POSIX 1003.2 Regular Expression} + + <RelExpr>:: "(" <RelExpr> ")" | <RelExpr> "&&" <RelExpr> + | <RelExpr> "||" <RelExpr> | "!" <RelExpr> + | <IntRelExpr> | <FloatRelExpr> | <StringRelExpr> + | "true" | "false" ; + + <Signature>:: <StrEx> ; + + <SignatureField>:: "Signature:" <Signature> ; + + + +Blaze, et al. Informational [Page 34] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + + <StrEx>:: <StrEx> "." <StrEx> | <StringLiteral> | "(" <StrEx> ")" + | <DerefAttribute> | "$" <StrEx> ; + + <StringLiteral>:: {see section 4.3.1} ; + + <StringRelExpr>:: <StrEx> "==" <StrEx> | <StrEx> "!=" <StrEx> + | <StrEx> "<" <StrEx> | <StrEx> ">" <StrEx> + | <StrEx> "<=" <StrEx> | <StrEx> ">=" <StrEx> + | <StrEx> "~=" <RegExpr> ; + + <Test>:: <RelExpr> ; + + <Value>:: <StrEx> ; + + <VersionField>:: "KeyNote-Version:" <VersionString> ; + + <VersionString>:: <StringLiteral> | <IntegerLiteral> ; + +References + + [BFL96] M. Blaze, J. Feigenbaum, 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] M. Blaze, J. Feigenbaum, 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> + + [Bla99] M. Blaze, J. Feigenbaum, J. Ioannidis, A. Keromytis. The + Role of Trust Management in Distributed System Security. + Chapter in Secure Internet Programming: Security Issues for + Mobile and Distributed Objects (Vitek and Jensen, eds.). + Springer-Verlag, 1999. Available at + <ftp://ftp.research.att.com/dist/mab/trustmgt.ps>. + + [Cro82] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, August 1982. + + [DSA94] Digital Signature Standard. FIPS-186. National Institute of + Standards, U.S. Department of Commerce. May 1994. + + [PKCS1] PKCS #1: RSA Encryption Standard, Version 1.5. RSA + Laboratories. November 1993. + + + + +Blaze, et al. Informational [Page 35] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + + [RSA78] R. L. Rivest, A. Shamir, L. M. Adleman. A Method for + Obtaining Digital Signatures and Public-Key Cryptosystems. + Communications of the ACM, v21n2. pp 120-126. February 1978. + +Authors' Addresses + + Comments about this document should be discussed on the keynote-users + mailing list hosted at nsa.research.att.com. To subscribe, send an + email message containing the single line + subscribe keynote-users + in the message body to <majordomo@nsa.research.att.com>. + + Questions about this document can also be directed to the authors as + a group at the keynote@research.att.com alias, or to the individual + authors at: + + Matt Blaze + AT&T Labs - Research + 180 Park Avenue + Florham Park, New Jersey 07932-0971 + + EMail: mab@research.att.com + + + Joan Feigenbaum + AT&T Labs - Research + 180 Park Avenue + Florham Park, New Jersey 07932-0971 + + EMail: jf@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@dsl.cis.upenn.edu + + + + +Blaze, et al. Informational [Page 36] + +RFC 2704 The KeyNote Trust-Management System September 1999 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Blaze, et al. Informational [Page 37] + |