[Date Prev][Date Next] [Chronological] [Thread] [Top]

ACM Security Considerations



I think this section needs additional flushing out.  Here
are some comments in this area:

I believe some discussion about what can happen if an attacker is able
to add/modify/delete ldapACI and other ACM attributes (such
as the mechanism) might have.  For example, if the attacker
were able to change the mechanism, all access to all users
might be denied.  If unauthorized access to ldapACI were gained,
the user could grant or deny access for not only herself but
other users.  Etc.

Since the existing concern states ACI attributes are
"security-sensitive information" but only states
"unauthorized modification whenever it is stored or transmitted"
should be safeguarded. I would suggest add someing about in the
clear access.  That is, if the information is truely security-sensitive
than allowing any access is an issue.  [many security experts believe
that details of security policy and it's implemention should be
safeguarded].  Implementations might consider requiring strong
authentication and/or privacy and integrity safeguards before
allowing access to ACIs.

You might also note that implementation might want to provide
out-of-directory restrictions upon what accesses in-directory
can grant/deny.  [I believe this is already allowed by the
spec via the "No mechanisms are defined in this document to
control access to access control information."  That is,
an implementation is free to return unwillingToPerform (or
other suitable resultCode) if there is some administrative
control which prohibit from performing the update operation.
[I believe this MUST be allowed.  In some (GOV,MIL,B2B)
environments, "dynamic" (in directory) access control
information must be restricted by "static" (external to
directory configuration) means.]

	Kurt