Internet DRAFT - draft-blaze-trustmgt-keynote
draft-blaze-trustmgt-keynote
Trust Management Working Group Matt Blaze
Internet Draft Joan Feigenbaum
expires in six months Angelos D. Keromytis
John Ioannidis
August 1998
The KeyNote Trust-Management System
draft-blaze-trustmgt-keynote-00.txt (A)
Status of this Memo
This document is an Internet-Draft. Internet Drafts are working doc-
uments of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute work-
ing documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months, and may be updated, replaced, or obsoleted by other documents
at any time. It is not appropriate to use Internet Drafts as refer-
ence material, or to cite them other than as a ``working draft'' or
``work in progress.''
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Distribution of this memo is unlimited.
Abstract
This memo describes KeyNote, a simple trust-management system. It
outlines the syntax and semantics of KeyNote credentials, describes
action environment processing, and describes the application
architecture into which a KeyNote implementation would fit.
Terminology
The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT,"
"SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this
document are to be interpreted as described in [Bra97].
1. Introduction
This memo describes KeyNote, a simple trust-management system.
Trust management, introduced in the PolicyMaker system [BFL96], is
a unified approach to specifying and interpreting security
policies, credentials, and relationships that allows direct
KeyNote expires in six months [Page i]
DRAFT KeyNote August 1998
authorization of security-critical actions. In particular, a
trust-management system combines the notion of specifying security
policy with the mechanism for specifying security credentials
(subsuming the role of "certificates"). Credentials describe a
specific delegation of trust among public keys; unlike traditional
certificates, which bind keys to names, trust-management credentials
bind keys to the authorization to perform specific tasks.
KeyNote provides a simple notation for specifying both local security
policies and security credentials that can be sent over an untrusted
network. Policies and credentials, called "assertions", contain
predicates that describe the trusted actions permitted by the holders
of specific public keys. A signed assertion that can be sent over an
untrusted network is also called a Credential Assertion. Credential
assertions, which serve the role of "certificates," have the same
syntax as policy assertions but are also signed by the entity
delegating the trust.
In this document we assume that applications communicate with a
"KeyNote evaluator" that interprets KeyNote assertions and returns
results to applications. However, different hosts and environments
may provide a variety of interfaces to the KeyNote evaluator and
this document does not aim to specify a KeyNote API.
A KeyNote evaluator accepts as input a set of local policy and
credential assertions, and a set of attributes, called an "action
environment," that describes a proposed trusted action associated
with a set of public keys. The KeyNote evaluator determines whether
proposed actions are consistent with local policy by applying the
assertion predicates to the action environment. The KeyNote
evaluator can return values other than simply true and false,
depending on the application and the action-environment definition.
Furthermore, KeyNote assertions can return additional information
(such as arguments) to the invoking application.
2. KeyNote Syntax
The version of KeyNote assertions described in this document is 1.
All KeyNote assertions are encoded in ASCII strings. Four mandatory
fields MUST appear in all assertions (KeyNote-Version, Authorizer,
Licensees, and Conditions); these fields describe who authorizes
whom under what conditions. Four optional fields MAY appear (Export,
Comment, Signature, and Local-Init).
All fields MUST start at the beginning of a line; fields may be
continued by indenting with at least one SPACE or TAB character at
the beginning of the line. Whitespace separates tokens but is
otherwise ignored outside of quoted strings. (Our grammars below
omit whitespace processing in the interest of readability.) All
name tokens are case-insensitive.
KeyNote expires in six months [Page 1]
DRAFT KeyNote August 1998
In the following sections, the notation [X]* means zero or more
repetitions of the string X. The notation [X]+ means one or more
repetitions of the string X.
A complete sample assertion is shown below. The meaning of the
various fields is explained in the following sections.
KeyNote-Version: 1
Authorizer: rsa-pkcs1-hex:deaf
Licensees: dsa-hex:feeddead || rsa-pkcs1-hex:cafe
Export: Attr1, Attr2
Local-Init: localattribute = "xxx"
Comment: Your average credential assertion
Conditions: $foo == "bar" -> {write1 = "yes", return true}
Signature: rsa-md5-pkcs1-hex:f00f
2.1 Key Encoding
Keys in KeyNote credential assertions are encoded as
AlgorithmName:Encoding
AlgorithmName is a case-insensitive ASCII string that describes
the key type (e.g., RSA [RSA78] or DSA [DSA94]), encoding (e.g.,
PKCS1 [PKCS1]), and string encoding (e.g., HEX or BASE64).
AlgorithmName is given by [a-zA-Z][a-zA-Z0-9_-]*
The IANA will provide a registry of reserved AlgorithmName names.
Encoding is ([a-zA-Z0-9][a-zA-Z0-9_]*)|(\"(([^\"\n])|(\\[.\n]))*\")
and its format depends on AlgorithmName. Hex-encoded keys SHOULD
use lower-case digits. Encoding can can occupy more than one line
by using the "+" string concatenation operator.
Note that the keys used in examples in this document are fictitious
and generally shorter than would be required for security.
2.2 Attributes
Attributes in KeyNote are denoted by $AttrName in any of the
Authorizer, Licensees, and Conditions fields. Whenever an attribute
is encountered, a lookup MUST be made in the Local-Init
definitions. If that fails, for the Authorizer and Licensees fields
this results in the empty string. In the Conditions, a subsequent
lookup in the action environment must be made. (For more details on
the action environment, see section 4.) If that fails to match as
well, the result is the empty string. In case of a match, the
corresponding value is the result, in string form.
In the Conditions, attributes can also be denoted by @AttrName and
&AttrName. These cause the resulting value to be an integer or a
floating point number respectively. If $AttrName contains
characters other than whitespace, decimal digits and a
KeyNote expires in six months [Page 2]
DRAFT KeyNote August 1998
single '.' character, the resulting value MUST be zero. @AttrName
is equivalent to floor(&AttrName).
2.3 Key Comparisons
Key comparisons inside KeyNote (performed while trying to match
keys in Authorizer and Licensees or the action authorizers (see
section 5) should be between canonical forms of the keys. Every
algorithm used in KeyNote should define some method for converting
keys to this canonical form, and how the comparison for equality of
two keys is performed. If the algorithm is unknown or unsupported,
the implementation SHOULD do a case-sensitive string comparison,
for comparisons between keys in a Licensees and the action
authorizers (since a key that the application knows about but the
KeyNote implementation does not, may appear in the action
authorizers). Comparisons involving a key in the Authorizer field
MUST be between canonical forms, unless the assertion is localy
trusted (case-sensitive string comparison is used in that case).
2.4 Return Values
Some applications may use KeyNote in a form in which an assertion
evaluates to one of two values (true/false). However, KeyNote
supports more than two values (the number of supported values, as
well as the values themselves, SHOULD be a runtime option set by the
invoking application). The set of all possible return values should
be a totally ordered one. The return values are the possible values
both Licensees and Conditions can take after they have been
evaluated.
The KeyNote system will attempt to return the highest possible value
from a query using the evaluation rules described in the following
sections (in particular, section 6). The meaning and interpretation
of these values is application-dependent, and should be defined along
with the rest of action-environment details (see section 4).
2.5 Write-Back Environment
In addition to returning a non-boolean value to the invoking
application, KeyNote assertions can also pass back some additional
information through a write-back environment mechanism. Assertions
can not lookup information in this write-back environment. The
rules of how a write-back attribute is propagated back to the
invoking application are given in section 3.4. Section 3.8 contains
some additional information on scoping.
In some cases, two write-back sets of attributes will be "combined"
(section 3.4) using a non-reflective operation: an ordering of the
two write-back sets is defined, and the resulting write-back set is
the union of the two sets. Write-back attributes common to both
sets will have their values inherited from the second write-back
set. In that sense, the second write-back set writes over the first.
KeyNote expires in six months [Page 3]
DRAFT KeyNote August 1998
3. KeyNote Field Meanings
The following sections explain the contents and meaning of the
various fields that can appear in a KeyNote assertion.
3.1 The KeyNote-Version field
The KeyNote-Version field is of the form
KeyNote-Version: VersionNumber
where VersionNumber is an ASCII-encoded decimal number. The
current version is 1. This field MUST be the first field appearing
in a KeyNote assertion.
3.2 The Local-Init field
This field initializes action-environment attributes that are
specific to this assertion only. A typical use for this field is
to assign keys to logical names, so that the Licensees
field is more readable. This field is of the form
Local-Init: Name = ConstantString [, Name = ConstantString]*
Name is an identifier that can be used as an attribute (see section
2.2) in the Conditions, Authorizer, and Licensees fields instead
of the string ConstantString. If the Local-Init field defines more
than one identifier, it can occupy more than one line and be
indented. ConstantString is given by STRING in section 3.8, and
can also be composed by concatenating smaller strings using the
"+" operator (see the examples) and can thus occupy more than one
line. If an initialization identifier is accessed but has not been
defined, it should evaluate to the empty string (or zero, if it was
accessed as a numeric value).
When an initialization identifier is accessed in an Conditions
expression, it shadows the value of any existing action-environment
identifier, for this assertion only (see section 2.2). If an
identifier appears more than once in the Local-Init field, the
assertion MUST be considered invalid and omitted from processing by
the evaluator.
3.3 The Authorizer field
The Authorizer field is of the form
Authorizer: KEY
where KEY is a key encoded as described in section 2.1. The
Authorizer field can also be a logical tag, of the form
Authorizer: SomeString
KeyNote expires in six months [Page 4]
DRAFT KeyNote August 1998
for assertions that are trusted directly by the local environment
and thus do not require cryptographic verification. SomeString is
given by STRING in section 3.8, or can be a concatenation of smaller
strings, using the '+' operator. Tag comparisons are
case-sensitive. Finally, the Authorizer field can be of the form
Authorizer: $Attribute
where Attribute is a Local-Init identifier (see section 2.2). If
the Attribute does not exist in the Local-Init identifiers, the
assertion MUST be omitted from processing. The result is treated
as a key (see section 2.1) for comparison purposes.
A valid input to the KeyNote evaluator MUST contain at least one
Policy assertion (in which the authorizer field is the keyword
"POLICY", case-insensitive), which will serve as the "root" of a
trust structure that authorizes a requested action.
3.4 The Licensees field
The Licensees field describes who is being authorized by the
Authorizer. This field is of the form
Licensees: Key-Expr
Key-Expr is given by the following grammar:
Key-Expr: (Key-Expr) |
Key-Expr && Key-Expr |
Key-Expr || Key-Expr |
K-of(KeyList) | /* Threshold */
STRING |
KEY |
$STRING
KeyList: KEY |
ATTRIBUTE |
STRING |
KEY, KeyList |
ATTRIBUTE, KeyList |
STRING, KeyList
STRING: (([a-zA-Z][a-zA-Z0-9_-]*) | (\" (([^\"\n])|(\\[.\n]))* \"))
ATTRIBUTE: "$"[a-zA-Z0-9][a-zA-Z0-9_]*
The "&&" operator has higher precedence than the "||" operator.
"K" is an ASCII-encoded decimal number. A KeyList SHOULD contain
at least K keys.
Only identifiers that appear in the Local-Init can be used as
attributes in Licensees (see section 2.2). An attribute is
resolved to a string, which is then treated as a key or logical
KeyNote expires in six months [Page 5]
DRAFT KeyNote August 1998
tag. STRING can also be a quoted string, and/or a concatenation
of smaller strings using the '+' operator.
The keys, attributes, or logical tags that appear in the Licensees
and the various expressions are treated as variables for the
purpose of evaluation. The values these variables take are:
- If a key, attribute, or logical tag appears in the action
authorizers (see section 5), its value is the highest possible.
The empty write-back set is associated with it.
- Otherwise, if the key, attribute, or logical tag appears in the
Authorizer field of one or more assertions, the value it takes
is the higher value of those assertions, and the associated
write-back set. If more than one assertion shares the highest
possible value, the write-back set of one is picked arbitrarily.
Which one is picked is implementation-dependent and may be
non-deterministic.
- Otherwise, the value of the key, attribute, or logical tag is
the lowest possible. The empty write-back set is associated
with it.
If the Key-Expr field is empty, it always evaluates to the highest
possible value (which is set by the application), and is used for
direct authorization of an Conditions by a policy or a credential.
The semantics of the various key expressions are:
- An "(..)" expression has the value of the enclosed subexpression.
It also inherits the write-back set from the enclosing
subexpression.
- An "&&" expression has the lower of its two subexpression
values. The resulting write-back set is the combination of the
write-back sets of the two subexpressions, where the lower-value
write-back set writes over variables that appear in the
higher-value write-back set. For example, let
Licensees: Key1 && Key2
Key1's value is "value1"
Key2's value is "value2"
'value1' is higher than 'value2' in the linear order of
return values
Key1's write-back set is "str1=val1, str2=val2"
Key2's write-back set is "str1=val3, str4=val4"
Then the resulting value will be "value2," and the write-back set
will be "str1=val3, str2=val2, str4=val4."
If both subexpressions have the same value, then the left
KeyNote expires in six months [Page 6]
DRAFT KeyNote August 1998
subexpression's write-back set writes over the right
subexpression's write-back set. In the above setup, the resulting
write-back set if the two keys had the same value would be
"str1=val1, str2=val2, str4=val4"
- An "||" expression has the higher of its two subexpression
values. The resulting write-back set is that associated with the
returned value. In case of a tie, the left subexpression's
write-back set is the resulting write-back set.
- A "K-OF(...)" expression has the K-th highest value of those among
the KEYs and logical tags enclosed, counting multiplicity. That
is, if K = 3 and the values are (0, 1, 2, 2, 3), the value of the
threshold is 2.
The resulting write-back set is the combination of the write-back
sets associated with the K highest values in the list, with the
higher write-back sets writing over lower write-back sets. If more
than K keys share the K highest values, the leftmost K (as they
appear in the keylist) are used. For example, if K = 3 and the
values are (0, 1, 2, 2, 3), the resulting write-back set will be
that of the right-most '2', written-over by the write-back set of
the '2' on its left, and the result written-over by the write-back
set of the '3'.
Notice that in the case of two values (true/false), the above rules
of value resolution reduce to boolean logic.
3.5 The Signature field
The Signature field is of the form
Signature: AlgorithmName:Encoding
AlgorithmName is a case-insensitive ASCII string that indicates
the signature type and encoding (e.g., RSA-MD5-PKCS1-BASE64).
AlgorithmName is given by [a-zA-Z][a-zA-Z0-9_-]*
The IANA will provide a registry of reserved AlgorithmName names.
Encoding contains the signature encoded according to AlgorithmName.
Encoding is given by STRING, in section 3.8, and can occupy more
than one lines by using the '+' string concatenation operator.
Hex-encoded signatures SHOULD use lower-case hex digits. The
AlgorithmName here is not the same, but generally is related to
the AlgorithmName of the key that appears in the Authorizer field.
The signature is computed over the assertion, beginning at the
KeyNote-Version field (including the keyword), up to (and
including) the Signature field (the colon following the keyword is
also included), concatenated with the AlgorithmName field (trailing
colon included). This field MUST be last in a KeyNote assertion.
KeyNote expires in six months [Page 7]
DRAFT KeyNote August 1998
Note that the Signatures used in examples in this document are
fictitious and generally shorter than would be required for security.
3.6 The Comment field
The Comment field is of the form
Comment: .*
The interpretation of this field is application-dependent.
3.7 The Export field
The Export field is of the form
Export: Keyword [, KeyWord]*
where Keyword is given by [a-zA-Z][a-zA-Z0-9_-]*
This field contains a list of write-back environment attributes
that this assertion is willing to export to its descendants.
If this field is present but empty, it is taken to mean "All
write-back environment attributes are exported." If it is missing,
no write-back environment attribute is exported. See section 2.5
for more details on write-back environments. See section 6 on how
the Export field is used in conjunction with write-back
environments. Keyword may also be a quoted string, and/or the
concatenation of smaller strings using the '+' operator.
3.8 The Conditions field
The Conditions field describes what the Authorizer authorizes
the key(s) appearing in Licensees to do. This field is of the
form
Conditions: Program
where Program is given by the following grammar:
Program: /* Nothing */
| Program2
Program2: Expr -> { RecProgram2 }
| Expr -> { RecProgram2 } Program2
RecProgram2: Program2
| AssignmentList
AssignmentList: "return" STRING /* Case insensitive "return" */
| Str = Str , AssignmentList /* WriteBack */
| Str = NumEx , AssignmentList /* WriteBack */
| Str = FloatEx, AssignmentList /* WriteBack */
KeyNote expires in six months [Page 8]
DRAFT KeyNote August 1998
Expr: ( Expr ) | /* Parentheses */
Expr && Expr | /* Logical AND */
Expr || Expr | /* Logical OR */
!Expr | /* Logical NOT */
NumExpr | /* Integer boolean expression */
FloatExpr | /* Floating point boolean expression */
StringExpr | /* String boolean expression */
"true" | /* Case insensitive keyword */
"false" /* Case insensitive keyword */
NumExpr: NumEx == NumEx | /* Integer expression comparisons */
NumEx != NumEx |
NumEx < NumEx |
NumEx > NumEx |
NumEx <= NumEx |
NumEx >= NumEx |
FloatExpr: FloatEx < FloatEx | /* Floating point */
FloatEx > FloatEx |
FloatEx <= FloatEx |
FloatEx >= FloatEx
StringExpr: Str == Str | /* String equality */
Str != Str | /* String inequality */
Str < Str | /* Alphanumeric comparisons */
Str > Str |
Str <= Str |
Str >= Str |
Str ~= RegExp /* Regular expression matching */
Str: Str + Str | /* String concatenation */
Str . Str | /* Also string concatenation */
STRING | /* Quoted or otherwise */
ATTRIBUTE | /* Lookup in Local-Init and action environment */
$( Str ) /* Dynamic resolution */
NumEx: NumEx + NumEx | /* Integer operations */
NumEx - NumEx |
NumEx * NumEx |
NumEx / NumEx |
NumEx % NumEx |
NumEx ^ NumEx | /* Exponentiation */
-NumEx |
( NumEx ) |
NUMBER |
NUMATTRIBUTE |
@( Str ) /* Dynamic resolution */
FloatEx: FloatEx + FloatEx | /* Floating point operations */
FloatEx - FloatEx |
FloatEx * FloatEx |
FloatEx / FloatEx |
KeyNote expires in six months [Page 9]
DRAFT KeyNote August 1998
FloatEx ^ FloatEx | /* Exponentiation */
-FloatEx |
( FloatEx ) |
FLOAT |
FLOATATTRIBUTE |
&( Str ) /* Dynamic resolution */
NUMBER: [0-9]+
FLOAT: {NUMBER} . {NUMBER}
STRING: (([a-zA-Z][a-zA-Z0-9_-]*) | (\" (([^\"\n])|(\\[.\n]))* \"))
VSTRING: [a-zA-Z0-9][a-zA-Z0-9_]*
ATTRIBUTE: $VSTRING
NUMATTRIBUTE: @VSTRING
FLOATATTRIBUTE: &VSTRING
The binary numeric operation precedence is (higher to lower) ^,
(*, /, %), (+, -). Operators of equal precedence are evaluated
left-to-right.
Single-backslash ("\") and quote elimination must be performed on
quoted strings (e.g., "\ac" becomes ac).
String operations (including regexps) in the Conditions can be
case-sensitive or case-insensitive, specified as a run-time option.
A division (or modulo) by zero causes the enclosing boolean
expression to evaluate to the lowest value.
The keywords `true', `false', and `return' have special meaning
only in those grammar rules they are included. They can be used as
variable names or strings anywhere else in the Conditions.
The "$(str)" construct causes a lookup of the string ``str'' in the
Local-Init attributes (and if that fails to find a match, in the
action-environment attributes). If ``str'' evaluates to the empty
string, the enclosing boolean expression MUST evaluate to false.
Similarly for the "@(str)" and "&(str)" constructs.
RegExpr refers to the POSIX 1003.2 regular expression syntax and
semantics. A regular expression is true if the left hand string
expression matches RegExpr. If group matching is used, the number
of groups matched MUST be placed in the temporary attribute $0, and
the subsequent matches should be placed in the temporary attributes
$1, $2, ..., $($0). These values should be discarded when a
subsequent regular expression is encountered, or if the current
expression does not evaluate to true. If an invalid RegExpr is
encountered, the assertion MUST be omitted from processing.
If an Conditions field is empty, it always evaluates to the
highest possible return value. If no expressions match, the value
of this assertion is the lowest value, and there is no associated
write-back set.
KeyNote expires in six months [Page 10]
DRAFT KeyNote August 1998
More than one expressions can exist in an Conditions. The
semantics then are that the first expression that evaluates to true,
returns a value and a write environment.
Furthermore, expressions can be nested, using the "-> { ... }"
construct. Consequently, an expression can be viewed as a series of
boolean expressions that lead to a write-back environment/return
value. The first such expression where all the boolean expressions
are true ``fires''. As an example, consider the Conditions
with the following expressions:
expression1 -> { expression11 -> {return somevalue}
expression12 -> {return someothervalue}
}
expression2 -> { expression21 -> {return somethirdvalue} }
expression3 -> {return justavalue}
If expression1 and expression11 are true, then the returned value
will be "somevalue." If expression1 is true, expression11 is false,
and expression12 is true, "someothervalue" will be returned. If
expression1 if false, or both expression11 and expression12 are
false, the following expressions will be evaluated. A syntax or
semantic error in any of these expressions MUST cause the
assertion to be omitted from processing.
If a write-back environment block causes an exception (either
through a division by zero or through invalid use of one of the
"$(str)," "@(str)," or "&str" constructs), the expressions is
considered false. For example, the expression set
expression1 -> { expression11 -> {a=1/0, return something}
expression12 -> {a=1, return somethingelse}
}
(assuming all three expressions are true) MUST return
"somethingelse." An exception is also raised if the same
write-back attribute is used twice in the same block.
The return values MUST be checked (case-insensitive) for validity.
If a value is invalid, the assertion MUST be omitted from processing.
For the write-back expressions (which are of the form "expression =
expression"), the left subexpression MUST evaluate to a string.
The result MUST be treated as the name of an attribute in the
write-back environment. All attribute lookups made in the process
of constructing the left subexpression string MUST be made among
the Local-Init and action-environment attributes. All attribute
lookups made in the process of constructing the right subexpression
(which can be a string, integer, or floating point expression) are
made among the Local-Init and action-environment attributes.
KeyNote expires in six months [Page 11]
DRAFT KeyNote August 1998
The write-back set constructed, is associated with the return value
for the purposes of Licensees evaluation (see section 3.4).
4. Action Environments
Trusted actions to be evaluated by KeyNote are described by a
collection of attribute/value pairs called the Action Environment.
An action environment is passed to the KeyNote system as part of
each query and provides the values of the attributes used by
assertion predicates.
The action environment specifies a collection of values of named
attributes. The attributes may be examined as attributes by KeyNote
trust predicates.
The exact format for specifying an action environment is determined
by the particular KeyNote implementation. In general, an
environment may be thought of as a list of assignments to
attributes:
ATTRIBUTE1=VALUE1
ATTRIBUTE2=VALUE2
...
If an action-environment attribute is not defined, it MUST
evaluate to the empty string (if accessed as a string) or the
value zero (if accessed as an integer or a float).
An attribute that is accessed as an integer (by prepending the "@"
character) or as a float (through the "&" character) MUST consist
entirely of digits and at most one period. In both cases if the
attribute contains any illegal character, the resulting value MUST
be zero.
The attribute "$Action_Authorizers," MAY hold the keys that have
signed the request. This attribute lists the action authorizers
keys (see section 5).
The names of all other attributes in the action environment are not
specified by KeyNote but must be agreed upon by the writers of any
policies and credentials that are to cooperate in a KeyNote query
evaluation. By convention, the name of the application domain in
which environment attributes should be interpreted is specified in
the attribute App_Domain. The IANA will provide a registry of
reserved App_Domain names with the names and meanings of the
attributes they use. Note that an attribute with a particular name
may have different meanings in different application domains. Note
that the use of the registry is optional; a policy or credential
may depend on any attribute names used by the credentials to which
trust is deferred.
KeyNote expires in six months [Page 12]
DRAFT KeyNote August 1998
For example, an email application might reserve the App_Domain
"RFC822-EMAIL" and might use the following attributes:
$Address (the email address of a message's sender)
$Name (the human name of the message sender)
$Organization (the organization name).
The values of these attributes may be derived in the obvious way
from the email message headers.
Note that RFC822-EMAIL is simply 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
suggests.)
5. Action Authorizers
The keys that authenticate (sign) a request (i.e., the keys that
have signed a message whose trustworthiness KeyNote is evaluating)
are placed in an implementation-dependent data structure. Lookups
are made in that data structure to match keys in the Licensees
of an assertion and keys in the data structure, during the
Licensees parse process (section 3.4). Those comparisons are in
key-canonical form (as defined by the algorithm name of the key).
For logical tags or unsupported algorithms, case-sensitive string
comparison is used instead (see section 3.4).
6. KeyNote Action Evaluation
This section describes the semantics of KeyNote action evaluation.
An implementation is free to use any algorithm that provides
equivalent semantics.
Initialization:
The attribute $App_Domain is assigned the name of the
application (e.g., "RFC822-EMAIL").
The keys that sign the request for a trusted action are placed
in the implementation-dependent action authorizers data structure.
The rest of the action-environment attributes are placed in their
respective attributes.
The time of day MAY be placed in the attributes $GMTTimeOfDay and
$LocalTimeOfDay, using the format YYYYMMDDHHMMSS (e.g.,
19980307191512).
Any other implementation-dependent attributes and their bindings
KeyNote expires in six months [Page 13]
DRAFT KeyNote August 1998
are also created at this step.
For each KeyNote assertion passed to the evaluation engine, the
following steps are taken:
The Conditions expression is evaluated. If the result is
the lowest value, then the result of this assertion evaluation
is the lowest value.
Otherwise, the key expression in the Licensees field is
evaluated, and the resulting value of this assertion is the
lower of the values of its Conditions and its
Licensees expressions. The write-back set of this assertion
is the combination of:
- The write-back set of this assertion's Conditions (if
any)
- The write-back set that is the result of this assertion's
Licensees, after all the write-back attributes that are
not exported (through the Export field, see section 3.7) by
this assertion are removed.
The Licensees write-back set writes over the Conditions
write-back set.
The Licensees field public-key expression is evaluated as
follows:
Let the key expression contain public key PK_i. A variable `PK_i'
corresponds to this key.
If there is no assertion in which PK_i is the Authorizer, and PK_i
does not appear in the action authorizers, the value of the
variable `PK_i' is the lowest return value.
If PK_i appears in the action authorizers, the value of the
variable `PK_i' is the highest return value.
If PK_i appears in the Authorizer field of an assertion, the value
of the variable 'PK_i' is that of the assertion. If there is more
than one assertions where PK_i is the Authorizer, `PK_i' takes the
highest value among those assertions.
The goal is to construct a directed graph of KeyNote assertions
rooted at a POLICY assertion of the evaluator that connects with
at least one of the keys in the action authorizers. The value
returned to the application (and the associated write-back set) is
that of the highest-valued POLICY assertion.
Delegation of some authorization from key A to a set of keys B is
expressed as an assertion with key A in the Authorizer field, key set
KeyNote expires in six months [Page 14]
DRAFT KeyNote August 1998
B in the Licensees field, and the authorization delegated
encoded in the Conditions field. How the expression digraph is
constructed is implementation-dependent, in particular because
different implementations may use different algorithms for
optimizing the graph construction.
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 than that 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 evaluator will
determine, based on policy and credential assertions, whether a
proposed action is permitted according to policy. The usefulness
of this determination depends on a number of factors:
- The action-environment attributes and the assignment of their
values must reflect accurately the security requirements of the
application. Identifying the attributes to include in the action
environment 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 keys and for
predicates that should, in fact, be trusted by the application.
- Finally, KeyNote does not directly enforce policy; it only
provides advice to the applications that call it. KeyNote assumes
that the application itself is trusted and that the policy
assertions are correct. Nothing prevents an application from
submitting misleading assertions to KeyNote, or from ignoring
KeyNote altogether.
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 that even if inappropriate
credentials are provided to KeyNote, this cannot result in the
approval of an illegal action environment (as long as the policy
assertions are correct and the the action environment itself is
correctly passed to KeyNote).
KeyNote is monotonic; adding an assertion to a query can never
KeyNote expires in six months [Page 15]
DRAFT KeyNote August 1998
result in a query being rejected if it would have been accepted
without the assertion. Omitting credentials may, of course, result
in legal action environments being disallowed. Selecting
appropriate credentials (e.g., from a distributed database or "key
server") is outside the scope of KeyNote itself, and may properly
be handled by the remote client making a request, by the local
machine verifying 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 draft 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 the simplest, a KeyNote evaluator
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
This draft discusses a trust-management system The draft is itself
concerned with a security mechanism.
9. 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 draft.
References
[BFL96] M. Blaze, J. Feigenbaum, J. Lacy, Decentralized Trust
Management, 1996 IEEE Conference on Privacy and Security,
Oakland, 1996.
[BFS98] M. Blaze, J. Feigenbaum, M. Strauss, Compliance-Checking in
the PolicyMaker Trust-Management System, 1998 Financial
Crypto Conference
[Bra97] S. Bradner, Key words for use in RFCs to Indicate
Requirement Level, RFC 2119, March 1997.
KeyNote expires in six months [Page 16]
DRAFT KeyNote August 1998
[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.
[RSA78] A Method for Obtaining Digital Signatures and Public-Key
Cryptosystems, R. L. Rivest, A. Shamir, L. M. Adleman,
Communications of the ACM, v21n2, February 1978.
Contacts
Comments about this document should be discussed on the
trustmgt@east.isi.edu mailing list. The archive for that list can
be found at http://www.cairn.net/trustmgt/
Questions about this document can also be directed to:
Matt Blaze Joan Feigenbaum John Ioannidis
mab@research.att.com jf@research.att.com ji@research.att.com
AT&T Labs - Research
180 Park Avenue
Florham Park, New Jersey 07932-0000
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
KeyNote expires in six months [Page 17]
