[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05                                             
INTERNET-DRAFT                        Tatyana Ryutov
CAT Working Group                     Clifford Neuman
Expires February 1999                 USC/Information Sciences Institute
draft-ietf-cat-acc-cntrl-frmw-00.txt  August 07, 1998



      Access Control Framework for Distributed Applications

0. Status Of this Document

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as
"work in progress."

To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).


1. Abstract

This document describes a unified model to support authorization in a
wide range of applications, including metacomputing, remote printing,
video conference, and any other application which will require
interactions between entities across autonomous security domains.

The document proposes requirements for the support of:

   - flexible and expressive mechanism for representing
     and evaluating authorization policies

   - uniform authorization service interface for facilitating access
     control decisions for applications and requesting access control
     information about a particular resource.

This specification defines structures and their uses at a level
independent of underlying mechanism and programming language environment.
This document is accompanied by a second one describing the details of
proposed structures and services along with bindings for C language
environments. This document is to be found in
draft-ietf-cat-gaa-cbind-00.txt.

2. Introduction

The variety of services available on the Internet continues to increase
and new classes of applications such as metacomputing, remote printing,

Ryutov/Neuman                               Expires February 1999


video conference are evolving. These applications will require
interactions between entities across autonomous security domains.

The distributed nature of the system, consisting of mutually suspicious
security domains, requires a mechanism, which provides fine-grained
access control to resources.

For example, access control requirements of a remote printing application
may include:

   - authorized individual users and organizations
   - time availability, e.g. time of the day or day of the week
   - restrictions on resources consumed by the clients, e.g. maximum
     job size, maximum number of pages per job
   - required confidentiality/integrity message protection
   - accounting for consumed resources

Access control requirements of large-scale multicast application [4],
e.g. corporate video conference may include:

   - authorized individual users and organizations
   - host properties; users on slow hosts or hosts running the wrong
     OS will be denied communication
   - payment & charging

Some of the security requirements are common across different
applications, while others are more individual.

Access control policies can be formulated in many ways. Administrators
Of each domain might use domain-specific policy syntax and
heterogeneous implementations of the policies.

It is necessary to define a particular framework applicable for
a wide range of systems and applications, which will allow to discuss
specific requirements for the representation and evaluation of security
policies.

The focus of this framework is based on the following two abstractions:

1) uniform mechanism for representation and evaluation of security
   policies

It should be capable of implementing a number of different security
policies, based on diverse authorization models, which can coexist in
distributed system. Standardizing the way that applications define their
security requirements provides the means for integration of local and
distributed security policies and translation of security policies
across multiple authorization models.

The mechanism should support the common authorization requirements but
provide the means to defining and integration with application or
organization specific policies as well. Applications should not need to
re-implement the basic authorization functions in an
application-specific manner.

Ryutov/Neuman                               Expires February 1999


2) Generic Authorization and Access control Application Program
   Interface (GAA API)

A common API will facilitate authorization decisions for applications.
An application invokes API functions to determine if a requested
operation or set of operation are authorized or if additional checks
are necessary.

The API will support the needs of most applications, thus not forcing
the developers to design their own authorization mechanisms.
The API will allow better integration of multiple mechanisms with
application servers. The GSS API  can be used by the GAA API to
obtain principal's identity see section 12.

Section 13.3 gives an extended example how the GAA API can be used by
applications.

3. Glossary

OBJECT (RESOURCE)
   entity that has to be protected e.g. hosts, processes, files, and
   devices such as printers and faxes.

SUBJECT
   entity that can initiate requests to an object e.g. individual users,
   hosts, applications and groups.

PRINCIPAL
   identity associated with a subject as a result of some unspecified
   authentication protocol. It can refer to a person, group, host, and
   application. Several principals can be associated with the same
   subject.

SECURITY POLICY
   the set of rules that govern can access to objects

ACCESS RIGHT (OPERATION, PERMISSION)
   a particular type of access to a protected object e.g. read, write,
   and execute

RESTRICTION (CONDITION)
   a specific policy allowing an operation to be performed on an
   object

This policy can have two meanings:

    1) descriptive
         An operation is allowed  if certain condition is satisfied.
         For instance, a policy may require concurrence of two
         Principals to perform some operation. If participation of
         both principals can be proved then this policy is satisfied.

    2) prescriptive
         An operation will be allowed if certain restrictive policy

Ryutov/Neuman                               Expires February 1999

         is enforced.

         For example, a process will be authorized to run on a host
         if the memory usage limits that a process can occupy in main
         memory satisfies certain constraints.

DELEGATION
   is the ability of a principal to give to another principal limited
   authority to act on it's behalf.

CREDENTIAL
   a statement of identity, group membership and non-membership,
   privilege attribute and transfer of privilege encoded in
   certificates.

DISCRETIONARY ACCESS CONTROL (DAC)
   A means of restricting access to objects based on the identity of
   subjects and/or groups to which they belong. The controls are
   discretionary in the sense that a subject with a certain access
   permission is capable of passing that permission (perhaps indirectly)
   on to any other subject(unless restrained by mandatory access
   control).

MANDATORY ACCESS CONTROL (MAC)
   A means of restricting access to objects based on the sensitivity
   (as represented by a label) of the information contained in the
   objects and the formal authorization (i.e. clearance) of subjects
   to access information of such sensitivity.


4.  Security models to be supported

It is intended that the framework will support a range of security
Models. Security requirements for computer system can be based on
different security models:

1) discretionary access control (DAC)

DAC policies can be based on open or closed world models.

  a) closed world model based on implicit denial of all rights.
  Authorizations are granted by an explicit listing of positive access
  rights.

  b) open world  model based on implicit granting of all rights and
  listing of only negative authorizations.

