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

Re: [ldapext] [Fwd: New Version Notification for draft-pluta-ldap-srv-side-current-time-match-00]

Hi Steven,

Steven Legg wrote:

Hi Daniel, Daniel Pluta wrote:

Hi Steven, Steven Legg wrote:

Hi Daniel, Daniel Pluta wrote:

Hi Steven, Steven Legg wrote:

Hi Daniel, Daniel Pluta wrote:

Hi Steven, Steven Legg wrote:

Daniel Pluta wrote:

Steven Legg wrote:

Daniel Pluta wrote:




With your argument concerning the distributed DIT in mind this entry
local attribute does not seem to make sense (even in regard to your
scenario) so we tend to remove sect. 7.4 from the draft.


Let me try to make it clearer. Suppose that we have a DIT for
o=Acme Corporation with two subunits ou=Sales and ou=Finance. Further
suppose that there are two LDAP/X.500 servers. The first server holds the
o=Acme Corporation entry and the entire ou=Sales subtree. The second
server just holds the entire ou=Finance subtree. Consider an LDAP client
that connects to the first server and issues a search for (cn=Smith) with
the base object ou=Finance,o=Acme Corporation. The first server does not
hold any entries in this subtree so it chains the search request to the
second server. The second server performs the search and returns the
resulting entries to the first server which then forwards them to the
LDAP client. The entries in the result have all come from the second
server, though they were delivered to the client by the first server.
If access controls on the second server used the "now" ordering matching
rule, or if the filter instead included a filter item with the
"now" ordering rule, then the rule would have been evaluated with respect
to the current time on the second server. However, if the client read
the current server time from the root DSE (necessarily in a separate
operation), then it would get the current time on the first server,
which wasn't the time used to determine the results of the person search.
In this scenario the client derives no benefit from knowing the current
server time from the root DSE because it is irrelevant to the person
search result. A current time attribute appearing in each entry gives
the time of the server that actually evaluated that particular entry
(in this case, the second server).
Ok, attaching the current server time using a derived attribute seems to offer advantages in case of a chaining in action. So both sections' contents are of use and should stay in the draft.
And finally the minor important question: Q: In case the server would already publish its current system time, what about additionally publishing the server's timezone?
Publishing the server time as local time plus time zone (which is allowed by the Generalized Time syntax) allows UTC, server local time or time zone to be recovered from the one value. I would recommend doing that. 

That's fine and it complies with what we've suggested in sect. 6.2.
Just a short remark: Daylight saving time possibly reduces the grade of usefulness of this information in general, nevertheless I think it should be at least optional to be used instead of UTC time.
That is too inflexible. What you should be doing is extending the access control mechanisms in OpenLDAP so that it is possible to express which identities are permitted to apply which matching rules 
 to which attribute types. That, combined with the new matching
rules, would allow you to do everything you want to do with the new syntaxes and more besides. It would allow access controls to be tailored for the needs of each service and could be applied to syntaxes other than timestamps. It would also allow tighter controls to be placed on existing attributes of Generalized Time syntax. 

You're completely right here. We've also thought about that previously
but canceled it because in our opinion this won't be a general but only
a product specific solution.


There isn't a common, standardized access control model for LDAP that
you can extend, but that doesn't mean you have to standardize a poor
approach instead. It would be reasonable to have a non-normative
(informative) section or annex (or a separate draft) that describes
how the new matching rules (the normative part) can be used to protect
the privacy of timestamp values when used in conjunction with an access
control model that supports the ability to express what matching rules
can be applied to what attribute types.



You could use an extended
OpenLDAP access control model as a concrete example. Anyone wanting to
achieve the same thing on a different platform would need to extend
their native access controls in an equivalent way, but would have the
guidance from the draft and the example from OpenLDAP to go by.
I already had a look into OpenLDAP sources: It's quite not easy to implement some kind of search-privilege limitation using for example a matching rule white-/black-list attached to search privileges...
I've already implemented a just-for-fun patch which successfully extends the ACL-parsing to restrict search-privileges but applying the resulting data structure during matching is currently nearly impossible without major changes in OpenLDAP's current source. 



