development tree, servers/slapd/sasl.c (ITS#631)

[mei@isi.edu]

Full_Name: mei-hui su
Version: latest development tree
OS: sun solaris 2.7
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (128.9.64.206)


Hi,

  This is a patch file against the latest development tree. I am using
openldap with cyrus-sasl and globus gsi which is a GSSAPI and so there
are multiple handshaking roundtrip calls between client and servers.

  The check on the the 'mech' is needed because it is NULL when sasl_bind
is called again in continuation. 

  And the 2nd part is to implement the 'final step' for SASL server response.
(from rfc2222.txt) 

7.2.2 Server side of authentication protocol exchange

   ...

   When GSS_Accept_sec_context returns GSS_S_COMPLETE, the client takes
   the following actions: If the last call to GSS_Accept_sec_context   <<<----
   returned an output_token, the server returns it to the client in a
   challenge and expects a reply from the client with no data.  Whether
   or not an output_token was returned (and after receipt of any
   response from the client to such an output_token), the server then
   constructs 4 octets of data, with the first octet containing a bit-
   mask specifying the security layers supported by the server and the
   second through fourth octets containing in network byte order the
   maximum size output_token the server is able to receive.  The server
   must then pass the plaintext to GSS_Wrap with conf_flag set to FALSE
   and issue the generated output_message to the client in a challenge.
   The server must then pass the resulting response to GSS_Unwrap and
   interpret the first octet of resulting cleartext as the bit-mask for
   the selected security layer, the second through fourth octets as the
   maximum size output_message to send to the client, and the remaining

'<<<--' means that the call to GSS_Accept_sec_context does not need to
   result in an output_token, and only when there is a output_token produced
   should it be sent to the client. And then either case, server should do a    

   last server-step call and send that to the client

mei
Index: sasl.c
===================================================================
RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/sasl.c,v
retrieving revision 1.31
diff -u -r1.31 sasl.c
--- sasl.c      2000/07/15 21:25:47     1.31
+++ sasl.c      2000/07/19 20:29:08
@@ -401,7 +401,7 @@
 
        Debug(LDAP_DEBUG_ARGS,
                "==> sasl_bind: dn=\"%s\" mech=%s cred->bv_len=%d\n",
-               dn, mech, cred ? cred->bv_len : 0 );
+               dn, (mech==NULL) ? "": mech, cred ? cred->bv_len : 0 );
 -               send_ldap_sasl( conn, op, rc = LDAP_SASL_BIND_IN_PROGRESS,
-                       NULL, NULL, NULL, NULL,  &response );
-
+                if(response.bv_len > 0) {
+                        send_ldap_sasl( conn, op, rc =
LDAP_SASL_BIND_IN_PROGRESS,
+                        NULL, NULL, NULL, NULL,  &response );
+               } else {
+                        sc = sasl_server_step( ctx,
+                                cred->bv_val, cred->bv_len,
+                                (char **)&response.bv_val,
+                                (unsigned *)&response.bv_len, &errstr);
+                        if (sc != SASL_CONTINUE || response.bv_len == 0)
+                                send_ldap_result( conn, op,
+                                        rc = slap_sasl_err2ldap( sc ),
+                                        NULL, errstr, NULL, NULL );
+                        else send_ldap_sasl( conn, op,
+                                        rc = LDAP_SASL_BIND_IN_PROGRESS,
+                                        NULL, NULL, NULL, NULL,  &response );
+               }
        } else {
                send_ldap_result( conn, op, rc = slap_sasl_err2ldap( sc ),
                        NULL, errstr, NULL, NULL );

        if( ctx == NULL ) {
                send_ldap_result( conn, op, LDAP_UNAVAILABLE,
@@ -490,9 +490,22 @@
                }
 
        } else if ( sc == SASL_CONTINUE ) {