diff options
Diffstat (limited to 'doc/rfc/rfc1929.txt')
-rw-r--r-- | doc/rfc/rfc1929.txt | 115 |
1 files changed, 115 insertions, 0 deletions
diff --git a/doc/rfc/rfc1929.txt b/doc/rfc/rfc1929.txt new file mode 100644 index 0000000..64fa02c --- /dev/null +++ b/doc/rfc/rfc1929.txt @@ -0,0 +1,115 @@ + + + + + + +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 | + +----+------+----------+------+----------+ + + + + + + +Leech Standards Track [Page 1] + +RFC 1929 Username Authentication for SOCKS V5 March 1996 + + + 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 + + + + + + + + + + + + + + +Leech Standards Track [Page 2] + |