%\documentstyle[subfigure,psfig]{article}
\documentclass[twocolumn,10pt]{article}
\usepackage{graphics}
\begin{document}

\title{Representation and Evaluation of Security Policies for
 Distributed System Services}
\author{Tatyana Ryutov and Clifford Neuman \\
       \textit{Information Sciences Institute \\
       University of Southern California  \\
       4676 Admiralty Way suite 1001  \\
       Marina del Rey, CA 90292 \\ 
       \{tryutov, bcn\}@isi.edu\\
       (310)822-1511 (voice) (310)823-6714 (fax)}\\
       }

\maketitle

\begin{abstract}

\textit{ 
We present a new model for authorization that integrates both
local and distributed access control policies and that is extensible
across multiple applications and administrative entities.
We introduce a general mechanism that is capable of implementing multiple
security policies including role-based access control, Clark-Wilson, ACLs, 
capabilities, and lattice-based access controls.
The Generic Authorization and Access-control API (GAA API) provides a 
general framework for applications to facilitate access control decisions 
and request authorization information about a particular resource, thus 
making our model application-independent.  We have integrated our system 
with the Prospero Resource Manager and Globus Security Infrastructure.}
\end{abstract}

%-----------------------------------------------------------------------

\section{1.Introduction}

The conventional concept of an Access Control List (ACL) has been
the architectural foundation of many authorization mechanisms for some
time. A typical ACL is associated with an object to be protected
and enumerates the list of authorized users and their rights to
access an object. Access rights are selected from a predefined fixed set
built into the authorization mechanism. Specification of the subjects
is bound to the particular security mechanism employed by the
system. The limitations of the traditional access control model become
apparent when it is applied in a heterogeneous, administratively
decentralized, distributed system environment.

The variety of services available on the Internet continues to increase
and new classes of applications such as metacomputing, remote printing, 
and video conferencing are evolving. These applications will require
interactions between entities across autonomous security domains.

The generic traditional access rights may not be sufficient for
some applications to express their authorization requirements. For
example, a site might be willing to make its resources available to others
limited to a maximum amount of CPU time and memory or based on a
requirement of payment for the resources consumed. It is difficult to
specify such security policies in terms of conventional ACLs.

Specification of security policies for principals from multiple 
administrative domains poses additional problems:

\begin{itemize}

\item  In a multipolicy environment, policy integration should
incorporate the diverse authorization models that can coexist in a distributed system.

\item  The implementation will require integration of different sets of policies associated 
with the domain providing resources, the domain requesting resources and the individual users within each domain.

\item There are multiple mechanisms for authentication of users
in different domains. Therefore, there may be no single syntax
for specification of principals.

\item Administrators of each domain might use domain-specific policy 
 syntax and heterogeneous implementations of the policies. Generalizing the 
 way that applications define their security requirements provides the means 
 for integration and translation of security policies across multiple
 authorization models.

\end{itemize}

This paper describes an authorization framework designed to meet
these needs. Our framework is applicable for a wide range of systems
and applications. It includes a flexible mechanism for security
policy representation and provides the integration of local and
distributed security policies. The system supports the common authorization
requirements and provides the means for defining and integrating
application or organization specific policies as well.
We show how this mechanism can implement role-based access control, 
Clark-Wilson model, and lattice-based policies.

Our framework consists of two components, a policy language and the
Generic Authorization and Access-control API.

\begin{itemize}

\item Policy language

The language allows us to represent existing access control models 
(e.g. ACL, capability, lattice-based access controls) in a uniform and 
consistent manner.
Authorization restrictions allow the administrator to define which
operations are allowed, and under what conditions (e.g., user
identity, group membership, or time of day).
These restrictions may implement application-specific
policies.

\item Generic Authorization and Access-control API (GAA API)

A common access control API facilitates the application integration of
authentication and authorization.  This API allows
applications to request the authorization policy information for a
particular resource and to evaluate this policy against credentials
carried in the security context for the current connections.  
Applications invoke the GAA API functions to determine if a requested 
operation or set of operations was authorized or if additional checks 
are necessary.

\end{itemize}


%-----------------------------------------------------------------------

\section {Related Work}

There has been other recent work on access control models for
Internet user agents \cite{nagaratnam}, \cite{gong}. These models are restricted
to using the Javakey utility as an authentication mechanism based on public key
digital signatures, while our model is general enough to use a variety of
security mechanisms based on public or secret key cryptosystems. 
Also, our model is application-independent whereas the models in
\cite{nagaratnam} and \cite{gong} are targeted specifically at browser-like 
applications.

The Generalized Access Control List (GACL) framework described by Woo
and Lam \cite{lam} presents a language-based approach for specifying
authorization policies. The main goal of the GACL framework is merging policies associated with
different objects with complex dependencies. GACL allows specification of 
the inheritance rules; access rights can be propagated from one object to 
the other. A gacl may reference other gacl in its entries. The benefit of
this scheme is the ability to omit redundant information at the cost of of retrieval and evaluation of more then one gacl.
Specification of policy dependencies with inheritance is error-prone
and may result in circular dependency of the policies and inconcistent authorizations. 
More importantly, the expressive power of GACL is limited to an ACL-based 
schemes and provides no support for capabilities and multi-level security systems.

The GACL model supports only system state-related conditions within which
rights are granted, such as current system load and maximum number of copies of 
a program to be run concurrently. This may not be sufficient for distributed 
applications. Our model allows fine-grained control over the conditions.

