|
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" <Kurt@OpenLDAP.org> 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 Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext