RFC 1929 PROPOSED STANDARD SOCKS · AUTHENTICATION

SOCKS5 Username/Password: Username/Password Authentication for SOCKS V5

The simple username and password login step used by SOCKS version 5.

On rfc-editor.org ↗
PUBLISHED
March 1996
AUTHORS
M. Leech
STREAM
IETF
SUBNEGOTIATION VERSION
X'01'
USERNAME LENGTH
1 to 255 octets
PASSWORD LENGTH
1 to 255 octets
SUCCESS STATUS
X'00'
DOI
10.17487/RFC1929

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                                           M. Leech
Request for Comments: 1929                    Bell-Northern Research Ltd
Category: Standards Track                                     March 1996


             Username/Password Authentication for SOCKS V5

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

1.  Introduction

   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".

Note:

   Unless otherwise noted, the decimal numbers appearing in packet-
   format diagrams represent the length of the corresponding field, in
   octets.  Where a given octet must take on a specific value, the
   syntax X'hh' is used to denote the value of the single octet in that
   field. When the word 'Variable' is used, it indicates that the
   corresponding field has a variable length defined either by an
   associated (one or two octet) length field, or by a data type field.

2.  Initial negotiation

   Once the SOCKS V5 server has started, and the client has selected the
   Username/Password Authentication protocol, the Username/Password
   subnegotiation begins.  This begins with the client producing a
   Username/Password request:

           +----+------+----------+------+----------+
           |VER | ULEN |  UNAME   | PLEN |  PASSWD  |
           +----+------+----------+------+----------+
           | 1  |  1   | 1 to 255 |  1   | 1 to 255 |
           +----+------+----------+------+----------+

   The VER field contains the current version of the subnegotiation,
   which is X'01'. The ULEN field contains the length of the UNAME field
   that follows. The UNAME field contains the username as known to the
   source operating system. The PLEN field contains the length of the
   PASSWD field that follows. The PASSWD field contains the password
   association with the given UNAME.

   The server verifies the supplied UNAME and PASSWD, and sends the
   following response:

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

   A STATUS field of X'00' indicates success. If the server returns a
   `failure' (STATUS value other than X'00') status, it MUST close the
   connection.

3.  Security Considerations

   This document describes a subnegotiation that provides authentication
   services to the SOCKS protocol. Since the request carries the
   password in cleartext, this subnegotiation is not recommended for
   environments where "sniffing" is possible and practical.

4.  Author's Address

   Marcus Leech
   Bell-Northern Research Ltd
   P.O. Box 3511, Station C
   Ottawa, ON
   CANADA K1Y 4H7

   Phone: +1 613 763 9145
   EMail: mleech@bnr.ca

AI ELI5

On this page
PROBLEMSOCKS version 5 provides a framework for authentication subnegotiation but needs concrete methods that fit it.
MECHANISMThe client sends a version byte, the username and the password, each with a length, and the server replies with a version and a status byte where zero means success.
THE CATCHThe password travels in cleartext, so the RFC does not recommend it where sniffing is possible and practical.

§1Where This Fits in SOCKS V5

The SOCKS Version 5 specification defines a framework that allows arbitrary authentication protocols during connection setup. This document describes one of them, Username/Password Authentication, as it fits into the SOCKS V5 authentication subnegotiation.

Once the SOCKS V5 server has started and the client has selected this method, the subnegotiation begins. The packet diagrams show field lengths in octets, and X'hh' marks a specific octet value.

SOCKS lets you choose how to prove who you are. This is one way: a name and a password.

§2Request and Response

The client sends a request with five fields: VER (1 octet, X'01'), ULEN (1 octet, length of the username), UNAME (1 to 255 octets, the username as known to the source operating system), PLEN (1 octet) and PASSWD (1 to 255 octets).

The server checks the credentials and replies with VER and a one-octet STATUS. A STATUS of X'00' means success. Any other value is a failure, and the server MUST close the connection.

The client sends its name and password, each with a note of how long it is. The server answers with a yes or no code, and hangs up on a no.

USERNAME/PASSWORD SUBNEGOTIATION (RFC 1929)
ClientSOCKS server
  1. VER, ULEN, UNAME, PLEN, PASSWDVER is X'01'.
  2. VER, STATUSX'00' means success; anything else and the server MUST close.

§3Cleartext Passwords

The request carries the password in cleartext. For that reason the RFC says the subnegotiation is not recommended for environments where sniffing is possible and practical.

The password is sent as plain writing, so anyone listening on the wire could read it.