The gssapi function ASC (gss_accept_sec_context) is also complicated,
function, one can argue ASC is simpler then ISC since ASC only takes
(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*/,
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;
ret = gss_accept_sec_context(in, out);
if (ret == GSS_C_CONTINUE)
in = read_message();
} while (ret == GSS_C_CONTINUE);
/* done */