Subject: Comments on the ACL Model draft

From: [email-masked] (Richard V Huber)
Date: Thu, 16 Mar 2000 13:51:48 -0500

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 3

TECHNICAL:

             No mechanisms are defined in this document to control
             access to access control information or for storage of
             access control information at the server; this is vendor
             dependent.

But the ACIs are attributes.  Don't the normal access controls
described in the rest of the draft apply here?

EDITORIAL: Add reference to ACL Requirements document in last paragraph.

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.

Page 7:

EDITORIAL: Add Section number at end of last paragraph.

Page 9:

EDITORIAL:

             aCIMechanisms lists the values (list of OIDs) that
             defines the access control mechanism in effect for the
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
             scope of that subschema entry.  More than one mechanism
             may be in effect for the scope of that subschema entry.

Should be "define the access control mechanisms" since it explicitly notes
that there can be more than one.

EDITORIAL:

             The intent of the following attribute definitions is to
             design a common interchange format.  Any given LDAP
             server should be able to translate the below defined
             attributes into a meaningful operation requests. Each
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
             server should be able to understand the attributes; there
             should not be any ambiguity into what any part of the
             syntax means.

Should be "into meaningful operation requests" (drop the "a").

EDITORIAL: quote mismatch and add section number in second to last
paragraph.

ABNF:

TECHNICAL:

RFC 2234 gives standards for IETF ABNF, and the BNF in the draft does
not match the standards.  That drove many of the changes in our
suggested replacement, the reasons for other changes are commented.  We
suggest replacing the BNF with the following ABNF and including
references to RFCs 2234, 2252, and 2253:

Open issues:

1. Is the internal structure of a kerberosID really important in this
   context?  Can't we just leave <kerberosID> as a terminal token for
   this ABNF?

2. Are the quoted strings in the ABNF (e.g. "deny", "public") meant to
   be case sensitive or case insensitive?  RFC2234 assumes that quoted
   strings are case insensitive.  If they are meant to be case
   sensitive, RFC2234 requires that some really awful stuff be done to
   the grammar.

          <ldapACI> = <acl entry syntax>

; left angle bracket replaces pound sign since pound sign is legal in
; distinguished name per RFC 2253 DN specification and RFC 2252 attribute
; definitions (inherited from <rights>).  This was chosen because it cannot
; appear in unescaped form in DNs (see 2253) or in attribute names at all
; (see 2252).  Also, <subjectDn> was changed to <subjectID> since it is
; not always a DN (it might be an <ipAddress> or <kerberosID>).

          <acl entry syntax> = <familyOID> "<" <scope> "<"
                             <rights>  "<" <dnType> "<" <subjectID>

          <policyOwner> = <familyOid> "<" <scope> "<" <dnType> "<" <subjectID>

; <distinguishedName> is defined in RFC 2253

          <subjectID> = <distinguishedName> / "public" / "this" /
                          <kerberosID> / <ipAddress>

          <familyOid> = <oid>

          <scope> = "entry"  / "subtree"

; the printableString definitions in <dnType>, <userID>, and <realm>
; need to be more specific in terms of how to handle escaping of
; characters used literally in this ABNF spec

          <dnType> = "access-id" / "role" / "group" / "subtree"
                       / "ipAddress" / "kerberosID" / <printableString>  ;

          <kerberosID> = <userID> "@" <realm>

          <userID> = <printableString>

          <realm> = <printableString>

; Pound symbols used below in place of semi-colon since semi-colon can
; appear in attribute name specification per RFC2252.  This is really a
; nit - we admit that language and other tags are unlikely to show up
; here to cause syntax ambiguity.

          <rights> = ( "grant#" <permissions> "#" <attr> )
             / ( "deny#" <permissions> "#" <attr> ) /
             ( "grant#" <permissions> "#deny#" <permissions> "#" <attr> )

          <permissions> = [ <permission> *( "," <permission> ) ]

; printableString seems too general a syntax for collection name.  The
; syntax should be restricted to make sure that delimiter characters (";"
; or "#") can't occur in the collection name.  We suggest using <qdescrs>
; (defined in RFC 2252) for the attribute name since it better describes
; the allowable syntax for an attribute name.  Might as well use it for
; collection name as well.

          <attr> = ( "collection:" ( "[all]" / "[entry]"
                            / <qdescrs> ) )
                            / ( "attribute:" <qdescrs> )

          <permission> = "a" / "d" / "r" / "s" / "w" /
                             "c" / "e" / "b"

Page 10:

EDITORIAL:

             Two attributes are defined so access control information
             (ACI) can be addressed in a server independent of server
             implementation.  These attributes are used in typical
             LDAP APIs and in LDIF output of ACI. These two attributes
             may be queried or set on all directory objects:  ldapACI
             and policyOwner.  Their BNF and definitions are defined
                                                             ^^^^^^^
             below.

Should be "given" or "presented".

Page 12:

TECHNICAL:

                e    EditDN   Edit an entry's DN
                b    BrowseDN Browse an entry's DN

How is EditDN permission different from Write permission on the naming
attribute?  How is BrowseDN permission different from Search permission
on the naming attribute?  Can I have EditDN permission on the entry
without explicit Write permission on the naming attribute of the
entry?  What would it mean?

And do we really need both Search and Compare permissions?

Page 14:

