Minutes from Houston

[Clifford Neuman <[e-mail]>]

Attached is a draft of the minutes from Houston.  My apologies for
being so late with them.  I am sending these minutes in for the
proceedings, but if you have suggestions for changes, please let me
know, as I will probably be able to send a revised version if they
haven't done their editing yet.  If you have any comments, I would
like them by tomorrow (Monday) night if possible.  Thanks, and sorry
for the short notice.

	~ Cliff
---
       Minutes of the Authorization and Access Control WG (AAC)
		       Houston, Texas, USA IETF
		       November 1 1993, 4:00 PM
				   
		      Chair: B. Clifford Neuman
		  University of Southern California
		    Information Sciences Institute

The Authorization and Access Control working group met at the November
IETF. The agenda for the meeting was:

. Presentation of a revised list of restrictions and privilege
  attributes needed by applications and existing security
  systems, and a proposed method for representing them. 

. 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.

. 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.

. 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 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.  Requests to be added
to the working group mailing list should be directed to
[e-mail]. 

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.

1. 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 doesn't 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.

. 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.

. 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 T'so 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 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.

. 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.  We can make it 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, we can add the restriction:

    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.

2. Discussion of information maintained in security context

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

  (a) servers which handle multiple requests within a single process
      (e.g. DCE RPC), and 
  (b) 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 wasn't
enabled for this context.

Ted T'so warned that this might inappropriately overload the GSS-API
credential, as such non-delegated "credentials" couldn't 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 CAT WG.

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.

3. 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:

  verified authentication information - gssapi, uuids, groups
  unverified authentication information - to be checked when needed
  verified & unverified authorization information - proxies, etc
  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. don't 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 wasn't
clear where there was one manager for all the ACLs, or whether the
application stores the ACL itself.  In fact, we want to support both
models.  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 the answer is that we really don't need them.  If you have them you an
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.

. 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.

. 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 we
will provide.

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.

4. 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 we are developing.

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.

5. 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.

Minutes submitted by Clifford Neuman with portions provided by Piers McMahon.