summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1929.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1929.txt')
-rw-r--r--doc/rfc/rfc1929.txt115
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]
+