Policy management issues were addressed by Blaze, et al \cite{blaze}. 
The authors claim that a system using the PolicyMaker has strengthened security 
because the PolicyMaker credentials bind granted rights to public keys, rather 
then identities, thus eliminating one level of indirection.
This is not the case if the system uses X.509 or PGP certificates, the
most widely used certificates, because the application is responsible for translating them to the PolicyMaker format.

Policies in the PolicyMaker format can be easily expressed in our
framework. We think about security policies as a set of operations
that subjects are allowed to perform on the targeted objects, and optional 
constraints are placed on the granted operations.
The purpose of access control is to protect objects from unauthorized access. 
The basic question is whether this subject is allowed to perform the 
requested operation. 
The GAA API provides a common interface for asking this question and it is
as simple as setting an appropriate bit.

In contrast, to use PolicyMaker an application developer must define 
an application-specific language describing the requested operation.
The language may not be reusable across different application domains
and it forces developers to reinvent the weel. 

Both policy evaluation mechanisms, GACL and PolicyMaker, are static. Decisions 
are based on a set of policies and credentials presented at the time of the
request. In contrast, our framework allows dynamic policy evaluation. Additional credentials can be obtained during recursive evaluation within 
the GAA API. 



%-----------------------------------------------------------------------

\section{Overview of the Framework}

Our framework is applied to distributed systems that span multiple 
autonomous administrative domains without a central management
authority. Applications may impose their own security policies
and use different authentication services, e.g. Kerberos, DCE or X.509 certificates. 
We assume that within a distributed system, multiple independent
applications coexist. The individual security requirements of each
application are reflected in application-specific security policies.
There might exist common ACLs that apply to sets of applications. 
Therefore, we wanted to design a flexible and expressive mechanism for
representing and evaluating authorization policies. It had to be
general enough to support a variety of security mechanisms based
on public or secret key cryptosystems, and it had to be usable by
multiple applications supporting different operations and even different
kinds of protected objects.

The major components of the architecture are: 

\begin{itemize}

\item Authentication mechanisms perform authentication of users and supply them with initial credentials. 

\item A group server that maintains group membership information.

\item GAA API. Applications call GAA API routines to check 
authorization against its authorization model.
The API routines obtain policies from local files, distributed authorization servers, and from credentials provided by the user. They combinine local and distributed authorizations under a single API according to the requirements 
of the application.


\item Delegation is supported through inclusion of delegation
credentials, such as those supported by {\it restricted proxies} \cite{neuman-proxy}.

\end{itemize}


%-----------------------------------------------------------------------

\subsection{Policy Language} 

The security policy associated with a protected resource
consists of a set of allowed operations, a set of approved principals, and 
and optional operation constraints. For example, a system administrator can define the 
following security policy to govern access to a printer: "Joe Smith 
and members of Department1 are allowed to print documents Monday 
through Friday, from 9:00AM to 6:00PM".
This policy can be described by an ACL mechanism, where for each resource,
a list of valid entities is granted a set of access rights.
The same policy can be implemented using a capability mechanism.
However, traditional ACL and capability abstractions should be extended
to allow conditional restrictions on access rights.

Therefore, in implementing a policy, it should be possible to 
define: \\
1) access identity \\  
2) grantor identity \\
3) a set of access rights \\
4) a set of conditions \\
The policy language represents a sequence of tokens. Each
token consists of:

\begin{itemize}

\item {\tt Token Type} 
      
     Defines the type of the token. Tokens of the same type 
     have the same authorization semantics.  
      
\item {\tt Defining Authority}
      
     It indicates the authority responsible for defining the value 
     within the token type. 

\item {\tt Value} 
      
     The value of the token. Its syntax and semantics are determined by 
     the token type. The name space for the value is defined by
     the {\tt Defining Authority} field.    
\end{itemize}
The rest of this section describes the user-level representation of
the policy language tokens, which can be used to implement both
ACLs and capabilities. More precise syntax is given in the Appendix. 



%-----------------------------------------------------------------------

\subsubsection{Specification of Access Identity} 

The access identity represents an identity to be used for access 
control purposes. The authorization framework supports the 
following types of access identity: {\tt USER}, {\tt HOST}, {\tt APPLICATION}, 
{\tt CA} (Certification Authority), {\tt GROUP} and {\tt ANYBODY}. Where 
{\tt ANYBODY} represents any entity regardless of authentication. This may 
be useful for setting the default policies.
The type of access identity is useful in determining which additional credentials
are needed (see section 3.3). Principals can be aggregated into a single entry 
when the same set of access rights and conditions applies to all of them.

Our framework supports multiple existing principal naming 
methods. Different administrative domains might use different 
authentication mechanisms, each having a particular syntax for 
specification of principals. Therefore, {\tt Defining Authority}
for access identity indicates the underlying authentication mechanism used 
to provide the principal identity. Value represents the particular 
principal identity.

\subsubsection{Specification of Grantor Identity} 

The grantor identity represents an identity used to specify the 
grantor of a capability or a delegated credential. Its structure is
similar to the one of the access identity described in the previous 
subsection.

\subsubsection {Specification of Access Rights}

It must be possible to specify which principals or groups of principals are 
authorized for specific operations, as well as who is explicitly
denied authorizations, therefore we define positive and negative access rights. 

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

\begin{tabular}{llr}
{\tt Token Type:} {\sl pos\_access\_rights }\\
{\tt Defining Authority:} {\sl local\_manager}\\
{\tt Value:} {\sl FILE:read,write,execute }\end{tabular} \\
 
However, in a bank application, an object might be a customer 
account, and the following set of operation might be defined:


