Re: ACM Security Considerations

[Rob Byrne - Sun Microsystems <Robert.Byrne@france.sun.com>]

Kurt,

These are very good points.  Just to say that I think that the model of
allowing the LDAP Mechanism to control access to these ACM attributes
itself (which I believe is the natural and simplest model) is compatible
with the requirements you outline--once we have a way to express the
authentication level of subjects.

For the "out-of-directory" policy point...I can see a strong need for that
and but it clearly jepordizes interoperability.  Are there other standard
technolgies that have this concept that we learn from...?

Rob.

"Kurt D. Zeilenga" wrote:

> 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