There could be hybrid approaches allowing a mix of negative and
Positive authorizations. Authorization conflicts can be resolved
according to application-specific rules.

2) mandatory access control model (MAC)

5. Access Control Lists (ACLs)


Ryutov/Neuman                               Expires February 1999

ACL is more appropriate management abstraction (comparing to
capabilities)for distributed system environment. It allows
administrators of a security domain to specify security policies with
respect to resources that it controls.
ACL provides convenient review what subjects authorized what modes of
access. Another advantage is the ease in which access can be revoked.
The owner of the object can simply remove or modify any ACL entry to
revoke or change type of access granted to any subject. ACL-based
approach more readily supports groups of subjects.

6.  Objects

The purpose of access control is protecting objects from unauthorized
access. The kinds of objects to be protected are specific to the
application to which the authorization model is applied and are not
included into the authorization model.
The objects that need to be protected include files, directories,
network connections, hosts and auxiliary devices, e.g. printers and
faxes. An authorization mechanism should support these different
kinds of objects in a uniform manner. Same ACL structure should be
used to specify access policies for different kinds of objects.
Object names should be drawn from the application-specific name space
and must be opaque to the authorization mechanism.

7.  ACL format

This section describes external (user-level) format for the ACL.
The presented ACL format is intended as an example of ACL
specification language usable by different applications to express
their security policies.
The ACL format in this framework extends the conventional ACL concept
in two ways:

1) by using conditional authorization as an extension to authorization
   policies, implemented as restrictions on authentication and
   authorization credentials

2) by enabling the syntactic specification of various authentication
policies

Identification of a subject should identify the authentication method
to be used in identifying the subject.

Flexibility in describing a subject's identity is important because
of various authentication mechanisms coexisting in a distributed
system, which may not share a common name space.

An ACL consists of a set of ACL entries.  Each ACL entry represents
access control policies directly associated with a principal. It
specifies a principal, a list of principals (aggregated principal),
or a group of principals, together with a set of granted and/or
denied access rights and optional conditions associated with the
rights.
We use the Backus-Naur Form to denote the elements of our ACL
language.

Ryutov/Neuman                               Expires February 1999


Square brackets, [ ], denote optional items and curly brackets, {},
surround that can repeat zero or more times. A vertical line, |
separates alternatives. Items inside double quotes are the terminal
symbols.
The wild-card symbol "*" has the same meaning as in the UNIX
environment.
ACL is specified according to the following format:

acl ::=  {acl_entry}

acl_entry ::= principal {principal}
                        "<" positive_access_rights ">"{condition}
                       {"<" positive_access_rights ">"{condition}}";"|
                        "<" negative_access_rights ">" ";"

7.1  Principals

The authorization framework should support the following kinds
of subjects:

1) USER
      identifies a person, e.g. authenticated user name.

2) HOST
      identifies a subject as a machine from which request to access
      the object was originated, e.g., an IP address or host DNS name
      or host public key.

3) APPLICATION
      identifies a certain program that has its own associated identity
      (principal),e.g., a checksum or certified name.
      This can be useful to grant access to a certain application,
      e.g. payment program, that is trusted to be written correctly and
      perform only it's intended purpose.

4) GROUP
      identifies a group of subjects. The kind of subjects
      (individual user, host or application) composing the group is
      opaque to the authorization mechanism.

5) ANYBODY
      represents any subject regardless of authentication.
      This may be useful for setting the default policies.

Principals can be aggregated into a single entry when the same set
of access rights and conditions applies to all of them.

Roles can be represented in the framework using the principal types
listed above and privilege constrain conditions, see section 7.3.1.1.
The framework should support multiple existing principal naming
methods. Different administrative domains might use different
authentication mechanisms, each having a particular syntax for
specification of principals. For example, an application may use
Kerberos V5  as an authentication service.  Kerberos V5 provides

Ryutov/Neuman                               Expires February 1999


secret-key based authentication and the format of the Kerberos V5
principal name is user_name/instance@realm.  Other domains may use
DCE to obtain the user's identity credentials, usually identified by a
User ID and Group ID. Another domain might use client authentication
in SSL, based on public-key cryptography, where principals are
identified by a global name, syntactically tied to the X.500 directory.

The syntax of a principal ID is defined according to the underlying
security mechanism. It is tagged to identify the name space. This
specification relies upon the underlying authentication mechanism to
provide the principal identities tagged with a type of the mechanism
used. GAA API will compare the provided principal identity and one
from ACL entries for equality.
Note that the model  enables the syntactic specification of multiple
authentication policies, but it does not translate between
heterogeneous authentication mechanisms.

The framework should support various strengths of user authentication
mechanisms. ACL may have entries associated with a different
principals identifying same subject using different authentication
methods.

Authentication in distributed systems can be accomplished using weak
methods, such as authentication by assertion or password-based
authentication, as well as stronger methods based on cryptography,
such as Kerberos, DASS, SSL.

Specification of weaker authentication methods including network
address, host name or username will allow the GAA API to be used with
any existing application that does not have support for strong
authentication.

A subject may be granted a different set of rights, depending on the
strength of the authentication method used for identification. For
example, access rights granted to a subject identified by the IP
address or DNS name can be more restricted compared to the rights
granted to the same subject if stronger authentication method, such
as Kerberos, was used.

The principal is specified according to the following format:

principal ::= principal_type  sec_mech  principal_ID  |  "ANYBODY"

principal_type ::= "HOST"  |  "USER"  |  "GROUP"  |  "APPLICATION"

sec_mech ::= alphanumeric_string

principal_ID ::= alphanumeric_string

Examples of principal specifications are:

ANYBODY
USER             kerberos.v5   kot@ORG.EDU
HOST             IPaddress     164.67.21.82

