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

Text File | 1994-02-23 | 23KB | 516 lines

CURRENT_MEETING_REPORT_

Reported by B. Clifford Neuman/Information Sciences Institute and
Piers McMahon/ICL

Minutes of the Authorization and Access Control Working Group (AAC)


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 Presentation of a revised list of restrictions and privilege
     attributes needed by applications and existing security systems,
     and a proposed method for representing them.

   o Discussion of the information maintained in the security context
     and where it should come from.  The security context maintains
     information about the user that is used to make authorization
     decisions.

   o Discussion of the intended use of the authorization attributes by
     applications, ACL formats for an authorization API, and discussion
     of an API to provide a simple interface for application developers.

   o Discussion of guidelines for adding authorization to network
     accessible applications.  These guidelines should be written and
     released initially as an Internet-Draft, and eventually as an
     Informational RFC.


The purpose of the the initial work on a framework to represent security
attributes and restrictions is to provide a uniform framework for both
distributed authorization and local authorization.  Local authorization
will be based on access control lists.  Distributed authorization will
be based on proxies.  Both have common elements.  These elements (or
attributes) may be stored on access control list entries on security
servers, carried in credentials, and evaluated on the end system the
same way they would be evaluated if stored on an access control list
maintained by the end system itself.


Presentation of a Revised List of Attributes and Restrictions

At the Amsterdam IETF, there was concern that the representation of all
rights conveyed by a set of credentials as restrictions on rights
possessed by the grantor of those credentials was confusing.  A revised
framework for representing rights and restrictions on those rights was
sent to the mailing list and presented at the meeting.  In the Amsterdam
discussion, the use of the term certificate was also confusing.  The
revised framework uses the term proxy which is less confusing, though
more closely tied to one particular proposed implementation of the
framework.

In the revised framework for representing privileges, privileges are
conveyed by proxies.  Proxies enumerate positive rights they convey, but
these rights are limited by the rights available to the principal that
signed the proxy (the grantor).  Some proxies specify that all rights
available to the grantor are conveyed, supporting unrestricted
delegation or authentication forwarding.  Proxies may be further
restricted to limit the rights that are conveyed.  Certain restrictions
require the presentation of additional proxies called endorsements
before the original proxy may be used.  A proxy and all required
endorsements together form a proxy chain (a proxy that does not require
endorsements constitutes a chain by itself).  Endorsement may apply
additional restrictions.  The restrictions specified by each proxy in a
chain are applied, resulting in a more restricted set of rights.  A
principal may collect multiple independent proxy chains, and the rights
granted by each chain are added providing additional rights.


o Attributes and Restrictions

A structured set of authorization attributes are associated with each
proxy.  Each attribute in the set is typed, and the interpretation of
the data associated with the attribute is determined by its type.  Some
types of attributes are specific to specific servers.  A flags field
associated with each kind of attribute encodes the appropriate behavior
if the interpretation of the attributed is not known.  The two possible
behaviors are rejection of the request, or ignoring the attribute.

Attributes are further divided into three classes:  privilege
attributes, restrictions, and aggregates.  The class is also encoded in
the flags field.

Privilege attributes identify some operation that is permitted, or
assert identifying information such as group information or user
identifiers that grant additional rights to the principal that presents
a proxy.  Privilege attributes may be placed in a proxy only at the time
it is created.  They may not be added subsequently, and they may not
appear in endorsements.  Further, in order for a privilege attribute to
apply, the principal granting the proxy must possess the ability to
grant such an attribute.  (Though privilege attributes grant rights,
they are interpreted as explicitly enumerating the rights that are to be
granted by a proxy and all other rights are presumed not to be granted
by the proxy).

Restrictions specifically remove rights from those conveyed by a proxy,
or they place additional constraints on when, how, where, or by whom a
proxy may be exercised.  Restriction may be present when a proxy is
initially created, they may be added subsequently and they may be
present in endorsements.  Restrictions that are present in a required
endorsement are applied in addition to the restrictions present in the
proxy that is endorsed.

Aggregate attributes may be positive (privilege attributes) or negative
(restrictions).  The rules about where each may appear apply to
aggregates as well.  An aggregate attribute encapsulates a set of
attributes and specifies how they are to be interpreted.  One form of
aggregate limits the application of a set of attributes to a particular
end server or a particular application.


o Discussion

