RFC 1961 (rfc1961) - Page 2 of 9
GSS-API Authentication Method for SOCKS Version 5
Alternative Format: Original Text Document
RFC 1961 GSS-API Authentication for SOCKS V5 June 1996
GSS-API V2 specification.
The approach for use of GSS-API in SOCKS V5 is to authenticate the
client and server by successfully establishing a GSS-API security
context - such that the GSS-API encapsulates any negotiation protocol
for mechanism selection, and the agreement of security service
options.
The GSS-API enables the context initiator to know what security
services the target supports for the chosen mechanism. The required
level of protection is then agreed by negotiation.
The GSS-API per-message protection calls are subsequently used to
encapsulate any further TCP and UDP traffic between client and
server.
3. GSS-API Security Context Establishment
3.1 Preparation
Prior to use of GSS-API primitives, the client and server should be
locally authenticated, and have established default GSS-API
credentials.
The client should call gss_import_name to obtain an internal
representation of the server name. For maximal portability the
default name_type GSS_C_NULL_OID should be used to specify the
default name space, and the input name_string should treated by the
client's code as an opaque name-space specific input.
For example, when using Kerberos V5 naming, the imported name may be
of the form "SERVICE:socks@socks_server_hostname" where
"socks_server_hostname" is the fully qualified host name of the
server with all letters in lower case. Other mechanisms may, however,
have different name forms, so the client should not make assumptions
about the name syntax.
3.2 Client Context Establishment
The client should then call gss_init_sec_context, typically passing:
GSS_C_NO_CREDENTIAL into cred_handle to specify the default
credential (for initiator usage),
GSS_C_NULL_OID into mech_type to specify the default
mechanism,
McMahon Standards Track