Ryutov/Neuman                               Expires February 1999

GROUP            DCE           7
APPLICATION      checksum      0x77AA45

7.2 Access rights

The proposed framework should support different types of access
rights. ACL entry may contain multiple access rights because it is
common to grant or deny a multiple access rights to the same set of
principals. It must be possible to specify which principals or
groups of principals are authorized for specific operations, as well
as which principals are explicitly denied authorizations for
protected object.

Conditions placed on positive access rights have the goal of
restricting the granted rights. The meaning of conditions on negative
(denied) access rights is unclear. We intend to investigate this issue,
however, for the time being, we require that:

1) A single ACL entry must not specify both positive and negative
   rights.

2) If an ACL entry specifies negative rights, it must not have
   any conditions placed on the denied rights.

All operations defined on the object are grouped by type of access
to the object they represent, and named using a tag.
For a file the following operations are defined:

     FILE : read
     FILE : write
     FILE : execute

However, in a bank application, an object might also be a customer
account, and the following set of operation might be defined:

     ACCOUNT : deposit
     ACCOUNT : withdraw
     ACCOUNT : transfer

Access rights names are from application-specific name space and
opaque to the authorization mechanism.
Internally a tagged bit vector represents access rights.
Each bit in the vector corresponds to an access right.

If  ACL entry type is GRANT, then a bit is set if the corresponding
right is granted.  If  ACL entry type is DENY, then a bit is set if the
corresponding  right is denied.

The tag indicates how the bits in the bit vector are to be interpreted,
for example, for the set of rights, associated with the tag FILE the
first bit should be interpreted as read, while for the set associated
with tag ACCOUNT, the same bit should be interpreted as deposit.

Access rights are specified using the format:


Ryutov/Neuman                               Expires February 1999


positive_access_rights ::=     tag   ":"   value
                           {   tag   ":"   value }

negative_access_rights ::=     tag   ":"   "-" value
                           {   tag   ":"   "-" value }

tag ::= alphanumeric_string

value ::= alphanumeric_string


7.3  Conditions

Authorization in distributed system, consisting of mutually suspicious
security domains, requires fine-grained control over the conditions
within which rights are granted. Individual requirements of evolving
applications require access control decisions to depend on the state
of other objects within a system, e.g. system load, time, client's
host properties.

The proposed framework should provide a means for applications to
specify any necessary conditions on authorized rights in a uniform
manner.

Conditions are placed in ACLs, as well as in identity, group
membership and authorization credentials. Conditions carried in the
credentials are evaluated by the access control framework in addition
to the conditions in the matching ACL entry.

Conditions can be categorized as generic or specific. A condition
is generic if it is evaluated by the access control model. Specific
conditions are application-dependent and evaluated by the application.

Conditions specify the type-specific policies under which an operation
can be performed on an object. A condition is interpreted according to
its type.

The format used for specifying conditions is as follows:

condition ::=   type  ":"  value

type  ::= alphanumeric_string

value ::= alphanumeric_string  |
                alphanumeric_string {alphanumeric_string} ","

7.3.1  Generic conditions

Issues that should be recognized in expressing generic conditions:

1) whether a condition is common across different applications

2) degree to which it can actually be enforced. Certainly, security


Ryutov/Neuman                               Expires February 1999

   policies can be written that express conditions that are
   impossible to implement. For instance, a policy that allows a
   given access only if some undecidable problem is solved would not
   be possible to implement. Thus,
   security policy expression requires some knowledge of the degree
   to which a given procedure is solvable.

2) whether a condition can be evaluated by the access control
   framework. If it requires interactions on application-specific
   level, then this condition should be evaluated by the application.

7.3.1.1 Proposed generic conditions that will appear in both ACLs
And credentials

The following list of conditions should not be considered exhaustive.

  a) time

     Time periods for which access is granted, e.g. time of day or
     day of the week

  b) location

     Location of the principal. Authorization is granted to the
     principals residing in specific hosts or domains.

  c) network connection

     Granting or denying authorization for specific routes.

  d) message protection constraints

     1) required confidentiality message protection
        This condition specifies a mechanism, or a set of
        mechanisms to be used in confidentiality message protection.

     2) required integrity message protection
        This condition specifies a mechanism, or a set of
        mechanisms to be used in integrity message protection.

  e) privilege constraints

    In general, a principal may belong to more than one group.
    By default, principal operates with the union of privileges of
    all groups to which it belongs, as well as all of his individual
    privileges.
    In assigning privileges, one can choose to:

      1) have the subject operate with the privilege of only one group
         at a time. This can be used to reduce privileges as a
         protection against accidents.
         E.g. a person is a member of two groups: PROGRAMMERS and
         SYSTEM_MANAGERS. The person may act with the privileges of the
         group PROGRAMMERS most of the time, and enable privileges of
         the SYSTEM_MANAGERS group only on occasion.

Ryutov/Neuman                               Expires February 1999


      2) have the subject operate with privileges of several specified
         groupsat a time

      3) endorsement
         Concurrence of N of M (N <= M) principals to perform some
         operation.

  f) multi-level security constraints

  Examples of using these conditions can be found in section 13.2.

  g) payment

  This restriction can be specified in two ways:

   1)  Specifies currency and amount that must  be paid prior
    access to an object will be granted, e.g. payment : $20.

   2)  Specifies currency and a formula for calculating the amount
    that must be paid for consumed resources, e.g. payment : $0.5_per_MB.
    The amount of consumed resources must be known to the authorization
    framework in order to evaluate the payment condition.

    A valid certificate, stating the amount and currency paid must
    be presented to the authorization framework.

  j) quota

   This restriction specifies a limit. It limits the quantity of a
   resource that can be consumed or obtained.
   For example, a remote printing application may use quota : 10_MB.
   This condition specifies maximum job size, expressed in mega bytes,
   that can be sent to a printer.

  k) strength of authentication

   Specifies the authentication mechanism or set of suitable
   mechanisms, used to authenticate a user, e.g.
   sec_mech : kerberos.V5.
   This restriction may be useful to specify default access, e.g.

   ANYBODY  < FILE:read
              FILE:write >       sec_mech : DCE ;

  This condition means that anyone, who has been authenticated by DCE
  has read and write access to the object.

  l) attributes of subjects

  This class of conditions defines a set of attributes that must be
  Possessed by subjects in order to get access to the object.

  Examples:


