[Date Prev][Date Next] [Chronological] [Thread] [Top]

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



At 10:17 PM 7/19/00 +0000, mei@isi.edu wrote:
>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.

I've been testing mostly with GSSAPI, in particular with
Heimdal Kerberos 5.

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

Thanks, fixed.


>  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.

This should be handled by the Cyrus SASL GSSAPI plugin, not slapd.
The plugin should return SASL_CONTINUE with response containing
the output_token.  The client should then step() and send resulting
no data to server.  The server should then step() to get SASL_OK.

Likely something we should discussion the cyrus-sasl mailing
list.


>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 ) {