Michael B Allen wrote:
On Sat, 27 Jan 2007 22:48:24 -0800 Howard Chu hyc@symas.com wrote:
Michael B Allen wrote:
Hi,
I need to gss_wrap/gss_unwrap all requests and responses into SASL buffers. Is there an existing method for doing that?
Otherwise, I suppose the best techniqure would be to allow the user to register an "inspect" callback that will be called with the data buffer just read from or wrtten to the network. I'm starting to look at the code now but if someone could give me a hint I would appreciate it.
libldap interfaces with libsasl. The SASL GSSAPI module already handles gss_wrap/gss_unwrap.
Your question doesn't provide enough context; give a broader explanation of what you're trying to do.
Mmm, I *think* you're talking about mechanism "GSSAPI". I'm doing "GSS-SPNEGO" which is little different. In particular, after the GSS-SPNEGO bind, requests and responses (e.g. searches) are wrapped with gss_wrap/gss_unwrap. That presents a problem because the current API doesn't seem to provide a method for accessing network buffers.
Anyway, I have GSS-SPNEGO almost working (only wrapping outgoing messages at the moment, unwrapping is tomorrow) but it required modifying libldap and liblber. I added an ldap_set_inspect_hdlr function that sets read/write callbacks. They're invoked in sockbuf.c:{ber_int_sb_read,ber_int_sb_write} if Sockbuf has a handler installed. The user must supply handler that read/write and "inspect" the buffers possibly writing alternative data (ie the gss_wrap'd data).
The modifications were pretty simple and clean. Is there a better way?
Do you guys want to support GSS-SPNEGO?
You clearly don't understand the layering of the subsystems you're working with. The "GSS" in "GSSAPI" stands for "Generic Security Service" - it is designed to work with arbitrary security mechanisms. SPNEGO is only one possible choice of GSS mechanism, and of course it is not a security mechanism itself, but a multiplexor that can select Kerberos or NTLM or some other arbitrary security mechanism.
As I already said - libldap doesn't talk to GSSAPI directly. It talks to libsasl. It is libsasl's job to talk to the GSSAPI layer. Granted, in the current Cyrus SASL implementation, their GSSAPI module can only use Kerberos 5 as the underlying security mechanis, so that would need to be modified.
You should look at adding SPNEGO support to Cyrus SASL. Then it will automatically be available to OpenLDAP (and every other app that uses libsasl) through the SASL interface. There is no reason to modify any part of libldap or liblber. The abstraction layers are already well defined. All you have to do is plug your code in at the correct layer.