TECHNICAL:

             <attr> describes either an attribute name or an attribute
             collection.  The keyword attribute indicates that the
             following printable string refers to an attribute name.
             If the string refers to an attribute not defined in the
             given server's schema, the server SHOULD report an error.
             The keyword "collection" indicates that the string that
             follows describes a group of attributes.  The method for
                                                       ^^^^^^^^^^^^^^
             grouping attributes is server specific.  Another option
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
             for the collection printable string is "[entry]". This is ...

This seems to say that no ACI containing an attribute collection can be
portable between vendors' LDAP products.  Since attribute grouping may
well be common (if you have a number of attributes that are always
treated the same way for access control) this seems to be a major
interoperability problem.

Wouldn't it be better to require that the wire protocol list all the
attributes and leave collections as a shortcut that some vendors'
products may use in their administrative interface?  Note we do not
object to "[all]" and "[entry]" since they are well defined, we just
have a problem with the server specific collections.

TECHNICAL: What's the interaction between "[entry]" and attributes: if
somebody has add permission for objects but is denied permissions for
certain attributes, what happens?

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

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.  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?

TECHNICAL:

             Deny takes precedence over Grant. When there are
             conflicting ACI values, deny takes precedence over grant.
             Deny is the default when there is no access control
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
             information.
             ^^^^^^^^^^^

Does this mean that in the absence of any ACI at all, there is no
access to anything?  Does it imply that there MUST be an ldapACI at the
root, since root can't inherit and without an explicit ldapACI there
will be no access at all?

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?

According to our reading of the definition of "access identity" in
Section 3, a Kerberos ID would BE an access identity.  Why make a
distinction here?

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?  What is
the precedence among precedence groupings?

Page 18:

EDITORIAL:

          6.5.2  Modifying the ldapACI Values

          Modify-Replace works as defined in the ldap oepration
                                                      ^^^^^^^^^
          modify. If the attribute value does not exist, create the
          value. If the attribute does exist, replace the value.  If
          the ldapACI value is replaced, all ldapACI values are
          replaced.

Spelling.

Page 20:

TECHNICAL:

Examples are useful and should be encouraged, but they should not be
the sole source of parts of the specification.  Example #2 is the only
place we have found that says that ACI is combined when two dnTypes
have the same precendence.  And the fact that the combination is by
union is not stated anywhere, though it can be inferred from the
example.

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?

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?

Page 25:

EDITORIAL:

             dnType speficies the type of subject security attribute.
                    ^^^^^^^^^
             Defined types are specified in the BNF.

Spelling.

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.

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?

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?

---

From: Ellen Stokes <[email-masked]>
Date: Thu, 16 Mar 2000 17:30:52 -0600

Ryan and Rick,
My responses are embedded and prefaced by (EJS).  Some of your
comments have been delete in this email and will be addressed in a
separate email.
Ellen

>the last day's discussion on the list, but there is a fair amount of new

(EJS)  No.  This was an agreement several ldapext meetings ago that
this was out of scope.  Please also see section 6.4 first paragraph that
states:  "Policy ownership controls administrative subdomains. It
can also control who has permission to set / change acls
for implementations that do not have ACI controlling
access to itself. ... "

>EDITORIAL: Add reference to ACL Requirements document in last paragraph.

(EJS)  Will do, may need to add at or during last call because although the
ACL requirements doc has been approved for RFC publication, it hasn't been
published yet so I don't have the RFC number.

>              A "subject' is an entity which initiate actions in an

(EJS) Will do - I'll use the word 'initiates'.

>EDITORIAL: Add Section number at end of last paragraph.

(EJS)  Will do.

>              defines the access control mechanism in effect for the

(EJS) Will do.

>              attributes into a meaningful operation requests. Each

(EJS)  Will do.

>EDITORIAL: quote mismatch and add section number in second to last

(EJS)  Will do.

>Should be "given" or "presented".

(EJS)  Will do.

>              follows describes a group of attributes.  The method for

(EJS)  See my previous email on this topic...

>              is more specific than "[all]".

(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.

>different developers.  (EJS) I'll tighten up the text for specificity and
so explanation is not just implied by example.

>Also, what would happen if a DN was a member of

>(EJS) yes.
>access to anything?

(EJS) Yes, this was discussed on the list several weeks ago and
was the consensus of the group.

>Does it imply that there MUST be an ldapACI at the

(EJS)  There does not have to be a ldapACI at the root or even a default
ldapACI.  Root could inherit from a default, but that is implementation
defined.  And without an explicit ldapACI at the root, there is not access
(which was consensus).

>                 - access-id, kerberosID (both same precedence)

(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.

>Section 3, a Kerberos ID would BE an access identity.  Why make a

(EJS)  Syntax.  access-ID is a DN, kerberosID is typically something like
userID@realm.  Also, recall here, that there is pending email on generalizing
kerberosID.

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

>           the ldapACI value is replaced, all ldapACI values are

(EJS)  Will do.

>union is not stated anywhere, though it can be inferred from the

(EJS)  We'll explicitly state union and intersection semantics so as
not to infer from examples.

>              Defined types are specified in the BNF.

(EJS) Will do.

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

---

From: "Ryan Moats" <[email-masked]>
Date: Fri, 17 Mar 2000 08:15:20 -0600

Ok, my $0.02, delineated with <rm>...</rm>
I've also cut whole swaths to save space...

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

---

From: Ellen Stokes <[email-masked]>
Date: Fri, 17 Mar 2000 09:00:38 -0600

>| >              Precedence of Privilege Attribute dnTypes within a scope

(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: "Ryan Moats" <[email-masked]>
Date: Fri, 17 Mar 2000 10:32:14 -0600

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

Seems fair to me (and you already have my opinion :-).

Ryan