HANDOUT NOTES

Summary

This is a large draft technical report

I.1

Architecture for Authorization for Distributed Applications and Groups.

Intent is to make security usable.

Will be implemented in Windows NT

I.2

Goals:

Make distributed authorization easy.
Scalability
Share policy information

4. Design Overview

4.1 How Policies are Implemented

Figure 1, page 15.

Security Administrator creates English policy.

Enters it through Visual Policy Builder

VPB entries translated into Authorization Language (text file)

AL files checked for correctness / consistency by AL translator

AL translator sends commands to Authorization Database Server
which updates the User Policy Database

UPD used for viewing, but translated to low-level
Security Policy Database, which is used for actual authorization
decisions.

4.2 How policies are enforced

One UPD per "cell".

UPD referenced through ADS.

ADS translates UPD to SPD.

SPD used by Authorization Engine.  AE currently part of ADS.

Engine invoked by Adage authorization interface.  Request
has principal, target, action.  Engine compares with SPD.

II. User Level Design

6. Trust Model

ADAGE uses identity & attribute information from external
authentication authorities in authorization decisions.

"trust metrics" determine how external authorities are
known and how the information they provide is trusted.

This determines which Adage authorization policies the
information may be used in.

6.1 How are Authentication Authorities Recognized?

Each cell has at least one "local" authentication
authority.  Cell works with it directly with proper
protocol (like DCE or Kerberos).  Local authority
vouches for Adage to external users and applications.

Adage translates information from local authentication
authorities about "principals" into "actor attributes".
Such authorities have been "introduced" to Adage.

Non-local authorities are introduced by SA or by "referrals"
from other trustworthy authorities.

6.2 Do I trust you?

Cell may trust authentication authority based on several
factors:

* quality of software / techniques

* security of host OS

* competence of security manager

* quality of users

* politics

No mention of how this is factored in.

6.3 How much trust do I have in you?

Trust modelled from maximum trust (local) to maximum distrust
(hostile).  Zero point indicates no knowledge.

6.4 What do I trust you for?

External authentication authorities may provide:

* attribute information about principals, possibly narrowed
  down into particular sets of attributes or principals
  (depending on trust).

* identity information similarly

* nothing (without proper trust)

* referrals of other authentication authorities

6.5 How do I restrict your input to decisions?

Trust model allows different classes of authentication authorities
to provide or be denied providing information about particular
classes of policies, targets, and actions.

6.6 How do I meet new authentication authorities?

Introduced by SA or by referral

Referrals by chain of Adage cells to the authority.

Trust by local cell of external authority based on local's
trust of external cell, and external cell's trust of the authority.

Anything can be overridden by SA.

6.7 Trust metrics

Principals inherit trustworthiness from their authority.

6.7.1 Citizenship metric (base trust)

Assigned to authority and its principals.

   3 native
  2 foreign -- principals can't be SA
  1 tourist -- limited access, general authenticated population
  0 alien   -- unknown, unauthenticated
 -1 suspect -- known, possibly hostile or tainted referral path
 -2 enemy   -- known hostile, denied all access

6.7.1.1 Length of disuse

Base trust level degraded at each level:

 Fresh: 0-7 days
 Recent: 8-30 days
 Mature: 31-90 days
 Old: 91-180 days
 Expired: > 180, level set to alien

6.7.1.2 Quantity of denials

Measured over one hour.
Base trust value decremented each time level changes:

 Innocuous: 0-3
 Suspect: 4-8
 Malicious: >8

6.7.2 Trusted content

Limit the scope of information accepted by cell from a particular
authentication authority.  Possible categories:

 * Identity information (about principals from that
          authority)
 * Attribute information, possibly restricted to certain
   attributes
 * Referrals

6.7.3 Scope of trust

Which decisions can a particular authority or (citizenship)
class affect?  Set in a rule:

 <AuthorityType AccessType Context>

 AuthorityType : Name of authority or citizenship class
 AccessType: positive or negative
 Context: specified sets of policies, attributes, or actions

6.7.4 Referral Chains Metrics

6.7.4.1 Length of chain of referral

Weakens base trust:

 Close:  0-2 hops,  0
 Distant: 3-4 hops, -1
 Remote:  5-6 hops, -2
 Too Far: >6 hops, unusable

6.7.4.2 Quality of Link