\begin{tabular}{llr}
{\tt Token Type:} {\sl pos\_access\_rights }\\
{\tt Defining Authority:} {\sl local\_manager}\\
{\tt Value:} {\sl ACCOUNT:deposit,withdraw,transfer }\end{tabular} 
Internally, a tagged bit vector represents access rights.
Each bit in the vector corresponds to an access right. 

The tag indicates how the bits in the bit vector are to be interpreted.
In the examples above, for the set of rights associated with the tag {\sl FILE} the first bit should be interpreted as {\sl read}, while for the set associated
with tag {\sl ACCOUNT}, the same bit should be interpreted as {\sl deposit}.
 
\subsubsection {Specification of Conditions} 

Conditions specify the type-specific policies under which an operation can 
be performed on an object. A condition is interpreted according to its type. 
Conditions can be categorized as generic or specific. Generic conditions are 
evaluated by the access control model; specific conditions are application-dependent and usually are evaluated by the application. 

 These are several of the more useful generic conditions \cite{neuman-proxy}.

\begin{itemize}

  \item \textbf{time} 

     Time periods for which access is granted. 

  \item  \textbf{location}

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

  \item  \textbf{message protection}

     Required confidentiality/integrity message protection.
     This condition specifies a mechanism, or a set of 
     mechanisms to be used in confidentiality/integrity message protection.
  
  \item  \textbf{privilege constraints} 

  Specifies well-formed transactions and separation of duty constraints. 
  For more details see Section 8.

  \item  \textbf{multi-level security constraints} 

  Specifies mandatory confidentiality and integrity constraints. For more 
  information see Section 9.

  \item  \textbf{payment}

    Specifies currency and amount that should be paid prior
    access to an object will be granted.

\item  \textbf{quota}

   Specifies a currency and a limit. It limits the quantity of a resource 
   that can be consumed or obtained.

  \item \textbf{strength of authentication}

   Specifies the authentication mechanism or set of suitable mechanisms,
   for authentication. 

  \item  \textbf{trust constraints} 

 Specifies restrictions placed on security credentials. For more information see 
 Section 6.

  \item \textbf{attributes of subjects}

  Defines a set of attributes that must be possessed by subjects in order to 
  get access to the object, e.g. security label. 

 \end{itemize}


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


%-----------------------------------------------------------------------


\subsubsection {Extended Access Control Lists (EACLs)} 

Extended Access Control Lists (EACLs) extend the conventional ACL concept
by allowing one to specify conditional authorization policies. These are
implemented as conditions on authentication and authorization credentials.
An EACL is associated with an object and lists the subjects allowed 
to access this object and the type of granted access.
For example, the following EACL implements policy stating that
anyone authenticated by Kerberos.V5 has read access to the 
targeted resource and any member of group 15 connecting from 
the {\tt USC.EDU} domain has read and write access to the object.


\begin{tabular}{llr}
{\tt Token Type:}  {\sl access\_id\_ANYBODY }\\
{\tt Defining Authority:} {\sl none}\\
{\tt Value:} {\sl none }\end{tabular} 
\vspace{.3cm}

\begin{tabular}{llr}
{\tt Token Type:} {\sl pos\_access\_rights }\\
{\tt Defining Authority:} {\sl local\_manager}\\
{\tt Value:} {\sl FILE:read }\end{tabular} 
\vspace{.3cm}
 
\begin{tabular}{llr}
{\tt Token Type:} {\sl authentication\_mechanism}\\
{\tt Defining Authority:} {\sl  system\_manager}\\
{\tt Value:} {\sl kerberos.V5} \end{tabular} 
\vspace{.3cm}

\begin{tabular}{llr}
{\tt Token Type:} {\sl access\_id\_GROUP} \\
{\tt Defining Authority:} {\sl DCE} \\
{\tt Value:} {\sl 15} \end{tabular} 
\vspace{.3cm}

\begin{tabular}{llr}
{\tt Token Type:} {\sl pos\_access\_rights }\\
{\tt Defining Authority:} {\sl local\_manager }\\
{\tt Value:} {\sl FILE:read FILE:write } \end{tabular} 
\vspace{.3cm}

\begin{tabular}{llr}
{\tt Token Type:} {\sl location }\\
{\tt Defining Authority:} {\sl system\_manager} \\
{\tt Value:} {\sl *.USC.EDU }\end{tabular} \\

 The framework supports various strengths of user authentication 
mechanisms. A user may be granted a different set of rights, depending on the strength 
of the authentication method used for identification.

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

The objects that need to be protected include files, directories, network 
connections, hosts, and auxiliary devices, e.g. printers and faxes.
An authorization mechanism  supports these different kinds of objects in 
a uniform manner. The same EACL structure can be used to specify access policies
for different kinds of objects.
Object names are drawn from the application-specific name space and are
opaque to the authorization mechanism.

When aprotected object is created, it requires the association of an EACL. 
The management of EACLs, including giving authority to modify EACL, is supported
through inclusion of entries specifying which principals are allowed to modify 
the EACL. The control permissions comprise a separate set of access rights 
named with the tag {\sl MANAGEMENT}. To restrict the ability to pass the 
control permissions to others a condition {\sl no\_delegation } can be specified.

\subsubsection {Capabilities}

Here we present here an implementation of a capability. The example  states that the capability granted by the group {\sl admin} permits read access if the capability is presented 
during the specified time period.\\

\begin{tabular}{llr}
{\tt Token Type:} {\sl grantor\_id\_GROUP }\\
{\tt Defining Authority:} {\sl kerberos.V5 }\\
{\tt Value:} {\sl admin@USC.EDU } \end{tabular} 
\vspace{.3cm}

