Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/92nov/aac-minutes-92nov.txt

Text File | 1993-02-17 | 14KB | 342 lines

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 [e-mail].  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 [e-mail].
   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             [e-mail]
Richard Fisher           [e-mail]
Barbara Fraser           [e-mail]
Shari Galitzer           [e-mail]
Richard Graveman         [e-mail]
Thomas Hacker            [e-mail]
Neil Haller              [e-mail]
Ken Hirata               [e-mail]
David Katinsky           [e-mail]
John Linn                [e-mail]
Steven Lunt              [e-mail]
Clifford Neuman          [e-mail]
Tu Nguyen                [e-mail]
Rakesh Patel             [e-mail]
Tim Seaver               [e-mail]
William Simpson          [e-mail]
Sam Sjogren              [e-mail]
Chuck Warlick            [e-mail]



                                   6