Editor's Note: Minutes received 7/31 CURRENT_MEETING_REPORT_ Reported by Clifford Neuman/ISI Minutes of the Authorization and Access Control BOF (AAC) The first meeting of a new BOF on Authorization and Access Control met at the July IETF. The purpose of the BOF was to discuss authorization and access control issues for the Internet. The discussion centered around two problems: first, the need for a uniform method for specifying access control information, and second on services and mechanisms for distributing authorization in the Internet. Agenda o Discussion of requirements for the specification of access control information. o Discussion of existing and evolving distributed authorization mechanisms including: DCE, DSSA, ECMA, Sesame, and Proxies. o Discussion of the relationship between this Group and the Common Authentication Technology Working Group. o Discussion of our goals. Discussion The first two items were related and discussion flowed from one into the other and back again. The need for a uniform method of specifying access control information for distributed applications was discussed. One of the motivations for such an interface is to interact with the network authentication methods that are evolving. Such methods identify the subject accessing a service, but service specific methods are then needed to decide whether the subject is authorized access. Most existing applications do not presently maintain the information needed to make such decisions. In the near future, application developers will have a common interface (the GSSAPI) that they can use to add strong authentication to their applications. That solves only half the problem. Ideally there would also be a common set of tools that they can use to decide whether the subject is authorized access. The general consensus was that our work in this area should concentrate on access control lists as a conceptual model. Some of the distributed authorization mechanisms (described later) enable that model to support a full spectrum of access control methods including capabilities. 1 Support for these mechanisms should be considered for inclusion in the model. It was mentioned that work has gone on in POSIX and elsewhere to specify access control list mechanism for Unix. It was felt that we should consider such work, and build upon rather than replace it, but that we must support the needs of network applications. An access control list (ACL) can be associated with objects to be protected. The ACL contains entries that identify subjects, either as individuals, or as members of groups. The entries specify the rights of the named subject to access the protected object. One point of contention was whether each distinct right for an object (read, write, execute, etc.) should be represented by a separate ACL (i.e., column in the access matrix), or an ACL should be associated with each object with the entries within the ACL specifying the rights. The two are equivalent, and consensus was that a single ACL per object was the preferred choice. It was also felt that in general the meaning of rights in an ACL entry would be application specific (interpreted by the server), but that the meaning of certain rights, in particular the ability to modify the ACL, should be common across all ACLs. One extension to the ACL concept important for use on the Internet is that the identification of the subject should also identify the authentication method (or set of acceptable methods) to be used in identifying the subject. This is important because of the varying strengths of alternative authentication methods, and perhaps more importantly because the methods might not share a common name space for principals. There was very little discussion on this topic and any decisions here can await further work on the security model and access control abstractions. A less straightforward extension is the addition of an optional field to each ACL entry that would allow restrictions of the authorization to be specified. Examples of restrictions include time of use, the need for additional authentication or authorization (e.g., a co-signer), etc. Steve Crocker pointed out that the mechanism and abstraction must be simple and easy to understand in the common case, a sentiment with which everyone agreed. It was also felt, however, that in the ideal case the mechanism would also be flexible enough to support the needs of most applications, so that developers would not be forced to design their own mechanisms. It was felt that our goals in this area should be to: 1. Identify the target applications from which to draw requirements (e.g., Mailing lists, files, login, X windows). 2. Identify the security models to be supported (e.g., We might consider discretionary access control, mandatory access control, capabilities, access control lists, etc.). 2 3. Work out the appropriate access control abstractions. 4. Consider an application programmer interface (API) to support those abstractions (consider POSIX, DCE, our own, etc.). A final issue raised concerned whether our model needed to support the needs of licensing and accounting mechanisms. It was felt that we should keep such mechanism in mind, but that it was premature to consider them as an integral part of our current work. The second phase of the meeting concentrated on the evolving mechanisms and architectures for authorization in distributed systems. This phase consisted of informal presentations of some of the mechanisms. Joe Pato described the authorization mechanism used by OSF's Distributed Computing Environment. Authorization in DCE is based on privilege attribute certificates issued by a privilege server. These certificates are restricted Kerberos tickets (see restricted proxies described later) that specify the UID and groups to which a principal belongs. The privilege attribute certificate is then used by the principal to assert its membership in groups, and its UID. The DCE also supports an extensible ACL model for distributed systems based on and extending that in the POSIX draft. Authorization is a combination of privilege attributes and control attributes (e.g., ACLs). Support for delegation is being considered, further exploiting the ability to construct restricted proxies. John Linn then described the authorization mechanisms that are part of the Digital Distributed System Security Architecture (DSSA). One key aspect of the DSSA is that authorization credentials are pulled by the server, rather than pushed by the client, though the client provide's hints suggesting which credentials should be pulled. A second aspect of the DSSA is that reduced authorization can be granted by establishing a new role, a new principals with reduced privileges. The DSSA supports delegation with identifiable intermediaries, but delegation is of all rights possessed by a particular role. Piers McMahon then outlined the main features of the ECMA TC32/TG9 Security Architecture. The ECMA model is that a trusted authentication service authenticates subjects using a suitable authentication method, and that a logically separate privilege attribute server (PAS) grants privileges (e.g., identity, role, group, capability, clearance) to that subject. The privilege acquisition is constrained by the level to which the subject is authenticated - but is independent of the authentication method. The privileges are cryptographically protected by the PAS and returned in a data element called a Privilege Attribute Certificate (PAC), and are sent (pushed) by the security subject to target systems to inform access control decisions. Methods for protection of PACs, together with controls on their use and delegation are defined by current ECMA work. Piers then described SESAME. Some background information was given to 3 explain that SESAME is a phased project based on ECMA TC32/TG9 work. Phase 1 produced a prototype which showed that the basic model was feasible. Phase 2 is building on this to develop product-level distributed security infrastructure with support for dialogue protection and DCE-interworking. An outline of the SESAME Phase 2 architecture was given to show how it built on the ECMA architecture, and a brief walkthrough of the privilege acquisition protocol was presented. It was stated that SESAME Phase 2 supports a subset of the full ECMA privilege attributes (identity, role, group), and a profile of ECMA PAC protection and controls. Next, Clifford Neuman described restricted proxies. A restricted proxy can be implemented on top of an authentication mechanism by issuing authentication credentials authorizing a second party (the grantee) to act as the issuer for the purpose of performing a restricted set of operations, under specific conditions. These restrictions are supported by Kerberos V5 in the authorization data field. It was then described how restricted proxies can be used to implement a range of authorization mechanisms from capabilities, to authorization and group servers, and how restricted proxies might interact with the access control list mechanisms described earlier. The next topic of discussion was how these mechanism might be used by applications. In particular, might it be appropriate to develop a common API within which they might fit. If so, might this API become part of the common authentication technology (GSSAPI) so that the programmer only need deal with one mechanism, instead of two. Finally, we discussed the possibility of convergence of the various approaches. Some of the approaches are still in their early stages, and it would be helpful if we could encourage, for example, a common certificate structure across mechanisms. However, some of the mechanisms, in particular DCE, are further along, and significant changes would present problems. In any event, where possible, we should try to promote fewer protocols and message formats. It was felt that our immediate goals in the distributed authorization area should be: 1. To look for common characteristics among the mechanisms. 2. Decide on a course of action. The range of possibilities include encouraging the use of a common credential format, developing other interoperability mechanism, defining a common API, and unifying the protocols. Finally, It was felt that work is needed in the area of authorization and access control, and that the Group should continue to meet. As a potential working group, we must: o Decide what the product of the working group would be. o Develop a set of goals and milestones. 4 o Write a Charter. It was felt that we should refine the Group's objectives through the mailing list. If we can develop a Charter in time for the next IETF, we can form a working group. If not, we should meet again as a second BOF, part of the purpose of which will be to agree on a Charter. A mailing list has been set up, ietf-aac@ISI.EDU. Requests for addition or deletion should be sent to ietf-aac-request@ISI.EDU. Attendees Derek Atkins warlord@thumper.bellcore.com Tony Ballardie a.ballardie@cs.ucl.ac.uk Doug Barlow barlow@decwet.dec.com Mark Baushke mdb@cisco.com David Borman dab@cray.com Geetha Brown geetha@decvax.dec.com Stephen Crocker crocker@tis.com Tom Farinelli tcf@tyco.ncsc.mil Barbara Fraser byf@cert.org Maria Gallagher maria@nsipo.nasa.gov Neil Haller nmh@thumper.bellcore.com John Linn linn@erlang.enet.dec.com Ellen McDermott emcd@osf.org P.V. McMahon p.v.mcmahon@rea0803.wins.icl.co.uk Cyndi Mills cmills@nnsc.nsf.net Clifford Neuman bcn@isi.edu Brad Passwaters bjp@sura.net Allan Rubens acr@merit.edu Gregory Ruth gruth@bbn.com Paul Sangster sangster@ans.net Jeffrey Schiller jis@mit.edu Robert Shirey shirey@mitre.org Jeremy Siegel jzs@nsd.3com.com Sam Sjogren sjogren@tgv.com Simon Spero ses@cmns.think.com Theodore Ts'o tytso@mit.edu John Vollbrecht jrv@merit.edu Jesse Walker walker@eider.lkg.dec.com Peter Williams p.williams@uk.ac.ucl.cs 5