\begin{tabular}{llr}
{\tt Token Type:} {\sl pos\_access\_rights}\\
{\tt Defining Authority:} {\sl local\_manager} \\
{\tt Value:} {\sl FILE:read } \end{tabular} 
\vspace{.3cm}

\begin{tabular}{llr}
{\tt Token Type:} {\sl time\_window } \\
{\tt Defining Authority:} {\sl eastern\_timezone }\\
{\tt Value:} {\sl 8:00AM-5:00PM }\end{tabular} 

%-----------------------------------------------------------------------

\subsection {EACL evaluation}

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

Restrictions 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 EACL entry must not specify both positive and negative rights.

2) If an EACL entry specifies negative rights, it must not have any conditions. 

If both negative and positive authorizations are allowedf in
individual or group entries, inconsistencies must be resolved according to resolution rules.  The design approach we adopted
allows the ordered interpretation \cite{dewan} of EACLs. Evaluation of 
ordered EACL starts from the first to the last in the list of EACL entries.
The resolution of inconsistent authorization is based on ordering. 
The authorizations that already have been examined take precedence
over new authorizations.  

Other interpretations are possible, but we found that for many
such policies, resolution of inconsistencies was either NP-Complete or
undecidable.

In general, when an EACL grants a requested opertation and no additional 
credentials are required, the GAA API will look for credentials that can 
cause denial. A principal may chose to withhold credentials that it believes 
may result in a denial. 
There may be interactions when independent credentials are used, i.e., one set 
of credentials causes denial, but the other causes accept. 
The administrator must deal with these issues by carefully setting policies 
in an EACL. It may be appropriate to specify a more restricted set of rights and
require grant credentials to be presented. 

Conflicts may arise when more then one entry applies. For example, 
one matching entry specifies individual subject (user, host or application), and another matching entry spesifies 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 EACL entries with different conditions apply, the access is based
on the conditions in the first matching entry found. 
An ordered evaluation approach is easier to implement as it allows only 
partial evaluation of EACL and resolves the authorization conflicts.
The problem with this approach is that it requires total ordering among authorizations.
It requires careful writing of EACL by the security administrator and is 
error-prone. Disordering of the EACL entries may result in discrepancies 
between the intended policy and the one that results from evaluation of the EACL.
It might be useful to have a separate module \cite{samarati}, \cite{blaze}, that would help verify and debug the EACL to assure that it expresses the 
desired policy.

%-----------------------------------------------------------------------

\subsection {Credential evaluation}

Credentials are translated to the GAA API internal format and 
placed into the GAA API security context.
When evaluating an EACL, the security context is searched for the
necessary credentials.
Assume that file {\it doc.txt} has the following EACL shown in \textbf{Table 1. }  
stored in the authorization data base:
\begin{center}
\rotatebox{270}{\scalebox{.60}{\includegraphics{fig2.eps}}}\\
\vspace{.2cm}
\textbf {Table 1.}
\end{center}

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

Identity credential: \\

\begin{tabular}{llr}
{\sl access\_id\_USER kerberos.v5 tom@ORG.EDU}\\ 
{\tt condition:} {\sl time\_window  pacific\_tzone 6am-7pm}
\end{tabular}\\ 
 
Group membership credential: \\

{\sl access\_id\_GROUP kerberosV5 admin@ORG.EDU}\\
{\tt condition:} {\sl privilege restricted}  \\

Delegation credential: \\

{\tt grantor:} {\sl grantor\_id\_USER kerberosV5 joe@ORG.EDU} \\ 
{\tt grantee:} {\sl access\_id\_USER  kerberosV5 tom@ORG.EDU} \\
{\tt objects:} {\sl doc.txt}\\ 
{\tt rights:} {\sl pos\_access\_rights local\_manager FILE:write}\\
{\tt condition:} {\sl location local\_manager *.org.edu} \\


Let's consider a request from a user Tom who is connecting from 
the {\sl ORG.EDU} domain to write to the file {\it doc.txt} at 5pm.

In evaluating the EACL, the first entry does not grant the requested 
operation, however the second entry grants it. The evaluation function will
then check the security context for the group {\tt admin} membership credential. The proper credential is found, however, there is a condition 
{\tt privilege:restricted}. This 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 a delegation
credential for {\tt tom@ORG.EDU} issued by {\tt joe@ORG.EDU}.
The appropriate delegation credential is found. The condition on location {\tt *org.edu} is satisfied, 
so the requested access will be granted.


%-----------------------------------------------------------------------

\subsection{Generic Authorization and Access-control API (GAA API)}

In this section we provide a description of the main GAA API routines.

\subsection{GAA API functions}

The {\tt gaa\_get\_object\_policy\_info} function is called to obtain the 
security policy associated with the object.
 
\begin{itemize}
\item \textbf{Input}: 

\begin{itemize}

