CURRENT_MEETING_REPORT_ Reported by B. Clifford Neuman/Information Sciences Institute and Piers McMahon/ICL Minutes of the Authorization and Access Control Working Group (AAC) The charter, past minutes, mailing-list discussions, and other documents mentioned in these minutes are available by anonymous FTP from prospero.isi.edu in the directory /pub/aac. Agenda o Presentation of a revised list of restrictions and privilege attributes needed by applications and existing security systems, and a proposed method for representing them. o Discussion of the information maintained in the security context and where it should come from. The security context maintains information about the user that is used to make authorization decisions. o Discussion of the intended use of the authorization attributes by applications, ACL formats for an authorization API, and discussion of an API to provide a simple interface for application developers. o Discussion of guidelines for adding authorization to network accessible applications. These guidelines should be written and released initially as an Internet-Draft, and eventually as an Informational RFC. The purpose of the the initial work on a framework to represent security attributes and restrictions is to provide a uniform framework for both distributed authorization and local authorization. Local authorization will be based on access control lists. Distributed authorization will be based on proxies. Both have common elements. These elements (or attributes) may be stored on access control list entries on security servers, carried in credentials, and evaluated on the end system the same way they would be evaluated if stored on an access control list maintained by the end system itself. Presentation of a Revised List of Attributes and Restrictions At the Amsterdam IETF, there was concern that the representation of all rights conveyed by a set of credentials as restrictions on rights possessed by the grantor of those credentials was confusing. A revised framework for representing rights and restrictions on those rights was sent to the mailing list and presented at the meeting. In the Amsterdam discussion, the use of the term certificate was also confusing. The revised framework uses the term proxy which is less confusing, though more closely tied to one particular proposed implementation of the framework. In the revised framework for representing privileges, privileges are conveyed by proxies. Proxies enumerate positive rights they convey, but these rights are limited by the rights available to the principal that signed the proxy (the grantor). Some proxies specify that all rights available to the grantor are conveyed, supporting unrestricted delegation or authentication forwarding. Proxies may be further restricted to limit the rights that are conveyed. Certain restrictions require the presentation of additional proxies called endorsements before the original proxy may be used. A proxy and all required endorsements together form a proxy chain (a proxy that does not require endorsements constitutes a chain by itself). Endorsement may apply additional restrictions. The restrictions specified by each proxy in a chain are applied, resulting in a more restricted set of rights. A principal may collect multiple independent proxy chains, and the rights granted by each chain are added providing additional rights. o Attributes and Restrictions A structured set of authorization attributes are associated with each proxy. Each attribute in the set is typed, and the interpretation of the data associated with the attribute is determined by its type. Some types of attributes are specific to specific servers. A flags field associated with each kind of attribute encodes the appropriate behavior if the interpretation of the attributed is not known. The two possible behaviors are rejection of the request, or ignoring the attribute. Attributes are further divided into three classes: privilege attributes, restrictions, and aggregates. The class is also encoded in the flags field. Privilege attributes identify some operation that is permitted, or assert identifying information such as group information or user identifiers that grant additional rights to the principal that presents a proxy. Privilege attributes may be placed in a proxy only at the time it is created. They may not be added subsequently, and they may not appear in endorsements. Further, in order for a privilege attribute to apply, the principal granting the proxy must possess the ability to grant such an attribute. (Though privilege attributes grant rights, they are interpreted as explicitly enumerating the rights that are to be granted by a proxy and all other rights are presumed not to be granted by the proxy). Restrictions specifically remove rights from those conveyed by a proxy, or they place additional constraints on when, how, where, or by whom a proxy may be exercised. Restriction may be present when a proxy is initially created, they may be added subsequently and they may be present in endorsements. Restrictions that are present in a required endorsement are applied in addition to the restrictions present in the proxy that is endorsed. Aggregate attributes may be positive (privilege attributes) or negative (restrictions). The rules about where each may appear apply to aggregates as well. An aggregate attribute encapsulates a set of attributes and specifies how they are to be interpreted. One form of aggregate limits the application of a set of attributes to a particular end server or a particular application. o Discussion After the initial presentation several questions were raised. Among the questions was how one determines which principals are authorized to issue proxies granting particular rights. The end server will still have to maintain access control lists for this information, but these ACLs only contain the names of the principals that grant rights for an operation, rather than those authorized to perform the operation. Presumably this information changes less frequently, and is more compact. Checking these ACLs would be handled by the authorization API, so the client does not have to worry about it directly. The contents of this ACL might be specified by a configuration option for the local system. This check might be done when establishing a security context for a request or a login session, on the remote machine. Ted Ts'o commented that the information about the grantor of a privilege should be carried along as extra information in the security context even after verification, so that an application that has special requirements can check it. Another issue raised was concern about placing too much of the burden on the application programmer to interpret such proxies and proxy chains. In fact, the interpretation would be handled by two APIs, one of which would be specific to the distributed authorization method in use, and one would be the authorization API which was discussed later in the meeting. This latter API will take several arguments, and answer yes or no indicating whether an operation is to be allowed. o Enumeration of Attributes and Restrictions An initial set of positive and negative attributes was presented and it was discussed how they fit into the revised framework. Some of the attributes are application specific, and other application specific attributes can be defined. The positive privilege attributes can only be grated in an initial proxy and can not be added subsequently, to augment rights. In enumerating an initial set, a goal was to cover the rights needed and used by various distributed authorization mechanisms including ECMA, DCE, and restricted proxies. Among the positive attributes were: LOCAL-UID set UID for local system GROUP-MEMBERSHIP enumerate local groups to be used locally DCE-PAC globally unique groups and uuids AUTHORIZED encodes list of objects and rights for objects QUOTA like authorized, but specifies numeric limit Other suggested positive attributes include: ROLE to include rights of individual in particular role ALL which might be needed to mean all rights of grantor For the AUTHORIZED attribute, the encoding of the identified objects and the rights on those objects would be application specific, and opaque to other parts of the system. Among the negative attributes were: FOR-USE-BY-PRINCIPAL who may use a proxy, or compound principal FOR-USE-BY-GROUP only members of group may use proxy ACCEPT-N-TIMES can only be exercised N times on a given server VALID-TIME-OF-DAY e.g. can only be used between 9AM and 5PM VALID-PERIOD expires after, not good until NETMASK application specific, used by network access server FOR-USE-ON-SERVER identifies specific server where proxy is valid FOR-USE-FROM local terminal, secure area, not sure how to implement Other suggestions for negative attributes included a means to restrict the day of the week (for example, only Monday through Friday). John Linn made the observation that given that time of day is a one time decision, once logged in, one can do whatever one wants. This can be addressed if the application checks periodically, or notes the end time during the initial check and requires reauthorization at that time. It can be made easier for applications to note the end of the authorization period if an expiration time were returned as an additional value by the authorization API. Some applications would use this expiration time, while others might not. Some systems, AFS in particular, do note the expiration of credentials. Finally, though login has a one time authorization check, other operations like file accesses might not. It was also pointed out that the negative attributes did not include the ability to exclude enumerated rights. This might be useful so that one can list a broad class of positive attributes, then enumerate exceptions as negative attributes. Thus, the restriction can be added: EXCLUDE excludes list of objects and rights for objects The encoding of the objects and rights for EXCLUDE would be application specific. It was suggested that there be a way to combine positive attributes from separate proxies into a single proxy. Unfortunately, this is clearly not possible when the rights conferred are granted by different principals. When granted by a the same principal, a proxy can be granted to enumerates multiple rights. Combining them after multiple proxies have been issued, however, requires the reissuance of the combined proxy by the grantor. There was some discussion of how the attributes are related to the authorization API. This discussion appears later in the minutes. Due to the limited time for the meeting, the aggregate attributes were not discussed at the meeting, but are described in the message sent out to the mailing list. Discussion of Information Maintained in Security Context Piers McMahon noted that authorization decisions would be made on two types of application servers: 1. Servers which handle multiple requests within a single process (e.g. DCE RPC) 2. Per-request daemons (e.g.: TELNET) He concluded that the authorization security context in the authorization API must be able to refer to either a security context (for the former case) or a delegated credential (for the latter case). In order to make the authorization API simpler, he also suggested that the GSS-API gss_accept_sec_context should always return a credential which could then be used consistently to represent the authorization context (in an analogous way to the DCE login context) even if delegation was not enabled for this context. Ted Ts'o warned that this might inappropriately overload the GSS-API credential, as such non-delegated ``credentials'' could not be used to initiate contexts. In response, Piers observed that this was also true for acceptor usage credentials, and suggested that the ``usage'' of the credential could be perhaps extended to include an ``accepted security context'' type in addition to initiator and acceptor. After some further exchanges, it was agreed that further discussion on this topic should be carried on in the Common Authentication Technology Working Group (CAT). John Linn commented that it might be appropriate to add a primitive inquire_security_context, to to query information from the security context, and perhaps a similar primitive to add information to the security context after it is initially established. Discussion of the Authorization API A one-page handout was distributed that outlined the arguments to the check_authorization function in the authorization API. Some of the goals in the design of the API were that it be simple to use for simple applications, but extensible and also easily usable by applications that have additional constraints and more advanced requirements for authorization. The arguments to the check authorization function are described below: answer = check_authorization(det_answer,/* Detailed answer (out) */ sc, /* Security context */ target, /* Object to be manipulated */ operation, /* Operation to be performed */ parameters)/* Modifiers to request */ In the interest of providing a simple interface to most applications, the authorization API returns an answer of yes (0), no (2), or maybe (1). Simple applications would treat this as yes, or not yes. Further, the first argument to the API is an out parameter containing extra information that may be used by more advanced applications if the answer is a maybe. This structure might also contain information about when the authorization so granted is due to expire. The form of the security context, the second argument, was already discussed. Ideally, information to be contained in the security context will include the following elements: o verified authentication information - gssapi, uuids, groups o unverified authentication information - to be checked when needed o verified and unverified authorization information - proxies, etc o delegated authorization credentials - to be used with other servers It should be possible to add to the security context subsequent to its initial creation. This might allow lazy verification of authorization credentials (i.e. do not verify them until they are needed for an operation), as well as requests for additional credentials from clients for certain operations. The third argument identifies the target of the operation for which authorization is to be checked. This would typically be a null terminated string with the name of the object. The namespace from which the name is drawn can be local to an application. Names for different applications can be made distinct by specifying a namespace identifier in the parameters argument described later. There was a question raised about ACL management. In particular, it was not clear where there was one manager for all the ACLs, or whether the application stores the ACL itself. In fact, both models should be supported. For the latter model, one might want to pass in the ACL as an argument, rather than the name of the object which would then be looked up by the ACL manager. One way to support this is using an additional flag in the parameters argument that would indicated that the target argument is a pointer to the actual ACL. There was a suggestion to use object identifiers to identify the target, but they are really not needed. If you have them, you can use them as one of the name spaces, but you will not always have object identifiers as the names of objects in an application. Only if the application uses OIDs, would this be the name of the targets. A separate name space for OIDs is easily supported in the parameters. The fourth argument is a pointer to a bit vector identifying the operations for which authorization is being checked, or the bit vector itself if less than 32 bits. How the field is interpreted depends on flags in the parameter argument. The parameter argument also tells how the bits are to be interpreted so that privilege bits from one application (meaning certain rights) are not confused with those from other applications that might mean something different. The final argument is the parameters argument. This argument describes the behavior of the API. It is expected that the argument will remain fixed for a particular application. It defines how the other arguments are to be interpreted. It identifies the name space of the object names and the form of the other arguments. The same structure would be passed on all calls to check authorization. o Access Control List Entries The access control lists used by the API are similar to those in common use today. An access control list will be associated with each object to be protected. Entries in the list will identify the principals or groups authorized access by that entry. The principal and group specified will be matched against the principal and group identifiers in the security context by the authorization API. The rights specifically authorized by the entry will be specified in the entry as a tagged bit vector. The tag indicates how the bits in the bit vector are to be interpreted. The ACLs will be extended beyond those in common use today in that each entry will have an optional additional list of restrictions (the negative attributes described earlier in the minutes). This list of restrictions places additional constraints on the access granted. For example, it might allow access to be granted only between 9AM and 5PM, or the access might expire at a particular date and time. Restrictions in an ACL entry might also encode which intermediaries are allowed to be involved when authenticating principals that use the entry. Simple applications will never see these restrictions. Instead, they will be evaluated by the authorization API itself, and the yes/no answer seen by the application will already reflect the result of that evaluation. o Use of the Authorization API by Advance Applications More advanced applications will rely on additional information returned in the detailed answer argument. Among the information returned will be an expiration time for access so granted if such a restriction in the ACL entry is present or if the expiration time of any authentication or authorization credentials is known. Further, the authorization API can return an answer of maybe, indicating that restrictions (negative attributes) were present in authorization credentials or access control list entries that could not be interpreted directly by the authorization API. This is likely to be the case if application specific restrictions were used. When such an answer is returned, the unresolved restrictions are returned to the application in the detailed answer structure. This list will then be checked by the application using a fairly well defined procedure, plugging local checks into boilerplate restriction checking code that will be provided. The network access server will provide a good example of how such checks are to be performed, and a description of the use of the authorization API by the network access server should be included in documents describing the mechanism. Discussion of Guidelines Document There was a brief discussion about the development of a set of guidelines for application developers on how to support fine grained authorization for network accessible applications. This document would be released initially as an Internet-Draft and then as an Information RFC. The advice would be basic. For example, advising the developer to first look through the application and identify the objects to be protected, and the granularity of the objects to be protected: is it a file, is it something more general, or more specific. The document would then work through how one would use the API which is being developed. The document should also discuss design implications of particular choices, especially with respect to how long authorization continues (i.e. whether you check the returned expiration time), and whether authorizations checks are per session, or per operation, as well as issues related to the granularity of the objects that are protected. The document would give an example of the use of the authorization API for a simple application that just uses the yes/no answer, and for a more advanced application such as the network access server that makes use of application specific restrictions. How to Proceed The meeting concluded with a brief discussion of how to proceed. Work items include refining the authorization API and developing real code, coming up with a revised definition of the security context, revising the list of authorization attributes, and writing the guidelines document. Piers will continue his work on the security context in part here, and in part in the CAT Working Group. Cliff will work with Piers on the security context, and will work on the other work items. John Vollbrecht will work on the section of the guidelines document describing how the network access server uses the authorization API. Attendees Andy Adams ala@merit.edu Garrett Alexander gda@tycho.ncsc.mil Nick Alfano alfano@mpr.ca Alireza Bahreman bahreman@bellcore.com Steven Bellovin smb@research.att.com Larry Blunk ljb@merit.edu Antonio Fernandez afa@thumper.bellcore.com Vincent Gebes vgebes@sys.attjens.co.jp Jisoo Geiter geiter@mitre.org Mei-Jean Goh goh@mpr.ca Chris Gorsuch chrisg@lobby.ti.com Marco Hernandez marco@cren.net Charlie Kaufman kaufman@zk3.dec.com Stephen Kent kent@bbn.com David Kristol dmk@allegra.att.com Gordon Lee gordon@ftp.com John Linn linn@security.ov.com Kanchei Loa loa@sps.mot.com Steven Lunt lunt@bellcore.com Piers McMahon p.v.mcmahon@rea0803.wins.icl.co.uk Michael Michnikov mbmg@mitre.org Bob Morgan morgan@networking.stanford.edu Robert Moskowitz 3858921@mcimail.com Clifford Neuman bcn@isi.edu Allan Rubens acr@merit.edu Richard Schmalgemeier rgs@merit.edu Wolfgang Schneider schneiw@darmstadt.gmd.de Vincent Shekher vin@sps.mot.com Sam Sjogren sjogren@tgv.com Dave Solo solo@bbn.com Don Stephenson don.stephenson@sun.com Barbara Sterling bjs@mcdata.com Vladimir Sukonnik sukonnik@process.com Dean Throop throop@dg-rtp.dg.com Jerry Toporek jt@mentat.com Theodore Ts'o tytso@mit.edu John Vollbrecht jrv@merit.edu Peter Yee yee@atlas.arc.nasa.gov