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 wrote:
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.
The point is that an LDAP session is full duplex, as I already described here http://www.openldap.org/lists/openldap-technical/200802/msg00121.html
Let me know if Sam needs more details than that.
| From: Sam Hartmanhartmans@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
Howard Chu hyc@symas.com writes:
The point is that an LDAP session is full duplex, as I already described here http://www.openldap.org/lists/openldap-technical/200802/msg00121.html
Ah, I just didn't fully understand the implications. The sequences for each direction of the connection are independent? (If so, this may work with the current MIT Kerberos concurrency model, although I should confirm that.)
I'll forward this along.
Howard Chu hyc@symas.com writes:
The point is that an LDAP session is full duplex, as I already described here http://www.openldap.org/lists/openldap-technical/200802/msg00121.html
The belief of the MIT folks is that, given the code, this will probably work now without any trouble. However, there is now an open bug to enhance the thread-safe guarantees and (more importantly) document them.
openldap-technical@openldap.org
-
Howard Chu -
Russ Allbery