Subject: replicating timestamps/counters (was: Re: [ldapext] Re: draft-behera-ldap-password-policy-07.txt)

From: "Jim Sermersheim" <[email-masked]>
Date: Sun, 24 Oct 2004 13:17:56 -0600

Regarding this thread, I currently agree with Kurt's final paragraph. I propose we leave the values in question (pwdFailureTime and pwdGraceUseTime) as GeneralizedTime syntax (and not switch to CSN syntax).
 
After reviewing the thread, I believe GeneralizedTime is capable of being used to populate unique, incrementing values of an attribute (whether replicated in a loosly consistent way or not).
 
For example, two servers in a loosly consistent replication agreement could either:
a) agree to use portions of the fractional seconds field to hold something akin to a 'replica ID'
b) agree to contact a single authoritative source for the generation of timestamps.
 
This also works fine for a single server system where (as Howard first mentioned) operations are happening faster than the system's timestamps could increment. A global function which generates unique timestamps would be a fairly trivial mechanism to solve this.
 
That said, I have a sneaking suspicion that I'm overlooking something * otherwise, why all the fuss with CSN syntax (in general) to begin with? Why not just abuse the fractional seconds of Generalized Time?
 
Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 3/16/04 11:38:46 AM >>>
At 08:17 AM 3/16/2004, Ludovic Poitou wrote:
>> Also, doesn't this mean you can
>>attack all the shadows at will until the master communicates
>>that the account is locked?
>> 
>That is an implementation issue (one can apply the change locally and communicate it to the Master). 

Doesn't this go against your' user's desire to have a strict
lock out on N retries policy across the service? I mean, if
implementations are free to local retries counts, than cannot
those be abused to get retries than the policy allowed?

Ignoring DoS attacks in this area, is there a scaling problem
here?

We have deployments involving large numbers of replicas
where maintain policy state information on a context
wide basis would be prohibitively expensive.

It seems to me that it would be better to define any state
information to be DSA-specific, but with a comment saying
that DSAs may agree to share state information but that
the how to that sharing could be performed is beyond the
scope of this document.

Kurt 

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext