Tatyana Ryutov
`INTERNET-DRAFT
`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
`
`EMC v. IV
`IPR2017-00338
`Ex. 1003
`1
`
`

`

`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
`
`2
`
`

`

`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 13.
`Section 14.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:
`
`3
`
`

`

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

`

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

`

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

`

`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"
`
`7
`
`

`

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

`

`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
`
`Conditions
`7.3
`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
`
`9
`
`

`

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

`

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

`

`
`
`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 credential
`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
`
`12
`
`

`

`
`
`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 condition
`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.
`
`13
`
`

`

`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
`
`14
`
`

`

`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
`
`15
`
`

`

`Expires February 1999
`
`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
`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.
`11. 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 grou