A packet or streams layer for GENSEC/SASL?

[Michael B Allen]

On Sat, 04 Feb 2006 00:27:30 -0500
simo <idra at samba.org> wrote:

> On Sat, 2006-02-04 at 16:21 +1100, Andrew Bartlett wrote:
> > I've been looking at the complexities of the GENSEC 'wrap' code for
> > GSSAPI, and trying to follow the spec in the process.  
> > 
> > One of the important details that is securely negotiated between client
> > and server is the maximum buffer size.  Currently, there isn't a good
> > way to communicate this up and down the stack, and I get the felling
> > that we are using gensec_wrap() in the 'wrong way'. 
> > 
> > It seems to me that just as gnutls is free to accept 'writes' and manage
> > it's own 'network socket' (by means of plugin 'read'/'write' functions),
> > that is how SASL wants us to behave.  A SASL layer should break up the
> > LDAP packets into 4-byte prefixed SASL packets, for output on a stream
> > socket.
> > 
> > Indeed, with both the TLS libs and GENSEC wanting to be in this stack,
> > could we simply define them both in terms of our current socket API, and
> > have them recurse down to a real socket?  Or would that all end up in a
> > mess with events?
> 
> I'd go with the layer approach and let them manage the socket exposing a
> stackable API, in my experience that's what works best.

I'm disappointed that OpenSSL basically takes over socket operations
requiring the user to litter their code with SSL_read, SSL_write, etc
all over the place. That's just not necessary. What happends if you want
to pass buffers through shared memory so that another process can do
the socket I/O? How do you know you will be using a socket at all? IMO
the input / output token concept of GSSAPI is the most flexible model
(not to be discredited by the grossly overspecifed nature of GSSAPI's
languange bindings). If you want a convenient functions that give you
a socket API then you can easily build that on top of the read/write
tokens style stack. Doing the reverse is potentially ugly.

Mike