Ryutov/Neuman                               Expires February 1999

  A large-scale multicast application can use condition
  OS : SUN_Solaris_V2. This will restrict hosts running the wrong
  OS from to participating in a communication. Access will be granted
  if valid certificate, stating the OS running on the host will be
  presented to the authorization framework.

  A metacomputing application can specify condition
  application_endorser : Globus
  This will restrict applications that can be run on the node to only
  ones, certified by Globus authority.

  A filtering application can use condition age : >=18
  This will restrict access to some sites for underage users.
  The access will be authorized if valid certificate, stating the age
  of the user, is presented to the authorization framework.

7.3.1.2  Generic conditions appearing only in credentials

The authorization framework to make access control decision will
evaluate these conditions along with conditions in the matching ACL
entries. The following list of conditions should not be considered
exhaustive.

  a) grantee

     This restriction specifies a list of principals (users, groups,
     applications or hosts) authorized to exercise the credential.
     This condition will not appear in ACLs.

  b) issued for

     Restriction specifies set of servers authorized to
     accept the public-key credentials which otherwise verifiable by
     and exercisable on all servers.

  c) group membership

     This restriction specifies that the user is a member of only the
     listed groups.

  d) group non-membership

     This restriction specifies that the user is NOT a member of the
     listed groups. This may be useful if authorization specification
     explicitly denies access to a specific group.

  e) authorized

     This restriction specifies a complete list of objects which
     may be accessed using the rights granted by the credential and,
     optionally, a list of operations that may be performed on each
     object.

     This condition usually appears in credentials used as
     capabilities or in credentials, returned by an authorization server.

Ryutov/Neuman                               Expires February 1999

f) accept N times

     This condition specifies that the credential should be accepted
     no more than N times.

COMMENTS ON THE ADDITIONAL TYPES OF GENERIC CONDITIONS ARE SOLICITED.

7.3.2  Application-specific conditions

If generic conditions are not sufficient for expressing
application-specific security policies, applications specify their
own conditions.
Anything that can be expressed as type:value alphanumeric string can
be a condition. The application must provide a means for evaluation
of the application-specific conditions.

8. ACL evaluation

The ACL language we presented supports authorization models based on
the closed world model, when all rights are implicitly denied.
Authorizations are granted by an explicit listing of positive access
rights.
The framework also supports negative authorizations. If one allows
both negative and positive authorizations in individual or group
entries, inconsistencies must be resolved according to different
resolution rules.

The design approach we adopted allows the ordered interpretation of
ACLs. An ordered evaluation approach is easier to implement as it
allows only partial evaluation of ACL and resolves the authorization
conflicts.

Evaluation of ordered ACL starts from the first to the last in the
List of ACL entries. Evaluation stops either when all requested access
rights have been granted by one or more ACL entries, or when any one
of the requested access rights has been denied by one of the ACL
entries.

ACL entries containing principals that do not match the current
Subject identity and the identities that are associated with the subject,
stored in the security context, e.g. group memberships and delegated
credentials, have no effect on the outcome of the evaluation.

The resolution of inconsistent authorization is based on ordering.
The ACL entries that already have been examined take precedence
over new authorizations.

Conflicts may arise when more then one entry applies. For example,
one matching entry corresponds to a principal specifying individual
subject (user, host or application), and the second entry matching
a certain group name. In this case, one would expect the entry for
the individual subject to be placed before the  entry for the group,
on the assumption that the policy expressed by the individual subject
entry is an exception to the policy expressed by the group entry.
When several ACL entries with different conditions apply, the access

Ryutov/Neuman                               Expires February 1999

is based on the conditions in the first matching entry found. For
example, if these two entries apply:

USER  kerberos.v5 tom@ORG.EDU  < FILE : read  > time_window : 6AM-8PM ,
                                              time_day : Mon-Fri  ;

GROUP kerberos.v5 admin@ORG.EDU < FILE : read > time_window : 9AM-6PM ;

Then the resulting conditions to be checked by the authorization
framework are: time_window:6AM-8PM and time_day : Mon-Fri
The ACL entry must have either only positive or only negative access
rights.
ACL entries specifying negative rights must not have any conditions.

Other ACL interpretations are possible, such as unordered.

9. Security context

The security context is a GAA API data structure, which is passed as
an argument to the GAA API.
It stores information relevant to access control policy, e.g.
authentication and authorization credentials presented or used by the
peer entity (usually the client of the request), connection state
information. All credentials are  in the GAA API internal format.

The context consists of:

1) Identity

Verified authentication information, such as principal ID for a
Particular security mechanism.  To determine which entries apply,
the GAA API checks if the specified principal ID appears in an ACL
entry that is paired with a privilege for the type of access requested.

3) Authorized credentials
   This type of credentials is used when individuals grant delegated
   Credential or generate a capability.

3) Group membership
   This type of credentials specifies that the grantee is a member of
   only listed groups.

4) Group non-membership
   This type of credentials specifies that the grantee is NOT a member
   of listed groups.

