Subject: Re: Comments on the ACL Model draft

From: [email-masked] (Richard V Huber)
Date: Thu, 16 Mar 2000 19:04:53 -0500

I'll try to clarify a couple of places where our comments weren't clear
enough.

Rick Huber

: >Page 15:
: >
: >TECHNICAL:
: >
: >              means that this group (Dept XYZ) is granted permission to
: >              read and search all attributes except attr1 because attr1
: >              is more specific than "[all]".
: >              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: >
: >What if it were two collections rather than specific attribute vs. [all]?
: >How do you determine which is "more specific"?
: 
: (EJS)  Collection is more specific than All.  Collections are server defined,
: so it is possible, but not probable, for an attribute to be a member of both
: collections.  The specificity would be server defined.  Also, keep in mind
: that I'm soliciting input on whether to keep or remove 'collection' - we'll do
: whatever is the consensus.

The question was meant to address the case where an attribute is a
member of more than one collection and the different collections have
different permissions.

As for whether to keep or remove collections, my vote is to remove them
and put in the "list of attributes" from one of the earlier email
exchanges on this topic.  But you will still have the issue of what to
do when one attribute appears in two different lists and the different
lists have different permissions.

: >TECHNICAL:
: >
: >"deny" takes precedence over "grant", but groups have precedence over
: >roles.  What happens if a permission is granted to a subject by virtue
: >of group membership but denied by virtue of role membership?
: 
: (EJS) Let's answer when we settle on precedence of groups and roles.
: 
: >What is the precedence among precedence groupings?
: 
: (EJS) If I understand the question correctly, none; union semantics would
: apply and deny takes precedence over grant when both are listed.

I think we didn't make the question clear.  There is a precedence of
dnTypes, and there is a precedence of grant/deny.  It is not clear how
these precedences interact.  We used group vs role only as an example.
The question could be restated as:

  What happens if a permission is granted to a subject by virtue of the
  subject's access-ID but denied by virtue of subtree membership?  Since
  access-ID has precedence over subtree membership, the permission
  should be granted, but since deny has precedence over grant it should
  be denied.  Which precedence rule applies?

I don't think union semantics apply to this question.

: >Page 31:
: >
: >TECHNICAL:
: >
: >Should the security considerations section include some mention of the
: >special problems that might arise in a replicated environment?  What
: >happens when new entries or attributes arrive at a replicated server
: >out of sequence with the arrival of associated ldapACI data?
: 
: (EJS)  I suggest that at a future time there be a draft that discusses the
: interaction of access control with other directory functions/features.  In the
: case of replication, perhaps we should look at adding this to one of the
: (many) ldup drafts.  I'll put this on my list to discuss since I author an 
: ldup draft.

I don't think that we were suggesting that this issue must be resolved
in the draft, just that it should be raised as a security concern that
has to be considered.  I agree that a full treatment of the issue is
worth detailed examination in an LDUP document, but it is a security
consideration related to the subject of this draft and should be
noted as such in this draft.

---

From: [email-masked]
Date: Fri, 17 Mar 2000 10:15:47 -0600

My responses prefaced with < djb >

Page 26

TECHNICAL:

                    subjectDN     LDAPString | "public" |
                                    "this" |  "*"

What does it mean to getEffectiveRights for "everyone who has access to
the entry" (definition of "*" on Page 25)?  Return all the ACIs?  All
possible subject DNs can't be known.  And if all the ACIs are desired
it would be simpler to just read the ldapACI attribute.

< djb > * is intended to return the effective access for all DNs which are
defined within the ACI. This is different from simply reading the ACI b/c
it does the expansions and evaluations of grant / deny / group memberships
etc and returns the granted rights after evaluation.

Page 28:

TECHNICAL:

                 dnType        "access-id"|"group"|
                                "role"|"ipAddress"|
                                "kerberosID"|
                                <printableString> |
                                "*",
                                ^^^
                 subjectDN     LDAPString | "public" |
                                    "this" | "*"
                                             ^^^