How much a link is trusted to refer others.  Calculated like
base trust.  Paper is unclear about who is trusting the link:
the cell getting the chain, or the next link in the chain.

6.7.4.3 Number of chains

Must be completely distinct chains, no overlaps.  More is
better.

6.8 Trust computation

6.8.1 Computing trust in external authorities

Set by SA or calculated from referral chain.

Chain cleaned up first, then trustworthiness of each node
re-calculated.

Resulting trust level determines how information from
that authority is used.

Conflicts may be generated automatically.  Adage disables
those policies.

6.8.2 Calculating Base Trust from referrals

Each chain is trusted at the level of the lowest link
  and possibly lowered to max trust at that distance.
Trust levels of chains are calculated by algorithm on
page 29

6.8.3 Examples

7 Adage Visual Policy Builder GUI

Only prototyped so far

7.1 Overview

Policies made of three elements, called "building blocks":
actors, targets and regulations

Elements can be grouped arbitrarily (not necessarily homogeneously)

Buildings blocks have "attributes" associated with them

7.2 Authentication Authorities

External authentication authority principals turned into actors.
Adage synchronizes with authorities when needed.

7.3 Actors

Same as "subjects" or "principals".

Group of actors is a "team".

Single or multiple authentication identity (multiple accounts).

Identified by name field (attribute?)

Built-in attributes:  label, label set, group-membership,
secrecy level, integrity level

GUI provides dialog box for manipulating actor attributes

7.3.1 Actor templates

SA can refer to all actors of a particular type

7.4 Targets

Thing that an actor requests access to.

Group of targets called "collection".

Similar set of built-in attributes, dialog box, templates

7.5 Applications and Actions

7.5.1 Registered Actions

Applications that use Adage for authorization register with
the GUI to indicate what actions they want to use on which
targets.

7.6 Regulations

Specify actions that actors are allowed to take on targets.

Group of actions called a "manual"

Regulations may have simple constraints using a single
relational operator (each) and may be templated.

7.7 Groups

Sets of various policy pieces.

Groups may contain groups, and members of the contained
group are made members of the containing group.

7.8 Policies

Policy is a group containing at leaste one actor, target,
and regulation (or their respective templates).

Default policy can be defined for requests with otherwise
undefined policy.

7.9 Advanced features

7.9.1 Constraints

7.9.2 Historical dependencies

Actor has (not) done an action on a target

Useful for Chinese Wall policy

7.9.3 Multi-Person Policies

Fuzzy, but some actions may require more than one actor
to execute.

7.9.4 Policies involving different types of actors

GUI provides way to specify multiple actors or actor templates
that are allowed to do something.  Sort of an on-the-fly
group of actors.

7.9.5 Delegated Identies

Supports delegation of authority from one principal to
another, not clear how.

7.9.6 Group (really TEAM) Constraints

Can avoid team overlap, avoid a user using more than one
at a time, and set the maximum cardinality of a team.

7.10 Function Summary

Functions available through GUI

8. Adage Authorization Language

Textual representation of stuff from the Visual Policy Builder

Extension to Tcl

8.1 Declaring objects

By type and name.  Declared by keyword for that kind of object,
the name of the object, then a list of attributes for that
object.  Many attributes are sets of lower-level objects.

8.1.1 Attributes

Same as available through GUI, plus "history", which specifies
what actions have happened in relation to the object.

8.1.2 Templates

Made with wildcards

8.1.4 Applications

Apps register via an AL (Tcl) script

Can have attributes mentioned in the GUI section, plus
sets of name/value pairs.  Text is not clear on what is
done with those pairs.

8.1.5  Targets

Same attributes as with GUI

8.1.6 Regulations

Same attributes as with GUI, but constraints may use all logical
operators as well instead of just AND'ing them.

8.1.7 Teams

Sets of actors & their templates
As with GUI, with the team constraints.

8.1.8 Collections

Sets of targets & their templates
As with GUI.

8.1.9 Manuals

Sets of regulations & their templates
As with GUI.  Regulations on same action are AND'ed together.

8.1.10 Meta-actions

Groups of actions.

8.1.11 Roles

Also groups of actions, used to enforce least privilege

"role-team" attribute indicates who can take actions within a role.

8.1.12 Policy pieces

Not clear.  Give additional semantics to actors and teams.