Assertion Syntaxes:
- Two standalone assertion syntaxes preferred:
  - simple "NOW"
  - flexible X.680 (based on your already avail. implementation)
  - both compatible with the above matching rules
- Alternative:
  Differentiation between "now" and "nowOffset" assertion syntax
  not strictly needed: both can be integrated in one "Assertion
  Syntax" that supports any offset (also "NOW" using some kind
  of a zero offset?).


Whether that differentiation is needed depends on how one extends
the access control model. If there is only the offset assertion
syntax, then the extended access control model needs to be able to
express which identities can apply what matching rules *and*
*assertion* *values* to what attribute types. Note that you need
to be able to prevent the use of non-zero offsets to protect the
timestamps in the ways you want. If there is a nowMatch and a
separate nowOffsetMatch (likewise nowOrderingMatch and
nowOffsetOrderingMatch), then the extended access control model
only needs to be able to express which identities can apply what
matching rules to what attribute types. Only the nowMatch and
nowOrderingMatch rules would be allowed for a protected timestamp
attribute type. The nowOffsetMatch and nowOffsetOrderingMatch rules
would be prohibited, amongst other rules.
Yes that would fulfill our original intentions in an ideal way - the "only" difficulty regarding OpenLDAP's current source seems to be the application of acl structures during matching. 

Another approach which currently also works for us:
Using "filter=...." statements in current OpenLDAP ACLs fulfills our requirements, too. Because this filtering takes place in the last step (right before delivery).
This acl-filter is not applied in the user-context thus the user does not need access to the time-stamp attributes at all. Instead the server processes this filter in its own context.
Possible disadvantage: it could happen that an user's requested search uses "(objectClass=*)" which results in a huge result set, which will be reduced two 1 entry during the final filtering step in the server. 

A probably more efficient approach would be:
Using the rewrite module to dynamically add limiting filter expressions to incoming user requests: 

(ojbectClass=*) ==slapo-rwm==> (&(objectClass=*)(limit1)(limit2)).
Such extended/limiting filters would lead to initially smaller result sets in the first step. Additionall the final server-context-filtering could be skipped completely. The only (big) problem as the filter is rewritten in the user's context the user needs search permissions on the attribute. Granting common search privileges do not fulfill our privacy scenarios because inappropriate matching rules can be chosen using extensible match filters. Thus the search-permission should be further narrowed e.g. on attribute to matching rule association basis... 



- In my opinion: "NOW" would offer improved readability


Yes, except that there is an existing assertion syntax that you could
use. It is useful for interoperability with X.500 for each new LDAP
syntax to define its corresponding ASN.1 type. The assertion
syntax for the rules without offset carries no information, which would
naturally correspond to the ASN.1 NULL type. RFC 3687 defines
an LDAP syntax for the NULL type (1.2.36.79672281.1.5.1).


Ohh yeah!  :-/
Although I understand the idea behind this type and also your suggestion I'm just not very happy with this syntax only because there is no ASN.1 definition for a an abstract type like "the current time" (additionally to the ISO8601 specified common "point in time" for example). On the other hand: the comparison takes place on server side so we do not (need to) send any value to be compared which justifies to indicate this by NULL, e.g. using "(timeAttr=)" as a filter.
Nevertheless I'm not happy with this especially in regard to usability/readability.
Even more, Am I right that a valid filter expression would look like: (timeAttr=NULL) in case the LDAP string representation is "NULL"? If yes in my personal opinion I would prefer to use "NOW" instead of "NULL".
Focused on the LDAP string representation: sending "NULL" instead of "NOW" seems to be not more than an ineffectual misuse to me. Even "" (the empty string) would be preferable instead of "NULL" in my opinion.
So, let me just try to justify the use of "NOW" instead of "NULL": the latter needs 33% additional resources! ;-) 



Operational Attribute for each Entry:
- Distributed DIT could result in many different "NOW"s
  - Currently there's no known use-case for something like this.


The use-case is the generalization for a distributed or virtualized DIT
of *your* use-case.


As stated above this makes of course sense - NOW. ;-)
Many thanks for the scenario!


Best regards,
Daniel
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext