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

Text File | 1993-05-12 | 15KB | 343 lines

CURRENT_MEETING_REPORT_


Reported by Clifford Neuman/Information Sciences Institute

Minutes of the Authorization and Access Control BOF (AAC)

The third meeting of the Authorization and Access Control BOF was held
at the March IETF. This should be the last BOF meeting as the Charter
has already been submitted to the IESG and is currently under review.

Agenda


   o Review the AAC Charter as submitted to the IESG for review.

   o Identify common characteristics of evolving distributed
     authorization mechanisms and begin discussion on how best to
     encourage interoperability across mechanisms.

   o Review the authorization API from the last meeting, in light of the
     DCE and Sesame documents made available by Piers McMahon, and
     consider characteristics as identified in the preceding item.

   o Assign work items to generate an access control API Internet-Draft
     and assign other items to be accomplished before the Amsterdam
     IETF.


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

Review of Charter

The Working Group Charter, discussed at the previous meeting, was
submitted to the IESG for approval.  Based on several comments from IESG
members, the Charter was revised to make the relationship with other
working groups clearer.  A new version was provided to the IESG and
distributed to the AAC mailing list.  Everyone at the meeting seemed
comfortable with the revised Charter and no additional changes were
suggested.  The Charter is once again in the hands of the IESG, which
seems reluctant to form new groups without understanding the ``big
picture'' of how all the groups in an area fit together.  Steve Crocker,
the Security Area Director, will provide the IESG with such a statement.

Evolving Distributed Authorization Mechanisms

The goals of distributed authorization mechanisms include avoiding the
need to duplicate common information about principals' access rights on
each end-system and facilitating ease of management, often by enabling

                                   1





centralized maintenance of access control and revocation information.
Evolving mechanisms for distributed authorization was discussed,
including DCE, ECMA/Sesame, and restricted proxies (Kerberos V5).  In
each of these mechanisms, a certificate grants privileges to a
principal, either by explicitly enumerating privileges, or by
restricting privileges.  Positive privileges are represented in the
latter case as the set of rights available to the issuer of the
certificate which are not explicitly restricted.

Clifford Neuman argued that the restricted forms of credentials are more
general since they allow the addition of restrictions during delegation,
and also because the rights of the issuer of a certificate naturally
limit what can be granted, rather than requiring a separately maintained
list of which principals are authorized to grant particular privileges.
Piers McMahon and John Linn suggested that the term restriction is a
confusing term for permission.  It also wasn't clear to them how one
could compose privileges from different sources.  Cliff responded that
the permissions are granted by certificates which provide all rights
possessed by the signer and that the restrictions apply to what is
granted by a particular certificate, limiting the permissions.  By
providing multiple certificates one gets a sum of products; i.e., the
sum of the remaining rights from each of the restricted certificates.
There was some skepticism about this role of restrictions in the
representation of what appear to be positive rights; the issue will be
revisited later.

It would improve interoperability across mechanisms if there were a
common set of restrictions or privileges.  This would make it easier to
translate from one mechanism to another (i.e., the translation would be
syntactic, rather than semantic).  Clifford Neuman will compile a list
of restrictions sufficient to represent privileges supported by DCE,
Sesame, restricted proxies, and any other mechanisms brought to the
Group's attention.  He will also accept input from application
developers on the restrictions and privileges they require.  Submissions
can be in either form, restrictions or permissions.  They will be
represented at least initially as restrictions in the compiled list to
asses the benefits of such a representation.

Example permissions/restrictions:


DCE:      A way of specifying global userID and groups the user is in.
DCE:      ``Optional'' restrictions.
NAS:      A way of restricting the subnets to which a user may connect.
Sesame:   A way to represent each of its privilege attributes.
Others:   Roles.


Authorization API (and more)

                                   2





The Working Group began refining the strawman ACL API presented at the
Washington D.C. IETF. There is more than just an API involved.  In
particular, it will be necessary to define the authorization information
that can be stored.  The API will be designed to allow easy integration
with distributed authorization methods, including support for the
specification of restrictions on ACL entries.  Ted Ts'o suggested that
since the API is not restricted to what people normally think of as
ACLs, that it should be called an Authorization API, rather than an ACL
API. This change in terminology was adopted.

The Group started to define the input and output arguments to the API.
To set the stage for this discussion, Piers McMahon and Clifford Neuman
described the anticipated flow of control for the end-server.  When a
request is received, calls are made to the GSSAPI or other
authentication routines.  The output of the GSSAPI is a Security Context
which contains information about the client.  This might then be passed
into additional function to verify authorization credentials.  The
distributed authorization mechanisms might instead be handled as part of
the GSSAPI itself.

The output of the combined GSSAPI and distributed authorization
functions will be a Security Context which is fed into the authorization
API. For simplicity at this point in the discussion, the authorization
API will return a yes/no answer indicating whether a particular
operation is allowed.  We need to define what needs to be part of the
Security Context, an input to the authorization API. It might then be
possible to extend the GSSAPI Security Context definition so that it can
be used directly.  The diagram below shows the flow of control.


                       This is the Security Context to be defined
                             /
-----+  +---------+  +-------X---------+ +-------> yes/no+restrictions
     |  |         |  |                 | |
     V  |         V  |                 V |
    GSSAPI        Dist            Authorization
              Authorization            API
+----possibly combined----+



The authorization API will provide mechanisms to query a local
authorization database to check authorization.


     answer = check_authorization(sc, target, operation)


SC is the Security Context, containing information about the identity of
the client and about authorization credentials that have been received
(and possibly verified).  Piers McMahon agreed to work on defining the
form of the Security Context for our present needs, trying to define it
in such a way that it will later be able to accommodate information from

                                   3





