CURRENT_MEETING_REPORT_ Reported by Clifford Neuman/Information Sciences Institute Minutes of the Authorization and Access Control BOF (AAC) The third meeting of the Authorization and Access Control BOF was held at the March IETF. This should be the last BOF meeting as the Charter has already been submitted to the IESG and is currently under review. Agenda o Review the AAC Charter as submitted to the IESG for review. o Identify common characteristics of evolving distributed authorization mechanisms and begin discussion on how best to encourage interoperability across mechanisms. o Review the authorization API from the last meeting, in light of the DCE and Sesame documents made available by Piers McMahon, and consider characteristics as identified in the preceding item. o Assign work items to generate an access control API Internet-Draft and assign other items to be accomplished before the Amsterdam IETF. The draft 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. Review of Charter The Working Group Charter, discussed at the previous meeting, was submitted to the IESG for approval. Based on several comments from IESG members, the Charter was revised to make the relationship with other working groups clearer. A new version was provided to the IESG and distributed to the AAC mailing list. Everyone at the meeting seemed comfortable with the revised Charter and no additional changes were suggested. The Charter is once again in the hands of the IESG, which seems reluctant to form new groups without understanding the ``big picture'' of how all the groups in an area fit together. Steve Crocker, the Security Area Director, will provide the IESG with such a statement. Evolving Distributed Authorization Mechanisms The goals of distributed authorization mechanisms include avoiding the need to duplicate common information about principals' access rights on each end-system and facilitating ease of management, often by enabling 1 centralized maintenance of access control and revocation information. Evolving mechanisms for distributed authorization was discussed, including DCE, ECMA/Sesame, and restricted proxies (Kerberos V5). In each of these mechanisms, a certificate grants privileges to a principal, either by explicitly enumerating privileges, or by restricting privileges. Positive privileges are represented in the latter case as the set of rights available to the issuer of the certificate which are not explicitly restricted. Clifford Neuman argued that the restricted forms of credentials are more general since they allow the addition of restrictions during delegation, and also because the rights of the issuer of a certificate naturally limit what can be granted, rather than requiring a separately maintained list of which principals are authorized to grant particular privileges. Piers McMahon and John Linn suggested that the term restriction is a confusing term for permission. It also wasn't clear to them how one could compose privileges from different sources. Cliff responded that the permissions are granted by certificates which provide all rights possessed by the signer and that the restrictions apply to what is granted by a particular certificate, limiting the permissions. By providing multiple certificates one gets a sum of products; i.e., the sum of the remaining rights from each of the restricted certificates. There was some skepticism about this role of restrictions in the representation of what appear to be positive rights; the issue will be revisited later. It would improve interoperability across mechanisms if there were a common set of restrictions or privileges. This would make it easier to translate from one mechanism to another (i.e., the translation would be syntactic, rather than semantic). Clifford Neuman will compile a list of restrictions sufficient to represent privileges supported by DCE, Sesame, restricted proxies, and any other mechanisms brought to the Group's attention. He will also accept input from application developers on the restrictions and privileges they require. Submissions can be in either form, restrictions or permissions. They will be represented at least initially as restrictions in the compiled list to asses the benefits of such a representation. Example permissions/restrictions: DCE: A way of specifying global userID and groups the user is in. DCE: ``Optional'' restrictions. NAS: A way of restricting the subnets to which a user may connect. Sesame: A way to represent each of its privilege attributes. Others: Roles. Authorization API (and more) 2 The Working Group began refining the strawman ACL API presented at the Washington D.C. IETF. There is more than just an API involved. In particular, it will be necessary to define the authorization information that can be stored. The API will be designed to allow easy integration with distributed authorization methods, including support for the specification of restrictions on ACL entries. Ted Ts'o suggested that since the API is not restricted to what people normally think of as ACLs, that it should be called an Authorization API, rather than an ACL API. This change in terminology was adopted. The Group started to define the input and output arguments to the API. To set the stage for this discussion, Piers McMahon and Clifford Neuman described the anticipated flow of control for the end-server. When a request is received, calls are made to the GSSAPI or other authentication routines. The output of the GSSAPI is a Security Context which contains information about the client. This might then be passed into additional function to verify authorization credentials. The distributed authorization mechanisms might instead be handled as part of the GSSAPI itself. The output of the combined GSSAPI and distributed authorization functions will be a Security Context which is fed into the authorization API. For simplicity at this point in the discussion, the authorization API will return a yes/no answer indicating whether a particular operation is allowed. We need to define what needs to be part of the Security Context, an input to the authorization API. It might then be possible to extend the GSSAPI Security Context definition so that it can be used directly. The diagram below shows the flow of control. This is the Security Context to be defined / -----+ +---------+ +-------X---------+ +-------> yes/no+restrictions | | | | | | V | V | V | GSSAPI Dist Authorization Authorization API +----possibly combined----+ The authorization API will provide mechanisms to query a local authorization database to check authorization. answer = check_authorization(sc, target, operation) SC is the Security Context, containing information about the identity of the client and about authorization credentials that have been received (and possibly verified). Piers McMahon agreed to work on defining the form of the Security Context for our present needs, trying to define it in such a way that it will later be able to accommodate information from 3 additional distributed authorization mechanisms. Defining the Security Context will require interaction with those defining other parts of the API, and should include consultation with John Linn and the CAT Working Group to make sure that it is consistent with, and perhaps ultimately included in, the GSSAPI. TARGET specifies the target of the attempted access. If the authorization database were represented as a set of access control lists, the target would identify which list is to be consulted. TARGET should have a two part name, one part identifying an application or set of applications that share the same set of objects, and the name of the individual object. This is useful when the authorization database is maintained on a system wide basis (for example by an ACL manager) rather than by individual applications. For now we will define TARGET to be two strings, an identifier for an application and an application specific object name. This can be represented as a single string using a ``:'' as a separator (this means : can not appear in the identifier of the application). OPERATION identifies the operation to be performed on the target. The definition of this field will correspond to the rights field in the ACLs in the authorization database. The Group decided that this field would be an extensible bit vector of application specific rights, together with a tag identifying the application (the tag for the operation bit vector should be compared with the tag for the bit vector in the ACL to make sure the bits are interpreted correctly). At this point it was felt that the Group needed to specify the form of the authorization database. The access control list method was proposed, with rights specified as described in the preceding paragraph, but with the ACL entry extended so entries would include an optional list of restrictions that further specify the conditions under which the operation would be allowed. Among these restrictions might be time of day restrictions, as well as application specific restrictions such as a netmask of network access servers, or perhaps a restriction for a mailing list server that allowed modification of a mailing list, but only to add or delete oneself. These restrictions would exist in the same space as those defined for distributed authorization mechanisms. In fact, it should be possible to apply the restrictions returned from an authorization database directly to distributed authorization credentials issued by security servers (authorization servers, privilege attribute servers, etc). If restrictions are supported, the value returned by check_authorization would no longer be yes/no, but instead a list of restrictions. An answer of ``no'' would be represented by the restriction ``not authorized''. An answer of ``yes'' would be represented as an empty list of restrictions. A conditional yes would be represented by the list of conditions/restrictions. Some restrictions, such as time of day, could be checked directly by the authorization API, while others would be returned by the API as unresolved. These unresolved restrictions might be application specific, and they would be handled by a function wrapped around the API, avoiding the need for the authorization API to understand the needs of all potential applications. 4 For example, consider the pseudo code to check authorization to use a network access server: check_nas_acl(sc, aclid) { resp = check_authorization(sc, "nas:network", 0x1); for restrict in resp { case: net_mask; ... break; case: toll_lines_only; ... break; case: spare_capacity_only; ... break; default: reject; } accept; } Technically, the principal identifier in an entry can be thought of as a restriction on who may use it, but we'll leave it as a separate field since that is what most people expect in an ACL entry. Multiple principal identifiers will be supported for each ACL entry, allowing the specification of compound principals. Principal identifiers will be typed. We considered using the GSSAPI representation for the principal. John Linn pointed out that the opaque nature of GSSAPI names makes them difficult to store in a persistent and shared access control list. Naming issues have been a stumbling block in other groups, and wanting to avoid that issue for now, we decided that we will support typed names. When the GSSAPI naming issues are resolved it might be one of the types. For now, the type would indicate the namespace (which at the present time is closely tied to the authentication method) from which the name is drawn. The definition of the get_acl call as an alternate interface to the authorization API was deferred until the authorization database itself is better defined. Work Items Clifford Neuman Compile a list of restrictions or privilege attributes addressing the needs of DCE, Sesame, restricted proxies, and various applications. Contact Russ Hobby for input on other application requirements. Piers McMahon Define the information that needs to be part of the Security Context. 5 Piers/Clifford Work to further refine the form of the authorization database. Allan Rubens/John Vollbrecht Provide a description of the authorization needs for the network access server. Sam Sjogren Provide the same for FTP. Thanks to Richard Graveman for his notes which were helpful in the preparation of these Minutes. Attendees Jim Barnes barnes@xylogics.com John Campbell jrcamp@nosc.mil Stephen Crocker crocker@tis.com Dale Dougherty dale@ora.com Jonathan Fellows jonf@gdstech.grumman.com Antonio Fernandez afa@thumper.bellcore.com Barbara Fraser byf@cert.org James Galvin galvin@tis.com Jisoo Geiter geiter@mitre.org Richard Graveman rfg@ctt.bellcore.com Richard Harris rharris@atc.boeing.com Laurent Joncheray lpj@merit.edu David Katinsky dmk@pilot.njin.net John Linn linn@gza.com Steven Lunt lunt@bellcore.com Cynthia Martin martin@spica.disa.mil P.V. McMahon p.v.mcmahon@rea0803.wins.icl.co.uk Clifford Neuman bcn@isi.edu Radia Perlman perlman@dsmail.enet.dec.com Christopher Provenzano proven@csi.compuserve.com Robert Raisch raisch@ora.com April Richstein amr@tycho.ncsc.mil Allan Rubens acr@merit.edu Paul Sangster sangster@reston.ans.net Wolfgang Schneider schneider@gmd.de Sam Sjogren sjogren@tgv.com Stuart Stubblebine stubblebine@isi.edu Louisa Thomson louisa@whitney.hac.com Klaus Truoel truoel@gmd.de Theodore Ts'o tytso@mit.edu John Vollbrecht jrv@merit.edu James Weatherford weatherf@nosc.mil 6