Fwd: GSSAPI contexts used in multiple threads

[Russ Allbery <rra@stanford.edu>]

As part of the discussion of adding additional thread safety guarantees to
MIT Kerberos's GSS-API implementation to support OpenLDAP's use case, Sam
Hartman had the following additional questions about how OpenLDAP uses
SASL in such a way as to run into this problem.  I'm happy to forward
answers back to him.  I don't understand the usage well enough to explain
it myself.

| From: Sam Hartman <hartmans@mit.edu>
| Subject: GSSAPI contexts used in multiple threads
| Date: Mon, 03 Mar 2008 16:28:13 -0500
| 
| Hi.  I'm catching up on email.  I read a discussion (although I cannot
| find it now) of adding support so that an established gss-api context
| can be used in multiple threads at the same time.  This seems like a
| fine feature to add to MIT Kerberos.
| 
| However I'm quite puzzled as to how this works for LDAP or any other
| SASL application.  SASL is a stream protocol; it presents an ordered
| stream across the network connection.  In order to guarantee this the
| sasl security layer requires that tokens be wrapped and unwrapped in
| the same order.  If you don't do that you can get into a situation
| where the wrap order is different from the unwrap order and you get
| spurious gap tokens or out of order tokens.  You cannot tell the
| difference between this and an attack.  Also, since SASL applications
| may chunk data into GSS-API tokens in arbitrary order, GSS-API tokens
| may not line up with LDAP PDU boundaries.
| 
| So, I'm very confused about how an LDAP implementation could be a
| correct application and run into problems with MIT's current thread
| safety requirements.
| 
| I'd appreciate it if people who do remember the original discussion
| could forward my message to the right place to get an answer.
| 
| Thanks,
| 
| --Sam

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>