rfc-1929

Username/Password Authentication for SOCKS V5

M. Leech

date1996-03 streamIETF areasec wgaft statusPROPOSED STANDARD pages2 canonicalhttps://www.rfc-editor.org/rfc/rfc1929 doi10.17487/RFC1929

The protocol specification for SOCKS Version 5 specifies a generalized framework for the use of arbitrary authentication protocols in the initial socks connection setup. This document describes one of those protocols, as it fits into the SOCKS Version 5 authentication "subnegotiation". [STANDARDS-TRACK]

Extracted elements (7)

design-rationale §1

This subnegotiation is designed to fit within the SOCKS V5 generalized authentication framework, which allows arbitrary authentication protocols to be negotiated during initial connection setup rather than mandating a single scheme.

security

interoperability-note §1

This protocol is only applicable after a SOCKS V5 client and server have agreed to use Username/Password Authentication during the SOCKS V5 initial method negotiation; it cannot be used standalone.

security

normative-requirement §2 MUST

If the server returns a failure STATUS (any value other than X'00'), it MUST close the connection.

security

protocol-element §2

The VER field in the client subnegotiation request must be X'01', identifying version 1 of the username/password subnegotiation protocol.

security

security-consideration §3

The username/password subnegotiation transmits the password in cleartext and is therefore not recommended for environments where packet sniffing is possible and practical.

security, privacy

wire-format §2

The client authentication request contains five fields: VER (1 octet, value X'01'), ULEN (1 octet, length of UNAME), UNAME (1–255 octets, username), PLEN (1 octet, length of PASSWD), and PASSWD (1–255 octets, password).

security

wire-format §2

The server authentication response contains two fields: VER (1 octet) and STATUS (1 octet). A STATUS value of X'00' indicates success; any other value indicates failure.

security