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