What would it mean to return "*" as part of the RESPONSE to
getEffectiveRights?  Isn't a separate PartialEffectiveRightsList
element needed for each dnType in the response?  If "*" is part of the
query, shouldn't the various elements of the response indicate which
specific dnType they refer to rather than repeating the "*"?  When
would "*" be returned?  And it is even less clear what "*" means for
in the response for subjectDN.

We note that the "*" is not allowed in the
ldapGetEffectiveRightsResponse on Page 31.  Was it left in
PartialEffectiveRightsList by accident?

< djb > Yes, it should be removed from the response

Thanks,

Debora Byrne
Manager Secure Way Directory Config / User Interface
INet: [email-masked]
Phone: (512)838-1930 ( T/L 678 )

Ellen Stokes <[email-masked]> on 03/17/2000 09:00:38 AM

To:   "Ryan Moats" <[email-masked]>, "Richard V Huber"
      <[email-masked]>, [email-masked], Debora
      Byrne/Austin/IBM@IBMUS
cc:   [email-masked]
Subject:  RE: Comments on the ACL Model draft

>
>| >Page 16:
>| >
>| >TECHNICAL:
>| >
>| >              Precedence of Privilege Attribute dnTypes within a scope
>| >              (highest to lowest):
>| >
>| >                 - ipAddress
>| >                   ^^^^^^^^^
>| >
>| >                 - access-id, kerberosID (both same precedence)
>| >                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>| >
>| >                 - group
>| >
>| >                 - role
>| >
>| >                 - subtree
>| >
>| >Requirement S6 of the requirements draft states:
>| >
>| >              S6.  Access policy SHOULD NOT be expressed in terms of
>| >              attributes which are easily forged (e.g. IP addresses).
>| >              There may be valid reasons for enabling access based on
>| >              attributes that are easily forged and the
>| >              behavior/implications of doing that should be documented.
>| >
>| >Isn't use of ipAddress flaunting this?
>|
>| (EJS)  Not really.  The requirements document was put in place to serve
>| as a guideline for writing the model draft, not as an explicit
>| 'must follow' for writing the draft.  So some things in the requirements
>| are not in the draft and vice-versa.  This was explained at previous
>| ldapext meeting.  Just because ipAddress is in the draft and an
>| implementation provides it, doesn't mean that the deployment of the
>| server needs to use it.
>
>Hang on.  I don't buy this (and I don't remember that particular LDAPEXT
>meeting, but I might have been someplace else).  As I read SHOULD NOT, we
>need a good reason for using ipAddress.  I don't see any documentation
>of why ipAddress is supported in this draft.  At a bare minimum, we should
>document (a) why ipAddress is being proposed and (b) make a specific
>"Security Consideration" note about ipAddress being easily forgable.
>I'd really like for support of ipAddress to be a MAY (with everything else
>in the list a MUST), since this document is standards track.
>
>Ryan

(EJS) OK, let's step back for moment and start this discussion again.
So far, I think we've all agreed that the supported dnTypes are access-id,
group, and role.  As for the addition of kerberosID, I haven't heard any
violent
objections - only that we should look at generalizing it and bringing it in
line
with the authmeth doc - and I'm looking into that.

Now for other dnTypes such as ipAddress.  I agree that we should include
a note in the Security Considerations section about it being easily forged.
ipAddress is useful when all directory updates are forced from a given
machine or network domain.  Given that this is an easily forged type, it's
reasonable to ask the mailing list whether this type should be a MUST,
SHOULD, or MAY, or perhaps remove it.  So I'd like to hear opinions
ipAddress so we can reach consensus.

---

From: [email-masked] (Richard V Huber)
Date: Fri, 17 Mar 2000 13:33:15 -0500

Thanks.  Now I understand what the "*" for subjectDn means.  It would
be helpful to include your explanation in the document.

