Unless the server chooses no authentication (0x00) for the following requests. The client and server then enter a method-specific sub-negotiation.

If the selected authentication method supports encapsulation for the purposes of integrity, authentication and/or confidentiality. The data are encapsulation method depends on the authentication agreement.

Similarly, when the server writes data to the client, it MUST encapsulate the data as appropriate for the authentication method in use.

Username/Password

Username/Password (RFC 1929) is the most common authentication method in SOCKS5 connections. All SOCKS implementations should support this method (0x02).

If the server has agreed with Username/Password authentication, the client should send a username/password request in the following format:

+-----+--------+-----+-------+-----+
| VER | IDLEN  | ID  | PWLEN | PW  |
+-----+--------+-----+-------+-----+
   1      1     1-255    1    1-255

where:

The server verifies the username and password, and should create an authentication response in the following format:

+-----+--------+
| VER | STATUS |
+-----+--------+
   1      1

where:

GSS-API

GSS-API (RFC 1508, RFC 2078, RFC 2743) is a generic framework for a range of authentication strategies at an independent level of the underlying environment mechanism. Client and server exchange opaque tokens, and these tokens are used to perform per-message encapsulation. Concrete GSS-API bindings in C are available in RFC 1509 (v1) and RFC 2744 (v2). The use of GSS-API by the Secure Shell Protocol (SSH - RFC 4251) in standardised in RFC 4462.

SOCKS clients that use the sub-negotiation method 0x02 should implement the method described in RFC 1961 to authenticate SOCKS users in conjunction with the GSS-API. After exchanging tokens with the function gss_init_sec_context of the C API, the SOCKS client should send the output token to the server:

+------+------+------+.......................+
+ VER  | MTYP | LEN  |       TOKEN           |
+------+------+------+.......................+
+ 0x01 | 0x01 | 0x02 | up to 2^16 - 1 octets |
+------+------+------+.......................+

where:

The server will call gss_accept_sec_context with the provided token:

If the server refuses the connection, it should return:

+------+------+
+ VER  | MTYP |
+------+------+
+ 0x01 | 0xff |
+------+------+

where:

After establishing the security context, the nodes exchanges their required and accepted protection levels:

+------+------+------+.......................+
+ VER  | MTYP | LEN  |   TOKEN               |
+------+------+------+.......................+
+ 0x01 | 0x02 | 0x02 | up to 2^16 - 1 octets |
+------+------+------+.......................+

where:

The TOKEN is generated and verified with the GSS-API functions gss_seal()/gss_unseal(). The user should close the connection if the server's protection level is unacceptable.

From this point, client and server messages should be encapsulated with gss_seal(). The encapsulated messages should be sent in the following framing:

+------+------+------+.......................+
+ VER  | MTYP | LEN  |   TOKEN               |
+------+------+------+.......................+
+ 0x01 | 0x02 | 0x02 | up to 2^16 - 1 octets |
+------+------+------+.......................+

where:

A number of authentication mechanisms exist for the GSS-API, such as:

In practice, the dominant GSS-API mechanism implementation in use is Kerberos (RFC 1510) GSS-API mechanism (RFC 1964, RFC 4121).

Due to the complexity of the GSS-API and practical limitation on the number of authentication methods, SOCKS clients and servers usually do not support the GSS-API authentication method or redirect its calls to other libraries, such as Libgss.

Identification Protocol

SOCKS Protocol Version 4 does not specify a sub-negotiation step for authentication methods. Instead, the protocol describes all requests should contain an identity as defined by the Identity Protocol (or Ident) in RFC 1413.

The Ident protocol is meant to identify the user of a TCP connection. Suppose user B, port 6191, is connected to its the host A, port 23. Then A can open a connection on the Ident service on B (usually port 113) and send the query 6191, 23 to find out the username of B. The client B would issue a response with identifying the user and the local operating system, such as 6193, 23 : USERID : UNIX : username, or an error, such as 6195, 23 : ERROR : NO-USER.

In general, an Ident response has the following format:

<port-on-server> , <port-on-client> : <resp-type> : <add-info>

where:

The Ident daemon is responsible for identifying the user in the server's system. The user id is provided by the system administrator. However, Ident provides no additional authentication when the user is connecting directly from their personal computer, on which they have enough privileges to control the Ident daemon.

In practice, due the limited applicability of the protocol, SOCKS4 servers tend to consider an empty identity as a request with no authentication and maintain a whitelist of permitted usernames. Ident requests can also be redirected to an ident service, such as identd.