Re: [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