5) Attributes
   This type of credentials contains  miscellaneous attributes
   attached to the grantee, e.g. age of the grantee, grantee security
   clearance.

6) Unevaluated Credentials
   Evaluation of the acquired credentials can be deferred till the
   credential is needed to perform the operation.


Ryutov/Neuman                               Expires February 1999

 7) Evaluation and Retrieval Functions for Upcalls

These functions are called to evaluate application-specific conditions,
to request additional credentials and verify them.
The GSS API is an example of how this is filled in.

8) Connection State Information

Containts a mechanism-specific representation of per-connection
context, some of the data stored here include keyblocks, addresses.

10. Credential evaluation

Credentials are parsed to the GAA API internal format and
placed into the GAA API security context.
When evaluating an ACL, the necessary credentials are looked
for in the security context.

Example
Assume the following ACL for the  file doc.txt is stored in the
authorization data base:

USER    kerberos.v5   tom@ORG.EDU   < FILE : read  > ;

GROUP   kerberos.v5  admin@ORG.EDU  < FILE : read
                                      FILE : write >  ;

USER    kerberos.v5   joe@ORG.EDU   < FILE : write> ;

Assume the following credentials are stored in the security context
associated with the user Tom:

a)  identity credential

grantee: USER  kerberos.v5  tom@ORG.EDU
conditions: time_window : 06/07/98 19:49:21  06/08/98 05:49:19

b) group membership credential

member of: GROUP    kerberos.v5   admin@ORG.EDU
conditions:  privilege:constrained

c) unevaluated credential

cred_type:  GAA_AUTHORIZED
mech_type: DCE
grantor: USER DCE 88
grantee: USER DCE 99
mech_spec_cred: [DCE-specific credential]

c) authorized credential

grantor: USER    kerberos.v5   joe@ORG.EDU
grantee: USER    kerberos.v5   tom@ORG.EDU
objects: doc.txt

Ryutov/Neuman                               Expires February 1999

Operations: FILE:write
conditions: location : *.org.edu

Let's consider a request from a user Tom who is connecting from
the ORG.EDU domain to write to the file doc.txt on 06/07/98 20.10.01.

In evaluation the ACL the first entry does not grant the required
operation, the second entry grants it The evaluation function will
check the security context for the group membership credential.
The proper credential is found, however, there is a condition privilege:constrained.
It means that Tom can use this privilege only if logged in as an
administrator. Evaluation continues. The third entry grants the
requested operation. The evaluation function will look for authorized
credential for USER kerberos.v5 tom@ORG.EDU issued by
USER kerberos.v5 joe@ORG.EDU.
The appropriate authorized credential is found and it grants the
requested operation. The condition location:*org.edu is satisfied,
so the requested access will be granted.

10. Architecture

The major components of the architecture are:

Authentication mechanisms (perhaps involving an authentication
server) perform authentication of users and supply them with
initial credentials.

A group server is trusted to maintain and provide group membership
information. A group is a convenient method to associate a name with
a set of principals for access control purposes. A group server issues
group membership and non-membership certificates. When a connection is
established with an application server, these certificates are evaluated
(evaluation may be deferred until needed) the results are placed into
the GAA API security context. They are checked by the GAA API when
making authorization decisions.

The application calls the GAA API routines to check authorization
against the application authorization model.
These routines obtain access control list entries from local
files, distributed authorization servers, and from credentials
provided by the user, combining local and distributed authorizations
under a single API according to the requirements of the application.

Delegation is supported through inclusion of delegation
credentials. Mechanism for delegation such as those supported by
restricted proxies [1] in the security context, where they are
available for use by authentication and authorization mechanisms
used for subsequent connections from the server (now acting as an
intermediary) to another server.

Conditions can be embedded in authorization credentials or
certificates.
The restrictions or conditions carried in a certificate are
evaluated by the GAA API in addition to the restrictions in the

Ryutov/Neuman                               Expires February 1999

matching ACL entry.

11. Generic Authorization and Access API

The GAA API is built into applications through a library.
It is used by applications to decide whether a subject
is authorized to perform particular operations on an object.  In
this section we provide a brief description of the main GAA API
routines.

11.1 GAA API functions

The gaa_get_object_eacl function is called before other
GAA API routines which require a handle to an object ACL to identify
ACLs on which to operate.

Input:

o  Reference to the object to be accessed

The identifier for the object is from an application-dependent name
space, it can be represented as unique object identifier, or symbolic
name local to the application.

o  Pointer to application-specific authorization database

o  Upcall function for the retrieval of the object ACL.

   The application maintains authorization information in a form
   understood by the application.  It can be stored in a file,
   database, directory service or in some other way. The upcall
   function provided for the GAA API translates this information
   into the internal representation understood by the GAA API.

Output:

o  Mechanism-specific status code

o  A handle to the list of ACLs associated with the protected object.

The gaa_check_authorization function tells the application
server whether the requested operation is authorized, or if
additional application-specific checks are required.

Input:

o  A handle to the object ACL, returned by
   gaa_get_object_eacl

o  Principal's security context

o  Operations for authorization
   This argument is optional, it indicates operations to be
   performed.


Ryutov/Neuman                               Expires February 1999

o GAA API options structure
This argument describes the behavior of the GAA API and specifies
how the other arguments should be interpreted. For example, type of
the ACL: ordered or unordered.  Depending on this type corresponding
ACL evaluation algorithm will be used be the GAA API.

Output:


YES   (indicating authorization) is returned if all requested
      operationsare authorized.

NO    (indicating denial of authorization) is returned if at least one
      operation is not authorized.

MAYBE (indicating a need for application-specific checks) is returned
      if there are some unevaluated conditions and additional
      application-specific checks are needed, or continuous
      evaluation is required.

