Re: Comments on Access Control Model draft - grant/deny evaluation rules

[rvh@qsun.mt.att.com (Richard V Huber)]

Kurt's comments on my comments are preceeded by colons.  My replies are
on the lines that do not have colons.

Rick Huber

: >Some of the things that I don't think are clear in the current draft:
: >
: > - Groups and roles may contain other groups and roles.  Subtrees may
: >   contain groups and roles.  Since groups, roles, and subtrees are of
: >   different precedence, the interactions need to be spelled out.
: 
: I would recommend that subtrees, groups and roles not be
: recursively evaluated.

If groups and roles are not recursively evaluated, I think that the
principle of least surprise will be violated - it won't work the way
people expect it to.  If a group DN appears as a member of another
group, I believe the expected behavior is that the members of the
"inner" group get the access granted to the "outer" group.  How do we
get this behavior if groups/roles are not recursively evaluated?  As
for subtrees, are you saying that a group or role should not get the
access that is granted to a subtree containing the group?

: > - There are some things missing from the precedence lists (e.g.
: >   "authzID-dn:" vs. "authzID-u:", precedence of attribute
: >   specifications).
: 
: I believe they should have the same precedence as they are
: equally specific.

I wrote my comments to reflect my preference, but I could live with
Kurt's version.  The important thing is to explicitly state how it
should work to avoid implementaion inconsistencies down the road.

: > - The term "more specific" is useful in guidelines, but it should not
: >   be used in actual requirements since it is not well defined.
: 
: I concur.
: 
: >I've attached a revised version of the precedence lists and the access
: >decision algorithm below.  It attempts to resolve the issues above.
: >
: >Rick Huber
: >
: >--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
: >Precedence of Scope Types:
: >
: >  1. Entry
: >
: >  2. Subtree
: >     For a given subject DN (including authentication level) and target
: >     DN, subtreeACI lower in the tree take precedence over those higher
: >     in the tree.
: 
: lower and applicable / higher and applicable.

OK.  how about "... applicable ACI values from subtreeACI lower in the
tree take precedence over those higher in the tree."

: >Precedence of Subjects within a Scope:
: >
: >  1. ipAddress
: 
: I don't understand why ipAddress is viewed as being more
: specific than an authzID.
: 
: 
: >  2. Wildcarded DNS name
: >     If multiple wildcarded DNS names are applicable, they are of equal
: >     precedence.
: 
: I don't understand why ipAddress is viewed as being more
: specific than an authzID.

Bob Blakley sent some mail about this explaining the precedence.  This
isn't a subject type I would really want to use, but if you DO want to
use IP address to determine access controls, I agree with Bob that it
needs to have high precedence.

: >  3. authzID distinguished name ("authzID-dn:")
: >
: >  4. authzID userid ("authzID-u:")
: 
: All forms of authzID should have equal precedence.
: 
: >  5. this
: >
: >  6. role
: >     If the DN of a role or a group appears in a role (e.g. appears as
: >     a value of roleOccupant in an organizationalRole), it is
: >     recursively expanded.  For determination of precedence, the
: >     resulting expanded collection of names is considered to have come
: >     from a role regardless of the original source.
: >
: >  7. group
: >     If the DN of a role or a group appears in a group, it is
: >     recursively expanded.  For determination of precedence, the
: >     resulting expanded collection of names is considered to have come
: >     from a group regardless of the original source.
: >
: >  8. subtree
: >     Subtrees may contain groups and/or roles.  They should be
: >     recursively expanded.  For determination of precedence, members of
: >     groups or occupants of roles that apply because (after recursive
: >     expansion) the group or role is contained in a subtree are
: >     considered to have come from the subtree regardless of the
: >     original source.
: >
: >  9. public
: >
: >Precedence of Attribute Specifications
: >
: >  1. Access controls for a list of specific attributes (regardless of
: >     the number of attributes on the list) are all of equal
: >     precedence.
: >
: >  2. Access controls specifying "[all]" attributes are of lower
: >     precedence than specific lists.
: >
: >Precedence of grant/deny:
: >
: >  Deny takes precedence over grant
: >
: >Precedence of Authentication Levels
: >
: >  1. ACI that specifies a specific authentication level applies only if
: >     the subject has authenticated at the specified level.  It takes
: >     precedence over ACI that specifies the same subject with "authn"
: >     or "unauthn" authentication level or with no authentication level
: >     specified.
: 
: I note:
: 
: X.501(93) 16.4.2.3 AuthenticationLevel
: AuthenticationLevel defines the minimum requestor authentication level required for this ACIItem.
: 

But then we have to define a well-ordering of authentication levels,
and I believe that is a rathole.  And the rathole reopens every time
someone comes out with a new SASL mechanism.

: >  2. ACI that specifies "authn" or "unauthn" has lower precedence.
: >
: >  3. If the authentication level is omitted, it is treated as though
: >     "authn" had been specified.
: >
: >Default
: >
: >  Deny is the default when there is no access control information or
: >  when evaluation of the access control information yields no result
: >  that allows the requester access.
: >
: >Access Decision Algorithm
: >
: >  1. Determine all the entryACI and subtreeACI values which could apply
: >     to the target DN which is being accessed.  This is the DN of the
: >     entry which is being queried in a search, modified, deleted, etc.
: >     Precedence of values from different ACIs are handled according to
: >     the "Precedence of Scope Types" above.
: >
: >  2. Determine which of the collected ACI values (determined in step 1)
: >     apply to the bound DN.  Process one Subject Type at a time in
: >     order of precedence from the "Precedence of Subjects within a
: >     Scope"  Within each Subject Type, apply the the precedence rules
: >     for Authentication Level from "Precedence of Authentication
: >     Levels".  If at least one ACI value exists for a Subject Type when
: >     all ACI values for that Subject Type have been processed, proceed
: >     to Step 3 without processing any additional Subject Types.  If no
: >     ACI values remain after processing all Subject Types, access is
: >     denied.
: >
: >  3. Evaluate the remaining ACI values and determine a grant/deny
: >     decision.  For permissions that apply to attributes rather than
: >     entries, if conflicting ACI values exist for one attribute, apply
: >     the "Precedence of Attribute Specifications".
: >
: >  4. If conflicting values still exist, deny takes precedence over
: >     grant.
: >
: >  5. If more than one ACI value remains, union semantics apply.
: >
: >  6. If there is no grant for one or more of the permissions required
: >     for the operation in question, access is denied.