\item \textit{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.

\item \textit{Pointer to application specific Authorization
Database}.

\item \textit{Upcall function for the retrieval of the object
policy}. 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 retrieves this information  and translates it
into the internal representation understood by the GAA API.
\end{itemize}

\item \textbf{Output}: 

\begin{itemize}

\item \textit{Object policy handle}

\end{itemize}

\end{itemize}

The {\tt gaa\_check\_authorization} function tells the
application
server whether the requested operations are authorized, or if
additional application-specific checks are required.
 
\begin{itemize}
\item \textbf{Input}:

\begin{itemize}

\item \textit{Object policy handle, returned by} 
{\tt gaa\_get\_object\_policy\_info}
\item \textit{Principal's security context} (see section 3.5.1)
\item \textit{Operations for authorization}.
This argument indicates requested operations.

\end{itemize}

\item \textbf{Output}:

\begin{itemize}
\item {\tt YES}   (indicating authorization) is returned if
all requested operations are authorized. 

\item {\tt NO}    (indicating denial of authorization) is
returned if at least one operation is not authorized.

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

\item \textit{detailed answer} contains:

\begin{itemize}
\item 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 the GAA API, based on: 
\begin{enumerate}
\item Time-related conditions in the object policy, e.g. EACL matching entries.
\item Restrictions in the authentication and authorization credentials.  
\end{enumerate}
 
\item The requested operations are returned marked as granted or denied
along with a list of corresponding conditions, if any. 
Each condition is marked as evaluated or not evaluated, and if evaluated 
marked as met, not met or further evaluation or enforcement is required.
This tells application which policies must be enforced.

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

\end{itemize}

\end{itemize}



\item {\tt gaa\_inquire\_object\_policy\_info}
 
This function allows the application to discover access control policies 
associated with the targeted object applied to a particular principal. 
It returns a list of rights that the principal is authorized for and 
corresponding conditions, if any.
The application must understand the conditions that are returned
unevaluated, or it must reject the request.  If understood, the
application checks the conditions against information about the
request, the target object, or environmental conditions to
determine whether the conditions are met. Actual enforcement of
policies expressed through conditions is the responsibility of the 
application and is outside of the scope of this paper.

\end{itemize}


%-----------------------------------------------------------------------

\subsubsection{GAA API Security Context}

The security context is a GAA API data structure.
It stores information relevant to access control.
Some of its constituents are listed here:

\begin{description}

\item[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 EACL entry that is paired with a 
privilege for the type of access requested.

\item[Authorization Attributes]\\

Verified authorization credentials, such as group membership, group 
non-membership, delegation credentials, and capabilities.

\item[Evaluation and Retrieval Functions for Upcalls] \\

These functions are called to evaluate application-specific conditions,
to request additional credentials, and to verify them. 

\end{description}

\section {Creation of the GAA API security context}

Prior to calling the {\tt 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. 
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 or  authenticated RPC.  
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.  

The principal's authentication information is placed into the
security context and passed to the GAA API. When additional security
attributes are required for the requested operation, the list of
required attributes is returned to the application, which may request them.
The application may provide the 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 is added to the security context by the application or
transport.

%-----------------------------------------------------------------------

\section{An Extended Example}

To illustrate our approach 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 EACL files. These
files are stored in an authorization database, maintained by the Printer Manager.

%-----------------------------------------------------------------------

\subsection{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 conditions, such as
time, location, payment and quota. 

An example of Printer Manager-specific condition: printer load, expressed 
as maximum number of jobs that allowed to be submitted to a printer.
  
%-----------------------------------------------------------------------
 
\subsection{Authorization Walk-through}

Here we present an authorization scenario 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 {\it ps12a} has the following ordered EACL shown in \textbf{Table 2.}
stored in the Printer Manager authorization database.
\begin{center}
\rotatebox{270}{\scalebox{.37}{\includegraphics{fig1.eps}}}
\vspace{.2cm}\\
\textbf {Table 2.}
\end{center}

Let's consider a request from user Tom who is connecting from the
{\tt ORG.EDU} domain to print a document on the printer {\it ps12a} at 7:30 PM.

When a client process running on behalf of the user 
contacts the Printer Manager with the request to {\tt submit\_print\_job} to
printer {\it ps12a}, the Printer Manager first calls 
{\tt gaa\_get\_object\_policy\_info} to obtain a handle to the EACL of printer {\it ps12a}.  
The upcall function for retrieving the EACL
for the specified object from the Authorization Database system is passed
to the GAA API and is called by {\tt gaa\_get\_object\_policy\_info},
which returns the EACL handle.

The Printer Manager must place the principal's authenticated
identity in the security context to pass into the {\tt
gaa\_check\_authorization} function.  This context may be
constructed according to the first or second scenario, described in Section
8.  
If Tom is authenticated successfully, then verified identity
credentials are placed into the security context, specifying Tom as the 
Kerberos principal {\tt tom@ORG.EDU}.  

Next, the Printer Manager calls the {\tt gaa\_check\_authorization} function.
 In evaluating the EACL, the first entry applies. It grants the 
requested operation, but there two conditions that must be evaluated. 

The first condition is generic and is evaluated 
directly by the GAA API. Since, the request was issued at 7:30 PM 
this condition is satisfied.  The second condition is specific.
If the security context defined a condition evaluation function for upcall, 
then this function is invoked and if this condition is met then the final answer 
is {\tt YES} (authorized) and detailed answer contains authorization expiration time : 8PM (assume that authentication credential has expiration time 9PM),
allowed operation {\tt submit\_print\_job } and two conditions. 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 {\tt MAYBE} and the second condition is marked as not evaluated 
and must be checked by the Printer Manager.

When additional credentials are needed, if the security context defines a 
credential retrieval function for the upcall, it is invoked.
If the requested credential is obtained, then the final answer is {\tt YES}.
If the upcall function was not passed to the GAA API, the answer is {\tt NO}.


%-----------------------------------------------------------------------

 \section{Integration with alternative authentication mechanisms}

Our model is designed for a system that spans multiple administrative domains 
where each domain can impose its own security policies. It is still necessary 
that a common authentication mechanism be supported between two communicating systems. The model we present enables the syntactic specification of multiple 
authentication policies and the unambiguous identification of principals in 
each, but it does not translate between heterogeneous authentication 
mechanisms. 

We have integrated our distributed model for authorization with the Prospero
Resource Manager (PRM), a metacomputing resource allocation system developed 
at USC. PRM uses Kerberos \cite{neuman-kerberos} to achieve strong 
authentication. PRM uses calls to the Asynchronous Reliable Delivery 
Protocol (ARDP) \cite {ardp}, a communication protocol which handles a set 
of security services, such as authentication, integrity and payment.
ARDP calls the Kerberos library through a security API, requesting 
the principal's authentication information.

In addition, we have integrated the framework with the Globus Security 
Infrastracture (GSI), a component of the Globus metacomputing Toolkit 
\cite {globus}. GSI is implemented on top of the GSS-API which allows the 
integration of different underlying security mechanisms. Currently, GSI 
implementation uses SSL authentication protocol with X.509 certificates.

Public key authentication requires consideration of the trustworthness 
of the certifying authorities for the purpose of public key certification.
Authentication can not be based on the public key alone, anybody can issue 
a valid certificate. 

Certificates can comprise a chain, where each certificate (except the last 
one) is followed by a certificate of its issuer. Reliable authentication 
of public key must be based on complete chain of certificates which starts 
at an end-entity (e.g. user) certificate, includes zero or more Certification
Authorities (CA) certificates and ends at a self-signed root certificate.
A policy must be specified to validate the legitimacy of the received 
certificate chain and the autenticity of the specified keys. 
The policy must express the following trust constraints:

1) Constraints placed in the certificates by CA when issuing a certificate.
   They are represented as a list of certificate extensions and marked as 
   critical/non-critical. For example, the extension may contain policy
   specifying that no further delegation of CA authority is allowed.

2) Specify trustworthness of CA to sign certificates for limited set of users.

3) Restrictions on certification path:

   a) Permitted and denyed subtrees of CA authorities.

   b) Limit the length of certificate chains (depth of the subtree).