It does seem that "*" might result in HUGE responses in some fairly
common situations.  For example, if the ACI contains a dnType "subtree"
for a reasonably large part of the tree, wouldn't the response need to
contain every DN in that subtree?

Rick Huber

: From: [email-masked]
: To: [email-masked]
: cc: [email-masked], [email-masked],
:         Ellen Stokes <[email-masked]>
: Subject: RE: Comments on the ACL Model draft
: 
: 
: 
: 
: My responses prefaced with < djb >
: 
: Page 26
: 
: TECHNICAL:
: 
:                     subjectDN     LDAPString | "public" |
:                                     "this" |  "*"
: 
: What does it mean to getEffectiveRights for "everyone who has access to
: the entry" (definition of "*" on Page 25)?  Return all the ACIs?  All
: possible subject DNs can't be known.  And if all the ACIs are desired
: it would be simpler to just read the ldapACI attribute.
: 
: < djb > * is intended to return the effective access for all DNs which are
: defined within the ACI. This is different from simply reading the ACI b/c
: it does the expansions and evaluations of grant / deny / group memberships
: etc and returns the granted rights after evaluation.
: 
: 
: Page 28:
: 
: TECHNICAL:
: 
:                  dnType        "access-id"|"group"|
:                                 "role"|"ipAddress"|
:                                 "kerberosID"|
:                                 <printableString> |
:                                 "*",
:                                 ^^^
:                  subjectDN     LDAPString | "public" |
:                                     "this" | "*"
:                                              ^^^
: 
: What would it mean to return "*" as part of the RESPONSE to
: getEffectiveRights?  Isn't a separate PartialEffectiveRightsList
: element needed for each dnType in the response?  If "*" is part of the
: query, shouldn't the various elements of the response indicate which
: specific dnType they refer to rather than repeating the "*"?  When
: would "*" be returned?  And it is even less clear what "*" means for
: in the response for subjectDN.
: 
: 
: We note that the "*" is not allowed in the
: ldapGetEffectiveRightsResponse on Page 31.  Was it left in
: PartialEffectiveRightsList by accident?
: 
: < djb > Yes, it should be removed from the response
: 
: 
: Thanks,
: 
: Debora Byrne
: Manager Secure Way Directory Config / User Interface
: INet: [email-masked]
: Phone: (512)838-1930 ( T/L 678 )

---

From: [email-masked]
Date: Wed, 22 Mar 2000 10:38:23 -0600

My comments are preceded by <bb>

This is a  joint set of comments from Ryan Moats and Rick Huber.  We've
been discussing them internally for a while, so they may repeat some of
the last day's discussion on the list, but there is a fair amount of new
material here.

Rick Huber

Page 5:

EDITORIAL:

             A "subject' is an entity which initiate actions in an
                       ^                    ^^^^^^^^
             information system.

The quotes on subject don't match.  Also, "initiate" should be either
"may initiate" or "initiates".

TECHNICAL: How is a "role" really different from a "group" which
contains all of the subjects in the organizational position that the
role represents?  In Ellen's response to Dave Chadwick's questions, she
quotes Bob Blakley's previous posting on this.  Bob's posting talks
about having different semantics for combinations (union semantics vs.
intersection semantics), but the model in the draft does not seem to
allow for different merging semantics, so some of the reason to
separate roles and groups is not present.

<bb> I'm not sure I understand exactly the question here.  But let
<bb> me try again... precedence insures that either groups or roles
<bb> but not both will be used to make an access decision.  In the case
<bb> where both are present and relevant, precendence will ensure that
<bb> the decision will be based on the policy stated in the "group"
<bb> entries corresponding to the user's group memberships.  This is
<bb> in support of using groups as an exception mechanism to override
<bb> the more general policies enforced by the "role" entries.
<bb> You're correct that the current draft does not allow for
<bb> "role" entries to be combined using intersection semantics, which
<bb> is a function some people might want.  However, another way to
<bb> handle the same requirement is to ensure at credential construction time
<bb> that each user has only one role entry in his or her credential,
<bb> thus enforcing role exclusivity.  Not everyone agrees that roles
<bb> should have exclusivity semantics or intersection semantics, so
<bb> we don't want to require this -- in the future it might be good to
<bb> specify the semantics of entry combination explicitly in the ACL
<bb> but for now we've stuck with union default for all entry types
<bb> to simplify the resolution algorithm.  We'll clarify in the document
<bb> that both "group" and "role" entries are combined using union
<bb> semantics and that "group" entries and "role entries are not combined
<bb> with each other.