additional distributed authorization mechanisms.  Defining the Security
Context will require interaction with those defining other parts of the
API, and should include consultation with John Linn and the CAT Working
Group to make sure that it is consistent with, and perhaps ultimately
included in, the GSSAPI.

TARGET specifies the target of the attempted access.  If the
authorization database were represented as a set of access control
lists, the target would identify which list is to be consulted.  TARGET
should have a two part name, one part identifying an application or set
of applications that share the same set of objects, and the name of the
individual object.  This is useful when the authorization database is
maintained on a system wide basis (for example by an ACL manager) rather
than by individual applications.  For now we will define TARGET to be
two strings, an identifier for an application and an application
specific object name.  This can be represented as a single string using
a ``:''  as a separator (this means :  can not appear in the identifier
of the application).

OPERATION identifies the operation to be performed on the target.  The
definition of this field will correspond to the rights field in the ACLs
in the authorization database.  The Group decided that this field would
be an extensible bit vector of application specific rights, together
with a tag identifying the application (the tag for the operation bit
vector should be compared with the tag for the bit vector in the ACL to
make sure the bits are interpreted correctly).

At this point it was felt that the Group needed to specify the form of
the authorization database.  The access control list method was
proposed, with rights specified as described in the preceding paragraph,
but with the ACL entry extended so entries would include an optional
list of restrictions that further specify the conditions under which the
operation would be allowed.  Among these restrictions might be time of
day restrictions, as well as application specific restrictions such as a
netmask of network access servers, or perhaps a restriction for a
mailing list server that allowed modification of a mailing list, but
only to add or delete oneself.  These restrictions would exist in the
same space as those defined for distributed authorization mechanisms.
In fact, it should be possible to apply the restrictions returned from
an authorization database directly to distributed authorization
credentials issued by security servers (authorization servers, privilege
attribute servers, etc).

If restrictions are supported, the value returned by check_authorization
would no longer be yes/no, but instead a list of restrictions.  An
answer of ``no'' would be represented by the restriction ``not
authorized''.  An answer of ``yes'' would be represented as an empty
list of restrictions.  A conditional yes would be represented by the
list of conditions/restrictions.  Some restrictions, such as time of
day, could be checked directly by the authorization API, while others
would be returned by the API as unresolved.  These unresolved
restrictions might be application specific, and they would be handled by
a function wrapped around the API, avoiding the need for the
authorization API to understand the needs of all potential applications.

                                   4





For example, consider the pseudo code to check authorization to use a
network access server:

   check_nas_acl(sc, aclid) {
      resp = check_authorization(sc, "nas:network", 0x1);
      for restrict in resp {
          case: net_mask;
                ...
                break;
          case: toll_lines_only;
                ...
                break;
          case: spare_capacity_only;
                ...
                break;
          default:
                reject;
      }
      accept;
   }

Technically, the principal identifier in an entry can be thought of as a
restriction on who may use it, but we'll leave it as a separate field
since that is what most people expect in an ACL entry.  Multiple
principal identifiers will be supported for each ACL entry, allowing the
specification of compound principals.  Principal identifiers will be
typed.  We considered using the GSSAPI representation for the principal.
John Linn pointed out that the opaque nature of GSSAPI names makes them
difficult to store in a persistent and shared access control list.
Naming issues have been a stumbling block in other groups, and wanting
to avoid that issue for now, we decided that we will support typed
names.  When the GSSAPI naming issues are resolved it might be one of
the types.  For now, the type would indicate the namespace (which at the
present time is closely tied to the authentication method) from which
the name is drawn.

The definition of the get_acl call as an alternate interface to the
authorization API was deferred until the authorization database itself
is better defined.

Work Items


Clifford Neuman            Compile a list of restrictions or privilege
                           attributes addressing the needs of DCE,
                           Sesame, restricted proxies, and various
                           applications.
                           Contact Russ Hobby for input on other
                           application requirements.
Piers McMahon              Define the information that needs to be part
                           of the Security Context.

                                   5





Piers/Clifford             Work to further refine the form of the
                           authorization database.
Allan Rubens/John Vollbrecht Provide a description of the authorization
                           needs for the network access server.
Sam Sjogren                Provide the same for FTP.


Thanks to Richard Graveman for his notes which were helpful in the
preparation of these Minutes.

Attendees

Jim Barnes               [e-mail]
John Campbell            [e-mail]
Stephen Crocker          [e-mail]
Dale Dougherty           [e-mail]
Jonathan Fellows         [e-mail]
Antonio Fernandez        [e-mail]
Barbara Fraser           [e-mail]
James Galvin             [e-mail]
Jisoo Geiter             [e-mail]
Richard Graveman         [e-mail]
Richard Harris           [e-mail]
Laurent Joncheray        [e-mail]
David Katinsky           [e-mail]
John Linn                [e-mail]
Steven Lunt              [e-mail]
Cynthia Martin           [e-mail]
P.V. McMahon             [e-mail]
Clifford Neuman          [e-mail]
Radia Perlman            [e-mail]
Christopher Provenzano   [e-mail]
Robert Raisch            [e-mail]
April Richstein          [e-mail]
Allan Rubens             [e-mail]
Paul Sangster            [e-mail]
Wolfgang Schneider       [e-mail]
Sam Sjogren              [e-mail]
Stuart Stubblebine       [e-mail]
Louisa Thomson           [e-mail]
Klaus Truoel             [e-mail]
Theodore Ts'o            [e-mail]
John Vollbrecht          [e-mail]
James Weatherford        [e-mail]



                                   6