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.

On Sun, 28 Jan 2007 14:42:54 -0800 Howard Chu hyc@symas.com wrote:

Michael B Allen wrote:

...

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?

Assuming that OpenLDAP was the appropriate home for such code (which it is not) the correct approach would be to write a new Sockbuf handler and push it onto the existing stack of handlers. That's how both SASL and TLS are implemented. Mucking with sockbuf.c itself is definitely the wrong way. The whole point of the sockbuf infrastructure is that it allows arbitrary processing layers to be stacked without having to modify any core code.

Yup. That's exactly what I'm doing now. I just didn't see it before but cyrus.c seems to be the model for what I want to do. And I see ber_sockbuf_add_io et al is public so I'm hoping I can do it without touching libldap or liblber at all.

For reasons not worth dicussing I'm not very interested in using libsasl (at least not cyrus).

Thanks, Mike

PS: OpenLDAP is nice code. Well organised and understandable. Thanks to those involved.

On Sun, 28 Jan 2007 15:38:54 -0800 Howard Chu hyc@symas.com wrote:

However, the only standards-compliant way to enable this functionality is through a SASL Bind. Are you actually reimplementing that as well? We've

I'm not reimplementing all SASL mechs. I'm just doing GSSAPI and GSS-SPNEGO. Doing ldap_sasl_bind_s + gss_init_sec_context et al is relatively simple.

talked about jettisoning Cyrus SASL in favor of "something else" but there haven't been any other implementations worth considering. Feel free to continue this conversation on the openldap-devel mailing list if you want to pursue it further.

When I get everyting dialed in maybe I'll post it. Then we can speculate further.

Mike