SOCKS协议RFC
http://www.ietf.org/rfc/rfc1928.txt
Network Working Group M. Leech
Request for Comments: 1928 Bell-Northern Research Ltd
Category: Standards Track M. Ganis
International Business Machines
Y. Lee
NEC Systems Laboratory
R. Kuris
Unify Corporation
D. Koblas
Independent Consultant
L. Jones
Hewlett-Packard Company
March 1996
SOCKS Protocol Version 5
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.
Acknowledgments
This memo describes a protocol that is an evolution of the previous
version of the protocol, version 4 [1]. This new protocol stems from
active discussions and prototype implementations. The key
contributors are: Marcus Leech: Bell-Northern Research, David Koblas:
Independent Consultant, Ying-Da Lee: NEC Systems Laboratory, LaMont
Jones: Hewlett-Packard Company, Ron Kuris: Unify Corporation, Matt
Ganis: International Business Machines.
1. Introduction
The use of network firewalls, systems that effectively isolate an
organizations internal network structure from an exterior network,
such as the INTERNET is becoming increasingly popular. These
firewall systems typically act as application-layer gateways between
networks, usually offering controlled TELNET, FTP, and SMTP access.
With the emergence of more sophisticated application layer protocols
designed to facilitate global information discovery, there exists a
need to provide a general framework for these protocols to
transparently and securely traverse a firewall.
Leech, et al Standards Track [Page 1]
RFC 1928 SOCKS Protocol Version 5 March 1996
There exists, also, a need for strong authentication of such
traversal in as fine-grained a manner as is practical. This
requirement stems from the realization that client-server
relationships emerge between the networks of various organizations,
and that such relationships need to be controlled and often strongly
authenticated.
The protocol described here is designed to provide a framework for
client-server applications in both the TCP and UDP domains to
conveniently and securely use the services of a network firewall.
The protocol is conceptually a "shim-layer" between the application
layer and the transport layer, and as such does not provide network-
layer gateway services, such as forwarding of ICMP messages.
2. Existing practice
There currently exists a protocol, SOCKS Version 4, that provides for
unsecured firewall traversal for TCP-based client-server
applications, including TELNET, FTP and the popular information-
discovery protocols such as HTTP, WAIS and GOPHER.
This new protocol extends the SOCKS Version 4 model to include UDP,
and extends the framework to include provisions for generalized
strong authentication schemes, and extends the addressing scheme to
encompass domain-name and V6 IP addresses.
The implementation of the SOCKS protocol typically involves the
recompilation or relinking of TCP-based client applications to use
the appropriate encapsulation routines in the SOCKS library.
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.
3. Procedure for TCP-based clients
When a TCP-based client wishes to establish a connection to an object
that is reachable only via a firewall (such determination is left up
to the implementation), it must open a TCP connection to the
appropriate SOCKS port on the SOCKS server system. The SOCKS service
is conventionally located on TCP port 1080. If the connection
request succeeds, the client enters a negotiation for the
Leech, et al Standards Track [Page 2]
RFC 1928 SOCKS Protocol Version 5 March 1996
authentication method to be used, authenticates with the chosen
method, then sends a relay request. The SOCKS server evaluates the
request, and either establishes the appropriate connection or denies
it.
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.
The client connects to the server, and sends a version
identifier/method selection message:
+----+----------+----------+
|VER | NMETHODS | METHODS |
+----+----------+----------+
| 1 | 1 | 1 to 255 |
+----+----------+----------+
The VER field is set to X'05' for this version of the protocol. The
NMETHODS field contains the number of method identifier octets that
appear in the METHODS field.
The server selects from one of the methods given in METHODS, and
sends a METHOD selection message:
+----+--------+
|VER | METHOD |
+----+--------+
| 1 | 1 |
+----+--------+
If the selected METHOD is X'FF', none of the methods listed by the
client are acceptable, and the client MUST close the connection.
The values currently defined for METHOD are:
o X'00' NO AUTHENTICATION REQUIRED
o X'01' GSSAPI
o X'02' USERNAME/PASSWORD
o X'03' to X'7F' IANA ASSIGNED
o X'80' to X'FE' RESERVED FOR PRIVATE METHODS
o X'FF' NO ACCEPTABLE METHODS
The client and server then enter a method-specific sub-negotiation.
Leech, et al Standards Track [Page 3]
RFC 1928 SOCKS Protocol Version 5 March 1996
Descriptions of the method-dependent sub-negotiations appear in
separate memos.
Developers of new METHOD support for this protocol should contact
IANA for a METHOD number. The ASSIGNED NUMBERS document should be
referred to for a current list of METHOD numbers and their
corresponding protocols.
Compliant implementations MUST support GSSAPI and SHOULD support
USERNAME/PASSWORD authentication methods.
4. Requests
Once the method-dependent subnegotiation has completed, the client
sends the request details. If the negotiated method includes
encapsulation for purposes of integrity checking and/or
confidentiality, these requests MUST be encapsulated in the method-
dependent encapsulation.
The SOCKS request is formed as follows:
+----+-----+-------+------+----------+----------+
|VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT |
+----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | Variable | 2 |
+----+-----+-------+------+----------+----------+
Where:
o VER protocol version: X'05'
o CMD
o CONNECT X'01'
o BIND X'02'
o UDP ASSOCIATE X'03'
o RSV RESERVED
o ATYP address type of following address
o IP V4 address: X'01'
o DOMAINNAME: X'03'
o IP V6 address: X'04'
o DST.ADDR desired destination address
o DST.PORT desired destination port in network octet
order
The SOCKS server will typically evaluate the request based on source
and destination addresses, and return one or more reply messages, as
appropriate for the request type.
Leech, et al Standards Track [Page 4]
RFC 1928 SOCKS Protocol Version 5 March 1996
5. Addressing
In an address field (DST.ADDR, BND.ADDR), the ATYP field specifies
the type of address contained within the field:
o X'01'
the address is a version-4 IP address, with a length of 4 octets
o X'03'
the address field contains a fully-qualified domain name. The first
octet of the address field contains the number of octets of name that
follow, there is no terminating NUL octet.
o X'04'
the address is a version-6 IP address, with a length of 16 octets.
6. Replies
The SOCKS request information is sent by the client as soon as it has
established a connection to the SOCKS server, and completed the
authentication negotiations. The server evaluates the request, and
returns a reply formed as follows:
+----+-----+-------+------+----------+----------+
|VER | REP | RSV | ATYP | BND.ADDR | BND.PORT |
+----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | Variable | 2 |
+----+-----+-------+------+----------+----------+
Where:
o VER protocol version: X'05'
o REP Reply field:
o X'00' succeeded
o X'01' general SOCKS server failure
o X'02' connection not allowed by ruleset
o X'03' Network unreachable
o X'04' Host unreachable
o X'05' Connection refused
o X'06' TTL expired
o X'07' Command not supported
o X'08' Address type not supported
o X'09' to X'FF' unassigned
o RSV RESERVED
o ATYP address type of following address
Leech, et al Standards Track [Page 5]
RFC 1928 SOCKS Protocol Version 5 March 1996
o IP V4 address: X'01'
o DOMAINNAME: X'03'
o IP V6 address: X'04'
o BND.ADDR server bound address
o BND.PORT server bound port in network octet order
Fields marked RESERVED (RSV) must be set to X'00'.
If the chosen method includes encapsulation for purposes of
authentication, integrity and/or confidentiality, the replies are
encapsulated in the method-dependent encapsulation.
CONNECT
In the reply to a CONNECT, BND.PORT contains the port number that the
server assigned to connect to the target host, while BND.ADDR
contains the associated IP address. The supplied BND.ADDR is often
different from the IP address that the client uses to reach the SOCKS
server, since such servers are often multi-homed. It is expected
that the SOCKS server will use DST.ADDR and DST.PORT, and the
client-side source address and port in evaluating the CONNECT
request.
BIND
The BIND request is used in protocols which require the client to
accept connections from the server. FTP is a well-known example,
which uses the primary client-to-server connection for commands and
status reports, but may use a server-to-client connection for
transferring data on demand (e.g. LS, GET, PUT).
It is expected that the client side of an application protocol will
use the BIND request only to establish secondary connections after a
primary connection is established using CONNECT. In is expected that
a SOCKS server will use DST.ADDR and DST.PORT in evaluating the BIND
request.
Two replies are sent from the SOCKS server to the client during a
BIND operation. The first is sent after the server creates and binds
a new socket. The BND.PORT field contains the port number that the
SOCKS server assigned to listen for an incoming connection. The
BND.ADDR field contains the associated IP address. The client will
typically use these pieces of information to notify (via the primary
or control connection) the application server of the rendezvous
address. The second reply occurs only after the anticipated incoming
connection succeeds or fails.
Leech, et al Standards Track [Page 6]
RFC 1928 SOCKS Protocol Version 5 March 1996
In the second reply, the BND.PORT and BND.ADDR fields contain the
address and port number of the connecting host.
UDP ASSOCIATE
The UDP ASSOCIATE request is used to establish an association within
the UDP relay process to handle UDP datagrams. The DST.ADDR and
DST.PORT fields contain the address and port that the client expects
to use to send UDP datagrams on for the association. The server MAY
use this information to limit access to the association. If the
client is not in possesion of the information at the time of the UDP
ASSOCIATE, the client MUST use a port number and address of all
zeros.
A UDP association terminates when the TCP connection that the UDP
ASSOCIATE request arrived on terminates.
In the reply to a UDP ASSOCIATE request, the BND.PORT and BND.ADDR
fields indicate the port number/address where the client MUST send
UDP request messages to be relayed.
Reply Processing
When a reply (REP value other than X'00') indicates a failure, the
SOCKS server MUST terminate the TCP connection shortly after sending
the reply. This must be no more than 10 seconds after detecting the
condition that caused a failure.
If the reply code (REP value of X'00') indicates a success, and the
request was either a BIND or a CONNECT, the client may now start
passing data. If the selected authentication method supports
encapsulation for the purposes of integrity, authentication and/or
confidentiality, the data are encapsulated using the method-dependent
encapsulation. Similarly, when data arrives at the SOCKS server for
the client, the server MUST encapsulate the data as appropriate for
the authentication method in use.
7. Procedure for UDP-based clients
A UDP-based client MUST send its datagrams to the UDP relay server at
the UDP port indicated by BND.PORT in the reply to the UDP ASSOCIATE
request. If the selected authentication method provides
encapsulation for the purposes of authenticity, integrity, and/or
confidentiality, the datagram MUST be encapsulated using the
appropriate encapsulation. Each UDP datagram carries a UDP request
header with it:
Leech, et al Standards Track [Page 7]
RFC 1928 SOCKS Protocol Version 5 March 1996
+----+------+------+----------+----------+----------+
|RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA |
+----+------+------+----------+----------+----------+
| 2 | 1 | 1 | Variable | 2 | Variable |
+----+------+------+----------+----------+----------+
The fields in the UDP request header are:
o RSV Reserved X'0000'
o FRAG Current fragment number
o ATYP address type of following addresses:
o IP V4 address: X'01'
o DOMAINNAME: X'03'
o IP V6 address: X'04'
o DST.ADDR desired destination address
o DST.PORT desired destination port
o DATA user data
When a UDP relay server decides to relay a UDP datagram, it does so
silently, without any notification to the requesting client.
Similarly, it will drop datagrams it cannot or will not relay. When
a UDP relay server receives a reply datagram from a remote host, it
MUST encapsulate that datagram using the above UDP request header,
and any authentication-method-dependent encapsulation.
The UDP relay server MUST acquire from the SOCKS server the expected
IP address of the client that will send datagrams to the BND.PORT
given in the reply to UDP ASSOCIATE. It MUST drop any datagrams
arriving from any source IP address other than the one recorded for
the particular association.
The FRAG field indicates whether or not this datagram is one of a
number of fragments. If implemented, the high-order bit indicates
end-of-fragment sequence, while a value of X'00' indicates that this
datagram is standalone. Values between 1 and 127 indicate the
fragment position within a fragment sequence. Each receiver will
have a REASSEMBLY QUEUE and a REASSEMBLY TIMER associated with these
fragments. The reassembly queue must be reinitialized and the
associated fragments abandoned whenever the REASSEMBLY TIMER expires,
or a new datagram arrives carrying a FRAG field whose value is less
than the highest FRAG value processed for this fragment sequence.
The reassembly timer MUST be no less than 5 seconds. It is
recommended that fragmentation be avoided by applications wherever
possible.
Implementation of fragmentation is optional; an implementation that
does not support fragmentation MUST drop any datagram whose FRAG
field is other than X'00'.
Leech, et al Standards Track [Page 8]
RFC 1928 SOCKS Protocol Version 5 March 1996
The programming interface for a SOCKS-aware UDP MUST report an
available buffer space for UDP datagrams that is smaller than the
actual space provided by the operating system:
o if ATYP is X'01' - 10+method_dependent octets smaller
o if ATYP is X'03' - 262+method_dependent octets smaller
o if ATYP is X'04' - 20+method_dependent octets smaller
8. Security Considerations
This document describes a protocol for the application-layer
traversal of IP network firewalls. The security of such traversal is
highly dependent on the particular authentication and encapsulation
methods provided in a particular implementation, and selected during
negotiation between SOCKS client and SOCKS server.
Careful consideration should be given by the administrator to the
selection of authentication methods.
9. References
[1] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Security Symposium.
Author's Address
Marcus Leech
Bell-Northern Research Ltd
P.O. Box 3511, Stn. C,
Ottawa, ON
CANADA K1Y 4H7
Phone: (613) 763-9145
EMail: [email protected]
Leech, et al Standards Track [Page 9]
用户名、密码认证协议
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: [email protected]
Leech Standards Track [Page 2]
GSS-API认证协议
Network Working Group P. McMahon
Request for Comments: 1961 ICL
Category: Standards Track June 1996
GSS-API Authentication Method for SOCKS Version 5
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.
Table of Contents
1. Purpose ............................................ 1
2. Introduction ....................................... 1
3. GSS-API Security Context Establishment ............. 2
4. GSS-API Protection-level Options ................... 5
5. GSS-API Per-message Protection ..................... 7
6. GSS-API Security Context Termination ............... 8
7. References ......................................... 8
8. Acknowledgments .................................... 8
9. Security Considerations ............................ 8
10. Author's Address .................................. 9
1. Purpose
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
provides the specification for the SOCKS V5 GSS-API authentication
protocol, and defines a GSS-API-based encapsulation for provision of
integrity, authentication and optional confidentiality.
2. Introduction
GSS-API provides an abstract interface which provides security
services for use in distributed applications, but isolates callers
from specific security mechanisms and implementations.
GSS-API peers achieve interoperability by establishing a common
security mechanism for security context establishment - either
through administrative action, or through negotiation. GSS-API is
specified in [RFC 1508], and [RFC 1509]. This specification is
intended for use with implementations of GSS-API, and the emerging
McMahon Standards Track [Page 1]
RFC 1961 GSS-API Authentication for SOCKS V5 June 1996
GSS-API V2 specification.
The approach for use of GSS-API in SOCKS V5 is to authenticate the
client and server by successfully establishing a GSS-API security
context - such that the GSS-API encapsulates any negotiation protocol
for mechanism selection, and the agreement of security service
options.
The GSS-API enables the context initiator to know what security
services the target supports for the chosen mechanism. The required
level of protection is then agreed by negotiation.
The GSS-API per-message protection calls are subsequently used to
encapsulate any further TCP and UDP traffic between client and
server.
3. GSS-API Security Context Establishment
3.1 Preparation
Prior to use of GSS-API primitives, the client and server should be
locally authenticated, and have established default GSS-API
credentials.
The client should call gss_import_name to obtain an internal
representation of the server name. For maximal portability the
default name_type GSS_C_NULL_OID should be used to specify the
default name space, and the input name_string should treated by the
client's code as an opaque name-space specific input.
For example, when using Kerberos V5 naming, the imported name may be
of the form. "SERVICE:socks@socks_server_hostname" where
"socks_server_hostname" is the fully qualified host name of the
server with all letters in lower case. Other mechanisms may, however,
have different name forms, so the client should not make assumptions
about the name syntax.
3.2 Client Context Establishment
The client should then call gss_init_sec_context, typically passing:
GSS_C_NO_CREDENTIAL into cred_handle to specify the default
credential (for initiator usage),
GSS_C_NULL_OID into mech_type to specify the default
mechanism,
McMahon Standards Track [Page 2]
RFC 1961 GSS-API Authentication for SOCKS V5 June 1996
GSS_C_NO_CONTEXT into context_handle to specify a NULL
context (initially), and,
the previously imported server name into target_name.
The client must also specify its requirements for replay protection,
delegation, and sequence protection via the gss_init_sec_context
req_flags parameter. It is required by this specification that the
client always requests these service options (i.e. passes
GSS_C_MUTUAL_FLAG | GSS_C_REPLAY_FLAG | GSS_C_DELEG_FLAG |
GSS_C_SEQUENCE_FLAG into req_flags).
However, GSS_C_SEQUENCE_FLAG should only be passed in for TCP-based
clients, not for UDP-based clients.
3.3 Client Context Establishment Major Status codes
The gss_init_sec_context returned status code can take two different
success values:
- If gss_init_sec_context returns GSS_S_CONTINUE_NEEDED, then the
client should expect the server to issue a token in the
subsequent subnegotiation response. The client must pass the
token to another call to gss_init_sec_context, and repeat this
procedure until "continue" operations are complete.
- If gss_init_sec_context returns GSS_S_COMPLETE, then the client
should respond to the server with any resulting output_token.
If there is no output_token, the client should proceed to send
the protected request details, including any required message
protection subnegotiation as specified in sections 4 and 5
below.
3.4 Client initial token
The client's GSS-API implementation then typically responds with the
resulting output_token which the client sends in a message to the
server.
+------+------+------+.......................+
+ ver | mtyp | len | token |
+------+------+------+.......................+
+ 0x01 | 0x01 | 0x02 | up to 2^16 - 1 octets |
+------+------+------+.......................+
McMahon Standards Track [Page 3]
RFC 1961 GSS-API Authentication for SOCKS V5 June 1996
Where:
- "ver" is the protocol version number, here 1 to represent the
first version of the SOCKS/GSS-API protocol
- "mtyp" is the message type, here 1 to represent an
authentication message
- "len" is the length of the "token" field in octets
- "token" is the opaque authentication token emitted by GSS-API
3.5 Client GSS-API Initialisation Failure
If, however, the client's GSS-API implementation failed during
gss_init_sec_context, the client must close its connection to the
server.
3.6 Server Context Establishment
For the case where a client successfully sends a token emitted by
gss_init_sec_context() to the server, the server must pass the
client-supplied token to gss_accept_sec_context as input_token.
When calling gss_accept_sec_context() for the first time, the
context_handle argument is initially set to GSS_C_NO_CONTEXT.
For portability, verifier_cred_handle is set to GSS_C_NO_CREDENTIAL
to specify default credentials (for acceptor usage).
If gss_accept_sec_context returns GSS_CONTINUE_NEEDED, the server
should return the generated output_token to the client, and
subsequently pass the resulting client supplied token to another call
to gss_accept_sec_context.
If gss_accept_sec_context returns GSS_S_COMPLETE, then, if an
output_token is returned, the server should return it to the client.
If no token is returned, a zero length token should be sent by the
server to signal to the client that it is ready to receive the
client's request.
McMahon Standards Track [Page 4]
RFC 1961 GSS-API Authentication for SOCKS V5 June 1996
3.7 Server Reply
In all continue/confirmation cases, the server uses the same message
type as for the client -> server interaction.
+------+------+------+.......................+
+ ver | mtyp | len | token |
+------+------+------+.......................+
+ 0x01 | 0x01 | 0x02 | up to 2^16 - 1 octets |
+------+------+------+.......................+
3.8 Security Context Failure
If the server refuses the client's connection for any reason (GSS-API
authentication failure or otherwise), it will return:
+------+------+
+ ver | mtyp |
+------+------+
+ 0x01 | 0xff |
+------+------+
Where:
- "ver" is the protocol version number, here 1 to represent the
first version of the SOCKS/GSS-API protocol
- "mtyp" is the message type, here 0xff to represent an abort
message
4. GSS-API Protection-level Options
4.1 Message protection
Establishment of a GSS-API security context enables comunicating
peers to determine which per-message protection services are
available to them through the gss_init_sec_context() and
gss_accept_sec_context() ret_flags GSS_C_INTEG_FLAG and
GSS_C_CONF_FLAG which respectively indicate message integrity and
confidentiality services.
It is necessary to ensure that the message protection applied to the
traffic is appropriate to the sensitivity of the data, and the
severity of the threats.
McMahon Standards Track [Page 5]
RFC 1961 GSS-API Authentication for SOCKS V5 June 1996
4.2 Message Protection Subnegotiation
For TCP and UDP clients and servers, different levels of protection
are possible in the SOCKS V5 protocol, so an additional
subnegotiation stage is needed to agree the message protection level.
After successful completion of this subnegotiation, TCP and UDP
clients and servers use GSS-API encapsulation as defined in section
5.1.
After successful establishment of a GSS-API security context, the
client's GSS-API implementation sends its required security context
protection level to the server. The server then returns the security
context protection level which it agrees to - which may or may not
take the the client's request into account.
The security context protection level sent by client and server must
be one of the following values:
1 required per-message integrity
2 required per-message integrity and confidentiality
3 selective per-message integrity or confidentiality based on
local client and server configurations
It is anticipated that most implementations will agree on level 1 or
2 due to the practical difficulties in applying selective controls to
messages passed through a socks library.
4.3 Message Protection Subnegotiation Message Format
The security context protection level is sent from client to server
and vice versa using the following protected message format:
+------+------+------+.......................+
+ ver | mtyp | len | token |
+------+------+------+.......................+
+ 0x01 | 0x02 | 0x02 | up to 2^16 - 1 octets |
+------+------+------+.......................+
Where:
- "ver" is the protocol version number, here 1 to represent the
first version of the SOCKS/GSS-API protocol
- "mtyp" is the message type, here 2 to represent a protection
-level negotiation message
- "len" is the length of the "token" field in octets
McMahon Standards Track [Page 6]
RFC 1961 GSS-API Authentication for SOCKS V5 June 1996
- "token" is the GSS-API encapsulated protection level
4.4 Message Protection Subnegotiation Message Generation
The token is produced by encapsulating an octet containing the
required protection level using gss_seal()/gss_wrap() with conf_req
set to FALSE. The token is verified using gss_unseal()/
gss_unwrap().
If the server's choice of protection level is unacceptable to the
client, then the client must close its connection to the server
5. GSS-API Per-message Protection
For TCP and UDP clients and servers, the GSS-API functions for
encapsulation and de-encapsulation shall be used by implementations -
i.e. gss_seal()/gss_wrap(), and gss_unseal()/ gss_unwrap().
The default value of quality of protection shall be specified, and
the use of conf_req_flag shall be as determined by the previous
subnegotiation step. If protection level 1 is agreed then
conf_req_flag MUST always be FALSE; if protection level 2 is agreed
then conf_req_flag MUST always be TRUE; and if protection level 3 is
agreed then conf_req is determined on a per-message basis by client
and server using local configuration.
All encapsulated messages are prefixed by the following framing:
+------+------+------+.......................+
+ ver | mtyp | len | token |
+------+------+------+.......................+
+ 0x01 | 0x03 | 0x02 | up to 2^16 - 1 octets |
+------+------+------+.......................+
Where:
- "ver" is the protocol version number, here 1 to represent the
first version of the SOCKS/GSS-API protocol
- "mtyp" is the message type, here 3 to represent encapulated user
data
- "len" is the length of the "token" field in octets
- "token" is the user data encapsulated by GSS-API
McMahon Standards Track [Page 7]
RFC 1961 GSS-API Authentication for SOCKS V5 June 1996
6. GSS-API Security Context Termination
The GSS-API context termination message (emitted by
gss_delete_sec_context) is not used by this protocol.
When the connection is closed, each peer invokes
gss_delete_sec_context() passing GSS_C_NO_BUFFER into the
output_token argument.
7. References
[RFC 1508] Linn, J., "Generic Security Service API",
September 1993.
[RFC 1509] Wray, J., "Generic Security Service API : C-bindings",
September 1993.
[SOCKS V5] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D.,
and L. Jones, "SOCKS Protocol V5", RFC 1928, April
1996.
8. Acknowledgment
This document builds from a previous memo produced by Marcus Leech
(BNR) - whose comments are gratefully acknowleged. It also reflects
input from the AFT WG, and comments arising from implementation
experience by Xavier Gosselin (IUT Lyons).
9. Security Considerations
The security services provided through the GSS-API are entirely
dependent on the effectiveness of the underlying security mechanisms,
and the correctness of the implementation of the underlying
algorithms and protocols.
The user of a GSS-API service must ensure that the quality of
protection provided by the mechanism implementation is consistent
with their security policy.
In addition, where negotiation is supported under the GSS-API,
constraints on acceptable mechanisms may be imposed to ensure
suitability for application to authenticated firewall traversal.
McMahon Standards Track [Page 8]
RFC 1961 GSS-API Authentication for SOCKS V5 June 1996
10. Author's Address
P. V. McMahon
ICL Enterprises
Kings House
33 Kings Road
Reading, RG1 3PX
UK
EMail: [email protected]
Phone: +44 1734 634882
Fax: +44 1734 855106
McMahon Standards Track [Page 9]
说明：
SOCKS是通过应用程序中已知端口上（通常为1080/TCP）打开到一个SOCKS代理服务器（由用户在应用程序中配置，或在系统配置文件中指定）的连接。如果连接请求成功，则客户机进入一个使用认证方法的协商，用选定的方法认证。然后应用程序发送一个中继请求，把用户想要连接的机器名和端口号发送给服务器。SOCKS服务器评价该请求，并建立适当的连接或拒绝它。如果成功，则由SOCKS服务器实际连接远程主机，然后透明地在客户机和远程主机之间来回移动数据。用户甚至都不知道SOCKS服务器位于该循环中。
源码下载地址：ftp://ftp.inet.no/pub/socks/