Re: KITTEN: IETF 75 - 76

["Stefan (metze) Metzmacher" <[e-mail]>]

Michael B Allen schrieb:
> On Tue, 01 Sep 2009 15:18:13 -0700
> Love Hörnquist Åstrand <[e-mail]> wrote:
> 
>> 1 sep 2009 kl. 15:13 skrev Michael B Allen:
>>
>>>  it means that you need to call it again later
>> When is later unless you get a callback ?
> 
> When you call the function with the flag GSS_C_NOWAIT, the implementation transmits the network request [1] and then checks to see if data can be read (such as by using select(2)). If data is not available, the function simply returns a status of EAGAIN. Now the caller is free to perform other work (and thus it is async). But the caller now knows that the function needs to be called again to complete the operation. So later, it calls the function again. If the network response has been received, it returns success. Otherwise, if GSS_C_NOWAIT was supplied, it again returns EAGAIN. If GSS_C_NOWAIT was not supplied, it waits for the operation to complete (e.g. for a network response to be received) just like the non-async call. In fact async and non-async uses the same function - the GSS_C_NOWAIT flag alone controls async behavior.

That is true for system calls like send() and recv(), where the caller
is supposed to call select. But for gssapi the caller would have to poll
like this:

while (1) {

	ret = gss_call(&minor, ...);
	if (ret != 0 && minor == EAGAIN) {
		continue;
	}
	...
	break;
}

Or the application needs to try every few milli seconds...

What about a generic callback infrastructure:

typedef void *gss_async_cookie_t;

OM_uint32 gss_init_async_cookie(
	void (*callback)(gss_async_cookie_t *cookie,
                         void *callback_private),
	void *callback_private,
	gss_async_cookie_t **cookie
	);

OM_uint32 gss_release_async_cookie(gss_async_cookie_t **cookie);

#define GSS_S_ASYNC 12345678

and then either one function that autodetects if it should use
the input parameters based on its state in the async cookie.

OM_uint32 GSSAPI_LIB_FUNCTION gss_init_sec_context_async
           (OM_uint32 * /*minor_status*/,
            const gss_cred_id_t /*initiator_cred_handle*/,
            gss_ctx_id_t * /*context_handle*/,
            const gss_name_t /*target_name*/,
            const gss_OID /*mech_type*/,
            OM_uint32 /*req_flags*/,
            OM_uint32 /*time_req*/,
            const gss_channel_bindings_t /*input_chan_bindings*/,
            const gss_buffer_t /*input_token*/,
            gss_OID * /*actual_mech_type*/,
            gss_buffer_t /*output_token*/,
            OM_uint32 * /*ret_flags*/,
            OM_uint32 * /*time_rec*/,
            gss_async_cookie_t * /* cookie */
           );

or two functions.

OM_uint32 GSSAPI_LIB_FUNCTION gss_init_sec_context_input
           (OM_uint32 * /*minor_status*/,
            const gss_cred_id_t /*initiator_cred_handle*/,
            gss_ctx_id_t * /*context_handle*/,
            const gss_name_t /*target_name*/,
            const gss_OID /*mech_type*/,
            OM_uint32 /*req_flags*/,
            OM_uint32 /*time_req*/,
            const gss_channel_bindings_t /*input_chan_bindings*/,
            const gss_buffer_t /*input_token*/,
            gss_async_cookie_t * /* cookie */
           );

OM_uint32 GSSAPI_LIB_FUNCTION gss_init_sec_context_output
           (OM_uint32 * /*minor_status*/,
            gss_OID * /*actual_mech_type*/,
            gss_buffer_t /*output_token*/,
            OM_uint32 * /*ret_flags*/,
            OM_uint32 * /*time_rec*/,
            gss_async_cookie_t * /* cookie */
           );

If the gss_init_sec_context implementation has finished the work
it notifies the callback that it's done. But to get the actual results
the caller needs to call the gss_init_sec_context_async() function again
(or the gss_init_sec_context_output() function) and pass the same async
cookie.

I think something like this would make the api at least useful for Samba.

metze