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

Re: gss_wrap/gss_unwrap sasl buffers?

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.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/