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

Text File | 1993-02-17 | 13KB | 291 lines

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, [e-mail]. Requests for addition
or deletion should be sent to [e-mail].

Attendees

Derek Atkins             [e-mail]
Tony Ballardie           [e-mail]
Doug Barlow              [e-mail]
Mark Baushke             [e-mail]
David Borman             [e-mail]
Geetha Brown             [e-mail]
Stephen Crocker          [e-mail]
Tom Farinelli            [e-mail]
Barbara Fraser           [e-mail]
Maria Gallagher          [e-mail]
Neil Haller              [e-mail]
John Linn                [e-mail]
Ellen McDermott          [e-mail]
P.V. McMahon             [e-mail]
Cyndi Mills              [e-mail]
Clifford Neuman          [e-mail]
Brad Passwaters          [e-mail]
Allan Rubens             [e-mail]
Gregory Ruth             [e-mail]
Paul Sangster            [e-mail]
Jeffrey Schiller         [e-mail]
Robert Shirey            [e-mail]
Jeremy Siegel            [e-mail]
Sam Sjogren              [e-mail]
Simon Spero              [e-mail]
Theodore Ts'o            [e-mail]
John Vollbrecht          [e-mail]
Jesse Walker             [e-mail]
Peter Williams           [e-mail]



                                   5