idnits 2.17.1 draft-hedberg-spocp-sexp-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 164: '...ment in the list MUST be an atom (stri...' RFC 2119 keyword, line 336: '... MUST have different tags. This rest...' RFC 2119 keyword, line 469: '...singleton ranges MUST be replaced by (...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (January 2004) is 7379 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 892 -- Looks like a reference, but probably isn't: '1' on line 242 == Missing Reference: 'N' is mentioned on line 242, but not defined == Missing Reference: 'M' is mentioned on line 242, but not defined == Unused Reference: 'RFC1738' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'RFC2252' is defined on line 647, but no explicit reference was found in the text == Unused Reference: 'RFC2253' is defined on line 651, but no explicit reference was found in the text == Unused Reference: 'RFC2904' is defined on line 666, but no explicit reference was found in the text == Unused Reference: 'RFC3339' is defined on line 671, but no explicit reference was found in the text == Unused Reference: 'SDSI' is defined on line 674, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 2828 (Obsoleted by RFC 4949) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2253 (Obsoleted by RFC 4510, RFC 4514) ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Downref: Normative reference to an Experimental RFC: RFC 2693 ** Downref: Normative reference to an Informational RFC: RFC 2904 -- Possible downref: Non-RFC (?) normative reference: ref. 'SDSI' Summary: 13 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Hedberg 2 Internet-Draft Stockholm University 3 Expires: July 1, 2004 O. Bandmann 4 L4i 5 January 2004 7 Restricted S-expressions for use in a generalized authorization 8 service 9 draft-hedberg-spocp-sexp-00 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on July 1, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Table of Contents 39 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 3 40 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 41 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5 42 4. Problems with Access Control Lists . . . . . . . . . . . . . 6 43 5. Restricted S-expressions for authorization . . . . . . . . . 7 44 5.1 Simple S-expressions . . . . . . . . . . . . . . . . . . . . 7 45 5.2 Basic theory . . . . . . . . . . . . . . . . . . . . . . . . 8 46 5.3 Star forms . . . . . . . . . . . . . . . . . . . . . . . . . 9 47 5.3.1 The wildcard star form . . . . . . . . . . . . . . . . . . . 10 48 5.3.2 The set star form . . . . . . . . . . . . . . . . . . . . . 10 49 5.3.3 The range star form . . . . . . . . . . . . . . . . . . . . 11 50 5.3.4 The prefix star form . . . . . . . . . . . . . . . . . . . . 13 51 5.3.5 The suffix star form . . . . . . . . . . . . . . . . . . . . 14 52 6. S-expression comparison . . . . . . . . . . . . . . . . . . 15 53 7. Security considerations . . . . . . . . . . . . . . . . . . 17 54 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 18 55 References . . . . . . . . . . . . . . . . . . . . . . . . . 19 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 57 A. Collected Grammar . . . . . . . . . . . . . . . . . . . . . 21 58 B. Representing hierarchies . . . . . . . . . . . . . . . . . . 23 59 C. Representing Security Connection . . . . . . . . . . . . . . 26 60 Intellectual Property and Copyright Statements . . . . . . . 27 62 1. Abstract 64 This document describes restricted S-expressions as they are used for 65 storing and querying for access rights within the SPOCP (Simple 66 POlicy Control Protocol) project. We describe the restrictions we 67 have made to basic S-expressions and also the theory that allows us 68 to use S-expressions in a policy engine. 70 2. Introduction 72 The aim of the SPOCP project is to first develop a model for a 73 generalized authorization service server and then to implement such a 74 server. Generalized in this context means that it shall be equally 75 good in supporting several different types of applications and that 76 one and the same server shall be able to simultaneously support 77 several applications. 79 To achieve this goal we needed to design a policy engine that could 80 evaluate policies without knowing what applications the policies 81 referred to. The first step towards this goal was to pick a rule 82 syntax that was independent of the applications, and we think we have 83 found such a syntax in S-expressions [s-expression]. 85 The goal of this document is to describe how S-expressions can be 86 used in a generalized authorization service, and what restrictions we 87 have applied to S-expressions to make them really useful. 89 The two companion documents [spocp_prot] and [spocp_prot_tcp] 90 describes the Simple Policy Control Protocol and one implementation 91 of it. 93 The terms used in this draft is defined in [RFC2828]. 95 3. Background 97 S-expressions is not something new on the Internet arena, "The Simple 98 Public Key Infrastructure" (SPKI) working group within the IETF, 99 based its work on S-expressions. They also made restrictions on the 100 syntax of the S-expressions (See for instance [RFC2693]), something 101 we have built on in our work. 103 In contrast to the SPKI work we are not dealing with certificates but 104 have instead concentrated on using S-expressions as a policy language 105 syntax. A language suitable to express both access policies and 106 queries for permissions. 108 The differences between restricted S-expressions as defined by SPKI 109 and the restrcited S-expressions defined in this document are slight 110 but significant. They can be enumerated as: 112 1. We have added a companion to prefix called suffix 114 2. We do not distinguish between ALPHA and BINARY, there are treated 115 as one and the same 117 3. We have added the restriction that all lists in a set construct 118 have to have different tags 120 An important change is that we have replaced the AIntersect operation 121 with a partial order (pre-order, strictly speaking) compatible with 122 AIntersect. In order to guarantee completeness of the decision 123 algorithm described in section 6, the restriction in item 4 above is 124 needed (cf. [spki_authz]). 126 4. Problems with Access Control Lists 128 There are several problems with ACLs as they are normally used in 129 applications, that disappear if access control is based on policy 130 articulated in S-expressions. We list some of these problems below 131 and explain how they can be handled in a authorization policy written 132 using S-expressions. 134 1. The identity of future clients has to be known 136 An application that wants to use S-expressions for 137 authorization decisions, has a template for S-expression 138 construction. Whether a token representing the identity of the 139 client is part of that template or not, is a local matter and 140 irrelevant to the use of S-expressions. Hence neither the 141 application nor the authorization system needs to know the 142 identity of the client. 144 2. ACLs are static 146 When constructing the rules, you might not know or care about 147 who will fulfill the restrictions when an access right is 148 requested. Even if a rule appears to be static, the set of 149 persons and/or entities that fulfills the restrictions might 150 be highly dynamic. 152 3. The application has to have all the information necessary for 153 making the access decision. 155 It is not a problem if the application does not have access to 156 all the necessary information, as long as the Spocp server, or 157 an application it can use, has. 159 5. Restricted S-expressions for authorization 161 5.1 Simple S-expressions 163 A simple S-expression is a nested list enclosed in matching "(" and 164 ")". The first element in the list MUST be an atom (string) and is 165 the "tag" or "name" of the object represented by the list. With that 166 exception, every element in the list may in turn be a S-expression. 167 Note that empty lists are not allowed. 169 As in SPKI, we have chosen Rivest's compact "canonical form", see 170 [s-expression], as our internal representation of an S-expression. 172 A complete description of restricted S-expressions using ABNF 173 [RFC2234] is given in Appendix A . 175 S-expressions are used at the core in the authorization server, and 176 may be sent from a client to a server. If they are, the canonical 177 form is to be used [s-expression]. A canonical S-expression is formed 178 from octet strings (that is every octet can assume any byte value 179 between and including 0x00 and 0xFF), each prefixed by its length. 180 The length of a byte string is a non-negative ASCII decimal number, 181 with no leading "0" digits, terminated by ":". The canonical form is 182 a unique representation of an S-expression and is used as the input 183 to all hash and signature functions. 185 s-expr = "(" tag *s-part ")" 187 tag = octet-string 189 s-part = octet-string / s-expr / star-form 191 octet-string = decimal ":" 1*octet ; The number of octets should 192 be equal to the decimal specification 194 decimal = nzdigit *digit 196 nzdigit = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" 198 digit = "0" / nzdigit 200 octet = %x00-FF 202 star-form = "(1:*" [ set / range / prefix / suffix ] ")" 204 The specification of the star forms can be found in Section 5.3. 206 *Note:* Even though the canonical form is the one described by the 207 ABNF definition, the so called advanced form will be used in the 208 examples in this document since it is much easier for humans to read. 210 Example: 212 (5:spocp(8:Resource6:mailer)) -- canonical form 214 (spocp (Resource mailer)) -- advanced form 216 These are two representations of the same S-expression, consisting of 217 an octet string (the tag) "spocp" and another S-expression, that 218 consists of two octet strings "Resource" and "mailer". 220 5.2 Basic theory 222 In order to be able to use S-expressions for authorization, two 223 criteria have to be fulfilled. THe first is that S-expressions must 224 have the expressive power needed for conveniently stating an 225 authorization policy. Our practical experience has convinced us that 226 this criterion is satisfied, The other thing needed is the definition 227 of a binary relation '<=', that can be used to order S-expressions. 229 We want a relation where A '<=' B means that rule A is less 230 permissive than rule B. Once the relation is defined, we also need an 231 efficient way to decide (compute) if A '<=' B. A decision algorithm 232 for restricted S-expressions is given in Section 6 We begin by 233 defining '<=' for simple S-expressions; in the next subsection, '<=' 234 will be extended to general restricted S-expressions. 236 In [spki_authz] '<=' has been defined inductively as follows: Let x 237 and y be simple S-expressions then 239 1. if x and y are simple 'atomic' elements (strings) then x '<=' y 240 if and only if x = y. 242 2. If x = (x[0] x[1] ... x[N]) and y = (y[0] y[1] ... y[M] ), then x 243 '<=' y if and only if N >= M and x[i] '<=' y[i], for i = 0, ..., 244 M 246 Example 1, If, 248 x = (http (page index.html)(action GET)(user olav)) 250 then x is intended to represent the authorization to the user olav to 251 read ( in HTTP terms GET ) the page index.html using HTTP. 253 Let 254 y = (http (page index.html)(action GET)(user)) 256 Then y means almost the same as x except for the fact that the 257 permission to read index.html is given to any user. By definition x 258 '<=' y. Furthermore, if 260 z = (http (page index.html)(action)(user olav)) 262 then z means almost the same as x except for the fact that now Olav 263 can perform any operation on index.html that HTTP supports. Note 264 that y and z are unrelated with respect to the partial order '<='. 266 From the example above it should be obvious that the application 267 generating these S-expressions has restrictions on the format of 268 them, restrictions that correspond to the desired semantics. It is 269 essential to the idea of a centralized authorization service that 270 this semantic does not require a modification of the '<=' relation. 272 The intended use of S-expressions for authorization evaluation is as 273 follows. Assume that a certain principal P wants to perform an action 274 A requiring the authorization X. Then P has the authorization for A 275 if and only if P has the some authorization Y satisfying X '<=' Y. 277 More about partial ordering in Section 6, we have to introduce you to 278 star forms first. 280 So by the use of S-expressions, and the partial order we get an 281 important benefit: we can build an authorization system that works 282 independently of what the policies actually mean. 284 5.3 Star forms 286 To extend simple S-expressions to restricted S-expressions we have to 287 add a new type of element: star forms. These can be divided into the 288 following categories: 290 wildcard 292 set 294 range 296 prefix 298 suffix 300 Despite their list-like apearence (see below), starforms are not 301 lists. They are succinct ways of representing every element that fits 302 into a specific set. Hence, restricted S-expressions (simple 303 S-expressions extended with star forms) really represent _sets_ of 304 simple S-expressions. 306 In order to preserve the intended semantics for the ordering '<=' 307 (from the previous subsection), the only possible way to extend this 308 relation to _sets_ of simple S-expressions, is to define: 310 X '<=' Y if and only if every simple S-expression A in X is bounded 311 by some simple S-expression B in Y (i.e. A '<=' B in the sense of 312 previous subsection) 314 An algorithm for effective computation of this relation is given in 315 section 6 (cf. [spki_authz]). 317 5.3.1 The wildcard star form 319 Is written '(*)' and matches any single octet string or s-expression. 321 5.3.2 The set star form 323 Described by the ABNF 325 set = "3:set" 1*s-expr 327 They are a way of specifying a limited set of elements, a group. 329 Example: 331 (* set apple orange lemon) 333 The important difference between this star form 'set' and the one in 334 SPKI ([RFC2693]), is that here, 'set' is restricted in the following 335 way: all lists appearing at the top level in a 'set'-construction 336 MUST have different tags. This restriction implies completeness of 337 the algorithm for computation of '<=' presented in Section 6. The 338 following is an example of a valid restricted S-expression: 340 (t (* set (a x) (b (a y)) (c) a) a) 342 and this one is not: 344 (t (* set (a (x y)) (b c) (a d))) 346 Furthermore, to simplify and streamline the algorithm description in 347 Section 6, we will also make the trivial restriction on the set star 348 form, that a set is not permitted to contain a set as a top level 349 element. E.g. 351 (* set (* set x y) z ) 353 can not be part of a restricted S-expression. While, on the other 354 hand, 356 (* set x y z ) 358 can. Immediately nested sets can always be eliminated in this fashion 359 (without changing the semantics). Note that deeper nestings (i.e. 360 within lists) are permitted. E.g. 362 (* set (x (* set y z)) t) 364 can be part of a restricted S-expression. 366 5.3.3 The range star form 368 Since one needs to know the type when one deals with ranges, there 369 are a couple of types predefined. 371 alpha: which is normal text 373 numeric: non-negative numbers between 0 and 4294967295 (UINT32_MAX) 375 date: date specification of the form YYYY-MM-DD_HH:MM:SS or using the 376 notation used by strftime %G:%m:%d_%H:%M:%S 378 time: time of day specification HH:MM:SS 380 ipv4: the IPv4 address in the normal dot notation format 382 ipv6: IPv6 address in their normal notation 384 In the specification of a range you may use constants in these types 385 in combination with relational operators in a straight forward way. 386 The ABNF specification for range is: 388 rangespec = alpha / numeric / date / time / ipv4 / ipv6 390 alpha = "5:alpha" [lole utf8string [goge utf8string]] / 391 [goge utf8string [lole utf8string]] 393 numeric = "7:numeric" [ lole number [ goge number ]] / [ 394 goge number [ lole number ]] 396 date = "4:date" [ goge dat [ lole dat ]] / [ lole dat [ 397 goge dat ]] 398 time = "4:time" [ lole hms [ goge hms ]] / [ goge hms [ 399 lole hms ]] 401 ipv4 = "4:ipv4" [ lole ipnum [ goge ipnum ]] / [ goge 402 ipnum [lole ipnum ]] 404 ipv6 = "4:ipv6" [ lole ip6num [ goge ip6num ]] / [ goge 405 ip6num [lole ip6num ]] 407 lole = "2:lt" / "2:le" 409 goge = "2:gt" / "2:ge" 411 number = decimal ":" 1*digit 413 dat = decimal ":" date-time ; date format as 414 specified by RFC3339 416 date-fullyear = 4DIGIT 418 date-month = 2DIGIT ; 01-12 420 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 dependent on 421 month/year 423 time-hour = 2DIGIT ; 00-23 425 time-minute = 2DIGIT ; 00-59 427 time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap 428 second rules 430 time-secfrac = "." 1*DIGIT 432 time-numoffset = ("+" / "-") time-hour ":" time-minute 434 time-offset = "Z" / time-numoffset 436 partial-time = time-hour ":" time-minute ":" time-second 438 full-date = date-fullyear "-" date-month "-" date-mday 440 full-time = partial-time time-offset 442 date-time = full-date "T" full-time 444 hms = decimal ":" partial-time 445 ipnum = decimal ":" 1*3digit "." 1*3digit "." 1*3digit 446 "." 1*3digit 448 ip6num = IPv6address ; as defined in [RFC2373] 450 utf8string = decimal ":" 1*UTF8 452 UTF8 = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 / UTF8-3 / 453 UTF8-4 / UTF8-5 / UTF8-6 455 UTF8-1 = %x80-BF 457 UTF8-2 = %xC0-DF UTF8-1 459 UTF8-3 = %xE0-EF 2UTF8-1 461 UTF8-4 = %xF0-F7 3UTF8-1 463 UTF8-5 = %xF8-FB 4UTF8-1 465 UTF8-6 = %xFC-FD 5UTF8-1 467 Finally, note that there is the extra requirement (compared to SPKI) 468 that a range star form always must contain at least two elements. In 469 other words, redundant singleton ranges MUST be replaced by (single) 470 atoms. 472 Example 474 (worktime (* range time ge 08:00:00 le 17:00:00)) 476 or 478 (* range numeric l 15 ge 10) 480 which is the same as 482 (* set 10 11 12 13 14) 484 If in a date specification, time-offset is not 'Z' but a 485 time-numoffset the equivalent date without time-numoffset must be 486 calculated before the value is used. "2002-12-31T23:59:59+01" must be 487 transform to "2003-01-01T00:59:59" before usage. 489 5.3.4 The prefix star form 491 Used to represent sets of strings that all have the same prefix ABNF: 493 prefix = "6:prefix" utf8string 495 Example 497 (file (* prefix conf)) 499 This expression will match any expression with the tag "file", whose 500 second element is an octet string that starts with the string "conf". 502 5.3.5 The suffix star form 504 Used to represent sets of strings that all have the same suffix 506 ABNF: 508 suffix = "6:suffix" utf8string 510 Example 512 (file (* suffix pdf)) 514 This expression will match any expression with the tag "file", whose 515 second element is an octet string that ends with the string "pdf". 517 6. S-expression comparison 519 In this section we present an effective algorithm ( from 520 [spki_authz]) to decide the other relation '<=' defined in Section 521 5.2 and Section 5.3. 523 Recall the definition of '<=' for simple S-expressions from Section 524 5.2: 526 For two octet strings A and B, A '<=' B if and only if A == B 528 If S and T are lists, then S '<=' T if S has at least as many 529 elements as T and every element in S is '<=' the corresponding 530 element in T (if S has more elements than T, just ignore the extra 531 elements in S). 533 Example: 535 (fruit apple large red) '<=' (fruit apple) 537 (fruit apple (size large) red) '<=' (fruit apple (size) red) 539 and these are not '<=' 541 (fruit apple large red) compared to (fruit apple (large) red) 543 (fruit apple large red) compared to (fruit apple red large) 545 order is absolutely vital 547 (apple (weight 100)(color red)) is not '<=' (apple (color 548 red)(weight 100)) 550 Thus, in the case of simple S-expressions the definition of '<=' 551 immediately gives us an algorithm. For general restricted 552 S-expressions the following recursive procedure gives us an 553 algorithm. Before the algorithm can be applied, however, the 554 restricted S-expressions which are to be compared need to be 555 normalized. 557 To normalize an element of a restricted S-expression means that in 558 each set star form, ranges of the same type and atoms are joined 559 together in single ranges, whenever possible. E.g. 561 (* set 44 (* range numeric ge 4 le 8) 11 (* range numeric ge 6 le 562 10)) 564 normalizes to 565 (* set (* range numeric ge 4 le 11) 44) 567 The "normal form" is obviously not syntactically unique (even though 568 it is semantically unique), but further reductions should not be 569 possible. 571 After normalization, the algorithm proceeds as follows. If any of the 572 nine cases below applies, the comparison returns true, otherwise it 573 returns false. 575 S '<=' T, when S and T are normalized elements of S-expressions, if: 577 1. T = (*) 579 2. S and T are strings and S == T 581 3. S is a string and T is a set, range, suffix or prefix star form 582 that contains S 584 4. S and T are range-forms where T contains S 586 5. S and T are prefix-forms where T contains S 588 6. S and T are suffix-forms where T contains S 590 7. S = (X[0] ... X[m]), T = (Y[0] ... Y[n]) n <= m and X[i] '<=' 591 Y[i] for i = 0,...,n 593 8. S = (* set X[0] ... X[m]) and X[i] '<=' T for all i=0,..,m 595 9. T = (* set Y[0] ... Y[n]) and S '<=' Y[i] for some i=0,..,n 597 Strictly speaking, there are a few other (trivial) pathological cases 598 to deal with, see [spki_authz]. In particular, here we have made the 599 simplifying assumption that range and prefix/suffix star forms are 600 incomparable w.r.t. '<='. 602 Finally, a proof of soundness and completeness for this algorithm, 603 when applied to restricted S-expressions, can also be found in 604 [spki_authz]. 606 7. Security considerations 608 Authorization decisions obviously have an immediate impact on 609 security. Concerning the choice of S-expressions as a syntax for 610 representing access policies, the only real security concern, on this 611 level, is whether using S-expressions in some way, is inherently 612 insecure. On a theoretical level it has been shown (see [spki_authz]) 613 that the algorithm to decide the '<=' relation on restricted 614 S-expressions is both sound (never falsely claims that the relation 615 holds) and complete (whenever the relation holds, the algorithm 616 returns 'true'). 618 8. Acknowledgment 620 This work originated at at the Swedish Institute of Computer Science 621 (SICS). Babak Sadighi had the original thoughts on management of 622 rigths, Olav Bandmann brought S-expressions into the process and 623 together with Mads Dam he did the mathematical evaluation of the less 624 permissive relationship between S-expressions. 626 The Spocp project is funded by SUNET (The Swedish University 627 Network), UNINETT ( The Norwegian University Network), the 628 universities in Ume�, Uppsala, Stockholm and Lund, The Karolinska 629 Intitute and the NyA project. 631 Torbj�rn Wiberg is the project leader for the Spocp project and has 632 been very active in the project work. Leif Johansson and Ola 633 Gustafsson has been heavily involved in the technical development of 634 the project. 636 References 638 [RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform 639 Resource Locators (URL)", RFC 1738, December 1994. 641 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May 642 2000. 644 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 645 Specifications: ABNF", RFC 2234, November 1997. 647 [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, 648 "Lightweight Directory Access Protocol (v3): Attribute 649 Syntax Definitions", RFC 2252, December 1997. 651 [RFC2253] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory 652 Access Protocol (v3): UTF-8 String Representation of 653 Distinguished Names", RFC 2253, December 1997. 655 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 656 Architecture", RFC 2373, July 1998. 658 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, 659 B. and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 660 September 1999. 662 [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher 663 Suites to Transport Layer Security (TLS)", RFC 2712, 664 October 1999. 666 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 667 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. 668 Spence, "AAA Authorization Framework", RFC 2904, August 669 2000. 671 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 672 Timestamps", RFC 3339, July 2002. 674 [SDSI] Rivest, R. and B. Lampson, "SDSI - A Simple Distributed 675 Security Infrastructure", . 678 [sexp_code] 679 Rivest, R., "code and description of S-expressions", 680 . 682 [s-expression] 683 Rivest, R., "S-Expressions", ID draft-rivest-sexp-00.txt, 684 May 1997, . 686 [spocp_prot] 687 Hedberg, R., "The Simple Policy Protocol". 689 [spocp_prot_tcp] 690 Hedberg, R., "The Simple Policy Control Protocol over TCP/ 691 IP". 693 [spki_authz] 694 Bandmann, O. and M. Dam, "A Note On SPKI's Authorisation 695 syntax", . 697 Authors' Addresses 699 Roland Hedberg 700 Stockholm University 701 Kasamark 114 702 Umea 90586 703 Sweden 705 Phone: +46 90 147275 706 EMail: roland@it.su.se 708 Olav Bandmann 709 Industrilogik L4i AB 710 Odengatan 87 711 Stockholm 11322 712 Sweden 714 EMail: olav@L4i.se 716 Appendix A. Collected Grammar 718 This appendix contains the complete ABNF [RFC2234] grammar for all 719 the syntax specified by this document. 721 By itself, however, this grammar is incomplete. It refers by name to 722 syntax rules that are defined by RFC 3339. Rather than reproduce 723 those definitions here, and risk unintentional differences between 724 the two, this document simply refers the reader to RFC 3339 for the 725 remaining definitions. 727 s-expr = "(" tag *s-part ")" 729 tag = octet-string 731 s-part = octet-string / s-expr / star-form 733 octet-string = decimal ":" 1*octet ; The number of octets must 734 be equal to the decimal specification 736 decimal = nzdigit *digit 738 nzdigit = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / 739 "9" 741 digit = "0" / nzdigit 743 octet = %x00-FF 745 star-form = "(1:*" [ set / range / prefix / suffix ] ")" 747 set = "3:set" 1*s-expr 749 range = "5:range" rangespec 751 rangespec = alpha / numeric / date / time / ipv4 / ipv6 753 alpha = "5:alpha" [lole utf8string [goge utf8string]] / 754 [goge utf8string [lole utf8string]] 756 numeric = "7:numeric" [ lole number [ goge number ]] / [ 757 goge number [ lole number ]] 759 date = "4:date" [ goge dat [ lole dat ]] / [ lole dat [ 760 goge dat ]] 762 time = "4:time" [ lole hms [ goge hms ]] / [ goge hms [ 763 lole hms ]] 764 ipv4 = "4:ipv4" [ lole ipnum [ goge ipnum ]] / [ goge 765 ipnum [lole ipnum ]] 767 ipv6 = "4:ipv6" [ lole ip6num [ goge ip6num ]] / [ goge 768 ip6num [lole ip6num ]] 770 lole = "2:lt" / "2:le" 772 goge = "2:gt" / "2:ge" 774 number = decimal ":" 1*digit 776 dat = decimal ":" date-time ; date-time format as 777 specified by RFC3339 779 hms = decimal ":" partial-time ; partial-time as 780 define by RFC3339 782 ipnum = decimal ":" 1*3digit "." 1*3digit "." 1*3digit 783 "." 1*3digit 785 ip6num = IPv6address ; as defined in [RFC2373] 787 utf8string = decimal ":" 1*UTF8 789 UTF8 = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 / UTF8-3 / 790 UTF8-4 / UTF8-5 / UTF8-6 792 UTF8-1 = %x80-BF 794 UTF8-2 = %xC0-DF UTF8-1 796 UTF8-3 = %xE0-EF 2UTF8-1 798 UTF8-4 = %xF0-F7 3UTF8-1 800 UTF8-5 = %xF8-FB 4UTF8-1 802 UTF8-6 = %xFC-FD 5UTF8-1 804 prefix = "6:prefix" utf8string 806 suffix = "6:suffix" utf8string 808 typespecific = *UTF8 810 Appendix B. Representing hierarchies 812 When we have been working with S-expression we have found it useful 813 to split queries and rules into three parts: 815 Resource The resource that someone want to use or perform some action 816 on 818 Action The action that is to be performed on the said resource 820 Subject The entity that wants to perform the action on the resource 822 In many situations your application has organised and named both 823 subjects, sctions and resources as hierarchies. If you want to take 824 full advantage of the hierarchical names in rules and queries you 825 have to study carefully how S-expressions are evaluated by the policy 826 engine. Assume that a name is represented as (name p[0] ... p[n]) 827 where p[0] is the part of the name that is closest to the root of the 828 hierarchy. Then you can represent the whole space of names below 829 p[0], by just specifying the top part of the namespace: (name p[0]). 830 Correspondingly you can represent a specific part of the namespace by 831 defining a larger part of the hierarchy (name p[0] ... p[m]), m < n. 833 But what if you would like to represent every object who has the same 834 last name p[n] ? 836 An example of when this would be is if you defined role names within 837 a organization as a concatenation of the organization name, the name 838 of all the organizational units from the top with the roletype. Like 839 this: (role o ou[0] ... ou[n] r) 841 "(role UmU Umdac boss)" would then be the rolename for the boss of 842 the organizational unit Umdac within the organization UmU. 844 Using this structure you could say (role UmU Umdac) and mean every 845 role within that organizational unit and all the organizational units 846 below. But if you said (role UmU boss ) you would refer to the boss 847 of UmU and not all the bosses within UmU. This since (role UmU umdac 848 boss) is not '<=' (role UmU boss). So adding a role type to a list of 849 O and OU's would mean exactly that role at that level in the 850 organization. 852 If you instead would define the role name to be represented as (role 853 r o ou[0] .. ou[n]), then you could address every specific roletype 854 within the organization by writing things like (role boss UmU), which 855 would then mean every 'boss' within the organization UmU. This 856 follows since (role boss UmU OU) is '<=' (role boss UmU). On the 857 other hand you could not specifically target the boss at UmU using 858 this representation. 860 One can add complexity to this by using role types that are 861 hierarchical such that the name would be (role o ou[0] ... ou[n] r[0] 862 ... r[m]) or (role r[0] ... r[m] o ou[0] ... ou[n]). By using the 863 first form you could address every role within a role hierarchy at a 864 specific place in the organization hierarchy but not in the whole 865 organization tree. Using the later role you could address one whole 866 subtree of the role hierarchy anywhere within a subtree of the 867 organizational hierarchy. 869 (role UmU admin finance) '<=' (role UmU admin) 871 (role UmU umdac admin) is not '<=' (role UmU admin) 873 and 875 (role admin UmU umdac) '<=' (role admin UmU) 877 (role admin finance UmU) is not '<=' (role admin UmU) 879 Remember that the decision of the meaning of a particular rule is 880 taken when modelling the authorisation policy for a particular 881 application. The Policy Engine does not know anything about the 882 application. It only compares queries to rules according to builtin 883 evaluation rules for restricted S-expressions, as described in this 884 document. What we are discussing in this section are the consequences 885 of choosing certain meanings of a particular S-expression, given how 886 the Policy Engine tests for the '<='-relation. These properties of 887 the Policy Engine must be fully understood by those deciding the 888 structures of rules and queries. 890 When you have two hierarchies that are linked to each other it might 891 be best to decouple them and make two lists of them, (role (org o 892 ou[0] ... ou[n])(type r[0] ... r[m])) which gives you freedome to 893 express the relationship "any role whithin a role hierarchy anywhere 894 within a organization hierarchy". 896 (role (org UmU) (type admin finance)) '<=' (role (org UmU) (type 897 admin)) 899 (role (org UmU umdac) (type admin)) '<=' (role (org UmU) (type 900 admin)) 902 There is of course nothing that prevents you from using one nameform 903 in one set of rules and another form in another as long as the 904 queries you pose to the policy engine use the appropriate one. What 905 you should make certain though is that the form you choose gives you 906 the possibility to express exactly what you are aiming for. 908 Appendix C. Representing Security Connection 910 Lots of applications uses SSL/TLS to protect the connection between a 911 client and a server. This is a good reason for specify how the 912 information about such a connection should be represented in a 913 S-expression. 915 The information present are: 917 SSL/TLS version 919 Cipher Suite used 921 SubjectDN 923 IssuerDN 925 So a plausible structure which then would describe the connection as 926 viewed from one of the partners ( either the client of the server) 927 would be: 929 (TransportLayerSec (protocolVersion ) (chipherSuite 930 ) (autname "X509" (subject ) (issuer 931 ))) 933 If X.509 certificates are in use, if instead kerberos [RFC2712] was 934 used that would only change the later part of the structure: 936 (TransportLayerSec (protocolVersion ) (chipherSuite 937 ) (autname "gss-name" (uid ) (realm ))) 939 Remembering that this connection information is about the connection 940 between a client and a application server that gives access to some 941 resource, and that the application server probably has its 942 restrictions on what kind of connections, ciphersuites and 943 clientcertificates combinations it will accept. So this is about 944 having a second opinion from the owner of the resource on which 945 combination it allows. If it is more restrictive than the application 946 server you might end up with the situation where the client gets a 947 SSL/TLS protected connection to the server but no data will flow over 948 the connection because the resource owner demands that a different 949 ciphersuite must be used. 951 Intellectual Property Statement 953 The IETF takes no position regarding the validity or scope of any 954 intellectual property or other rights that might be claimed to 955 pertain to the implementation or use of the technology described in 956 this document or the extent to which any license under such rights 957 might or might not be available; neither does it represent that it 958 has made any effort to identify any such rights. Information on the 959 IETF's procedures with respect to rights in standards-track and 960 standards-related documentation can be found in BCP-11. Copies of 961 claims of rights made available for publication and any assurances of 962 licenses to be made available, or the result of an attempt made to 963 obtain a general license or permission for the use of such 964 proprietary rights by implementors or users of this specification can 965 be obtained from the IETF Secretariat. 967 The IETF invites any interested party to bring to its attention any 968 copyrights, patents or patent applications, or other proprietary 969 rights which may cover technology that may be required to practice 970 this standard. Please address the information to the IETF Executive 971 Director. 973 Full Copyright Statement 975 Copyright (C) The Internet Society (2004). All Rights Reserved. 977 This document and translations of it may be copied and furnished to 978 others, and derivative works that comment on or otherwise explain it 979 or assist in its implementation may be prepared, copied, published 980 and distributed, in whole or in part, without restriction of any 981 kind, provided that the above copyright notice and this paragraph are 982 included on all such copies and derivative works. However, this 983 document itself may not be modified in any way, such as by removing 984 the copyright notice or references to the Internet Society or other 985 Internet organizations, except as needed for the purpose of 986 developing Internet standards in which case the procedures for 987 copyrights defined in the Internet Standards process must be 988 followed, or as required to translate it into languages other than 989 English. 991 The limited permissions granted above are perpetual and will not be 992 revoked by the Internet Society or its successors or assignees. 994 This document and the information contained herein is provided on an 995 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 996 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 997 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 998 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 999 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1001 Acknowledgment 1003 Funding for the RFC Editor function is currently provided by the 1004 Internet Society.