Editor's Note: Minutes received 12/11/92 CURRENT_MEETING_REPORT_ Reported by Clifford Neuman/USC Minutes of the Authorization and Access Control BOF (AAC Agenda 1. Discuss strawman of Charter (to be distributed at meeting). (a) Discuss possible goals of the Working Group. o Common mechanism for specifying local access control information. o Improving interoperability for distributed authorization mechanisms. o Others (b) Evaluate each in terms of whether sufficient experience exists, or whether we would be premature in our efforts. (c) Select achievable goals and prepare a timetable. (d) Agree on mechanics for preparation and approval of Charter. 2. For the goals selected in 1b. (a) Discuss approaches and alternatives (b) Assign work item to prepare strawman 3. For common mechanisms to specify access control information . (a) Discuss strawman (to be distributed at meeting). 4. Any other business. Overview The second meeting of a BOF on Authorization and Access Control met at the November IETF. The purpose of the BOF was to organize a Working Group to address authorization and access control issues for the Internet. The discussion was centered primarily around two issues: 1. Development of a Charter and Milestones for the Working Group. 2. Initial work to develop an application programmer interface (API) supporting authorization. 1 Though not discussed in depth at this meeting, the Group is also concerned with mechanisms for distributed authorization on the Internet. Charter and Goals of the Group A draft Charter for the Working Group was distributed at the meeting. The Charter had been sent to the mailing list a day earlier and was made available by FTP for remote participants at the meeting. The first goal of the Working Group will be to develop a common mechanism for specifying access control information that will work well with distributed authentication mechanisms that are becoming available. The Working Group will also examine evolving mechanisms and architectures for authorization in distributed systems and to establish criteria that enable interworking of confidence and trust across systems and to encourage the evolution of (or develop ourselves) credential formats that more readily allow support for or translation across multiple mechanisms. A timetable for these deliverables was discussed. There seemed to be agreement that we should move rapidly toward developing a common mechanism for specifying access control information. Clifford Neuman will submit a draft API for discussion prior to the March IETF. By the July IETF we hope to have examples of its use for selected applications, and the goal is to submit the specification of the API to the IESG by next November. There was considerably less agreement on the timetable for work on distributed authorization mechanisms. The original timetable was less specific for work on distributed authorization mechanisms, initially exploring the area, trying not to constrain evolving implementations until more experience is gained. Several attendees, in particular Steve Crocker and Bill Simpson, felt that we should develop our own protocol and credential formats before incompatible mechanisms arise. There was no resolution on this issue, and it will be discussed further at the next meeting. Piers McMahon will submit specifications for DCE authorization, particularly with respect to proposed enhancements from SESAME for DCE. Clifford Neuman will submit additional information on authorization through restricted proxies. As part of the discussion, a question was raised about whether the output of the Group would be a protocol. Our work on the API will not result in a protocol, instead it will yield a common mechanism for making authorization decisions based on authentication information obtained through other protocols (application protocols, and authentication and authorization protocols). The work on distributed authorization mechanisms, however, would result in a protocol or at least a common credential format to be used by other protocols. Even before distributed authorization mechanism are in place the API together with existing authentication protocols (e.g., CAT) would allow the retrieval and evaluation of fine-grained access control information allowing access by specific principals not previously registered (in terms of having an account) on a server. 2 During discussion of the API, Piers McMahon suggested that the scope of the API should support the specification of delegated principal identifiers, though the mechanism for delegation would be the subject of subsequent work. Richard Graveman suggested that the mechanism should support the specification of groups. Mechanism to certify membership in groups would be the subject of the distributed authorization work, but the specification of required group membership does belong in any access control list mechanism, and this should be part of the API. Steve Lunt pointed out that the naming of principals is an important issue that must be addressed by the API. Steve Crocker pointed out that the need for a common naming mechanism is a problem that the IAB is aware of, but that we shouldn't expect such a mechanism to be in place soon, we must support the multiple existing mechanisms for now. John Linn pointed out that the GSSAPI exports names tagged with a type and provides a function to compare two names for equality, and that that mechanism may be sufficient for our needs. Piers McMahon asked about the scope of our mechanism. Is it to be Internet specific, or is it to extend beyond the Internet? The answer was that we would like it to be universal, but to the extent that making it so adds complexity or hinders progress we should restrict it to the Internet. In any event, we will look at mechanisms and APIs developed in other contexts, including DCE and Posix. Comments on Charter should be sent to ietf-aac@isi.edu. After a couple weeks for discussion, the Charter will be submitted for approval by Steve Crocker (the Security Area Director) and the IAB. Authentication Requirements After discussion of the Charter, Neil Haller spoke about an Internet-Draft he and Randall Atkinson submitted on Internet Authentication Requirements. The draft discusses authentication requirements and guidelines for different applications. The mechanisms covered include simple password mechanisms, non-disclosing passwords, Kerberos, DASS, and CAT. It is not clear which working group is best for discussion of this document. It was felt that in general that this work item fits best under the Common Authentication Technology (CAT) Working Group and John Linn indicated his willingness to take it on as a separate work item for the CAT Group. Some issues, in particular how authentication requirements interact with authorization mechanisms used by particular applications (the login application was presented as an example) should be considered in this (AAC) Group. Neil Haller did not receive many comments when the Internet-Draft was first submitted to the INET-AUTH list. He will resubmit it to the CAT list in hope that CAT will provide the input required. Authorization and Access Control API 3 The next topic of discussion was an API for access control. A strawman outline was distributed and made available to remote participants. The strawman called for a function: answer = check_acl(id,(object/acl/multiple_acl),operation) and each input and output was discussed. The first item of discussion was the ID structure. In the strawman: id = user and/or group identification from distributed authentication mechanisms and future authorization mechanisms. We should support the passing of multiple identifiers to support user and group and to support ACL entries naming compound principals (i.e., two principals must be present to perform an operation). John Linn suggested that perhaps there should be separate inputs for the clients identity and other authorization credentials. It was felt that this was a bad idea. It was resolved that there should be a single identifier if at all possible, that this identifier might be a GSSAPI security context, and that the security context might need to be extended to include addition information as required. object/acl/multiple_acl = a reference or identifier for the object to be accessed, or a reference to a specific access control list associated with the object. Multiple acl's might be necessary for example if an acl is associated with both a directory and an object within the directory. The topic of discussion here was whether one names an object whose ACL is to be checked, or pass the ACL itself. In either case there is an abstraction violation. In one case the application must manage ACLs so that they may be passed to the API. In the other case, the code implementing the API many require knowledge about the application. Steve Lunt suggested that the each ACL should be named, and that the application would decide how to map the object into the name of the appropriate ACL. The name of the ACL might be simply the name of the object. If a system wide authorization database is shared by more than one application, it would be important to make sure that no name conflicts arise. 4 operation = a list of those operations to be performed, or more precisely a list of those rights needed to perform the requested operation. The issue here was whether the operation should be passed as input and checked by the API returning a yes/no answer , or whether the API should return the operations allowed and let the application decide. The resolution is that we should support two calls, one that returns the rights and one that checks them returning yes or no. Sam Sjorgen suggested support for VMS/Tops-20 style enabling and disabling of capabilities during the checking of rights. Unfortunately, it is not clear how such a capability would work in a distributed environment. In particular, the rights that are enabled are simply those passed to the server, and checked by the API. Disabled rights would not be visible to the process checking for access. answer = A yes/no response indicating whether the operation is allowed, and optionally a list of restrictions to be applied by the application. Applications that don't require or can't interpret restrictions in a response would not have an authorization database that provides them. Thus if you don't need this functionality, your ACL mechanism doesn't need to support it. If your ACL mechanism does return a restriction that the application can't understand the response will be treated as not authorized. Discussion on this topic centered around the use of restrictions. Does the use of restrictions place too great a burden on the application to understand what they mean? Some restrictions, for example time of day, are relatively common and could be interpreted by the code implementing the API, but some are inherently application specific and could not be interpreted by the code implementing the API. Bill Simpson raised the network access server as an example of an application that could use the API. He wants a mechanism that they can put in their boxes. Restrictions for the network access server might be an address mask restricting where a user can connect. John Linn asked what the objects are that are being protected. The answer is network addresses to which one can connect. Clifford Neuman pointed out that the restrictions allow one to specify ACLs for fewer objects. For the same fine-grained control without restrictions, one would specify an ACL for each address (or at least each subnet). With restrictions, one has a single ACL with an application restriction that provides finer grained control. Whether an application choose to use restrictions is a design decision, we should not make the decision for them. Piers McMahon asked whether we had considered existing APIs for access control. Posix was looked at, but it is not suited to distributed 5 principals not previously registered as users on a system. Piers asked if we had considered the OSF API for access control. The answer was no, since we were not aware of it. Conditioned on obtaining OSF approval to do so, Piers will submit a copy of the OSF access control API to the list. To Proceed o Comments on the Charter should be sent to ietf-aac@isi.edu. o The Charter will be submitted for approval in the next few weeks. o The ACL API will be refined. Discussion will take place on the ietf-aac mailing list. o Addition information on authorization in DCE, ECMA, and using restricted proxies will be submitted to the list by Piers McMahon and Clifford Neuman. Attendees Vickie Brown brown@osi540sn.gsfc.nasa.gov Richard Fisher rfisher@cdhf1.gsfc.nasa.gov Barbara Fraser byf@cert.org Shari Galitzer shari@mitre.org Richard Graveman rfg@ctt.bellcore.com Thomas Hacker hacker@citi.umich.edu Neil Haller nmh@thumper.bellcore.com Ken Hirata khirata@emulex.com David Katinsky dmk@rutgers.edu John Linn linn@erlang.enet.dec.com Steven Lunt lunt@bellcore.com Clifford Neuman bcn@isi.edu Tu Nguyen Nguyen1T@cc.ims.disa.mil Rakesh Patel patel@noc.rutgers.edu Tim Seaver tas@concert.net William Simpson Bill.Simpson@um.cc.umich.edu Sam Sjogren sjogren@tgv.com Chuck Warlick warlick@theophilis.nsfc.nasa.gov 6