måndag 5 oktober 2009

The use of of gss_accept_sec_context (ASC)

This is continuation of the previous article about ISC.

The gssapi function ASC (gss_accept_sec_context) is also complicated,
function, one can argue ASC is simpler then ISC since ASC only takes
11 arguments.
OM_uint32
gss_accept_sec_context
(OM_uint32 * /*minor_status*/,
gss_ctx_id_t * /*context_handle*/,
const gss_cred_id_t /*acceptor_cred_handle*/,
const gss_buffer_t /*input_token_buffer*/,
const gss_channel_bindings_t /*input_chan_bindings*/,
gss_name_t * /*src_name*/,
gss_OID * /*mech_type*/,
gss_buffer_t /*output_token*/,
OM_uint32 * /*ret_flags*/,
OM_uint32 * /*time_rec*/,
gss_cred_id_t * /*delegated_cred_handle*/
);

Again, just like ISC the main problem is that consumers if this interface tries to pass in too much information, less is usually better.

Not passing in a credential


If consumers instead of passing a credential checked the name afterward it would work in more situations. For example, using the GSSAPI Kerberos mech as an acceptor: when the client connects the server doesn't know what name the client used, and if the server specifies a credential (thus an implicitly a name) the client have selected another name, ASC will fail.

Do when do server and client not patch up on names ? There are plent of examples, where: HTTP/www, http/www.example.com is the one to start with. Kerberos is case sensitive and client might expect aliases to work.

The logic flow for ASC


The flow of a server part of gss-api negotiation looks like this:
in = null;
do {
ret = gss_accept_sec_context(in, out);
if (GSS_ERROR(ret))
abort();
send_message(out);
if (ret == GSS_C_CONTINUE)
in = read_message();
} while (ret == GSS_C_CONTINUE);

if (check_return_flags())
abort();

if (check_that_name_is_ok(ctx))
abort();

/* done */