GSS-API Authentication Method for SOCKS Version 5
Extracted elements (24)
Protection level 3 (selective per-message integrity or confidentiality) is anticipated to be impractical for most implementations due to the difficulty of applying selective controls to messages passed through a SOCKS library; levels 1 or 2 are expected in practice.
The client should use GSS_C_NULL_OID as the default name_type when importing the server name for maximal portability, since different mechanisms (e.g. Kerberos V5 vs. others) use different name forms and the client should not assume name syntax.
The GSS-API context termination message emitted by gss_delete_sec_context is not used by this protocol; instead, each peer calls gss_delete_sec_context with GSS_C_NO_BUFFER when the connection is closed. This avoids an additional protocol round-trip for teardown.
GSS-API peers achieve interoperability by establishing a common security mechanism — either through administrative action or through negotiation — before context establishment. The SOCKS V5 GSS-API method encapsulates any mechanism-selection negotiation within GSS-API itself.
This specification is intended for use with RFC 1508/RFC 1509 GSS-API implementations and the emerging GSS-API V2 specification; implementations must handle the token-exchange loop correctly across both GSS-API versions.
GSS_C_SEQUENCE_FLAG should only be passed for TCP-based clients, not for UDP-based clients.
If protection level 1 is agreed, conf_req_flag MUST always be FALSE; if protection level 2 is agreed, conf_req_flag MUST always be TRUE; if protection level 3 is agreed, conf_req is determined per-message by local configuration.
If the client's GSS-API implementation fails during gss_init_sec_context, the client must close its connection to the server.
If the server's choice of protection level is unacceptable to the client, the client must close its connection to the server.
The client must specify GSS_C_MUTUAL_FLAG | GSS_C_REPLAY_FLAG | GSS_C_DELEG_FLAG | GSS_C_SEQUENCE_FLAG in req_flags when calling gss_init_sec_context, requiring mutual authentication, replay protection, delegation, and sequence protection.
The server must pass the client-supplied token to gss_accept_sec_context as input_token when a client successfully sends a token emitted by gss_init_sec_context.
The server must send a zero-length token to signal readiness to receive the client's request when gss_accept_sec_context returns GSS_S_COMPLETE with no output_token.
Four message types are defined: 0x01 (authentication token), 0x02 (protection-level negotiation), 0x03 (encapsulated user data), 0xff (abort/failure). Protocol version is always 0x01.
GSS-API per-message protection uses gss_seal()/gss_wrap() for encapsulation and gss_unseal()/gss_unwrap() for de-encapsulation. The protection level subnegotiation token encapsulates a single octet with conf_req set to FALSE.
Three protection levels are defined for subnegotiation: 1 = required per-message integrity, 2 = required per-message integrity and confidentiality, 3 = selective per-message integrity or confidentiality based on local configuration.
The security services provided through GSS-API are entirely dependent on the effectiveness of the underlying security mechanisms and the correctness of the implementation of the underlying algorithms and protocols.
Users of a GSS-API service must ensure the quality of protection provided by the mechanism implementation is consistent with their security policy. Where GSS-API negotiation is supported, constraints on acceptable mechanisms may be imposed to ensure suitability for authenticated firewall traversal.
After successful GSS-API context establishment, client and server exchange protection-level subnegotiation messages (mtyp=0x02). If client rejects server's level, client closes connection; otherwise both sides proceed to per-message GSS-API encapsulation for all subsequent traffic.
Context establishment loop: client calls gss_init_sec_context; if GSS_S_CONTINUE_NEEDED, sends token and awaits server token then repeats; if GSS_S_COMPLETE, sends any output_token then proceeds to protection-level subnegotiation. Server mirrors this with gss_accept_sec_context.
Client initial GSS-API token message: ver (1 octet, 0x01), mtyp (1 octet, 0x01 for authentication), len (2 octets), token (up to 2^16-1 octets, opaque GSS-API output_token).
Per-message encapsulation framing: ver (0x01), mtyp (0x03 for encapsulated user data), len (2 octets), token (up to 2^16-1 octets of GSS-API wrapped user data).
Protection-level subnegotiation message: ver (0x01), mtyp (0x02), len (2 octets), token (up to 2^16-1 octets containing GSS-API encapsulated protection level octet).
Security context failure/abort message: ver (1 octet, 0x01), mtyp (1 octet, 0xff). Sent by server when refusing a client connection for any reason.
Server reply message uses the same format as the client token: ver (0x01), mtyp (0x01), len (2 octets), token (up to 2^16-1 octets).