idnits 2.17.1 draft-blaze-trustmgt-keynote-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([Bra97]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 943 has weird spacing: '...att.com jf@r...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1998) is 9386 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'BFL96' -- Possible downref: Non-RFC (?) normative reference: ref. 'BFS98' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSA94' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS1' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA78' Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Trust Management Working Group Matt Blaze 3 Internet Draft Joan Feigenbaum 4 expires in six months Angelos D. Keromytis 5 John Ioannidis 6 August 1998 8 The KeyNote Trust-Management System 9 draft-blaze-trustmgt-keynote-00.txt (A) 11 Status of this Memo 13 This document is an Internet-Draft. Internet Drafts are working doc- 14 uments of the Internet Engineering Task Force (IETF), its Areas, and 15 its Working Groups. Note that other groups may also distribute work- 16 ing documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months, and may be updated, replaced, or obsoleted by other documents 20 at any time. It is not appropriate to use Internet Drafts as refer- 21 ence material, or to cite them other than as a ``working draft'' or 22 ``work in progress.'' 24 To view the entire list of current Internet-Drafts, please check 25 the "1id-abstracts.txt" listing contained in the Internet-Drafts 26 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 27 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 28 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 29 (US West Coast). 31 Distribution of this memo is unlimited. 33 Abstract 35 This memo describes KeyNote, a simple trust-management system. It 36 outlines the syntax and semantics of KeyNote credentials, describes 37 action environment processing, and describes the application 38 architecture into which a KeyNote implementation would fit. 40 Terminology 42 The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," 43 "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this 44 document are to be interpreted as described in [Bra97]. 46 1. Introduction 48 This memo describes KeyNote, a simple trust-management system. 49 Trust management, introduced in the PolicyMaker system [BFL96], is 50 a unified approach to specifying and interpreting security 51 policies, credentials, and relationships that allows direct 53 DRAFT KeyNote August 1998 55 authorization of security-critical actions. In particular, a 56 trust-management system combines the notion of specifying security 57 policy with the mechanism for specifying security credentials 58 (subsuming the role of "certificates"). Credentials describe a 59 specific delegation of trust among public keys; unlike traditional 60 certificates, which bind keys to names, trust-management credentials 61 bind keys to the authorization to perform specific tasks. 63 KeyNote provides a simple notation for specifying both local security 64 policies and security credentials that can be sent over an untrusted 65 network. Policies and credentials, called "assertions", contain 66 predicates that describe the trusted actions permitted by the holders 67 of specific public keys. A signed assertion that can be sent over an 68 untrusted network is also called a Credential Assertion. Credential 69 assertions, which serve the role of "certificates," have the same 70 syntax as policy assertions but are also signed by the entity 71 delegating the trust. 73 In this document we assume that applications communicate with a 74 "KeyNote evaluator" that interprets KeyNote assertions and returns 75 results to applications. However, different hosts and environments 76 may provide a variety of interfaces to the KeyNote evaluator and 77 this document does not aim to specify a KeyNote API. 79 A KeyNote evaluator accepts as input a set of local policy and 80 credential assertions, and a set of attributes, called an "action 81 environment," that describes a proposed trusted action associated 82 with a set of public keys. The KeyNote evaluator determines whether 83 proposed actions are consistent with local policy by applying the 84 assertion predicates to the action environment. The KeyNote 85 evaluator can return values other than simply true and false, 86 depending on the application and the action-environment definition. 87 Furthermore, KeyNote assertions can return additional information 88 (such as arguments) to the invoking application. 90 2. KeyNote Syntax 92 The version of KeyNote assertions described in this document is 1. 93 All KeyNote assertions are encoded in ASCII strings. Four mandatory 94 fields MUST appear in all assertions (KeyNote-Version, Authorizer, 95 Licensees, and Conditions); these fields describe who authorizes 96 whom under what conditions. Four optional fields MAY appear (Export, 97 Comment, Signature, and Local-Init). 99 All fields MUST start at the beginning of a line; fields may be 100 continued by indenting with at least one SPACE or TAB character at 101 the beginning of the line. Whitespace separates tokens but is 102 otherwise ignored outside of quoted strings. (Our grammars below 103 omit whitespace processing in the interest of readability.) All 104 name tokens are case-insensitive. 106 DRAFT KeyNote August 1998 108 In the following sections, the notation [X]* means zero or more 109 repetitions of the string X. The notation [X]+ means one or more 110 repetitions of the string X. 112 A complete sample assertion is shown below. The meaning of the 113 various fields is explained in the following sections. 115 KeyNote-Version: 1 116 Authorizer: rsa-pkcs1-hex:deaf 117 Licensees: dsa-hex:feeddead || rsa-pkcs1-hex:cafe 118 Export: Attr1, Attr2 119 Local-Init: localattribute = "xxx" 120 Comment: Your average credential assertion 121 Conditions: $foo == "bar" -> {write1 = "yes", return true} 122 Signature: rsa-md5-pkcs1-hex:f00f 124 2.1 Key Encoding 126 Keys in KeyNote credential assertions are encoded as 128 AlgorithmName:Encoding 130 AlgorithmName is a case-insensitive ASCII string that describes 131 the key type (e.g., RSA [RSA78] or DSA [DSA94]), encoding (e.g., 132 PKCS1 [PKCS1]), and string encoding (e.g., HEX or BASE64). 133 AlgorithmName is given by [a-zA-Z][a-zA-Z0-9_-]* 134 The IANA will provide a registry of reserved AlgorithmName names. 136 Encoding is ([a-zA-Z0-9][a-zA-Z0-9_]*)|(\"(([^\"\n])|(\\[.\n]))*\") 137 and its format depends on AlgorithmName. Hex-encoded keys SHOULD 138 use lower-case digits. Encoding can can occupy more than one line 139 by using the "+" string concatenation operator. 141 Note that the keys used in examples in this document are fictitious 142 and generally shorter than would be required for security. 144 2.2 Attributes 146 Attributes in KeyNote are denoted by $AttrName in any of the 147 Authorizer, Licensees, and Conditions fields. Whenever an attribute 148 is encountered, a lookup MUST be made in the Local-Init 149 definitions. If that fails, for the Authorizer and Licensees fields 150 this results in the empty string. In the Conditions, a subsequent 151 lookup in the action environment must be made. (For more details on 152 the action environment, see section 4.) If that fails to match as 153 well, the result is the empty string. In case of a match, the 154 corresponding value is the result, in string form. 156 In the Conditions, attributes can also be denoted by @AttrName and 157 &AttrName. These cause the resulting value to be an integer or a 158 floating point number respectively. If $AttrName contains 159 characters other than whitespace, decimal digits and a 161 DRAFT KeyNote August 1998 163 single '.' character, the resulting value MUST be zero. @AttrName 164 is equivalent to floor(&AttrName). 166 2.3 Key Comparisons 168 Key comparisons inside KeyNote (performed while trying to match 169 keys in Authorizer and Licensees or the action authorizers (see 170 section 5) should be between canonical forms of the keys. Every 171 algorithm used in KeyNote should define some method for converting 172 keys to this canonical form, and how the comparison for equality of 173 two keys is performed. If the algorithm is unknown or unsupported, 174 the implementation SHOULD do a case-sensitive string comparison, 175 for comparisons between keys in a Licensees and the action 176 authorizers (since a key that the application knows about but the 177 KeyNote implementation does not, may appear in the action 178 authorizers). Comparisons involving a key in the Authorizer field 179 MUST be between canonical forms, unless the assertion is localy 180 trusted (case-sensitive string comparison is used in that case). 182 2.4 Return Values 184 Some applications may use KeyNote in a form in which an assertion 185 evaluates to one of two values (true/false). However, KeyNote 186 supports more than two values (the number of supported values, as 187 well as the values themselves, SHOULD be a runtime option set by the 188 invoking application). The set of all possible return values should 189 be a totally ordered one. The return values are the possible values 190 both Licensees and Conditions can take after they have been 191 evaluated. 193 The KeyNote system will attempt to return the highest possible value 194 from a query using the evaluation rules described in the following 195 sections (in particular, section 6). The meaning and interpretation 196 of these values is application-dependent, and should be defined along 197 with the rest of action-environment details (see section 4). 199 2.5 Write-Back Environment 201 In addition to returning a non-boolean value to the invoking 202 application, KeyNote assertions can also pass back some additional 203 information through a write-back environment mechanism. Assertions 204 can not lookup information in this write-back environment. The 205 rules of how a write-back attribute is propagated back to the 206 invoking application are given in section 3.4. Section 3.8 contains 207 some additional information on scoping. 209 In some cases, two write-back sets of attributes will be "combined" 210 (section 3.4) using a non-reflective operation: an ordering of the 211 two write-back sets is defined, and the resulting write-back set is 212 the union of the two sets. Write-back attributes common to both 213 sets will have their values inherited from the second write-back 214 set. In that sense, the second write-back set writes over the first. 216 DRAFT KeyNote August 1998 218 3. KeyNote Field Meanings 220 The following sections explain the contents and meaning of the 221 various fields that can appear in a KeyNote assertion. 223 3.1 The KeyNote-Version field 225 The KeyNote-Version field is of the form 227 KeyNote-Version: VersionNumber 229 where VersionNumber is an ASCII-encoded decimal number. The 230 current version is 1. This field MUST be the first field appearing 231 in a KeyNote assertion. 233 3.2 The Local-Init field 235 This field initializes action-environment attributes that are 236 specific to this assertion only. A typical use for this field is 237 to assign keys to logical names, so that the Licensees 238 field is more readable. This field is of the form 240 Local-Init: Name = ConstantString [, Name = ConstantString]* 242 Name is an identifier that can be used as an attribute (see section 243 2.2) in the Conditions, Authorizer, and Licensees fields instead 244 of the string ConstantString. If the Local-Init field defines more 245 than one identifier, it can occupy more than one line and be 246 indented. ConstantString is given by STRING in section 3.8, and 247 can also be composed by concatenating smaller strings using the 248 "+" operator (see the examples) and can thus occupy more than one 249 line. If an initialization identifier is accessed but has not been 250 defined, it should evaluate to the empty string (or zero, if it was 251 accessed as a numeric value). 253 When an initialization identifier is accessed in an Conditions 254 expression, it shadows the value of any existing action-environment 255 identifier, for this assertion only (see section 2.2). If an 256 identifier appears more than once in the Local-Init field, the 257 assertion MUST be considered invalid and omitted from processing by 258 the evaluator. 260 3.3 The Authorizer field 262 The Authorizer field is of the form 264 Authorizer: KEY 266 where KEY is a key encoded as described in section 2.1. The 267 Authorizer field can also be a logical tag, of the form 269 Authorizer: SomeString 271 DRAFT KeyNote August 1998 273 for assertions that are trusted directly by the local environment 274 and thus do not require cryptographic verification. SomeString is 275 given by STRING in section 3.8, or can be a concatenation of smaller 276 strings, using the '+' operator. Tag comparisons are 277 case-sensitive. Finally, the Authorizer field can be of the form 279 Authorizer: $Attribute 281 where Attribute is a Local-Init identifier (see section 2.2). If 282 the Attribute does not exist in the Local-Init identifiers, the 283 assertion MUST be omitted from processing. The result is treated 284 as a key (see section 2.1) for comparison purposes. 286 A valid input to the KeyNote evaluator MUST contain at least one 287 Policy assertion (in which the authorizer field is the keyword 288 "POLICY", case-insensitive), which will serve as the "root" of a 289 trust structure that authorizes a requested action. 291 3.4 The Licensees field 293 The Licensees field describes who is being authorized by the 294 Authorizer. This field is of the form 296 Licensees: Key-Expr 298 Key-Expr is given by the following grammar: 300 Key-Expr: (Key-Expr) | 301 Key-Expr && Key-Expr | 302 Key-Expr || Key-Expr | 303 K-of(KeyList) | /* Threshold */ 304 STRING | 305 KEY | 306 $STRING 308 KeyList: KEY | 309 ATTRIBUTE | 310 STRING | 311 KEY, KeyList | 312 ATTRIBUTE, KeyList | 313 STRING, KeyList 315 STRING: (([a-zA-Z][a-zA-Z0-9_-]*) | (\" (([^\"\n])|(\\[.\n]))* \")) 316 ATTRIBUTE: "$"[a-zA-Z0-9][a-zA-Z0-9_]* 318 The "&&" operator has higher precedence than the "||" operator. 319 "K" is an ASCII-encoded decimal number. A KeyList SHOULD contain 320 at least K keys. 322 Only identifiers that appear in the Local-Init can be used as 323 attributes in Licensees (see section 2.2). An attribute is 324 resolved to a string, which is then treated as a key or logical 326 DRAFT KeyNote August 1998 328 tag. STRING can also be a quoted string, and/or a concatenation 329 of smaller strings using the '+' operator. 331 The keys, attributes, or logical tags that appear in the Licensees 332 and the various expressions are treated as variables for the 333 purpose of evaluation. The values these variables take are: 335 - If a key, attribute, or logical tag appears in the action 336 authorizers (see section 5), its value is the highest possible. 337 The empty write-back set is associated with it. 339 - Otherwise, if the key, attribute, or logical tag appears in the 340 Authorizer field of one or more assertions, the value it takes 341 is the higher value of those assertions, and the associated 342 write-back set. If more than one assertion shares the highest 343 possible value, the write-back set of one is picked arbitrarily. 344 Which one is picked is implementation-dependent and may be 345 non-deterministic. 347 - Otherwise, the value of the key, attribute, or logical tag is 348 the lowest possible. The empty write-back set is associated 349 with it. 351 If the Key-Expr field is empty, it always evaluates to the highest 352 possible value (which is set by the application), and is used for 353 direct authorization of an Conditions by a policy or a credential. 355 The semantics of the various key expressions are: 357 - An "(..)" expression has the value of the enclosed subexpression. 358 It also inherits the write-back set from the enclosing 359 subexpression. 361 - An "&&" expression has the lower of its two subexpression 362 values. The resulting write-back set is the combination of the 363 write-back sets of the two subexpressions, where the lower-value 364 write-back set writes over variables that appear in the 365 higher-value write-back set. For example, let 367 Licensees: Key1 && Key2 369 Key1's value is "value1" 370 Key2's value is "value2" 371 'value1' is higher than 'value2' in the linear order of 372 return values 373 Key1's write-back set is "str1=val1, str2=val2" 374 Key2's write-back set is "str1=val3, str4=val4" 376 Then the resulting value will be "value2," and the write-back set 377 will be "str1=val3, str2=val2, str4=val4." 379 If both subexpressions have the same value, then the left 381 DRAFT KeyNote August 1998 383 subexpression's write-back set writes over the right 384 subexpression's write-back set. In the above setup, the resulting 385 write-back set if the two keys had the same value would be 386 "str1=val1, str2=val2, str4=val4" 388 - An "||" expression has the higher of its two subexpression 389 values. The resulting write-back set is that associated with the 390 returned value. In case of a tie, the left subexpression's 391 write-back set is the resulting write-back set. 393 - A "K-OF(...)" expression has the K-th highest value of those among 394 the KEYs and logical tags enclosed, counting multiplicity. That 395 is, if K = 3 and the values are (0, 1, 2, 2, 3), the value of the 396 threshold is 2. 398 The resulting write-back set is the combination of the write-back 399 sets associated with the K highest values in the list, with the 400 higher write-back sets writing over lower write-back sets. If more 401 than K keys share the K highest values, the leftmost K (as they 402 appear in the keylist) are used. For example, if K = 3 and the 403 values are (0, 1, 2, 2, 3), the resulting write-back set will be 404 that of the right-most '2', written-over by the write-back set of 405 the '2' on its left, and the result written-over by the write-back 406 set of the '3'. 408 Notice that in the case of two values (true/false), the above rules 409 of value resolution reduce to boolean logic. 411 3.5 The Signature field 413 The Signature field is of the form 415 Signature: AlgorithmName:Encoding 417 AlgorithmName is a case-insensitive ASCII string that indicates 418 the signature type and encoding (e.g., RSA-MD5-PKCS1-BASE64). 419 AlgorithmName is given by [a-zA-Z][a-zA-Z0-9_-]* 420 The IANA will provide a registry of reserved AlgorithmName names. 422 Encoding contains the signature encoded according to AlgorithmName. 423 Encoding is given by STRING, in section 3.8, and can occupy more 424 than one lines by using the '+' string concatenation operator. 425 Hex-encoded signatures SHOULD use lower-case hex digits. The 426 AlgorithmName here is not the same, but generally is related to 427 the AlgorithmName of the key that appears in the Authorizer field. 429 The signature is computed over the assertion, beginning at the 430 KeyNote-Version field (including the keyword), up to (and 431 including) the Signature field (the colon following the keyword is 432 also included), concatenated with the AlgorithmName field (trailing 433 colon included). This field MUST be last in a KeyNote assertion. 435 DRAFT KeyNote August 1998 437 Note that the Signatures used in examples in this document are 438 fictitious and generally shorter than would be required for security. 440 3.6 The Comment field 442 The Comment field is of the form 444 Comment: .* 446 The interpretation of this field is application-dependent. 448 3.7 The Export field 450 The Export field is of the form 452 Export: Keyword [, KeyWord]* 454 where Keyword is given by [a-zA-Z][a-zA-Z0-9_-]* 456 This field contains a list of write-back environment attributes 457 that this assertion is willing to export to its descendants. 458 If this field is present but empty, it is taken to mean "All 459 write-back environment attributes are exported." If it is missing, 460 no write-back environment attribute is exported. See section 2.5 461 for more details on write-back environments. See section 6 on how 462 the Export field is used in conjunction with write-back 463 environments. Keyword may also be a quoted string, and/or the 464 concatenation of smaller strings using the '+' operator. 466 3.8 The Conditions field 468 The Conditions field describes what the Authorizer authorizes 469 the key(s) appearing in Licensees to do. This field is of the 470 form 472 Conditions: Program 474 where Program is given by the following grammar: 476 Program: /* Nothing */ 477 | Program2 479 Program2: Expr -> { RecProgram2 } 480 | Expr -> { RecProgram2 } Program2 482 RecProgram2: Program2 483 | AssignmentList 485 AssignmentList: "return" STRING /* Case insensitive "return" */ 486 | Str = Str , AssignmentList /* WriteBack */ 487 | Str = NumEx , AssignmentList /* WriteBack */ 488 | Str = FloatEx, AssignmentList /* WriteBack */ 490 DRAFT KeyNote August 1998 492 Expr: ( Expr ) | /* Parentheses */ 493 Expr && Expr | /* Logical AND */ 494 Expr || Expr | /* Logical OR */ 495 !Expr | /* Logical NOT */ 496 NumExpr | /* Integer boolean expression */ 497 FloatExpr | /* Floating point boolean expression */ 498 StringExpr | /* String boolean expression */ 499 "true" | /* Case insensitive keyword */ 500 "false" /* Case insensitive keyword */ 502 NumExpr: NumEx == NumEx | /* Integer expression comparisons */ 503 NumEx != NumEx | 504 NumEx < NumEx | 505 NumEx > NumEx | 506 NumEx <= NumEx | 507 NumEx >= NumEx | 509 FloatExpr: FloatEx < FloatEx | /* Floating point */ 510 FloatEx > FloatEx | 511 FloatEx <= FloatEx | 512 FloatEx >= FloatEx 514 StringExpr: Str == Str | /* String equality */ 515 Str != Str | /* String inequality */ 516 Str < Str | /* Alphanumeric comparisons */ 517 Str > Str | 518 Str <= Str | 519 Str >= Str | 520 Str ~= RegExp /* Regular expression matching */ 522 Str: Str + Str | /* String concatenation */ 523 Str . Str | /* Also string concatenation */ 524 STRING | /* Quoted or otherwise */ 525 ATTRIBUTE | /* Lookup in Local-Init and action environment */ 526 $( Str ) /* Dynamic resolution */ 528 NumEx: NumEx + NumEx | /* Integer operations */ 529 NumEx - NumEx | 530 NumEx * NumEx | 531 NumEx / NumEx | 532 NumEx % NumEx | 533 NumEx ^ NumEx | /* Exponentiation */ 534 -NumEx | 535 ( NumEx ) | 536 NUMBER | 537 NUMATTRIBUTE | 538 @( Str ) /* Dynamic resolution */ 540 FloatEx: FloatEx + FloatEx | /* Floating point operations */ 541 FloatEx - FloatEx | 542 FloatEx * FloatEx | 543 FloatEx / FloatEx | 545 DRAFT KeyNote August 1998 547 FloatEx ^ FloatEx | /* Exponentiation */ 548 -FloatEx | 549 ( FloatEx ) | 550 FLOAT | 551 FLOATATTRIBUTE | 552 &( Str ) /* Dynamic resolution */ 554 NUMBER: [0-9]+ 555 FLOAT: {NUMBER} . {NUMBER} 556 STRING: (([a-zA-Z][a-zA-Z0-9_-]*) | (\" (([^\"\n])|(\\[.\n]))* \")) 557 VSTRING: [a-zA-Z0-9][a-zA-Z0-9_]* 558 ATTRIBUTE: $VSTRING 559 NUMATTRIBUTE: @VSTRING 560 FLOATATTRIBUTE: &VSTRING 562 The binary numeric operation precedence is (higher to lower) ^, 563 (*, /, %), (+, -). Operators of equal precedence are evaluated 564 left-to-right. 566 Single-backslash ("\") and quote elimination must be performed on 567 quoted strings (e.g., "\ac" becomes ac). 569 String operations (including regexps) in the Conditions can be 570 case-sensitive or case-insensitive, specified as a run-time option. 572 A division (or modulo) by zero causes the enclosing boolean 573 expression to evaluate to the lowest value. 575 The keywords `true', `false', and `return' have special meaning 576 only in those grammar rules they are included. They can be used as 577 variable names or strings anywhere else in the Conditions. 579 The "$(str)" construct causes a lookup of the string ``str'' in the 580 Local-Init attributes (and if that fails to find a match, in the 581 action-environment attributes). If ``str'' evaluates to the empty 582 string, the enclosing boolean expression MUST evaluate to false. 583 Similarly for the "@(str)" and "&(str)" constructs. 585 RegExpr refers to the POSIX 1003.2 regular expression syntax and 586 semantics. A regular expression is true if the left hand string 587 expression matches RegExpr. If group matching is used, the number 588 of groups matched MUST be placed in the temporary attribute $0, and 589 the subsequent matches should be placed in the temporary attributes 590 $1, $2, ..., $($0). These values should be discarded when a 591 subsequent regular expression is encountered, or if the current 592 expression does not evaluate to true. If an invalid RegExpr is 593 encountered, the assertion MUST be omitted from processing. 595 If an Conditions field is empty, it always evaluates to the 596 highest possible return value. If no expressions match, the value 597 of this assertion is the lowest value, and there is no associated 598 write-back set. 600 DRAFT KeyNote August 1998 602 More than one expressions can exist in an Conditions. The 603 semantics then are that the first expression that evaluates to true, 604 returns a value and a write environment. 606 Furthermore, expressions can be nested, using the "-> { ... }" 607 construct. Consequently, an expression can be viewed as a series of 608 boolean expressions that lead to a write-back environment/return 609 value. The first such expression where all the boolean expressions 610 are true ``fires''. As an example, consider the Conditions 611 with the following expressions: 613 expression1 -> { expression11 -> {return somevalue} 614 expression12 -> {return someothervalue} 615 } 617 expression2 -> { expression21 -> {return somethirdvalue} } 619 expression3 -> {return justavalue} 621 If expression1 and expression11 are true, then the returned value 622 will be "somevalue." If expression1 is true, expression11 is false, 623 and expression12 is true, "someothervalue" will be returned. If 624 expression1 if false, or both expression11 and expression12 are 625 false, the following expressions will be evaluated. A syntax or 626 semantic error in any of these expressions MUST cause the 627 assertion to be omitted from processing. 629 If a write-back environment block causes an exception (either 630 through a division by zero or through invalid use of one of the 631 "$(str)," "@(str)," or "&str" constructs), the expressions is 632 considered false. For example, the expression set 634 expression1 -> { expression11 -> {a=1/0, return something} 635 expression12 -> {a=1, return somethingelse} 636 } 638 (assuming all three expressions are true) MUST return 639 "somethingelse." An exception is also raised if the same 640 write-back attribute is used twice in the same block. 642 The return values MUST be checked (case-insensitive) for validity. 643 If a value is invalid, the assertion MUST be omitted from processing. 645 For the write-back expressions (which are of the form "expression = 646 expression"), the left subexpression MUST evaluate to a string. 647 The result MUST be treated as the name of an attribute in the 648 write-back environment. All attribute lookups made in the process 649 of constructing the left subexpression string MUST be made among 650 the Local-Init and action-environment attributes. All attribute 651 lookups made in the process of constructing the right subexpression 652 (which can be a string, integer, or floating point expression) are 653 made among the Local-Init and action-environment attributes. 655 DRAFT KeyNote August 1998 657 The write-back set constructed, is associated with the return value 658 for the purposes of Licensees evaluation (see section 3.4). 660 4. Action Environments 662 Trusted actions to be evaluated by KeyNote are described by a 663 collection of attribute/value pairs called the Action Environment. 664 An action environment is passed to the KeyNote system as part of 665 each query and provides the values of the attributes used by 666 assertion predicates. 668 The action environment specifies a collection of values of named 669 attributes. The attributes may be examined as attributes by KeyNote 670 trust predicates. 672 The exact format for specifying an action environment is determined 673 by the particular KeyNote implementation. In general, an 674 environment may be thought of as a list of assignments to 675 attributes: 677 ATTRIBUTE1=VALUE1 678 ATTRIBUTE2=VALUE2 679 ... 681 If an action-environment attribute is not defined, it MUST 682 evaluate to the empty string (if accessed as a string) or the 683 value zero (if accessed as an integer or a float). 685 An attribute that is accessed as an integer (by prepending the "@" 686 character) or as a float (through the "&" character) MUST consist 687 entirely of digits and at most one period. In both cases if the 688 attribute contains any illegal character, the resulting value MUST 689 be zero. 691 The attribute "$Action_Authorizers," MAY hold the keys that have 692 signed the request. This attribute lists the action authorizers 693 keys (see section 5). 695 The names of all other attributes in the action environment are not 696 specified by KeyNote but must be agreed upon by the writers of any 697 policies and credentials that are to cooperate in a KeyNote query 698 evaluation. By convention, the name of the application domain in 699 which environment attributes should be interpreted is specified in 700 the attribute App_Domain. The IANA will provide a registry of 701 reserved App_Domain names with the names and meanings of the 702 attributes they use. Note that an attribute with a particular name 703 may have different meanings in different application domains. Note 704 that the use of the registry is optional; a policy or credential 705 may depend on any attribute names used by the credentials to which 706 trust is deferred. 708 DRAFT KeyNote August 1998 710 For example, an email application might reserve the App_Domain 711 "RFC822-EMAIL" and might use the following attributes: 713 $Address (the email address of a message's sender) 714 $Name (the human name of the message sender) 715 $Organization (the organization name). 717 The values of these attributes may be derived in the obvious way 718 from the email message headers. 720 Note that RFC822-EMAIL is simply a hypothetical example; such a 721 name may or may not appear in the actual registry with these or 722 different attributes. (Indeed, we recognize that the reality of 723 email security is considerably more complex than this example 724 suggests.) 726 5. Action Authorizers 728 The keys that authenticate (sign) a request (i.e., the keys that 729 have signed a message whose trustworthiness KeyNote is evaluating) 730 are placed in an implementation-dependent data structure. Lookups 731 are made in that data structure to match keys in the Licensees 732 of an assertion and keys in the data structure, during the 733 Licensees parse process (section 3.4). Those comparisons are in 734 key-canonical form (as defined by the algorithm name of the key). 735 For logical tags or unsupported algorithms, case-sensitive string 736 comparison is used instead (see section 3.4). 738 6. KeyNote Action Evaluation 740 This section describes the semantics of KeyNote action evaluation. 741 An implementation is free to use any algorithm that provides 742 equivalent semantics. 744 Initialization: 746 The attribute $App_Domain is assigned the name of the 747 application (e.g., "RFC822-EMAIL"). 749 The keys that sign the request for a trusted action are placed 750 in the implementation-dependent action authorizers data structure. 752 The rest of the action-environment attributes are placed in their 753 respective attributes. 755 The time of day MAY be placed in the attributes $GMTTimeOfDay and 756 $LocalTimeOfDay, using the format YYYYMMDDHHMMSS (e.g., 757 19980307191512). 759 Any other implementation-dependent attributes and their bindings 761 DRAFT KeyNote August 1998 763 are also created at this step. 765 For each KeyNote assertion passed to the evaluation engine, the 766 following steps are taken: 768 The Conditions expression is evaluated. If the result is 769 the lowest value, then the result of this assertion evaluation 770 is the lowest value. 772 Otherwise, the key expression in the Licensees field is 773 evaluated, and the resulting value of this assertion is the 774 lower of the values of its Conditions and its 775 Licensees expressions. The write-back set of this assertion 776 is the combination of: 778 - The write-back set of this assertion's Conditions (if 779 any) 781 - The write-back set that is the result of this assertion's 782 Licensees, after all the write-back attributes that are 783 not exported (through the Export field, see section 3.7) by 784 this assertion are removed. 786 The Licensees write-back set writes over the Conditions 787 write-back set. 789 The Licensees field public-key expression is evaluated as 790 follows: 792 Let the key expression contain public key PK_i. A variable `PK_i' 793 corresponds to this key. 795 If there is no assertion in which PK_i is the Authorizer, and PK_i 796 does not appear in the action authorizers, the value of the 797 variable `PK_i' is the lowest return value. 799 If PK_i appears in the action authorizers, the value of the 800 variable `PK_i' is the highest return value. 802 If PK_i appears in the Authorizer field of an assertion, the value 803 of the variable 'PK_i' is that of the assertion. If there is more 804 than one assertions where PK_i is the Authorizer, `PK_i' takes the 805 highest value among those assertions. 807 The goal is to construct a directed graph of KeyNote assertions 808 rooted at a POLICY assertion of the evaluator that connects with 809 at least one of the keys in the action authorizers. The value 810 returned to the application (and the associated write-back set) is 811 that of the highest-valued POLICY assertion. 813 Delegation of some authorization from key A to a set of keys B is 814 expressed as an assertion with key A in the Authorizer field, key set 816 DRAFT KeyNote August 1998 818 B in the Licensees field, and the authorization delegated 819 encoded in the Conditions field. How the expression digraph is 820 constructed is implementation-dependent, in particular because 821 different implementations may use different algorithms for 822 optimizing the graph construction. 824 7. Trust-Management Architecture 826 KeyNote provides a simple mechanism for describing security policy 827 and representing credentials. It differs from traditional 828 certification systems in that the security model is based on 829 binding keys to predicates that describe what the key is authorized 830 by policy to do, rather than on resolving names. The 831 infrastructure and architecture to support a KeyNote system is 832 therefore rather different than that for a name-based certification 833 scheme. The KeyNote trust-management architecture is based on that 834 of PolicyMaker [BFL96,BFS98]. 836 It is important to understand the separation between the 837 responsibilities of the KeyNote system and those of the application 838 and other support infrastructure. A KeyNote evaluator will 839 determine, based on policy and credential assertions, whether a 840 proposed action is permitted according to policy. The usefulness 841 of this determination depends on a number of factors: 843 - The action-environment attributes and the assignment of their 844 values must reflect accurately the security requirements of the 845 application. Identifying the attributes to include in the action 846 environment is perhaps the most important task in integrating 847 KeyNote into new applications. 849 - The policy of the application must be correct and well-formed. 850 In particular, trust must be deferred only to keys and for 851 predicates that should, in fact, be trusted by the application. 853 - Finally, KeyNote does not directly enforce policy; it only 854 provides advice to the applications that call it. KeyNote assumes 855 that the application itself is trusted and that the policy 856 assertions are correct. Nothing prevents an application from 857 submitting misleading assertions to KeyNote, or from ignoring 858 KeyNote altogether. 860 It is also up to the application (or some service outside KeyNote) 861 to select the appropriate credentials and policy assertions with 862 which to run a particular query. Note that even if inappropriate 863 credentials are provided to KeyNote, this cannot result in the 864 approval of an illegal action environment (as long as the policy 865 assertions are correct and the the action environment itself is 866 correctly passed to KeyNote). 868 KeyNote is monotonic; adding an assertion to a query can never 870 DRAFT KeyNote August 1998 872 result in a query being rejected if it would have been accepted 873 without the assertion. Omitting credentials may, of course, result 874 in legal action environments being disallowed. Selecting 875 appropriate credentials (e.g., from a distributed database or "key 876 server") is outside the scope of KeyNote itself, and may properly 877 be handled by the remote client making a request, by the local 878 machine verifying the request, or by a network-based service, 879 depending on the application. 881 In addition, KeyNote does not itself provide credential revocation 882 services, although credentials can be written to expire after some 883 date by including a date test in the predicate. Applications that 884 require credential revocation can use KeyNote to help specify and 885 implement revocation policies. A future draft will address 886 expiration and revocation services in KeyNote. 888 Because KeyNote is designed to support a variety of applications, 889 several different application interfaces to a KeyNote 890 implementation are possible. In the simplest, a KeyNote evaluator 891 would exist as a stand-alone application, with other applications 892 calling it as needed. KeyNote might also be implemented as a 893 library to which applications are linked. Finally, a KeyNote 894 implementation might run as a local trusted service, with local 895 applications communicating their queries via some interprocess 896 communication mechanism. 898 8. Security Considerations 900 This draft discusses a trust-management system The draft is itself 901 concerned with a security mechanism. 903 9. Acknowledgments 905 We thank Lorrie Faith Cranor (AT&T Labs - Research) and Jonathan M. 906 Smith (University of Pennsylvania) for their suggestions and 907 comments on earlier versions of this draft. 909 References 911 [BFL96] M. Blaze, J. Feigenbaum, J. Lacy, Decentralized Trust 912 Management, 1996 IEEE Conference on Privacy and Security, 913 Oakland, 1996. 915 [BFS98] M. Blaze, J. Feigenbaum, M. Strauss, Compliance-Checking in 916 the PolicyMaker Trust-Management System, 1998 Financial 917 Crypto Conference 919 [Bra97] S. Bradner, Key words for use in RFCs to Indicate 920 Requirement Level, RFC 2119, March 1997. 922 DRAFT KeyNote August 1998 924 [DSA94] Digital Signature Standard, FIPS-186, National Institute of 925 Standards, U.S. Department of Commerce, May 1994. 927 [PKCS1] PKCS #1: RSA Encryption Standard, Version 1.5, RSA 928 Laboratories, November 1993. 930 [RSA78] A Method for Obtaining Digital Signatures and Public-Key 931 Cryptosystems, R. L. Rivest, A. Shamir, L. M. Adleman, 932 Communications of the ACM, v21n2, February 1978. 934 Contacts 936 Comments about this document should be discussed on the 937 trustmgt@east.isi.edu mailing list. The archive for that list can 938 be found at http://www.cairn.net/trustmgt/ 940 Questions about this document can also be directed to: 942 Matt Blaze Joan Feigenbaum John Ioannidis 943 mab@research.att.com jf@research.att.com ji@research.att.com 945 AT&T Labs - Research 946 180 Park Avenue 947 Florham Park, New Jersey 07932-0000 949 Angelos D. Keromytis 950 Distributed Systems Lab 951 CIS Department, University of Pennsylvania 952 200 S. 33rd Street 953 Philadelphia, Pennsylvania 19104-6389 954 Email: angelos@dsl.cis.upenn.edu