Full_Name: Emmanuel Dreyfus Version: any OS: any URL: ftp://ftp.openldap.org/incoming/ldapotp.tgz Submission from: (NULL) (213.41.141.172) 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.
changed notes changed state Open to Suspended
changed notes changed state Suspended to Test moved from Incoming to Software Bugs
The "easy" fix is here <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-02-21-dontusecopy-otp.patch> I haven't committed it (needs some polishing) because it touches slapo-chain(5) in a couple of places, and I'd rather be sure it does not break anything. I won't be able to work at it for a while. It needs some polishing (SASL attributes that may need dontUseCopy should be at least configurable and so). Please test.
A more complete fix is here: <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-02-24-dontusecopy-otp.patch> It allows to configure what SASL auxprop names need the "dontUseCopy" approach. The "cmusaslsecretOTP" is set by default, if known through the schema. Please test. p.
<masarati@aero.polimi.it> wrote: > It allows to configure what SASL auxprop names need the "dontUseCopy" > approach. The "cmusaslsecretOTP" is set by default, if known through the > schema. Seems nice. I hope I'll have time to test this week. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@netbsd.org
<masarati@aero.polimi.it> wrote: > Please test. p. It works, but needs to adjustement to the master ACL. My basic configuration yield me this at OTP bind on replica: ldap_sasl_interactive_bind_s: Bad parameter to an ldap routine (-9) replica slapd logs: conn=1001 op=0 RESULT tag=103 err=50 text= SASL [conn=1001] Failure: Error putting OTP secret send_ldap_result: conn=1001 op=0 p=3 send_ldap_result: err=80 matched="" text="SASL(-1): generic failure: Error putting OTP secret" This has been fixed on the master, by adding this at the beginning of the ACL: access to * attrs=cmusaslsecretOTP by dn.regex="cn=replica,o=test" write stop by * break Another point: bind on the replica is impossible when the master is down. I understand this is to prevent replaying the same OTP on multiple replicas, but that defeats the purpose of setting up replicas for fail over. What about making the behavior configurable? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@netbsd.org
> <masarati@aero.polimi.it> wrote: > >> Please test. p. > > It works, but needs to adjustement to the master ACL. My basic > configuration yield me this at OTP bind on replica: > ldap_sasl_interactive_bind_s: Bad parameter to an ldap routine (-9) > > replica slapd logs: > > conn=1001 op=0 RESULT tag=103 err=50 text= > SASL [conn=1001] Failure: Error putting OTP secret > send_ldap_result: conn=1001 op=0 p=3 > send_ldap_result: err=80 matched="" text="SASL(-1): generic failure: > Error putting OTP secret" > > This has been fixed on the master, by adding this at the beginning of > the ACL: > > access to * attrs=cmusaslsecretOTP > by dn.regex="cn=replica,o=test" write stop > by * break This is orthogonal to the sasl auxprops discussion. It's a matter of well-configuring the authorizing identity in slapo-chain(5). > Another point: bind on the replica is impossible when the master is > down. I understand this is to prevent replaying the same OTP on multiple > replicas, but that defeats the purpose of setting up replicas for fail > over. This was clearly pointed out at the beginning of the discussion. You can't have both, it should be clear. > What about making the behavior configurable? Right now, cmusaslsecretOTP is hardcoded, because if the shadow copy is used, OTP breaks. If it is acceptable to have it broken, we can remove the hardcoding, and let admins decide whether they prefer fail-over over consistency. I'd have no doubt, and favor consistency. p.
<masarati@aero.polimi.it> wrote: > > access to * attrs=cmusaslsecretOTP > > by dn.regex="cn=replica,o=test" write stop > > by * break > > This is orthogonal to the sasl auxprops discussion. It's a matter of > well-configuring the authorizing identity in slapo-chain(5). I pointed it here for future reference because this is an unusual case. I suspect everyone configure replicas with universal read-only access. For this to work, replica must also have write access to cmusaslsecretOTP. > > Another point: bind on the replica is impossible when the master is > > down. I understand this is to prevent replaying the same OTP on multiple > > replicas, but that defeats the purpose of setting up replicas for fail > > over. > > This was clearly pointed out at the beginning of the discussion. You > can't have both, it should be clear. Yes, I understand that. > Right now, cmusaslsecretOTP is hardcoded, because if the shadow copy is > used, OTP breaks. If it is acceptable to have it broken, we can remove > the hardcoding, and let admins decide whether they prefer fail-over over > consistency. I'd have no doubt, and favor consistency. When you tell about using the shadow copy, the modification will still be sent to the master, right? Such a behavior allows replays attacks within the modification propagation time frame, but it ensures that bind are still possible when then master is down. I think it could be interesting to have a configuration setting for that. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@netbsd.org
> <masarati@aero.polimi.it> wrote: > >> > access to * attrs=cmusaslsecretOTP >> > by dn.regex="cn=replica,o=test" write stop >> > by * break >> >> This is orthogonal to the sasl auxprops discussion. It's a matter of >> well-configuring the authorizing identity in slapo-chain(5). > > I pointed it here for future reference because this is an unusual case. > I suspect everyone configure replicas with universal read-only access. > For this to work, replica must also have write access to > cmusaslsecretOTP. Well, if a shadow uses slapo-chain(5), the producer must be configured in order to allow writes coming from the shadow. >> > Another point: bind on the replica is impossible when the master is >> > down. I understand this is to prevent replaying the same OTP on >> multiple >> > replicas, but that defeats the purpose of setting up replicas for fail >> > over. >> >> This was clearly pointed out at the beginning of the discussion. You >> can't have both, it should be clear. > > Yes, I understand that. > >> Right now, cmusaslsecretOTP is hardcoded, because if the shadow copy is >> used, OTP breaks. If it is acceptable to have it broken, we can remove >> the hardcoding, and let admins decide whether they prefer fail-over over >> consistency. I'd have no doubt, and favor consistency. > > When you tell about using the shadow copy, the modification will still > be sent to the master, right? Not in the original code. In that case, the modification was bypassing replication, thus it was being applied to the shadow without generating a referral. The alternative, inconsistent solution you seem to indicate would require to replay the modification as internal in case the modification to the producer failed because the service was not available. > Such a behavior allows replays attacks > within the modification propagation time frame, but it ensures that bind > are still possible when then master is down. I think it could be > interesting to have a configuration setting for that. We should bring this to -devel, to see whether it makes sense and whether it would be acceptable. p.
changed notes
>> Such a behavior allows replays attacks >> within the modification propagation time frame, but it ensures that bind >> are still possible when then master is down. I think it could be >> interesting to have a configuration setting for that. > > We should bring this to -devel, to see whether it makes sense and whether > it would be acceptable. A fix in this sense is in HEAD. Modifications consist in the original patch (well-known SASL mechs exploit the dontUseCopy control to actually lookup and propagate auxprops to the master ("sasl-auxprops-dontusecopy" directive). Another directive ("sasl-auxprops-dontusecopy-ignore") allows to ignore errors and lookup/store auxprops locally. By default it's FALSE for consistency. If set to TRUE, replicas will be misaligned, but service will be possible. Choose what best fits your needs. Both directives are not documented yet, as I consider the whole code highly experimental. Right now, is only built when #define LDAP_DEVEL. Please note that the relatively minor modifications to slapo-chain(5) are not conditioned on #define SLAP_AUXPROP_DONTUSECOPY, because I think they are generally useful, and I've checked they don't break anything (I could check so far). Please report any inconvenience. p.
moved from Software Bugs to Development
Hi, I've received segmentation faults during some basic SASL OTP testing using CVS HEAD. Below you'll find a small patch (against HEAD) which seems to fix this issue ... Before the patch: root@tingletangle:~/repos/openldap# /usr/local/openldap/bin/ldapsearch -v -Y OTP -U test1 ldap_initialize( <DEFAULT> ) SASL/OTP authentication started ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) (<== slapd segfault) After the patch has been applied: root@tingletangle:~/repos/openldap# /usr/local/openldap/bin/ldapsearch -v -Y OTP -U test1 ldap_initialize( <DEFAULT> ) SASL/OTP authentication started Challenge: otp-md5 498 ti6311 ext Please enter your one-time password: huhu ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: (<== slapd still running ;-) ) As I'm not (yet ;-)) an OTP-expert I have not tested any further because I currently just don't know how to calculate the one-time password based on the challenge ... Best regards, Daniel Index: servers/slapd/sasl.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/sasl.c,v retrieving revision 1.274 diff -u -r1.274 sasl.c --- servers/slapd/sasl.c 15 Apr 2010 16:13:54 -0000 1.274 +++ servers/slapd/sasl.c 19 Jul 2010 19:55:11 -0000 @@ -548,7 +548,7 @@ op.o_req_ndn.bv_val = (char *)pr[i].values[0]; } #ifdef SLAP_AUXPROP_DONTUSECOPY - { + if ( slap_dontUseCopy_propnames != NULL ) { struct berval bv; ber_str2bv( &pr[i].name[1], 0, 1, &bv ); for ( j = 0; !BER_BVISNULL( &slap_dontUseCopy_propnames[ j ] ); j++ ) {
Daniel Pluta <daniel@pluta.biz> wrote: > As I'm not (yet ;-)) an OTP-expert I have not tested any further because > I currently just don't know how to calculate the one-time password based > on the challenge ... skey(1) can do it for you. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@netbsd.org
fixed in master