GSS_C_NULL_OID into mech_type to specify the default
         mechanism,



RFC 1961          GSS-API Authentication for SOCKS V5          June 1996

         GSS_C_NO_CONTEXT into context_handle to specify a NULL
         context (initially), and,

         the previously imported server name into target_name.

   The client must also specify its requirements for replay protection,
   delegation, and sequence protection via the gss_init_sec_context
   req_flags parameter.  It is required by this specification that the
   client always requests these service options (i.e. passes
   GSS_C_MUTUAL_FLAG | GSS_C_REPLAY_FLAG | GSS_C_DELEG_FLAG |
   GSS_C_SEQUENCE_FLAG into req_flags).

   However, GSS_C_SEQUENCE_FLAG should only be passed in for TCP-based
   clients, not for UDP-based clients.

3.3 Client Context Establishment Major Status codes

   The gss_init_sec_context returned status code can take two different
   success values:

    - If gss_init_sec_context returns GSS_S_CONTINUE_NEEDED, then the
      client should expect the server to issue a token in the
      subsequent subnegotiation response.  The client must pass the
      token to another call to gss_init_sec_context, and repeat this
      procedure until "continue" operations are complete.

    - If gss_init_sec_context returns GSS_S_COMPLETE, then the client
      should respond to the server with any resulting output_token.

      If there is no output_token, the client should proceed to send
      the protected request details, including any required message
      protection subnegotiation as specified in sections 4 and 5
      below.

3.4 Client initial token

   The client's GSS-API implementation then typically responds with the
   resulting output_token which the client sends in a message to the
   server.

    +------+------+------+.......................+
    + ver  | mtyp | len  |       token           |
    +------+------+------+.......................+
    + 0x01 | 0x01 | 0x02 | up to 2^16 - 1 octets |
    +------+------+------+.......................+



RFC 1961          GSS-API Authentication for SOCKS V5          June 1996

    Where:

    - "ver" is the protocol version number, here 1 to represent the
      first version of the SOCKS/GSS-API protocol

    - "mtyp" is the message type, here 1 to represent an
      authentication message

    - "len" is the length of the "token" field in octets

    - "token" is the opaque authentication token emitted by GSS-API

3.5 Client GSS-API Initialisation Failure

   If, however, the client's GSS-API implementation failed during
   gss_init_sec_context, the client must close its connection to the
   server.

3.6 Server Context Establishment

   For the case where a client successfully sends a token emitted by
   gss_init_sec_context() to the server, the server must pass the
   client-supplied token to gss_accept_sec_context as input_token.

   When calling gss_accept_sec_context() for the first time, the
   context_handle argument is initially set to GSS_C_NO_CONTEXT.

   For portability, verifier_cred_handle is set to GSS_C_NO_CREDENTIAL
   to specify default credentials (for acceptor usage).

   If gss_accept_sec_context returns GSS_CONTINUE_NEEDED, the server
   should return the generated output_token to the client, and
   subsequently pass the resulting client supplied token to another call
   to gss_accept_sec_context.

   If gss_accept_sec_context returns GSS_S_COMPLETE, then, if an
   output_token is returned, the server should return it to the client.

   If no token is returned, a zero length token should be sent by the
   server to signal to the client that it is ready to receive the
   client's request.