On 2/16/10 10:29 PM, Emmanuel Dreyfus wrote:
Hello
After exchanging a few private messages with Pierangelo Masarati, I just posted ITD#6475:
When binding using SASL OTP to a replica, the bind works, but the cmusaslsecretOTP attribute is modified on the replica and fail to be propagated to the master. On the next modification, the master will overwrite the replica's updated cmusaslsecretOTP value.
Here is a script that exhibit the behaviour: ftp://ftp.openldap.org/incoming/ldapotp.tgz
That require SASL enabled OpenLDAP, with the OTP plugin installed. The PATH in run.sh must probably be adjusted.
The problem is in sasl_auxprop_store(), who bypass the replication process. The easier fix to me seems to send a referal to the master on any SASL OTP bind, Any other idea?
I was experimenting with SASL OTP a few months ago and thought replication seemed problematic in general.
In a single provider, single consumer setup, it would seem that if the cmusaslsecretOTP was written to on the provider (as above), there would be a chance for a client to perform another SASL OTP bind against the consumer before the cmusaslsecretOTP was replicated. In such a situation, the password could be replayed.
In the current implementation, this cannot happen on a single consumer, as the SASL libraries prevent binding until the cmusaslsecretOTP has been written. Of course, if the entry with an old cmusaslsecretOTP is replicated, the password can be replayed.
Multi-consumer setups suffer from the same problem. Passwords can be used multiple times on different consumers.
I'm not sure how this problem can be solved. It would seem that in a replicated environment a SASL OTP bind would have to block across all providers until they are all updated to prevent passwords from being replayed. This seems difficult, to say the least.