After the initial presentation several questions were raised.  Among the
questions was how one determines which principals are authorized to
issue proxies granting particular rights.  The end server will still
have to maintain access control lists for this information, but these
ACLs only contain the names of the principals that grant rights for an
operation, rather than those authorized to perform the operation.
Presumably this information changes less frequently, and is more
compact.

Checking these ACLs would be handled by the authorization API, so the
client does not have to worry about it directly.  The contents of this
ACL might be specified by a configuration option for the local system.
This check might be done when establishing a security context for a
request or a login session, on the remote machine.  Ted Ts'o commented
that the information about the grantor of a privilege should be carried
along as extra information in the security context even after
verification, so that an application that has special requirements can
check it.

Another issue raised was concern about placing too much of the burden on
the application programmer to interpret such proxies and proxy chains.
In fact, the interpretation would be handled by two APIs, one of which
would be specific to the distributed authorization method in use, and
one would be the authorization API which was discussed later in the
meeting.  This latter API will take several arguments, and answer yes or
no indicating whether an operation is to be allowed.


o Enumeration of Attributes and Restrictions

An initial set of positive and negative attributes was presented and it
was discussed how they fit into the revised framework.  Some of the
attributes are application specific, and other application specific
attributes can be defined.

The positive privilege attributes can only be grated in an initial proxy
and can not be added subsequently, to augment rights.  In enumerating an
initial set, a goal was to cover the rights needed and used by various
distributed authorization mechanisms including ECMA, DCE, and restricted
proxies.

Among the positive attributes were:



LOCAL-UID               set UID for local system

GROUP-MEMBERSHIP        enumerate local groups to be used locally

DCE-PAC                 globally unique groups and uuids

AUTHORIZED              encodes list of objects and rights for objects

QUOTA                   like authorized, but specifies numeric limit



Other suggested positive attributes include:



ROLE                    to include rights of individual in particular
                        role

ALL                     which might be needed to mean all rights of
                        grantor



For the AUTHORIZED attribute, the encoding of the identified objects and
the rights on those objects would be application specific, and opaque to
other parts of the system.

Among the negative attributes were:



FOR-USE-BY-PRINCIPAL    who may use a proxy, or compound principal

FOR-USE-BY-GROUP        only members of group may use proxy

ACCEPT-N-TIMES          can only be exercised N times on a given server

VALID-TIME-OF-DAY       e.g.  can only be used between 9AM and 5PM

VALID-PERIOD            expires after, not good until

NETMASK                 application specific, used by network access
                        server

FOR-USE-ON-SERVER       identifies specific server where proxy is valid

FOR-USE-FROM            local terminal, secure area, not sure how to
                        implement



Other suggestions for negative attributes included a means to restrict
the day of the week (for example, only Monday through Friday).  John
Linn made the observation that given that time of day is a one time
decision, once logged in, one can do whatever one wants.  This can be
addressed if the application checks periodically, or notes the end time
during the initial check and requires reauthorization at that time.  It
can be made easier for applications to note the end of the authorization
period if an expiration time were returned as an additional value by the
authorization API. Some applications would use this expiration time,
while others might not.  Some systems, AFS in particular, do note the
expiration of credentials.  Finally, though login has a one time
authorization check, other operations like file accesses might not.

It was also pointed out that the negative attributes did not include the
ability to exclude enumerated rights.  This might be useful so that one
can list a broad class of positive attributes, then enumerate exceptions
as negative attributes.  Thus, the restriction can be added:



EXCLUDE                 excludes list of objects and rights for objects



The encoding of the objects and rights for EXCLUDE would be application
specific.

It was suggested that there be a way to combine positive attributes from
separate proxies into a single proxy.  Unfortunately, this is clearly
not possible when the rights conferred are granted by different
principals.  When granted by a the same principal, a proxy can be
granted to enumerates multiple rights.  Combining them after multiple
proxies have been issued, however, requires the reissuance of the
combined proxy by the grantor.

There was some discussion of how the attributes are related to the
authorization API. This discussion appears later in the minutes.  Due to
the limited time for the meeting, the aggregate attributes were not
discussed at the meeting, but are described in the message sent out to
the mailing list.



Discussion of Information Maintained in Security Context

Piers McMahon noted that authorization decisions would be made on two
types of application servers:


  1. Servers which handle multiple requests within a single process
     (e.g.  DCE RPC)

  2. Per-request daemons (e.g.:  TELNET)