o  Mechanism-specific status code

o  Detailed answer


Ryutov/Neuman                               Expires February 1999

Detailed answer contains:

   o   Authorization valid time period.
       The time period during which the authorization is granted is
       returned as condition to be checked by the application.
       Expiration time is calculated by GAA API, based on:
       time-related conditions in the object ACL matching entries

   o   Restrictions in the authentication, authorization and delegated
       credentials.

   o   List of all authorized rights and corresponding conditions,
       if any. Each condition is marked as evaluated or not evaluated,
       if evaluated marked as met or not met.

   o   Information about additional security attributes required.
       Additional credentials might be required from clients to
       Perform certain operations, e.g. group membership or delegated
       credentials.

If no operation was specified as an input, a list of authorized
rights and corresponding conditions, if any, is returned.  This allows
application to discover access control policies associated with
the target object.

The application must understand the conditions that are returned
unevaluated or it must reject the request.
If understood, the application checks the conditions against

Ryutov/Neuman                               Expires February 1999

information about the request, the target object, or environmental
conditions to determine whether the conditions are met. Enforcement
of the returned conditions is up to the application.

12. Creation of the GAA API security context

Prior to calling the gaa_check_authorization function, the
application must obtain the authenticated principal's identity
and store it in the security context.  This context may be
constructed from credentials obtained from different mechanisms,
e.g. GSS API, Kerberos or others.

Figure 1 shows the flow of control:
Application calls requesting the principal's identity (1);
the request and the verification of the principal's
identity credentials take place (2, 3);
The principal's authentication credentials are placed in the
security context (4a) and returns it to the application (4);
the application calls the GAA API (5); the security context,
containing the verified principal's identity is being passed into
the GAA API (5a).


|-----------------------|     5       |----------------------|
|     Application       |------------>|       GAA API        |
|----------|-^----------|             |-----------^----------|
        1  | | 4                               5a |
|----------V-|----------|     4a      - - - - - - |- - - - - - -
|    Security API       |------------>|    Security Context    |
|----------|-^----------|             - - - - - - - - - - - - -
        2  | | 3
|----------V-|----------|
|   Security Server     |
|-----------------------|
                               Figure 1



This scenario places a heavy burden on the application programmer
to provide the integration of the security mechanism with the
application.
A second scenario is to obtain the authentication
credentials from a transport protocol that already has the
security context integrated with it. For example, the application
can call SSL, and authenticated RPC, or the  Asynchronous Reliable
Delivery Protocol (ARDP), a communications protocol which handles
several security services including authentication, integrity and
payment. In this case, it is the implementation of the transport
mechanism (usually written by someone other than the application
programmer) which calls the security API requesting principal's
identity, and which constructs the security context.
The principal's authentication information is placed into the
security context and is passed to the GAA API. When additional security
attributes are required for the requested operation, the list of
required attributes is returned to be obtained by the application. The

Ryutov/Neuman                               Expires February 1999

application may provide GAA API with an upcall function for requesting
required additional credentials.
The credentials pulled by the GAA API are verified and added to
the security context by the upcall function. A reference to the
upcall function is passed to the GAA API as part of the security
context, and it is added to the security context by the application
or transport.


13.  Emulation of various security models

The following are examples of using proposed authorization framework
to express various access control models.

13.1  Open world model example

The open world model is practical when access to an object is granted
to a number of principals, and access denied to a few principals.
Instead of listing all principals and groups of principals with
corresponding positive rights, it is more convenient to make access


default and specify only principals with the negative rights.
This will save space and makes evaluation of ACL more efficient.

The open world model, which is based on implicit granting of all
rights, and listing of only negative authorizations can be represented
in this framework by including  ANYBODY * as the final entry in
an ACL (if ordered ACL interpretation is used). This will grant
everybody all rights regardless of authentication. Denial of rights
is then specified using negative rights in entries earlier in the ACL.


13.2 Mandatory  Security security models

It is intended, that proposed framework will allow incorporation of
multi-level security models.
Mandatory policies govern access on the basis of classification of
subjects and objects in the system.

These subjects and objects are assigned sensitivity labels that
Denote their hierarchical sensitivity and need-to-know attributes.
Specifically, a security label consists of two components: a
hierarchical security level and a possibly empty set of nonhierarchical
security categories.

For example, in the military, the set of levels consists of
Unclassified, Confidential, Secret, and Top secret. Set of categories
may consist of NATO, NASA, NOFORN.

In commercial environments, these levels might be Restricted,
Proprietary, Sensitive, and Public. Set of categories: Department1,
Department2 and Department3.
Security label that denotes the security sensitivity of a subject is
called CLEARANCE.

Ryutov/Neuman                               Expires February 1999

Security label that denotes the security sensitivity of an object is
called CLASSIFICATION.

A security label DOMINATES another when its security level component
is grater then or equal to the other's security level component and
when its set of security categories is a superset of the other's
security categories component.

For example, security label  Top Secret/NATO,NASA  dominates
security label  Confidential/NASA.
Neither of the following two security labels dominates the other:
Top Secret/NATO,NASA  and  Secret/NOFORN.

Mandatory Confidentiality Rules:

Read down:   A subject's security label must dominate the security
             label of the object being read.

Write up:    Subject's  security label must be dominated by the

Label of the object being written.


Mandatory Integrity Rules:

The hierarchy of the labels is based on the integrity rather
then disclosure-oriented security.

Read up:     A subject's integrity label must be dominated by the
             Integrity label of the object being read.

Write down:  Subject's  integrity label must dominate the label
             of the object being written.

Implementation of both Mandatory Confidentiality and Integrity rules
can be based on a single security level for both confidentiality and
integrity.
This would result in a read-equal and write-equal rules. The
drawback is reduced flexibility of the resulting system.