TECHNICAL:

             More specific policies must override less specific ones
             (e.g. individual user entry in ACI takes precedence over
              ^^^^
             group entry).

The "e.g." makes us very nervous.  There needs to be a solid definition
of what "more specific" means to avoid problems of interpretation by
different developers.

<bb> In the new draft we state the precedence rules explicitly

Also, what would happen if a DN was a member of
two groups, where one had rights while the other did not?  An example
on page 20 says to take the union of rights, but this behavior should
be specifically defined in the text, not just in an example.  Are union
semantics always used for dnTypes at the same precedence?

<bb> Yes.  This will be clarified.

--bob

Bob Blakley
Chief Scientist
Tivoli SecureWay Business Unit

---

From: [email-masked]
Date: Wed, 22 Mar 2000 11:24:53 -0600

All

--bob

Bob Blakley
Chief Scientist

>Page 21:
>
>TECHNICAL:
>
>We are not sure we understand the purpose of Section 7.  Is it just a
>set of high level examples of sequence of operations?

<bb> Section 7 is necessary because LDAP is only a protocol specification, not
<bb> an implementation specification.  Implementations are free to build richer
<bb> access control semantics than those specified in the LDAP ACL Model draft,
<bb> and they are also free to provide "proprietary" administrative interfaces
and
<bb> protocols which can cause - from the viewpoint of LDAP clients - "silent"
and
<bb> even undefined changes in the access control policy.

<bb> Section 7 describes two things:

<bb> (1) The effect of LDAP access control administrative operations on the
<bb> access decision which will subsequently be made by a server implementation
<bb> (that is, the semantics of indidividual ldap ACL admin operations), and

<bb> (2) under what circumstances administrative operations performed on the
<bb> server implementation but not performed through the LDAP access control
<bb> administration protocol will result in the semantics of access control
policy
<bb> being undefined from the viewpoint of an LDAP client.

>TECHNICAL:
>
>                 - Datastore Access Control Policy Update Actions: any
>                   operation implemented by the server which LDAP is
>                   using as its datastore which changes the access
>                   policy enforced with respect to attempts to access
>                   LDAP directory entries and their attributes.
>
>Is this meant to say that the underlying DBMS/filesystem/etc may impose
>policy which overrides the policies expressed by LDAP ACIs?  Or is it
>meant to say that non-LDAP means (SQL for an underlying RDBMS
>datastore) may change the data stored in ldapACI attributes?  While
>either may be true in general, is it not part of the job of the server
>developer to make sure it doesn't happen?  Shouldn't LDAP access
>control be the way that access control policy is expressed for an LDAP
>directory?

<bb> The server is free to support any policy it wants to as long as that policy
is capable of
<bb> expressing the semantics defined in the LDAP ACL model draft.  The server
is responsible
<bb> for enforcing the policy which has been defined.  The underlying server's
policy *IS* the
<bb> LDAP policy; this draft merely provides an implementation-independent way
of
<bb> administering the subset of that (underlying) policy which supports the
LDAP access control
<bb> semantics.  The underlying server administrator may make changes in the
policy, without
<bb> using the LDAP protocol and *perhaps* without having any LDAP privileges.
The changes
<bb> this administrator makes will be enforced even for LDAP resources.
<bb>
<bb> We've had a long set of discussions in the working group about whether all
LDAP-supporting
<bb> repositories must support identical policy semantics, and the consensus has
been that this
<bb> is not feasible.