He concluded that the authorization security context in the
authorization API must be able to refer to either a security context
(for the former case) or a delegated credential (for the latter case).

In order to make the authorization API simpler, he also suggested that
the GSS-API gss_accept_sec_context should always return a credential
which could then be used consistently to represent the authorization
context (in an analogous way to the DCE login context) even if
delegation was not enabled for this context.

Ted Ts'o warned that this might inappropriately overload the GSS-API
credential, as such non-delegated ``credentials'' could not be used to
initiate contexts.  In response, Piers observed that this was also true
for acceptor usage credentials, and suggested that the ``usage'' of the
credential could be perhaps extended to include an ``accepted security
context'' type in addition to initiator and acceptor.  After some
further exchanges, it was agreed that further discussion on this topic
should be carried on in the Common Authentication Technology Working
Group (CAT).

John Linn commented that it might be appropriate to add a primitive
inquire_security_context, to to query information from the security
context, and perhaps a similar primitive to add information to the
security context after it is initially established.



Discussion of the Authorization API

A one-page handout was distributed that outlined the arguments to the
check_authorization function in the authorization API. Some of the goals
in the design of the API were that it be simple to use for simple
applications, but extensible and also easily usable by applications that
have additional constraints and more advanced requirements for
authorization.

The arguments to the check authorization function are described below:


  answer = check_authorization(det_answer,/* Detailed answer (out)     */
                               sc,        /* Security context          */
                               target,    /* Object to be manipulated  */
                               operation, /* Operation to be performed */
                               parameters)/* Modifiers to request      */


In the interest of providing a simple interface to most applications,
the authorization API returns an answer of yes (0), no (2), or maybe
(1).  Simple applications would treat this as yes, or not yes.  Further,
the first argument to the API is an out parameter containing extra
information that may be used by more advanced applications if the answer
is a maybe.  This structure might also contain information about when
the authorization so granted is due to expire.

The form of the security context, the second argument, was already
discussed.  Ideally, information to be contained in the security context
will include the following elements:


   o verified authentication information - gssapi, uuids, groups
   o unverified authentication information - to be checked when needed
   o verified and unverified authorization information - proxies, etc
   o delegated authorization credentials - to be used with other servers


It should be possible to add to the security context subsequent to its
initial creation.  This might allow lazy verification of authorization
credentials (i.e.  do not verify them until they are needed for an
operation), as well as requests for additional credentials from clients
for certain operations.

The third argument identifies the target of the operation for which
authorization is to be checked.  This would typically be a null
terminated string with the name of the object.  The namespace from which
the name is drawn can be local to an application.  Names for different
applications can be made distinct by specifying a namespace identifier
in the parameters argument described later.

There was a question raised about ACL management.  In particular, it was
not clear where there was one manager for all the ACLs, or whether the
application stores the ACL itself.  In fact, both models should be
supported.  For the latter model, one might want to pass in the ACL as
an argument, rather than the name of the object which would then be
looked up by the ACL manager.  One way to support this is using an
additional flag in the parameters argument that would indicated that the
target argument is a pointer to the actual ACL.

There was a suggestion to use object identifiers to identify the target,
but they are really not needed.  If you have them, you can use them as
one of the name spaces, but you will not always have object identifiers
as the names of objects in an application.  Only if the application uses
OIDs, would this be the name of the targets.  A separate name space for
OIDs is easily supported in the parameters.

The fourth argument is a pointer to a bit vector identifying the
operations for which authorization is being checked, or the bit vector
itself if less than 32 bits.  How the field is interpreted depends on
flags in the parameter argument.  The parameter argument also tells how
the bits are to be interpreted so that privilege bits from one
application (meaning certain rights) are not confused with those from
other applications that might mean something different.

The final argument is the parameters argument.  This argument describes
the behavior of the API. It is expected that the argument will remain
fixed for a particular application.  It defines how the other arguments
are to be interpreted.  It identifies the name space of the object names
and the form of the other arguments.  The same structure would be passed
on all calls to check authorization.


o Access Control List Entries

The access control lists used by the API are similar to those in common
use today.  An access control list will be associated with each object
to be protected.  Entries in the list will identify the principals or
groups authorized access by that entry.  The principal and group
specified will be matched against the principal and group identifiers in
the security context by the authorization API. The rights specifically
authorized by the entry will be specified in the entry as a tagged bit
vector.  The tag indicates how the bits in the bit vector are to be
interpreted.