13.2.1 Implementing the mandatory security within proposed
       authorization framework

This section describes labeling requirements for objects, subjects
and access rights.

13.2.2  Labeling of objects and subjects

Objects and subjects are assigned security labels.
There are three label classes:

 a) Confidentiality labels, e.g. Top_Secret/NASA, Sensitive/Department2

 b) Integrity labels, e.g. High_integrity, Low_integrity


Ryutov/Neuman                               Expires February 1999

c) Single security labels for both confidentiality and

    integrity, e.g. Top_Secret/NASA,  Unclassified (assume that the
    first label denotes high integrity level, whereas the second one
    denotes low integrity level).

Newly created objects are labeled by the security label of the subject
that created the object, in order to prevent possible information flows
between the security levels, which violates mandatory security policies.

The creator of the object must not have the ability to change any
attribute of the object or change access permissions to the object.
Only the authorized system administration authority is the owner of the
all objects in the security domain, including newly created, and have
full control over the object security attributes as well as control
permissions to it.

There may be no mandatory controls on accessing objects categorized as
Unclassified or Public, e.g. public bulletin boards. Access to these

objects may be restricted by DAC mechanisms.

To prove eligibility to access an object, a subject has to present
a valid credential, stating subject's security label.


13.2.3 Labeling of access rights

All access rights are divided into read-class and write-class.
Appropriate rules are applied to each class. The rules are expressed
through generic conditions.

13.2.4 Generic conditions for read-class access rights

 a) conf_read_equal : cofidentiality_label

 This condition specifies that a subject, wishing to get read-class
 access to the object has to have security clearance equal to the one,
 specified in the cofidentiality_label field.

 b) conf_read_below : cofidentiality_label

 This condition is used to enforce "read down"  mandatory confidentiality
 rule. It specifies that a subject, wishing to get read-class access to
 the object has to have security clearance no less the one, specified in
 the cofidentiality_label field.

 c) integr_read_equal : integrity_label

 This condition specifies that a subject, wishing to get read-class access
 to the object has to have security clearance equal to the one, specified
 in the integrity_label field.

 d) integr_read_above : integrity_label


Ryutov/Neuman                               Expires February 1999

This condition is used to enforce "read up"  mandatory integrity rule.
It specifies that a subject, wishing to get read-class access to the
object has to have integrity clearance no less then the one, specified
in the integrity_label field.


13.2.5 Generic conditions for write-class access rights

 a) conf_write_equal  : cofidentiality_label

 This condition is used to enforce restricted "write up" mandatory
 confidentiality rule to avoid "blind writes" [?].
 It specifies that a subject, wishing to get write-class access to the
 object has to have security clearance equal to the one, specified
 in the cofidentiality_label field.

 b) conf_write_above  : cofidentiality_label

 This condition is used to enforce "write up" mandatory confidentiality
 rule. It specifies that a subject, wishing to get write-class access to
 the object has to have security clearance equal or greater then the one,
 specified in the cofidentiality_label field.

 c) integr_write_equal  : integrity_label

 This condition specifies that a subject, wishing to get write-class
 access to the object has to have security clearance equal to the one,
 specified in the integrity_label field.

 d) integr_write_below  : integrity_label

 This condition is used to enforce "write down" mandatory integrity
 rule. It specifies that a subject, wishing to get write-class
 access to the object has to have integrity clearance equal or greater
 then the one, specified in the integrity_label field.

13.2.6. Example

Assume file doc.txt has classification Sensitive/Departmen1 and
integrity label Medium, then ACL for this file can be specified as:

ANYBODY         FILE:read    conf_read_below:Sensitive/Department1
                             integr_read_above:Medium    ;

ANYBODY         FILE:write   conf_write_above:Sensitive/Department1
                             integr_write_below:Medium   ;

Note that the example above allows everybody in the distributed system
to get read or write access to the file doc.txt if valid credential
stating appropriate security label attribute is presented.
This pose a requirements for security labels to be unique across
Different security domains. This may not be easily satisfied.
There should be a way to restrict  scope of the security labels to
a particular administrative domain.
A possible solution can be specifying an additional condition, e.g.

Ryutov/Neuman                               Expires February 1999

location:*.org.com. Another solution may be using  wildcard symbol in
the principal's ID specification  instead of ANYBODY),
e.g. USER  Kerberos.V5  *@ORG.COM.


13.3  Extended example: simple Printer Manager application

To illustrate the flow of control involved in use of GAA API by
application servers we describe a simple Printer Manager application,
where protected objects are printers. The Printer Manager accepts
requests from users to access printers and invokes the GAA API
routines to make authorization decisions, under the assumption that
the administrator of the resources has specified the local policy
regarding the use of the resources by means of ACL files.
These files are stored in an Authorization Database, maintained by the
Printer Manager.


13.3.1 Conditions

Administrators will be more willing to grant access to the
printers if they can restrict the access to the resources to users or
organizations they trust.  Further, the administrators should be
able to specify time availability, restrictions on resources consumed
by the clients and accounting for the consumed resources. To specify
these limits, the Printer Manager uses generic and specific ACL
conditions.

The following are the examples of generic conditions, that might be
used by the Printer manager application to express security policies:

a) Time window, expressed as a time interval within which access
   to printer is allowed.
   Example: time_window : 8AM-6PM

b) Time window, expressed as days of week when access to the
   printer is allowed.
   Example: time_day : Monday-Friday

c) Location, expressed as hosts from which the access is allowed.
   Example: location : DNS_*_ORG.EDU

d) Payment required prior to submitting print job
   Example: payment  : $0.05/page

