doc: Add RFC documents

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]
+