> Right. > > > - SSL auth. does not help, as it en/decrypts all the data that is sent > > over the LDAP connection, which causes slight performance overhead. > > Unless your implementation supports re-negotiating the TLS cipher down > to null cipher after Bind. > > But is this slight performance overhead a problem for you? Or are you > solving a non-problem here, so you could just as well accept encryption > of the entire session? Our mission-critical application which accesses the remote LDAP server, has very high performant LDAP data access requirement. Also, en/decrypting all the data(except the password that is used for the authentication) that is sent over the LDAP connection is not a stringent requirement for us.
> > - SASL auth. also does not help. (I'm not sure here!) > > Yes it does. The DIGEST-MD5 mechanism for example. It supports a > security layer (just like TLS), but that's optional. Here, do you mean that the SASL mechanism can fulfill my requirement of sending only the password in encrypted and other data in non-encrypted form? I will also check it in detail. --- You are currently subscribed to ldap@umich.edu as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
