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?
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.
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?
Let me elaborate a bit. The scenario is an authentication procedure that involves modifications to the account. These modifications need to be done on the real data, cannot be local (much like many fields related to password policy, for instance).
The "right" approach would be to propagate the modifications to the master, wait for their replication and continue with the bind.
The real right approach would be to centralize binds, basically defeating the purpose of having replicas (with respect to authentication, at least).
I'm not a fan of OTP, but I believe this problem is worth being discussed not only with respect to OTP, but also because it may share issues with other auth methods where the directory stores auth-related data (like SASL auxprops).
When everything is set up correctly, a client should not direct binds with this type of mech to a replica.
When clients do not know that a DSA is in fact a shadow, the shadow DSA should be able to handle this type of requests seamlessly, although possibly not as efficiently as the master would. In this latter case, the auth procedure should be able to understand that the request will modify centrally administered info, and refuse to proceed. The frontend should be able to intercept this (much like when it receives a write request, or a request with the dontUseCopy control), and either give up or perform the write to the master, wait for success, and continue. Note that "continue" might imply waiting for replication to finalize, otherwise a subsequent request for stored auxprops would return invalid values. The above could be implemented at minimal cost using the chain mechanism already available to support writes to shadow databases, but binds do not return referrals by design.
In short, I believe this really messes up with the mess involved with distributed procedures. Either we solve it consistently (at the cost of performances) or consistently prevent things from messing up (like it is now); the latter might be the only viable solution if fixing things consistently is not worth because of excessive performance penalties.
p.
Pierangelo Masarati masarati@aero.polimi.it wrote:
I'm not a fan of OTP, but I believe this problem is worth being discussed not only with respect to OTP, but also because it may share issues with other auth methods where the directory stores auth-related data (like SASL auxprops).
When everything is set up correctly, a client should not direct binds with this type of mech to a replica.
A simple solution in the single master situation is to redirect any SASL OTP bind to the master. As far as I understand, we have no way of configuring this right now, it needs at add some code, right?
The multi-master setup is much more complicated to get done right.
On Fri, Feb 19, 2010 at 07:53:09AM +0100, Emmanuel Dreyfus wrote:
A simple solution in the single master situation is to redirect any SASL OTP bind to the master. As far as I understand, we have no way of configuring this right now, it needs at add some code, right?
Perhaps slapo-rwm can do that? Is there a way of matching OTP binds?
[Replying to both messages]
Emmanuel Dreyfus wrote:
On Fri, Feb 19, 2010 at 07:53:09AM +0100, Emmanuel Dreyfus wrote:
A simple solution in the single master situation is to redirect any SASL OTP bind to the master. As far as I understand, we have no way of configuring this right now, it needs at add some code, right?
Perhaps slapo-rwm can do that? Is there a way of matching OTP binds?
I'm afraid slapo-rwm can't do anything like that, since it is not involved in SASL binds (not even in rewriting identities).
To go back to your initial statement, redirecting SASL OTP binds to the master may sound simple, but the question is: is it acceptable? I mean: isn't it defeating the purpose of using replicas in the first place?
Going a bit technical, we need to let SASL bind know that some mechs may need to behave differently. But redirecting SASL binds to the master means playing man-in-the-middle, we'd rather need to have distributed SASL binds. Not familiar enough with SASL's internals to debate. As far as I understand, auxprops is the intended method to implement distributed SASL info storage and thus (try to) support distributed SASL bind. However, this means that not only slap_auxprop_store() needs to:
- understand it's acting on behalf of a shadow database
- redirect writes to the master
but also
- wait for replication to complete
before authentication can continue.
A totally different approach would be to have auxprop handling, including reads, redirected to the master. In this latter case, auxprop info (at least for specific SASL mechs) shouldn't be replicated at all.
p.
Pierangelo Masarati masarati@aero.polimi.it wrote:
- wait for replication to completebefore authentication can continue.
One problem:
If we do that, authentication cannot take place if the master or a replica is down. That defeats the purpose of setting up replicas to prevent failures.
IMO there is a trade off between reliability and security here. We can either (1) redirect the client to the master (lower availability, better security since no replay can happen at any time), or (2) accept the authentication locally and send the update to the master afterwards (more reliable. less secure)
IMO, OTP is inherently incompatible with replicas because a client can authenticate to each replica with what is intended to be a one time password. The only way to preclude this is, as was basically suggested, is to chain it to the master such that each password can only be used one time.
-- Kurt
IMO, OTP is inherently incompatible with replicas because a client can authenticate to each replica with what is intended to be a one time password. The only way to preclude this is, as was basically suggested, is to chain it to the master such that each password can only be used one time.
I have an "easy" fix in this direction; however, I stumbled into another issue: if slapo-chain(5) gets involved in an internal operation, it does not honor custom callbacks registered for the internal operation, and rather attempts to return the result to the caller. As a consequence, I need to address this issue first, before solving the original one.
p.
-
David Hawes -
Emmanuel Dreyfus -
Kurt Zeilenga -
manu＠netbsd.org
-
masarati＠aero.polimi.it -
Pierangelo Masarati