CURRENT_MEETING_REPORT_ Reported by B. Clifford Neuman/Information Sciences Institute Minutes of the Authorization and Access Control WG (AAC) The Authorization and Access Control Working Group met at the July IETF for the first time since the approval of its charter and official inception as a working group. The preceding three meetings were BOF sessions. 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 Report on approval of the AAC charter. o Presentation of a list of restrictions and privilege attributes needed by applications and existing security systems, and a proposed method for representing them. o Discussion of the intended use of these restrictions by applications, and the presentation of an Application Program Interface (API) to provide a simple interface for application developers. o Discussion of the information maintained in the security context. The security context maintains information about the user that is used to make authorization decisions. Report on the AAC Charter It was reported that the working group charter was approved by the IESG. Steve Crocker brought up several desires that were raised in the discussion by the IESG. Among these desires is the need for some kind of demonstration of the technology, in particular, integration with possible applications. Discussion of Possible Applications (Digression) Possible applications were discussed. An early test will be the Prospero Directory Service which already has support for access control lists, and an access control list type reserved for the mechanism developed by the working group. 1 Another possible application is in support of cross-site, remote execution. In particular, Tom Hutton is looking for a simple way to specify access controls for data and processing resources distributed across several sites. File transfer provides a third set of applications. Steve Crocker pointed out the need for secure file transfer to and between large diverse groups. This is related to the FTP extension work in the Common Authentication Technology Working Group (CAT) in that those extensions make available to the application the authenticated network identity of the client, and that identity might be used as a basis for authorization decisions. Some of the Washington University FTP daemon extensions are also of interest here. A final application that was discussed was network databases. Daisy Rose mentioned that the Network Database Working Group (NETDATA) has a need for an authorization mechanism that will allow them to determine which remote principals are authorized to access a database, and which local user ID is to apply to such remote accesses. How It Will Be Used by Applications Throughout the discussion of possible applications, the issue of how authorization information would be specified by applications was raised. There seemed to be two classes: applications that are aware of network identities, and those that are not. Applications that are not aware of network identities rely on local authorization using local user identities. A separate mechanism is used to map network identities to local identities. For such applications, authorization is confined to initially establishing who is authorized to assume a particular identity at the time a connection is initiated. It is not clear if this is an authentication issue or an authorization issue. Applications that are aware of network identities make a call to the authorization API for each operation that is to be mediated. The authorization API will return a yes or no answer, or a list of what the principal can do, based on the principal's network identity. Access control list entries could identify the type of authentication required, in addition to the name of the principal authorized by an entry. Sam Sjogren suggested allowing the specification of weaker authentication methods including regular expression matches on network address or hostname and usernames in addition to stronger methods. This would allow the authorization API to be used with an existing application that does not have support for strong authentication, and would allow easier transition to stronger mechanisms if they are later integrated into the application. There was a brief discussion about whether an administrative interface to maintain access control lists needs to be defined. This issue was 2 defered until it is decided what access control lists and the API for checking authorization will look like. The definition of an external representation for an access control list should be enough to get started. Presentation of Restrictions and Privilege Attributes A draft list of restrictions was distributed at the meeting. The list defines some common restrictions that are useful for representing privilege attributes and constraints on the use of credentials in distributed systems. Several restrictions were discussed. Sam Sjogren suggested that it might be useful to think of these in terms of the questions who, what, when, where, and how (why is more appropriate for audit than authorization). With this taxonomy, the restrictions discussed were: o who - for_use_by_principal, for_use_by_group; o what - local_uid, group_membership, dce_pac, authorized, quota, netmask; o when - accept_n_times, authorized_times; o where - for_use_on_server, limit_restriction, limit_application; and o how - connection_type (dial-in, hard-wired from a secure area, etc), application_name. Even with this breakdown, there was a great deal of confusion about the difference between the ``who'' restrictions which limit who may exercise the proxy, and the ``what'' restrictions that seem to assert local user IDs and group membership, instead of restrict them. It is clear from the discussion that the model needs to be refined so that this distinction is more understandable, or replaced so that positive and negative attributes are considered separately. During discussion after the meeting, some ideas for addressing this confusion were generated. A revised specification incorporating one of these ideas will be distributed to the mailing list by the third week of August, and it will be decided at that time if the concerns have been addressed. Discussion of the Security Context In the few minutes that remained, Piers McMahon discussed possible information to be included in the security context, a structure that stores information about a principal and is passed as input to the authorization API which uses it, to decide which access control list entries are applicable. The presentation outlined the security-relevant information about a session maintained by, exported by, or used by 3 several systems. The Generic Security Service Application Program Interface (GSS-API) supports authentication and message protection. Separate authorization mechanisms provide access mediation and enforcement. The network user identity authenticated by the GSS-API is part of the security context and can be used by the authorization API. In the OSF Distributed Computing Environment, a set of privileges are added to the security context. These privileges are securely transmitted in privilege attribute certificates signed using Kerberos. These privileges become part of the security context once validated by the end-server. The security context for Sesame includes privilege attributes and control attributes that can limit delegation and permissible targets. Max Six includes labels and audit IDs in the security contexts. Representation of attributes is likely to be needed in a security context used for access control. It is recommended that the GSS-API security context be extended to include privilege attributes. John Linn pointed out that if this is done, a set of widely accepted attributes will be needed. Thanks to Richard Graveman for his notes which were helpful in the preparation of these minutes. Attendees Chris Adie C.J.Adie@edinburgh.ac.uk Mohammad Alaghebandan mohammad_alaghebandan@3com.com Luc Boulianne lucb@cs.mcgill.ca Stefan Braun smb@cs.tu-berlin.de Stephen Crocker crocker@tis.com Kurt Dobbins dobbins@ctron.com Richard Graveman rfg@ctt.bellcore.com Neil Haller nmh@thumper.bellcore.com Alton Hoover hoover@ans.net Thomas Hutton hutton@opus.sdsc.edu Dale Johnson dsj@merit.edu Peter Koch pk@techfak.uni-bielefeld.de Kim Chr. Madsen kimcm@ic.dk Clifford Neuman bcn@isi.edu Mel Pleasant pleasant@hardees.rutgers.edu Lars Poulsen lars@cmc.com Robert Reschly reschly@brl.mil Michael Roe mrr@cl.cam.ac.uk Daisy Rose daisy@watson.ibm.com Wolfgang Schneider schneiw@darmstadt.gmd.de Heiner Schorn heiner.schorn@umdac.umu.se Sam Sjogren sjogren@tgv.com 4 James Zmuda zmuda@mls.hac.com 5