e) Quota, such as job size, expressed as maximum size in mega bytes.
   Example: quota : 10_MB

The following are the examples of application-specific conditions,
that might be used by the Printer manager application to express
security policies:

a) Printer load, expressed as maximum number of jobs that allowed to
   be submitted to a printer.
   Example: printer_load : 20

Ryutov/Neuman                               Expires February 1999

b) While a job is waiting to be printed or has been started but
   not yet completed, the original submitter shall be able to
   cancel the job entirely. The condition specifies who can perform
   this operation.
   Example: who : owner

13.3.2 Authorization walk-through

Here we present two authorization scenarios to demonstrate the use
of the authorization framework for the case of printing a document.
Assume Kerberos V5 is used for principal authentication. Assume that
printer ps12a has the following ordered ACL, stored in the Printer
Manager Authorization Database:


USER  kerberos.v5  tom@ORG.EDU
               < PRINTER : submit_print_job >  time_window  : 8AM-8PM
                                               printer_load : 20   ;

GROUP kerberos.v5 operators@ORG.EDU
USER  kerberos.v5 john@ORG.EDU     < PRINTER : * >
                                   < DEVICE  : * >  ;

ANYBODY   < PRINTER: view_printer_capabilities >  ;


Let's consider a request from user Tom who is connecting from the
ORG.EDU domain to print a document on the printer ps_12a on Monday
at 7:30 PM.
When a client process running on the behalf of user "Tom" contacts a
Printer Manager with the request to submit_print_job to printer
"ps_12a", the Printer Manager first calls  gaa_get_object_eacl
function to obtain a handle to the ACL of printer "ps_12a".
The upcall function for retrieving the ACL for the specified object
from the authorization database system is passed to the GAA API and
is being called by gaa_get_object_eacl, which returns the ACL handle.

The printer manager must place the principal's authenticated identity
in the security context to pass into the gaa_check_authorization
function. This context may be constructed according to the first or
second scenario, described in Section 12.

If Tom is authenticated successfully, then the verified identity
credential is placed into the security context, specifying Tom as the
Kerberos principal tom@ORG.EDU.
The gaa_check_authorization function is called by the Printer Manager,
which asks if "Tom" is authorized to submit_print_job to printer
"ps_12a". In evaluating the ACL, the first entry applies. It grants
the requested operation, but there two conditions that must be evaluated.

The first condition time_window : 8AM-8PM is generic and is evaluated
directly by the GAA API. Since, the request was issued on Monday at
7:30 PM this condition is satisfied.
The second condition printer_load : 20 is Printer Manager-specific.
If the security context passed by Printer Manager defined a condition

Ryutov/Neuman                               Expires February 1999

evaluation function for upcall, then this function is invoked and if
this condition is met then the final answer is YES (authorized) and
detailed answer contains:

Authorization expiration time : 8PM
Assume that authentication credential has expiration time 9PM.
Allowed operation:  submit_print_job
List of conditions: time_window    : 8AM-8PM
                    printer_load   : 20
Both conditions are marked as evaluated and met.

During the execution of the task the Printer Manager is enforcing

the limits imposed on the local resources and authorization time.

If the corresponding upcall function was not passed to the GAA
API, the answer is MAYBE and detailed answer contains:

Authorization expiration time : 8PM
Allowed operation:   submit_print_job
List of conditions:  time_window    : 8AM-8PM
                     printer_load   : 20

The first condition is marked as evaluated and met; the second
condition is marked as not evaluated and must be checked by the
Printer Manager.

Next, we present an authorization scenario where additional credentials
are needed. Let's consider a request from the same user Tom to change
priority of the job he has successfully submitted on the printer ps_12a
on Monday at 7:31 PM.
The Printer Manager calls the  gaa_check_authorization function with the
request for user "Tom" to change_print_job_attributes on printer "ps_12a".

In ACL evaluation, the first entry applies but does not grant this
operation. The temporary answer is NO (not authorized). The second entry
grants this permission. If the security context defines a credential
retrieval function for upcall, then this function is invoked and if either
a group "operators" membership credential or delegated credential from
user "John" for "Tom" is obtained, then the final answer is YES.
If the credential retrieval upcall function was not passed to the
GAA API, the answer is NO.


14.  References

[1] B.C. Neuman.
    Proxy-based authorization and accounting for distributed systems.
    Proceedings of the 13th International Conference on Distributed
    Computing Systems, Pittsburgh, May 1993.

[2] B.C. Neuman and Theodore Ts'o.
    Kerberos: An authentication service for computer networks.
    IEEE Communications Magazine, pages 33-38, September 1994


Ryutov/Neuman                               Expires February 1999

[3] M. Blaze, J. Feigenbaum and J. Lacy.
    Decentralized Trust Management.
    in Proc. IEEE Symp. on Security and Privacy, IEEE Computer Press,
    Los Angeles, pages 164-173, 1996.

[4] Large Scale Multicast Applications (lsma) working group.
    Taxonomy of Communication Requirements for Large-scale Multicast
    Applications.
    Internet draft.

[5] Department of Defence National Computer Security Center.

    Department of Defence Trusted Computer system Evaluation Criteria,
    December 1985. DoD 5200.28-STD


15.  Acknowledgments

Gene Tsudik, Brian Tung, Bapa Rao, Ilia Ovsiannikov and the Xerox IS
team have contributed to discussion of ideas and material in this
draft.

16.  Authors' Addresses

Tatyana Ryutov
Clifford Neuman
USC/Information Sciences Institute
4676 Admiralty Way Suite 1001
Marina del Rey, CA 90292-6695
Phone: +1 310 822 1511
E-Mail: {tryutov, bcn}@isi.edu









Ryutov/Neuman                               Expires February 1999