4) Restrictions imposed on cryptographic attributes: 
     - accepted signature scheme (e.g. DSA/SHA, RSA/MD2) 
     - minimum public key length (768, 1024 bits)

5) Deciding to trust particular end-entity certificate for particular purpose.

The following is an example of an EACL used for describing the Globus policy for what CAs are allowed to sign which certificates. The Globus CA can sign certificates for the Globus or the Alliance. The Alliance CA can sign certificates for the Alliance. 

\begin{tabular}{llr}
{\tt Token Type:} {\sl access\_id\_CA }\\
{\tt Defining Authority:} {\sl X509 }\\
{\tt Value:} {\sl /C=US/O=Globus/CN=Globus CA} \end{tabular} 
\vspace{.3cm}

\begin{tabular}{llr}
{\tt Token Type:} {\sl pos\_access\_rights}\\
{\tt Defining Authority:} {\sl globus} \\
{\tt Value:} {\sl CA:sign } \end{tabular} 
\vspace{.3cm}

\begin{tabular}{llr}
{\tt Token Type:} {\sl cond\_subjects} \\
{\tt Defining Authority:} {\sl globus}\\
{\tt Value:} {\sl /C=us/O=Globus/*  /C=us/O=Alliance/*}
\end{tabular} 

  
%-----------------------------------------------------------------------

\section{Groups and Roles}

A group is a convenient method to associate a name
with a set of subjectss and to use this group name for access control
purposes. The kind of subject (individual user, host, application or other group)
composing the group is opaque to the authorization mechanism.
A group server issues group membership and non-membership certificates.

In general, a principal may be a member of several groups. By default, a principal 
operates with the union of privileges of all groups to which it belongs, as well 
as all of his individual privileges.

Some applications adopt role-based access control.
The concept of roles is not consistent across different systems. 
Several definitions of roles are present in the literature. 
In general, a role is named collection of privileges needed to perform specific 
tasks in the system. Role properties \cite{samarati} include:

\begin{itemize}
\item A user can be a member of several roles
\item Role can be activated and deactivated by users at their discretion. 
\item Authorizations given to a role are applicable only when that role 
 is activated.
\item There may be various constraints placed on the use of roles, e.g.
 a user can activate just one role at a time.
\end{itemize}

Shandu et. al. \cite{shandu} view roles as a policy and groups as a mechanism for role 
implementation. We adopt this point of view.
In our framework we implement different flavors of roles using  notion  of group 
and a set of  restrictions on granted privileges. 
Consider a role-based policy, which assigns users: Tom, Joe, and Ken role 
{\tt Bank\_Teller}. This role allows a legitimate user to perform deposit and withdraw operations on objects {\it account\_1} and {\it account\_2}.
This policy may be easily expressed by our EACL framework:
\begin{enumerate}
\item Group {\tt Bank\_Teller} is defined which will include Tom, Joe, and Ken
\item The EACLs for objects {\it account\_1} and {\it account\_2} will contain 
the following entry:


\begin{tabular}{llr}
{\tt Token Type:} {\sl access\_id\_GROUP }\\
{\tt Defining Authority:} {\sl X.509 }\\
{\tt Value:} {\sl /C=US/O=Globus/CN=Bank Teller} \end{tabular} 
\vspace{.3cm}

\begin{tabular}{llr}
{\tt Token Type:} {\sl pos\_access\_rights}\\
{\tt Defining Authority:} {\sl pasific\_coast\_bank} \\
{\tt Value:} {\sl ACCOUNT:deposit,withdraw } \end{tabular} 
\vspace{.3cm}

\end{enumerate}

In  expressing role-based policy using groups, the issue of constrains on
role activation and use should be addressed.

%-----------------------------------------------------------------------

\section {Clark-Wilson}

The Clark-Wilson model \cite{clark} was developed to address  security issues
in commercial environments. The model uses two categories of mechanisms
to realize integrity: well-formed transactions and separation of duty.

Our framework is designed to handle the Clark-Wilson integrity model.
A possible way to represent a constraint that only certain trusted programs 
can modify objects is using {\tt application:checksum} condition,
where the checksum ensures authenticity of the application.
Another way is using {\tt application:endorser} condition, which indicates that a valid certificate, stating that the application has been endorsed by the  specified endorser, must be presented.

Static separation of duty is enforced by the security administrator when
assigning group membership.
Dynamic separation of duty enforces control over how permissions are used
at the access time \cite{simon}.
Here are examples of EACL conditions specific to the Dynamic separation of duty:

\begin{itemize}

\item {\tt privilege:restricted} 
Makes subject operate with the privilege of only one group at a time.
\item {\tt privilege:set\_of\_groups}
Makes subject operate with the privilege of only specified groups at a time. 

\item {\tt endorsement:list\_of\_endorsers}
Concurrence of several subjectss to perform some operation.

\end {itemize}

%-----------------------------------------------------------------------

\section{Lattice-based Policies}

Our framework allows incorporation of Mandatory Confidentiality 
\cite{lapadula}, Mandatory Integrity \cite{biba} models and their
combination.

Mandatory policies govern access on the basis of classification of subjects 
and objects in the system. Objects and subjects are assigned security labels:
\begin{enumerate}
 \item Confidentiality labels, e.g. Top\_Secret/NASA,
 Sensitive/Department2
\item Integrity labels, e.g. High\_integrity,  Low\_integrity

\item 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. 
\end{enumerate}

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

All access rights are divided into read-class and write-class.
Appropriate rules are applied to each class. 

Generic conditions for read-class access rights:

 a) {\tt 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) {\tt conf\_read\_below:cofidentiality\_label}

 This condition is used to enforce {\tt 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 
 {\tt cofidentiality\_label} field.

 c) {\tt 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 {\tt integrity\_label} field.

 d) {\tt integr\_read\_above:integrity\_label }

 This condition is used to enforce {\tt read up} mandatory integrity rule. 
 It specifies that a subject, wishing to get read-class access to the 
 object has to have integrity clearance less or equal to the one, specified 
 in the {\tt integrity\_label} field.
                 
Similarly we define generic conditions for write-class access rights.

Assume file {\it doc.txt} has classification Sensitive/Departmen1 and integrity 
label Medium, then EACL for this file can be specified as:

 
\begin{center}
\rotatebox{270}{\scalebox{.40}{\includegraphics{fig3.eps}}}\\
\vspace{.2cm}
\textbf {Table 3.}
\end{center}
                                                     
Note that in the example above, everybody in the distributed system 
can get read or write access to the file if a valid credential
stating the appropriate security label attribute is presented.
This poses a requirement that security labels be unique across different
security domains. This may not be easily satisfied.
A possible way to restrict the scope of security labels to a particular administrative domain is to specify an additional condition such as location.

%-----------------------------------------------------------------------

\section{Conclusions}

In this paper we presented a generic authorization mechanism that 
supports a variety of security mechanisms based on public or secret 
key cryptography. The mechanism is extensible across multiple 
applications supporting different operations and different kinds of 
protected objects. Alternative implementations may be chosen for underling 
security services that support the API.
By extending the traditional ACLs and capabilities with conditions on 
authorized rights we are able to support a flexible distributed
authorization mechanism, allowing applications and users to define their
own access control policies either independently or in conjunction with 
centralized authorization and group servers. The problem of policy translation is addressed by using generic or application-specific evaluation
functions.   
We are going to investigate the request and evaluation of 
additional credentials.
The assumption that all relevant credentials are passed for
evaluation contradicts privacy requirements. It might not
be always desirable to reveal group membership and principal attributes 
up front. 
We have integrated our model with several applications.

%-----------------------------------------------------------------------

\section {Appendix}

We use the Backus-Naur Form to denote the elements of our policy language.
Square brackets, {\tt[ ]}, denote optional items and curly
brackets, {\tt\{\}}, surround items that can repeat zero
or more times. A vertical line, {\tt|}, separates alternatives.
Items inside double quotes are the terminal symbols.

An EACL is specified according to the following format:

{\tt
{\small
eacl ::=  \{eacl\_entry\}

eacl\_entry ::=  \\
access\_id \{access\_id\} pos\_access\_rights \{condition\}  \\
             \{pos\_access\_rights \{condition\}\} | \\
access\_id \{access\_id\} neg\_access\_rights \\ 

access\_id ::= \\
access\_id\_type  def\_authority  value \\ 

access\_id\_type ::= \\
                           "access\_id\_HOST"  | \\
                           "access\_id\_USER"  | \\
                           "access\_id\_GROUP" | \\
                           "access\_id\_CA"  |   \\
                           "access\_id\_APPLICATION" | \\
                           "access\_id\_ANYBODY" \\
 }
}

A capability is defined according to the following format: \\

{\tt
{\small
capability ::= \\
 grantor\_id pos\_access\_rights \{condition\} \\
                 \{pos\_access\_rights \{condiction\}\} \\


grantor\_id ::= \\
grantor\_id\_type   def\_authority   value  \\ 

grantor\_id\_type ::= "grantor\_id\_HOST"  |   \\
                            "grantor\_id\_USER"   |  \\
                            "grantor\_id\_GROUP"  |  \\
                            "grantor\_id\_CA"  |     \\
                            "grantor\_id\_APPLICATION" | \\
                            "grantor\_id\_ANYBODY"  \\


pos\_access\_rights ::= \\
  "pos\_access\_rights" def\_authority value \\
\{"pos\_access\_rights" def\_authority value\} \\

neg\_access\_rights ::= \\
  "neg\_access\_rights" def\_authority value \\
\{"neg\_access\_rights" def\_authority value\} \\

condition ::= \\
  condition\_type  def\_authority  value \\ 

condition\_type ::= alphanumeric\_string \\

def\_authority ::= alphanumeric\_string \\

value ::= alphanumeric\_string
}
}

%-----------------------------------------------------------------------

\section {Acknowledgments}

This research was supported in part by the Defense Advanced Research Projects Agency under the Scalable Computing
Infrastructure (SCOPE) Project, TNT, Contract No. DABT63-95-C-0095, Security Infrastructure for Large Distributed
Systems (SILDS) Project, Contract No. DABT63-94-C-0034, and by a grant from Xerox Corporation. The views and
conclusions contained in this document are those of the authors and should not be interpreted as representing the official
policies, either expressed or implied, of the U.S. Army Intelligence Center and Fort Huachuca Directorate of Contracting, the
Defense Advanced Research Projects Agency, the U.S. Government, or Xerox Corporation. 

%-----------------------------------------------------------------------

\begin{thebibliography}{1}

\bibitem{neuman-proxy}
B.C. Neuman.
\newblock Proxy-based authorization and accounting for
distributed systems.
\newblock {\em Proceedings of the 13th International Conference
on Distributed Computing Systems, Pittsburgh}, May 1993.

\bibitem{neuman-kerberos}
B.C. Neuman and T. Ts'o.
\newblock Kerberos: An authentication service for computer
networks.
\newblock {\em IEEE Communications Magazine}, pages 33--38,
September 1994.
 
\bibitem{lam}
T.Y.C. Woo and S.S. Lam.
\newblock Designing a Distributed Authorization Service.
\newblock {\em In Procedings IEEE INFOCOM '98}, San Francisco, March 1998.

\bibitem{samarati}
S. Jajodia, P. Samarati and V.S. Subrahmanian.
\newblock A logical Language for Expressing Authorizations
\newblock {\em Proceedings of the 1997 IEEE Symposium on Security and Privacy},
1997.

\bibitem{abadi}
M. Abadi, M. Burrows, B. Lampson and G. Plotkin
\newblock A calculus for Access Control in Distributed Systems.
\newblock {\em ACM Transactions on Programming Languages and Systems, Vol. 15, No 4}, Pages 706-734, September 1993.

\bibitem{simon}
R. T. Simon and M. E. Zurko
\newblock Separation of Duty in Role-Based Environments
\newblock {\em Computer Security Foundations Workshop}, June 1997.

\bibitem{nagaratnam}
N.~Nagaratnam and S.B. Byrne.
\newblock Resource access control for internet user agent.
\newblock {\em Proceedings of the third USENIX Conference on
Object-Oriented Technologies and Systems, Portland, Oregon}, June 1997.

\bibitem{gong}
L. Gong and R. Schemers. 
\newblock Implementing Protection Domains in the Java Development
Kit 1.2.
\newblock {\em Proceedings of Network and Distributed System
Security Symposium, San Diego, California}, March 1998.

\bibitem{blaze}
M. Blaze, J. Feigenbaum and J. Lacy. 
\newblock Decentralized Trust Management.
\newblock in {\em Proc. IEEE Symp. on Security and Privacy, IEEE
Computer Press, Los Angeles}, pages 164-173, 1996.

\bibitem{shandu}
R. S. Shandhu, E. J. Coyne, Hal L. Feinstein and C. E. Youman
\newblock Role-Based Access Control : A Multi-Dimensional View.
\newblock  {\em Proc. of 10th Annual Computer Security Applications Conference}, December 5-9, pages 54-62, 1994.

\bibitem{dewan}
W. Shen and P. Dewan
\newblock Access Control for Collaborative Environments.
\newblock {\em Proc. of CSCW}, November, 1992, pages 51-58

\bibitem{clark}
D.D. Clark. and D.R. Wilson
\newblock Non Discretionary Controls Commercial Applications.
\newblock {\em Proc. of the IEEE Symposium on Security and Privacy},
 pages 184-194, April 1997.

\bibitem{lipner}
S.B. Lipner
\newblock A Comparison of Commercial and Military Computer  Security Policies.
\newblock {\em Proc. of the 1987 IEEE Symposium on Security and Privacy}, 1982.

\bibitem{lapadula}
D. Elliott Bell and L. J. LaPadula
\newblock{\em Secure Computer System: Unified Exposition and Multics
Interpretation, ESD-TR-75-306 (MTR-2997), The MITRE Corporation}
Bedford, Massachusetts, July 1975. 

\bibitem{biba}
K. J. Biba
\newblock {\em Integrity Considerations for Secure Computer Systems}, 
The MITRE Corporation, Bedford, MA, MTR-3153, 30 June 1975.

\bibitem{ardp}
\newblock The Asynchronous Reliable Delivery Protocol.
\newblock {\em  http://gost.isi.edu/info/ardp}

\bibitem{grid}
Edited by I. Foster and C. Kesselman.\\
\newblock The GRID: Blueprint for a New Computing Infrastructure
\newblock  {\em Morgan Kauffman Publishers}, 1999. 

\bibitem{globus}
I. Foster and C. Kesselman. \\
\newblock Globus: A metacomputing infrastructure toolkit.
\newblock {\em International Journal of Supercomputer Applications},
Summer 1997.


\end{thebibliography}



\end{document}


