[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#6199) [JLDAP] SASL integrity & confidentiality



Full_Name: Michael B Allen
Version: JLDAP
OS: Linux
URL: http://www.ioplex.com/~miallen/openldap-jldap-saslwrap.diff
Submission from: (NULL) (71.187.189.103)


It would be fabulous if SASL integrity and confidentiality worked in JLDAP.

I just tried and failed to add support for it. I could be just misguided but it
seems that because the ASN.1 routines encoded and decoded BER directly to and
from the socket element by element, there is a fairly low-level issue with
wrapping and unwrapping entire message buffers. But I was unable to pinpoint the
precise cause.

See the URL for my crude patch to test SASL wrap / unwrap. Of course you'll need
a SASL client and mechanism that supports at least integrity.

Since com.novell.ldap.Connection.writeMessage encodes the entire message before
writing it to the socket, the SASL wrap works.

However, reading data from the input stream has a strange off-by-one problem.
The first byte is missing. But since the first 4 bytes are the big endian SASL
buffer size, I can hack to code to skip it and it is unwrapped properly
(although it looks like a referral so I think perhaps my search() test program
isn't quite right either). It then hangs in LDAPSearchResults.hasMore:

        at java.lang.Object.wait(Object.java:474)
        at com.novell.ldap.MessageAgent.getLDAPMessage(MessageAgent.java:399)
        - locked <0x89152240> (a com.novell.ldap.MessageVector)
        at com.novell.ldap.LDAPMessageQueue.getResponse(LDAPMessageQueue.java:175)
        at com.novell.ldap.LDAPMessageQueue.getResponse(LDAPMessageQueue.java:126)
        at com.novell.ldap.LDAPSearchResults.getBatchOfResults(LDAPSearchResults.java:338)
        at com.novell.ldap.LDAPSearchResults.resetVectors(LDAPSearchResults.java:213)
        at com.novell.ldap.LDAPSearchResults.hasMore(LDAPSearchResults.java:175)
        at org.ietf.ldap.LDAPSearchResults.hasMore(LDAPSearchResults.java:89)

Unfortunately this looks like a fairly low-level architectual issue so I'll have
to fall-back to JNDI. But hopefully this will help someone who wants to add this
critical functionality in the future. Using the builtin integrity and
confidentiality offered by mechanisms like GSSAPI is pretty important IMO. At
least it's quite a bit more graceful than using TLS.