Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/aac/aac-minutes-93jul.txt

Text File | 1993-08-19 | 9.2 KB | 241 lines

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               [e-mail]
Mohammad Alaghebandan    [e-mail]
Luc Boulianne            [e-mail]
Stefan Braun             [e-mail]
Stephen Crocker          [e-mail]
Kurt Dobbins             [e-mail]
Richard Graveman         [e-mail]
Neil Haller              [e-mail]
Alton Hoover             [e-mail]
Thomas Hutton            [e-mail]
Dale Johnson             [e-mail]
Peter Koch               [e-mail]
Kim Chr.  Madsen         [e-mail]
Clifford Neuman          [e-mail]
Mel Pleasant             [e-mail]
Lars Poulsen             [e-mail]
Robert Reschly           [e-mail]
Michael Roe              [e-mail]
Daisy Rose               [e-mail]
Wolfgang Schneider       [e-mail]
Heiner Schorn            [e-mail]
Sam Sjogren              [e-mail]

                                   4





James Zmuda              [e-mail]



                                   5