The ACLs will be extended beyond those in common use today in that each
entry will have an optional additional list of restrictions (the
negative attributes described earlier in the minutes).  This list of
restrictions places additional constraints on the access granted.  For
example, it might allow access to be granted only between 9AM and 5PM,
or the access might expire at a particular date and time.  Restrictions
in an ACL entry might also encode which intermediaries are allowed to be
involved when authenticating principals that use the entry.

Simple applications will never see these restrictions.  Instead, they
will be evaluated by the authorization API itself, and the yes/no answer
seen by the application will already reflect the result of that
evaluation.


o Use of the Authorization API by Advance Applications

More advanced applications will rely on additional information returned
in the detailed answer argument.  Among the information returned will be
an expiration time for access so granted if such a restriction in the
ACL entry is present or if the expiration time of any authentication or
authorization credentials is known.

Further, the authorization API can return an answer of maybe, indicating
that restrictions (negative attributes) were present in authorization
credentials or access control list entries that could not be interpreted
directly by the authorization API. This is likely to be the case if
application specific restrictions were used.

When such an answer is returned, the unresolved restrictions are
returned to the application in the detailed answer structure.  This list
will then be checked by the application using a fairly well defined
procedure, plugging local checks into boilerplate restriction checking
code that will be provided.

The network access server will provide a good example of how such checks
are to be performed, and a description of the use of the authorization
API by the network access server should be included in documents
describing the mechanism.


Discussion of Guidelines Document

There was a brief discussion about the development of a set of
guidelines for application developers on how to support fine grained
authorization for network accessible applications.  This document would
be released initially as an Internet-Draft and then as an Information
RFC.

The advice would be basic.  For example, advising the developer to first
look through the application and identify the objects to be protected,
and the granularity of the objects to be protected:  is it a file, is it
something more general, or more specific.  The document would then work
through how one would use the API which is being developed.

The document should also discuss design implications of particular
choices, especially with respect to how long authorization continues
(i.e.  whether you check the returned expiration time), and whether
authorizations checks are per session, or per operation, as well as
issues related to the granularity of the objects that are protected.

The document would give an example of the use of the authorization API
for a simple application that just uses the yes/no answer, and for a
more advanced application such as the network access server that makes
use of application specific restrictions.


How to Proceed

The meeting concluded with a brief discussion of how to proceed.  Work
items include refining the authorization API and developing real code,
coming up with a revised definition of the security context, revising
the list of authorization attributes, and writing the guidelines
document.  Piers will continue his work on the security context in part
here, and in part in the CAT Working Group.  Cliff will work with Piers
on the security context, and will work on the other work items.  John
Vollbrecht will work on the section of the guidelines document
describing how the network access server uses the authorization API.


Attendees

Andy Adams               [e-mail]
Garrett Alexander        [e-mail]
Nick Alfano              [e-mail]
Alireza Bahreman         [e-mail]
Steven Bellovin          [e-mail]
Larry Blunk              [e-mail]
Antonio Fernandez        [e-mail]
Vincent Gebes            [e-mail]
Jisoo Geiter             [e-mail]
Mei-Jean Goh             [e-mail]
Chris Gorsuch            [e-mail]
Marco Hernandez          [e-mail]
Charlie Kaufman          [e-mail]
Stephen Kent             [e-mail]
David Kristol            [e-mail]
Gordon Lee               [e-mail]
John Linn                [e-mail]
Kanchei Loa              [e-mail]
Steven Lunt              [e-mail]
Piers McMahon            [e-mail]
Michael Michnikov        [e-mail]
Bob Morgan               [e-mail]
Robert Moskowitz         [e-mail]
Clifford Neuman          [e-mail]
Allan Rubens             [e-mail]
Richard Schmalgemeier    [e-mail]
Wolfgang Schneider       [e-mail]
Vincent Shekher          [e-mail]
Sam Sjogren              [e-mail]
Dave Solo                [e-mail]
Don Stephenson           [e-mail]
Barbara Sterling         [e-mail]
Vladimir Sukonnik        [e-mail]
Dean Throop              [e-mail]
Jerry Toporek            [e-mail]
Theodore Ts'o            [e-mail]
John Vollbrecht          [e-mail]
Peter Yee                [e-mail]