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 */