Full_Name: Luke Howard Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (165.228.130.11) Some SASL clients require that serverSaslCreds be provided when the last token returned by the server is zero length. Presently OpenLDAP omits serverSaslCreds. (This is obviously only an issue for mechanisms such as GSSAPI that return a zero length token on the last leg of the authentication.) The following patch fixes this: cvs server: Diffing . Index: sasl.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/sasl.c,v retrieving revision 1.165.2.12 diff -u -r1.165.2.12 sasl.c --- sasl.c 17 Jan 2004 19:32:20 -0000 1.165.2.12 +++ sasl.c 3 Mar 2004 22:42:27 -0000 @@ -1625,7 +1625,7 @@ } /* Must send response using old security layer */ - if (response.bv_len) rs->sr_sasldata = &response; + rs->sr_sasldata = &response; send_ldap_sasl( op, rs ); /* Now dispose of the old security layer.
This patch does appear to cause slapd to misbehave for reasons I have not yet determined... One note is that Cyrus SASL 2 returns a static constant string ("") for zero length responses. But as OpenLDAP doesn't try to free the response data for Cyrus SASL 2 it seems unlikely that this is the problem. -- Luke
I believe this change will cause breakage in other cases. A server returning data of any length (including zero) is distinct case from a server returning no data. Kurt At 07:50 AM 3/4/2004, lukeh@padl.com wrote: >Full_Name: Luke Howard >Version: HEAD >OS: Linux >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (165.228.130.11) > > >Some SASL clients require that serverSaslCreds be provided when the last token >returned by the server is zero length. Presently OpenLDAP omits >serverSaslCreds. > >(This is obviously only an issue for mechanisms such as GSSAPI that return a >zero length token on the last leg of the authentication.) > >The following patch fixes this: > >cvs server: Diffing . >Index: sasl.c >=================================================================== >RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/sasl.c,v >retrieving revision 1.165.2.12 >diff -u -r1.165.2.12 sasl.c >--- sasl.c 17 Jan 2004 19:32:20 -0000 1.165.2.12 >+++ sasl.c 3 Mar 2004 22:42:27 -0000 >@@ -1625,7 +1625,7 @@ > } > > /* Must send response using old security layer */ >- if (response.bv_len) rs->sr_sasldata = &response; >+ rs->sr_sasldata = &response; > send_ldap_sasl( op, rs ); > > /* Now dispose of the old security layer.
FWIW Cyrus SASL returns a zero-length string, not NULL, on the last leg of a GSS-API authentication. If we are to respect the difference between the two, shouldn't slapd only return serverSaslCreds if the SASL library returns NULL? I tested some alternative server implementations of the GSSAPI SASL mechanism: - Active Directory returns serverSaslCreds with length zero - PADL GSS-SASL doesn't return serverSaslCreds (as far as I can tell from the code, I didn't actually look at a packet trace) Did this ever come up in the working group? We should find out what Sun DS 5.2 does for GSSAPI... -- Luke
Sounds like something which should be discussed by LDAPBIS... Kurt At 02:04 PM 3/4/2004, lukeh@PADL.COM wrote: >FWIW Cyrus SASL returns a zero-length string, not NULL, on the last >leg of a GSS-API authentication. > >If we are to respect the difference between the two, shouldn't slapd >only return serverSaslCreds if the SASL library returns NULL? > >I tested some alternative server implementations of the GSSAPI >SASL mechanism: > >- Active Directory returns serverSaslCreds with length zero > >- PADL GSS-SASL doesn't return serverSaslCreds (as far as I can > tell from the code, I didn't actually look at a packet trace) > >Did this ever come up in the working group? > >We should find out what Sun DS 5.2 does for GSSAPI... > >-- Luke
changed notes changed state Open to Suspended
moved from Incoming to Software Bugs
moved from Software Bugs to Incoming
changed notes changed state Suspended to Closed
moved from Incoming to Archive.Incoming
pending IETF clarification MSAD kludged in ITS#4391