Network Working Group R. Hedberg Internet-Draft Stockholm University Expires: July 1, 2004 O. Bandmann L4i January 2004 Restricted S-expressions for use in a generalized authorization service draft-hedberg-spocp-sexp-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working 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 inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 1, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Hedberg & Bandmann Expires July 1, 2004 [Page 1] Internet-Draft S-expression based Authorization service January 2004 Table of Contents 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Problems with Access Control Lists . . . . . . . . . . . . . 6 5. Restricted S-expressions for authorization . . . . . . . . . 7 5.1 Simple S-expressions . . . . . . . . . . . . . . . . . . . . 7 5.2 Basic theory . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3 Star forms . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3.1 The wildcard star form . . . . . . . . . . . . . . . . . . . 10 5.3.2 The set star form . . . . . . . . . . . . . . . . . . . . . 10 5.3.3 The range star form . . . . . . . . . . . . . . . . . . . . 11 5.3.4 The prefix star form . . . . . . . . . . . . . . . . . . . . 13 5.3.5 The suffix star form . . . . . . . . . . . . . . . . . . . . 14 6. S-expression comparison . . . . . . . . . . . . . . . . . . 15 7. Security considerations . . . . . . . . . . . . . . . . . . 17 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 18 References . . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 A. Collected Grammar . . . . . . . . . . . . . . . . . . . . . 21 B. Representing hierarchies . . . . . . . . . . . . . . . . . . 23 C. Representing Security Connection . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . 27 Hedberg & Bandmann Expires July 1, 2004 [Page 2] Internet-Draft S-expression based Authorization service January 2004 1. Abstract This document describes restricted S-expressions as they are used for storing and querying for access rights within the SPOCP (Simple POlicy Control Protocol) project. We describe the restrictions we have made to basic S-expressions and also the theory that allows us to use S-expressions in a policy engine. Hedberg & Bandmann Expires July 1, 2004 [Page 3] Internet-Draft S-expression based Authorization service January 2004 2. Introduction The aim of the SPOCP project is to first develop a model for a generalized authorization service server and then to implement such a server. Generalized in this context means that it shall be equally good in supporting several different types of applications and that one and the same server shall be able to simultaneously support several applications. To achieve this goal we needed to design a policy engine that could evaluate policies without knowing what applications the policies referred to. The first step towards this goal was to pick a rule syntax that was independent of the applications, and we think we have found such a syntax in S-expressions [s-expression]. The goal of this document is to describe how S-expressions can be used in a generalized authorization service, and what restrictions we have applied to S-expressions to make them really useful. The two companion documents [spocp_prot] and [spocp_prot_tcp] describes the Simple Policy Control Protocol and one implementation of it. The terms used in this draft is defined in [RFC2828]. Hedberg & Bandmann Expires July 1, 2004 [Page 4] Internet-Draft S-expression based Authorization service January 2004 3. Background S-expressions is not something new on the Internet arena, "The Simple Public Key Infrastructure" (SPKI) working group within the IETF, based its work on S-expressions. They also made restrictions on the syntax of the S-expressions (See for instance [RFC2693]), something we have built on in our work. In contrast to the SPKI work we are not dealing with certificates but have instead concentrated on using S-expressions as a policy language syntax. A language suitable to express both access policies and queries for permissions. The differences between restricted S-expressions as defined by SPKI and the restrcited S-expressions defined in this document are slight but significant. They can be enumerated as: 1. We have added a companion to prefix called suffix 2. We do not distinguish between ALPHA and BINARY, there are treated as one and the same 3. We have added the restriction that all lists in a set construct have to have different tags An important change is that we have replaced the AIntersect operation with a partial order (pre-order, strictly speaking) compatible with AIntersect. In order to guarantee completeness of the decision algorithm described in section 6, the restriction in item 4 above is needed (cf. [spki_authz]). Hedberg & Bandmann Expires July 1, 2004 [Page 5] Internet-Draft S-expression based Authorization service January 2004 4. Problems with Access Control Lists There are several problems with ACLs as they are normally used in applications, that disappear if access control is based on policy articulated in S-expressions. We list some of these problems below and explain how they can be handled in a authorization policy written using S-expressions. 1. The identity of future clients has to be known An application that wants to use S-expressions for authorization decisions, has a template for S-expression construction. Whether a token representing the identity of the client is part of that template or not, is a local matter and irrelevant to the use of S-expressions. Hence neither the application nor the authorization system needs to know the identity of the client. 2. ACLs are static When constructing the rules, you might not know or care about who will fulfill the restrictions when an access right is requested. Even if a rule appears to be static, the set of persons and/or entities that fulfills the restrictions might be highly dynamic. 3. The application has to have all the information necessary for making the access decision. It is not a problem if the application does not have access to all the necessary information, as long as the Spocp server, or an application it can use, has. Hedberg & Bandmann Expires July 1, 2004 [Page 6] Internet-Draft S-expression based Authorization service January 2004 5. Restricted S-expressions for authorization 5.1 Simple S-expressions A simple S-expression is a nested list enclosed in matching "(" and ")". The first element in the list MUST be an atom (string) and is the "tag" or "name" of the object represented by the list. With that exception, every element in the list may in turn be a S-expression. Note that empty lists are not allowed. As in SPKI, we have chosen Rivest's compact "canonical form", see [s-expression], as our internal representation of an S-expression. A complete description of restricted S-expressions using ABNF [RFC2234] is given in Appendix A . S-expressions are used at the core in the authorization server, and may be sent from a client to a server. If they are, the canonical form is to be used [s-expression]. A canonical S-expression is formed from octet strings (that is every octet can assume any byte value between and including 0x00 and 0xFF), each prefixed by its length. The length of a byte string is a non-negative ASCII decimal number, with no leading "0" digits, terminated by ":". The canonical form is a unique representation of an S-expression and is used as the input to all hash and signature functions. s-expr = "(" tag *s-part ")" tag = octet-string s-part = octet-string / s-expr / star-form octet-string = decimal ":" 1*octet ; The number of octets should be equal to the decimal specification decimal = nzdigit *digit nzdigit = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" digit = "0" / nzdigit octet = %x00-FF star-form = "(1:*" [ set / range / prefix / suffix ] ")" The specification of the star forms can be found in Section 5.3. *Note:* Even though the canonical form is the one described by the Hedberg & Bandmann Expires July 1, 2004 [Page 7] Internet-Draft S-expression based Authorization service January 2004 ABNF definition, the so called advanced form will be used in the examples in this document since it is much easier for humans to read. Example: (5:spocp(8:Resource6:mailer)) -- canonical form (spocp (Resource mailer)) -- advanced form These are two representations of the same S-expression, consisting of an octet string (the tag) "spocp" and another S-expression, that consists of two octet strings "Resource" and "mailer". 5.2 Basic theory In order to be able to use S-expressions for authorization, two criteria have to be fulfilled. THe first is that S-expressions must have the expressive power needed for conveniently stating an authorization policy. Our practical experience has convinced us that this criterion is satisfied, The other thing needed is the definition of a binary relation '<=', that can be used to order S-expressions. We want a relation where A '<=' B means that rule A is less permissive than rule B. Once the relation is defined, we also need an efficient way to decide (compute) if A '<=' B. A decision algorithm for restricted S-expressions is given in Section 6 We begin by defining '<=' for simple S-expressions; in the next subsection, '<=' will be extended to general restricted S-expressions. In [spki_authz] '<=' has been defined inductively as follows: Let x and y be simple S-expressions then 1. if x and y are simple 'atomic' elements (strings) then x '<=' y if and only if x = y. 2. If x = (x[0] x[1] ... x[N]) and y = (y[0] y[1] ... y[M] ), then x '<=' y if and only if N >= M and x[i] '<=' y[i], for i = 0, ..., M Example 1, If, x = (http (page index.html)(action GET)(user olav)) then x is intended to represent the authorization to the user olav to read ( in HTTP terms GET ) the page index.html using HTTP. Let Hedberg & Bandmann Expires July 1, 2004 [Page 8] Internet-Draft S-expression based Authorization service January 2004 y = (http (page index.html)(action GET)(user)) Then y means almost the same as x except for the fact that the permission to read index.html is given to any user. By definition x '<=' y. Furthermore, if z = (http (page index.html)(action)(user olav)) then z means almost the same as x except for the fact that now Olav can perform any operation on index.html that HTTP supports. Note that y and z are unrelated with respect to the partial order '<='. From the example above it should be obvious that the application generating these S-expressions has restrictions on the format of them, restrictions that correspond to the desired semantics. It is essential to the idea of a centralized authorization service that this semantic does not require a modification of the '<=' relation. The intended use of S-expressions for authorization evaluation is as follows. Assume that a certain principal P wants to perform an action A requiring the authorization X. Then P has the authorization for A if and only if P has the some authorization Y satisfying X '<=' Y. More about partial ordering in Section 6, we have to introduce you to star forms first. So by the use of S-expressions, and the partial order we get an important benefit: we can build an authorization system that works independently of what the policies actually mean. 5.3 Star forms To extend simple S-expressions to restricted S-expressions we have to add a new type of element: star forms. These can be divided into the following categories: wildcard set range prefix suffix Despite their list-like apearence (see below), starforms are not lists. They are succinct ways of representing every element that fits Hedberg & Bandmann Expires July 1, 2004 [Page 9] Internet-Draft S-expression based Authorization service January 2004 into a specific set. Hence, restricted S-expressions (simple S-expressions extended with star forms) really represent _sets_ of simple S-expressions. In order to preserve the intended semantics for the ordering '<=' (from the previous subsection), the only possible way to extend this relation to _sets_ of simple S-expressions, is to define: X '<=' Y if and only if every simple S-expression A in X is bounded by some simple S-expression B in Y (i.e. A '<=' B in the sense of previous subsection) An algorithm for effective computation of this relation is given in section 6 (cf. [spki_authz]). 5.3.1 The wildcard star form Is written '(*)' and matches any single octet string or s-expression. 5.3.2 The set star form Described by the ABNF set = "3:set" 1*s-expr They are a way of specifying a limited set of elements, a group. Example: (* set apple orange lemon) The important difference between this star form 'set' and the one in SPKI ([RFC2693]), is that here, 'set' is restricted in the following way: all lists appearing at the top level in a 'set'-construction MUST have different tags. This restriction implies completeness of the algorithm for computation of '<=' presented in Section 6. The following is an example of a valid restricted S-expression: (t (* set (a x) (b (a y)) (c) a) a) and this one is not: (t (* set (a (x y)) (b c) (a d))) Furthermore, to simplify and streamline the algorithm description in Section 6, we will also make the trivial restriction on the set star form, that a set is not permitted to contain a set as a top level element. E.g. Hedberg & Bandmann Expires July 1, 2004 [Page 10] Internet-Draft S-expression based Authorization service January 2004 (* set (* set x y) z ) can not be part of a restricted S-expression. While, on the other hand, (* set x y z ) can. Immediately nested sets can always be eliminated in this fashion (without changing the semantics). Note that deeper nestings (i.e. within lists) are permitted. E.g. (* set (x (* set y z)) t) can be part of a restricted S-expression. 5.3.3 The range star form Since one needs to know the type when one deals with ranges, there are a couple of types predefined. alpha: which is normal text numeric: non-negative numbers between 0 and 4294967295 (UINT32_MAX) date: date specification of the form YYYY-MM-DD_HH:MM:SS or using the notation used by strftime %G:%m:%d_%H:%M:%S time: time of day specification HH:MM:SS ipv4: the IPv4 address in the normal dot notation format ipv6: IPv6 address in their normal notation In the specification of a range you may use constants in these types in combination with relational operators in a straight forward way. The ABNF specification for range is: rangespec = alpha / numeric / date / time / ipv4 / ipv6 alpha = "5:alpha" [lole utf8string [goge utf8string]] / [goge utf8string [lole utf8string]] numeric = "7:numeric" [ lole number [ goge number ]] / [ goge number [ lole number ]] date = "4:date" [ goge dat [ lole dat ]] / [ lole dat [ goge dat ]] Hedberg & Bandmann Expires July 1, 2004 [Page 11] Internet-Draft S-expression based Authorization service January 2004 time = "4:time" [ lole hms [ goge hms ]] / [ goge hms [ lole hms ]] ipv4 = "4:ipv4" [ lole ipnum [ goge ipnum ]] / [ goge ipnum [lole ipnum ]] ipv6 = "4:ipv6" [ lole ip6num [ goge ip6num ]] / [ goge ip6num [lole ip6num ]] lole = "2:lt" / "2:le" goge = "2:gt" / "2:ge" number = decimal ":" 1*digit dat = decimal ":" date-time ; date format as specified by RFC3339 date-fullyear = 4DIGIT date-month = 2DIGIT ; 01-12 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 dependent on month/year time-hour = 2DIGIT ; 00-23 time-minute = 2DIGIT ; 00-59 time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second rules time-secfrac = "." 1*DIGIT time-numoffset = ("+" / "-") time-hour ":" time-minute time-offset = "Z" / time-numoffset partial-time = time-hour ":" time-minute ":" time-second full-date = date-fullyear "-" date-month "-" date-mday full-time = partial-time time-offset date-time = full-date "T" full-time hms = decimal ":" partial-time Hedberg & Bandmann Expires July 1, 2004 [Page 12] Internet-Draft S-expression based Authorization service January 2004 ipnum = decimal ":" 1*3digit "." 1*3digit "." 1*3digit "." 1*3digit ip6num = IPv6address ; as defined in [RFC2373] utf8string = decimal ":" 1*UTF8 UTF8 = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 / UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6 UTF8-1 = %x80-BF UTF8-2 = %xC0-DF UTF8-1 UTF8-3 = %xE0-EF 2UTF8-1 UTF8-4 = %xF0-F7 3UTF8-1 UTF8-5 = %xF8-FB 4UTF8-1 UTF8-6 = %xFC-FD 5UTF8-1 Finally, note that there is the extra requirement (compared to SPKI) that a range star form always must contain at least two elements. In other words, redundant singleton ranges MUST be replaced by (single) atoms. Example (worktime (* range time ge 08:00:00 le 17:00:00)) or (* range numeric l 15 ge 10) which is the same as (* set 10 11 12 13 14) If in a date specification, time-offset is not 'Z' but a time-numoffset the equivalent date without time-numoffset must be calculated before the value is used. "2002-12-31T23:59:59+01" must be transform to "2003-01-01T00:59:59" before usage. 5.3.4 The prefix star form Used to represent sets of strings that all have the same prefix ABNF: Hedberg & Bandmann Expires July 1, 2004 [Page 13] Internet-Draft S-expression based Authorization service January 2004 prefix = "6:prefix" utf8string Example (file (* prefix conf)) This expression will match any expression with the tag "file", whose second element is an octet string that starts with the string "conf". 5.3.5 The suffix star form Used to represent sets of strings that all have the same suffix ABNF: suffix = "6:suffix" utf8string Example (file (* suffix pdf)) This expression will match any expression with the tag "file", whose second element is an octet string that ends with the string "pdf". Hedberg & Bandmann Expires July 1, 2004 [Page 14] Internet-Draft S-expression based Authorization service January 2004 6. S-expression comparison In this section we present an effective algorithm ( from [spki_authz]) to decide the other relation '<=' defined in Section 5.2 and Section 5.3. Recall the definition of '<=' for simple S-expressions from Section 5.2: For two octet strings A and B, A '<=' B if and only if A == B If S and T are lists, then S '<=' T if S has at least as many elements as T and every element in S is '<=' the corresponding element in T (if S has more elements than T, just ignore the extra elements in S). Example: (fruit apple large red) '<=' (fruit apple) (fruit apple (size large) red) '<=' (fruit apple (size) red) and these are not '<=' (fruit apple large red) compared to (fruit apple (large) red) (fruit apple large red) compared to (fruit apple red large) order is absolutely vital (apple (weight 100)(color red)) is not '<=' (apple (color red)(weight 100)) Thus, in the case of simple S-expressions the definition of '<=' immediately gives us an algorithm. For general restricted S-expressions the following recursive procedure gives us an algorithm. Before the algorithm can be applied, however, the restricted S-expressions which are to be compared need to be normalized. To normalize an element of a restricted S-expression means that in each set star form, ranges of the same type and atoms are joined together in single ranges, whenever possible. E.g. (* set 44 (* range numeric ge 4 le 8) 11 (* range numeric ge 6 le 10)) normalizes to Hedberg & Bandmann Expires July 1, 2004 [Page 15] Internet-Draft S-expression based Authorization service January 2004 (* set (* range numeric ge 4 le 11) 44) The "normal form" is obviously not syntactically unique (even though it is semantically unique), but further reductions should not be possible. After normalization, the algorithm proceeds as follows. If any of the nine cases below applies, the comparison returns true, otherwise it returns false. S '<=' T, when S and T are normalized elements of S-expressions, if: 1. T = (*) 2. S and T are strings and S == T 3. S is a string and T is a set, range, suffix or prefix star form that contains S 4. S and T are range-forms where T contains S 5. S and T are prefix-forms where T contains S 6. S and T are suffix-forms where T contains S 7. S = (X[0] ... X[m]), T = (Y[0] ... Y[n]) n <= m and X[i] '<=' Y[i] for i = 0,...,n 8. S = (* set X[0] ... X[m]) and X[i] '<=' T for all i=0,..,m 9. T = (* set Y[0] ... Y[n]) and S '<=' Y[i] for some i=0,..,n Strictly speaking, there are a few other (trivial) pathological cases to deal with, see [spki_authz]. In particular, here we have made the simplifying assumption that range and prefix/suffix star forms are incomparable w.r.t. '<='. Finally, a proof of soundness and completeness for this algorithm, when applied to restricted S-expressions, can also be found in [spki_authz]. Hedberg & Bandmann Expires July 1, 2004 [Page 16] Internet-Draft S-expression based Authorization service January 2004 7. Security considerations Authorization decisions obviously have an immediate impact on security. Concerning the choice of S-expressions as a syntax for representing access policies, the only real security concern, on this level, is whether using S-expressions in some way, is inherently insecure. On a theoretical level it has been shown (see [spki_authz]) that the algorithm to decide the '<=' relation on restricted S-expressions is both sound (never falsely claims that the relation holds) and complete (whenever the relation holds, the algorithm returns 'true'). Hedberg & Bandmann Expires July 1, 2004 [Page 17] Internet-Draft S-expression based Authorization service January 2004 8. Acknowledgment This work originated at at the Swedish Institute of Computer Science (SICS). Babak Sadighi had the original thoughts on management of rigths, Olav Bandmann brought S-expressions into the process and together with Mads Dam he did the mathematical evaluation of the less permissive relationship between S-expressions. The Spocp project is funded by SUNET (The Swedish University Network), UNINETT ( The Norwegian University Network), the universities in Ume…, Uppsala, Stockholm and Lund, The Karolinska Intitute and the NyA project. Torbj÷rn Wiberg is the project leader for the Spocp project and has been very active in the project work. Leif Johansson and Ola Gustafsson has been heavily involved in the technical development of the project. Hedberg & Bandmann Expires July 1, 2004 [Page 18] Internet-Draft S-expression based Authorization service January 2004 References [RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994. [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000. [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [RFC2253] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997. [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B. and T. Ylonen, "SPKI Certificate Theory", RFC 2693, September 1999. [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, October 1999. [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Framework", RFC 2904, August 2000. [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [SDSI] Rivest, R. and B. Lampson, "SDSI - A Simple Distributed Security Infrastructure", . [sexp_code] Rivest, R., "code and description of S-expressions", . [s-expression] Rivest, R., "S-Expressions", ID draft-rivest-sexp-00.txt, Hedberg & Bandmann Expires July 1, 2004 [Page 19] Internet-Draft S-expression based Authorization service January 2004 May 1997, . [spocp_prot] Hedberg, R., "The Simple Policy Protocol". [spocp_prot_tcp] Hedberg, R., "The Simple Policy Control Protocol over TCP/ IP". [spki_authz] Bandmann, O. and M. Dam, "A Note On SPKI's Authorisation syntax", . Authors' Addresses Roland Hedberg Stockholm University Kasamark 114 Umea 90586 Sweden Phone: +46 90 147275 EMail: roland@it.su.se Olav Bandmann Industrilogik L4i AB Odengatan 87 Stockholm 11322 Sweden EMail: olav@L4i.se Hedberg & Bandmann Expires July 1, 2004 [Page 20] Internet-Draft S-expression based Authorization service January 2004 Appendix A. Collected Grammar This appendix contains the complete ABNF [RFC2234] grammar for all the syntax specified by this document. By itself, however, this grammar is incomplete. It refers by name to syntax rules that are defined by RFC 3339. Rather than reproduce those definitions here, and risk unintentional differences between the two, this document simply refers the reader to RFC 3339 for the remaining definitions. s-expr = "(" tag *s-part ")" tag = octet-string s-part = octet-string / s-expr / star-form octet-string = decimal ":" 1*octet ; The number of octets must be equal to the decimal specification decimal = nzdigit *digit nzdigit = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" digit = "0" / nzdigit octet = %x00-FF star-form = "(1:*" [ set / range / prefix / suffix ] ")" set = "3:set" 1*s-expr range = "5:range" rangespec rangespec = alpha / numeric / date / time / ipv4 / ipv6 alpha = "5:alpha" [lole utf8string [goge utf8string]] / [goge utf8string [lole utf8string]] numeric = "7:numeric" [ lole number [ goge number ]] / [ goge number [ lole number ]] date = "4:date" [ goge dat [ lole dat ]] / [ lole dat [ goge dat ]] time = "4:time" [ lole hms [ goge hms ]] / [ goge hms [ lole hms ]] Hedberg & Bandmann Expires July 1, 2004 [Page 21] Internet-Draft S-expression based Authorization service January 2004 ipv4 = "4:ipv4" [ lole ipnum [ goge ipnum ]] / [ goge ipnum [lole ipnum ]] ipv6 = "4:ipv6" [ lole ip6num [ goge ip6num ]] / [ goge ip6num [lole ip6num ]] lole = "2:lt" / "2:le" goge = "2:gt" / "2:ge" number = decimal ":" 1*digit dat = decimal ":" date-time ; date-time format as specified by RFC3339 hms = decimal ":" partial-time ; partial-time as define by RFC3339 ipnum = decimal ":" 1*3digit "." 1*3digit "." 1*3digit "." 1*3digit ip6num = IPv6address ; as defined in [RFC2373] utf8string = decimal ":" 1*UTF8 UTF8 = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 / UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6 UTF8-1 = %x80-BF UTF8-2 = %xC0-DF UTF8-1 UTF8-3 = %xE0-EF 2UTF8-1 UTF8-4 = %xF0-F7 3UTF8-1 UTF8-5 = %xF8-FB 4UTF8-1 UTF8-6 = %xFC-FD 5UTF8-1 prefix = "6:prefix" utf8string suffix = "6:suffix" utf8string typespecific = *UTF8 Hedberg & Bandmann Expires July 1, 2004 [Page 22] Internet-Draft S-expression based Authorization service January 2004 Appendix B. Representing hierarchies When we have been working with S-expression we have found it useful to split queries and rules into three parts: Resource The resource that someone want to use or perform some action on Action The action that is to be performed on the said resource Subject The entity that wants to perform the action on the resource In many situations your application has organised and named both subjects, sctions and resources as hierarchies. If you want to take full advantage of the hierarchical names in rules and queries you have to study carefully how S-expressions are evaluated by the policy engine. Assume that a name is represented as (name p[0] ... p[n]) where p[0] is the part of the name that is closest to the root of the hierarchy. Then you can represent the whole space of names below p[0], by just specifying the top part of the namespace: (name p[0]). Correspondingly you can represent a specific part of the namespace by defining a larger part of the hierarchy (name p[0] ... p[m]), m < n. But what if you would like to represent every object who has the same last name p[n] ? An example of when this would be is if you defined role names within a organization as a concatenation of the organization name, the name of all the organizational units from the top with the roletype. Like this: (role o ou[0] ... ou[n] r) "(role UmU Umdac boss)" would then be the rolename for the boss of the organizational unit Umdac within the organization UmU. Using this structure you could say (role UmU Umdac) and mean every role within that organizational unit and all the organizational units below. But if you said (role UmU boss ) you would refer to the boss of UmU and not all the bosses within UmU. This since (role UmU umdac boss) is not '<=' (role UmU boss). So adding a role type to a list of O and OU's would mean exactly that role at that level in the organization. If you instead would define the role name to be represented as (role r o ou[0] .. ou[n]), then you could address every specific roletype within the organization by writing things like (role boss UmU), which would then mean every 'boss' within the organization UmU. This follows since (role boss UmU OU) is '<=' (role boss UmU). On the other hand you could not specifically target the boss at UmU using Hedberg & Bandmann Expires July 1, 2004 [Page 23] Internet-Draft S-expression based Authorization service January 2004 this representation. One can add complexity to this by using role types that are hierarchical such that the name would be (role o ou[0] ... ou[n] r[0] ... r[m]) or (role r[0] ... r[m] o ou[0] ... ou[n]). By using the first form you could address every role within a role hierarchy at a specific place in the organization hierarchy but not in the whole organization tree. Using the later role you could address one whole subtree of the role hierarchy anywhere within a subtree of the organizational hierarchy. (role UmU admin finance) '<=' (role UmU admin) (role UmU umdac admin) is not '<=' (role UmU admin) and (role admin UmU umdac) '<=' (role admin UmU) (role admin finance UmU) is not '<=' (role admin UmU) Remember that the decision of the meaning of a particular rule is taken when modelling the authorisation policy for a particular application. The Policy Engine does not know anything about the application. It only compares queries to rules according to builtin evaluation rules for restricted S-expressions, as described in this document. What we are discussing in this section are the consequences of choosing certain meanings of a particular S-expression, given how the Policy Engine tests for the '<='-relation. These properties of the Policy Engine must be fully understood by those deciding the structures of rules and queries. When you have two hierarchies that are linked to each other it might be best to decouple them and make two lists of them, (role (org o ou[0] ... ou[n])(type r[0] ... r[m])) which gives you freedome to express the relationship "any role whithin a role hierarchy anywhere within a organization hierarchy". (role (org UmU) (type admin finance)) '<=' (role (org UmU) (type admin)) (role (org UmU umdac) (type admin)) '<=' (role (org UmU) (type admin)) There is of course nothing that prevents you from using one nameform in one set of rules and another form in another as long as the queries you pose to the policy engine use the appropriate one. What you should make certain though is that the form you choose gives you Hedberg & Bandmann Expires July 1, 2004 [Page 24] Internet-Draft S-expression based Authorization service January 2004 the possibility to express exactly what you are aiming for. Hedberg & Bandmann Expires July 1, 2004 [Page 25] Internet-Draft S-expression based Authorization service January 2004 Appendix C. Representing Security Connection Lots of applications uses SSL/TLS to protect the connection between a client and a server. This is a good reason for specify how the information about such a connection should be represented in a S-expression. The information present are: SSL/TLS version Cipher Suite used SubjectDN IssuerDN So a plausible structure which then would describe the connection as viewed from one of the partners ( either the client of the server) would be: (TransportLayerSec (protocolVersion ) (chipherSuite ) (autname "X509" (subject ) (issuer ))) If X.509 certificates are in use, if instead kerberos [RFC2712] was used that would only change the later part of the structure: (TransportLayerSec (protocolVersion ) (chipherSuite ) (autname "gss-name" (uid ) (realm ))) Remembering that this connection information is about the connection between a client and a application server that gives access to some resource, and that the application server probably has its restrictions on what kind of connections, ciphersuites and clientcertificates combinations it will accept. So this is about having a second opinion from the owner of the resource on which combination it allows. If it is more restrictive than the application server you might end up with the situation where the client gets a SSL/TLS protected connection to the server but no data will flow over the connection because the resource owner demands that a different ciphersuite must be used. Hedberg & Bandmann Expires July 1, 2004 [Page 26] Internet-Draft S-expression based Authorization service January 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Hedberg & Bandmann Expires July 1, 2004 [Page 27] Internet-Draft S-expression based Authorization service January 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hedberg & Bandmann Expires July 1, 2004 [Page 28]