8.1.13 Policies

As with GUI.  One attribute indicates if policy is active or
latent.  Other attributes are sets (by type) of the things
that can be in the policy.

8.1.14 Authentication authorities

Indicates how the external authority data translates into Adage
objects and attributes

8.2 Operations on objects

Can add, remove, or modify objects in cells or attributes
in objects

Can list information in the cell

PolicyFor command can query whether particular action is allowed
by particular actor on particular target.  Specifying two of the triple
returns list of names of the third entity allowed.

10. User policy database

User-level abstractions from VPB and AL.

Not implemented.

When it is, various consistency checks will be done on the data.

Conflicts result in denials of access.

III. Protection Mechanism Design

11. Adage Protection Mechanisms

Based on protection matrix and on role-based access control.

Rules express complex authorization policies based on properties
of roles, buject, and object

You got history, too.

11.2 Terminology and Name Space

11.2.1 Terms for basic entities

VPB actors may have multiple "principals" in the protection
mechanisms

target = target

action = action

set of "rules" implements a VPB regulation

11.2.2 Groups

Homogeneous sets.  Flat, non-hierarchical group structure.

11.2.3 Name Space

VPB/AL is hierarchical.  Mechanisms is flat, with a flattening
name translation scheme (not described).

11.3  Basic Entities

11.3.1 Principal

active entities that access targets.  User, machine, or application

11.3.2 Target

information container

11.3.3 Actions

program or operation specific to a program

Actions must be part of a generic action when registered.
Generic actions are read, write, execute, append, delete, copy

11.4  Groups:  Teams, Collections, and Action Sets

11.5 Roles

Role contains three groups:  team, collection, and action set

By default, within a role, any role principal may perform any
role action on any role target.  Can be modified by
rules.

11.6 Labels

Tag on one of the three basic Agadge entities.  Has
confidentiality level, integrity level, and category names.

Used in rules to determine if access should be given.

11.6.2 Principal Labels

"Floating label" on a principal indicates its current level
of access.  Starts empty.  Filled in as principal performs
access.  Changes if role changes.

"Label closure" indicates total range of floating label
for a given principal for a given policy.

User shown current label status.

User may be required to acknowledge label status changes
to avoid trojans.

11.6.3 Target labels

Assigned by SA or by inheritance rules

11.6.4 Action Labels

Assigned by SA.  Indicate in what roles they are used.

11.6.5 Label Inheritance

Labels inherited from parent.  Not obvious what a parent is.

11.7 History

Indicates what principal has performed what action on what target.
Implemented as a 3D bit matrix.

11.8 Rules

Generalization of ACL.
Contain scopes and constraints

Scopes indicate teams, set of actions, and collection to
which the rule applies.

11.8.4 Constraint

Statement about relationship between principal's label and
target's label, and principal's history with the target.

Various label characteristic comparisons and logical operations
available (page 80).

11.9 Separation of duty and role activation

Normally, any principal in a role may assume it at any time.

Mutual exclusion and history are more complex.

11.9.1 Separation of duty

Two or more people may be responsible for the completion
of a task.

Variations based on when and on which objects principals
may act in different roles.

11.9.2 Role activation

Role activated by performing action permitted by that role.

11.9.3 Role de-activation

Happens when user explicitly deactivates.

11.9.4 Label float
Automatic label changes only increase levels.

11.9.5 Cardinality Rules
Limit the number of principals active in a a role.

11.10 An example

11.11 How access is computed

11.11.1 Decision Input
principal's label closure and floating label, action's label,
and target's label.

11.11.2 Rule Selection

rules selected for which the scopes in the appropriate
labels match

11.11.3 Role activation

Role containing appropriate rule activated if it activation
rules pass

11.11.4 Role reduction
Attempt to reduce set of roles about to be activated.

11.11.5 Rule evaluation
Evaluate constraints for each rule, & deny access if any fail.
Update label if now roles require.

11.11.6 Label computation
Updating of float label based on given algorithm.

12. Authorization Language Translation

not written

IV Low Level Design

13 Introduction

Adage is in C++

14 Supporting Classes and Data Structures
Not written.

15 Authorization Engine.
Description of a nifty C++ class.

16 Authorization database server
Not written

17 User policy database
Not written.

18 Security Policy Database
Not written.

V Case studies