draft-ietf-aft-socks-protocol-v5-00.txt   draft-ietf-aft-socks-protocol-v5-01.txt 
Socks Protocol Version 5 Socks Protocol Version 5
INTERNET-DRAFT INTERNET-DRAFT
Expires: April 24, 1995 M. Leech Expires: In Six Months M. Leech
<draft-ietf-aft-socks-protocol-v5-00.txt> M. Ganis <draft-ietf-aft-socks-protocol-v5-01.txt> M. Ganis
Y. Lee Y. Lee
R. Kuris R. Kuris
D. Koblas D. Koblas
L. Jones
SOCKS Protocol Version 5 SOCKS Protocol Version 5
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft document valid for a maximum of six months Internet-Drafts are draft document valid for a maximum of six months
skipping to change at page 1, line 33 skipping to change at page 1, line 34
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim). Rim).
Acknowledgments Acknowledgments
This memo describes a protocol that is an evolution of the previous This memo describes a protocol that is an evolution of the previous
version of the protocol, version 4. This new protocol stems from version of the protocol, version 4 [1]. This new protocol stems from
active discussions and prototype implementations. The key active discussions and prototype implementations. The key
contributors are: Marcus Leech: Bell-Northern Research, David Koblas: contributors are: Marcus Leech: Bell-Northern Research, David Koblas:
Independent Consultant, Ying-Da Lee: NEC Systems Laboratory, Lamont Independent Consultant, Ying-Da Lee: NEC Systems Laboratory, LaMont
Jones: Hewlett-Packard, Ron Kuris: Unify Corporation, Matt Ganis: Jones: Hewlett-Packard Company, Ron Kuris: Unify Corporation, Matt
International Business Machines. Ganis: International Business Machines.
1. Introduction 1. Introduction
The use of network firewalls, systems that effectively isolate an The use of network firewalls, systems that effectively isolate an
organizations internal network structure from an exterior network, organizations internal network structure from an exterior network,
such as the INTERNET is becoming increasingly popular. These firewall such as the INTERNET is becoming increasingly popular. These firewall
systems typically act as application-layer gateways between networks, systems typically act as application-layer gateways between networks,
usually offering controlled TELNET, FTP, and SMTP access. With the usually offering controlled TELNET, FTP, and SMTP access. With the
emergence of more sophisticated application layer protocols designed emergence of more sophisticated application layer protocols designed
to facilitate global information discovery, there exists a need to to facilitate global information discovery, there exists a need to
provide a general framework for these protocols to transparently and provide a general framework for these protocols to transparently and
securely traverse a firewall. securely traverse a firewall.
There exists, also, a need for strong authentication of such There exists, also, a need for strong authentication of such
traversal in as fine-grained a mannner as is practical. This traversal in as fine-grained a manner as is practical. This
requirement stems from the realization that client-server requirement stems from the realization that client-server
relationships emerge between the networks of various organizations, relationships emerge between the networks of various organizations,
and that such relationships need to be controlled and often strongly and that such relationships need to be controlled and often strongly
authenticated. authenticated.
The protocol described here is designed to provide a framework for The protocol described here is designed to provide a framework for
client-server applications in both the TCP and UDP domains to client-server applications in both the TCP and UDP domains to
conveniently and securely use the services of a network firewall. conveniently and securely use the services of a network firewall.
2. Existing practice 2. Existing practice
There currently exists a protocol, SOCKS Version 4, that provides for There currently exists a protocol, SOCKS Version 4, that provides for
unsecured firewall traversal for TCP-based client-server unsecured firewall traversal for TCP-based client-server
applications, including TELNET, FTP and the popular information- applications, including TELNET, FTP and the popular information-
discovery protocols such as HTTP, WAIS and GOPHER. discovery protocols such as HTTP, WAIS and GOPHER.
This protocol extends the SOCKS Version 4 model to include UDP, and This protocol extends the SOCKS Version 4 model to include UDP, and
extends the protocol header to include provisions for generalized extends the protocol to include provisions for generalized strong
strong authentication schemes, and extends the addressing scheme to authentication schemes, and extends the addressing scheme to
encompass domain-name and extended IP addresses. The implementation encompass domain-name and V6 IP addresses. The implementation of the
of the SOCKS protocol typically involves the recompilation or SOCKS protocol typically involves the recompilation or relinking of
relinking of TCP-based client applications to use the appropriate TCP-based client applications to use the appropriate encapsulation
encapsulation routines in the SOCKS library. routines in the SOCKS library.
3. Procedure for TCP-based clients 3. Procedure for TCP-based clients
When a TCP-based client wishes to establish a connection to an object 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 that is reachable only via a firewall (such determination is left up
to the implementation), it must open a TCP connection to the to the implementation), it must open a TCP connection to the
appropriate SOCKS port on the SOCKS server system. The SOCKS service appropriate SOCKS port on the SOCKS server system. The SOCKS service
is conventionally located on TCP port 1080. If the connection request is conventionally located on TCP port 1080. If the connection request
succeeds, the client sends a request to the server with its desired succeeds, the client enters a negotiation for the authentication
destination address, destination port, and authentication method to be used, authenticates with the chosen method, then sends a
information. The SOCKS server evaluates the information, and either relay request. The SOCKS server evaluates the request, and either
establishes the appropriate connection or denies it. establishes the appropriate connection or denies it.
The SOCKS request is formed as follows: The client connects to the server, and sends a version
identifier/method selection packet:
+-----+------+-----+----------+----------+-----+-----+------/ +----+----------+----------+------+
| 8 | 8 | 8 | 16 | var | 4 | 4 | 8 / |VER | NMETHODS | METHODS | MACS |
| VER | ATYP | CMD | DST.PORT | DST.ADDR | ULN | ILN | ALEN / +----+----------+----------+------+
| | | | | | | | / | 1 | 1 | 1 to 255 | 1 |
+-----+------+-----+----------+----------+-----+-----+------/ +----+----------+----------+------+
/---------+-----------+----------+
/ var | var | var |
/ SRC.USR | SRC.IDENT | SRC.AUTH |
/ | | |
/---------+-----------+----------+
Where: 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.
o VER protocol version: X'05' The server selects from one of the methods given in METH-
ODS, and a MAC algorithm, then sends a selection indica-
tor:
o ATYP address type of following address +----+--------+--------+
|VER | METHOD | MACSEL |
+----+--------+--------+
| 1 | 1 | 1 |
+----+--------+--------+
IP V4 address: X'01' If the selection indicator is X'FF', none of the METHODS
IP V5 address: X'02' listed by the client are acceptable, and the server MUST
DOMAINNAME: X'03' close the connection.
IPNG address: X'04'
o DST.ADDR desired destination address The values currently defined for METHOD are:
o DST.PORT desired destination port in network byte order o X'00' NO AUTHENTICATION REQUIRED
o X'01' BNR-1
o X'02' GSSAPI
o X'03' IKMP
o X'04' KERBEROS4
o X'05' KERBEROS5
o X'06' USERNAME/PASSWORD
o X'07' SECURE TOKEN TYPE 1 (NO CHALLENGE/RESPONSE)
o X'08' SECURE TOKEN TYPE 2 (CHALLENGE/RESPONSE)
o X'09' S/KEY
o X'0A' to X'FE' RESERVED
o X'FF' NO ACCEPTABLE METHODS
o CMD command: CONNECT X'01' BIND X'02' The client and server then enter a method-specific subne-
gotiation.
o ULN length of SRC.USR field in bytes: 4 bits Descriptions of the method-dependant subnegotiations
appear in separate drafts.
o ILN length of SRC.IDENT field in bytes: 4 bits The MACS field contains a bit-vector indicating the MAC
algorithms available to the client. Bits are labelled
from most-significant (0) to least significant (7):
o ALEN length of SRC.AUTH field in bytes: 8 bits o 0 - MD5 with 64-bit compression [2]
o 1 - MD5 with no compression (complete digest of 128 bits)
o 2 - SHA with 80-bit compression [3]
o 3 - SHA with no compression (complete digest of 160 bits)
o SRC.USR username as known to the client-side operating system The MACSEL field indicates which MAC algorithm that the
server wishes the client to use during computation of the
MAC field for UDP relay requests. A compliant implementa-
tion MUST support both compressed and uncompressed MD5.
o SRC.IDENT identifier as known to the authentication system 4. Requests
o SRC.AUTH authenticator as known to the authentication system Once the method-dependant 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-dependant encapsulation.
4. Addressing The SOCKS request is formed as follows:
In an address field (DST.ADDR, BND.ADDR), the ATYP field specifies +----+-----+-------+------+----------+----------+
the type of address contained within the field. If ATYP is X'01', the |VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT |
address is version-4 IP address, if it is X'02', then the field +----+-----+-------+------+----------+----------+
specifies a version-5 IP address (that is, IP protocol version 4/5, | 1 | 1 | X'00' | 1 | Variable | 2 |
not SOCKS protocol version 4/5). If the ATYP field is X'03', then the +----+-----+-------+------+----------+----------+
address field contains a DNS-style domain name, if it is X'04' then
the field specifies an IPNG address.
If the ATYP field is X'01', the length of BND.ADDR is 4 bytes, if Where:
X'02' the length is 8 bytes. If the ATYP field is X'03', then the
first byte of the BND.ADDR specifies the length, in bytes, of the
rest of the field.
5. Replies 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 request information is sent by the client as soon as it has The SOCKS server will evaluate the request based on
established a connection to the SOCKS server. The server evaluates source and destination addresses, and return one or more
the request, and returns a reply formed as follows: reply packets, as appropriate for the request type.
+-----+------+-----+----------+----------+ 5. Addressing
| 8 | 8 | 8 | 16 | var |
| VER | ATYP | REP | BND.PORT | BND.ADDR |
| | | | | |
+-----+------+-----+----------+----------+
||
\/
+---------------+
| 3 | 1 | 4 |
| ET | R | CODE |
| | | |
+----+---+------+
o VER protocol version: X'05' In an address field (DST.ADDR, BND.ADDR), the ATYP field
specifies the type of address contained within the field:
o ATYP address type of following address o X'01'
IP V4 address: X'01' the address is a version-4 IP address, with a length of 4
IP V5 address: X'02' octets
DOMAINNAME: X'03'
IPNG address: X'04'
o BND.ADDR server bound address o X'03'
o BND.PORT server bound port in network byte order the address field contains a DNS-style domain name. The
first octet of the address field contains the length of
the domain name.
o REP Reply field: o X'04'
The reply field is broken up into a 3 subfields: the address is a version-6 IP address, with a length of
16 octets.
ET encryption type: 3 bits 6. Replies
X'0' unencrypted The SOCKS request information is sent by the client as
X'1' DES soon as it has established a connection to the SOCKS
X'2' IDEA server, and completed the authentication negotiations.
X'3' PRIVATE_1 The server evaluates the request, and returns a reply
X'4' PRIVATE_2 formed as follows:
X'5' PRIVATE_3
R reply bit: always set for replies
CODE reason code 4 bits: +----+-----+-------+------+----------+----------+--------+
|VER | REP | RSV | ATYP | BND.ADDR | BND.PORT | COOKIE |
+----+-----+-------+------+----------+----------+--------+
| 1 | 1 | X'00' | 1 | Variable | 2 | 8 |
+----+-----+-------+------+----------+----------+--------+
X'0' succeeded Where:
X'1' general failure
X'2' bad/unknown identifier
X'3' connection not allowed by ruleset
X'4' authentication failure
X'5' identifier explicitly blocked
In a reply, the BND.ADDR and BND.PORT fields are the SOCKS server o VER protocol version: X'05'
address and port number of the outbound connection for a CONNECT o REP Reply field:
request, and contain the SOCKS server bind() address for a BIND o X'00' succeeded
request. If a reply contains a non-zero ET subfield, the server o X'01' general SOCKS server failure
expects that there will be a bi-directional encryption of user-data o X'02' connection not allowed by ruleset
on this connection using the encryption type specified in the ET o X'03' Network unreachable
subfield. It is expected that the server and client have already o X'04' Host unreachable
negotiated the appropriate key in an `out-of-band' process. It is o X'05' Connection refused
typically the case that the same key that is used for authentication o X'06' TTL expired
is used for encryption. o X'07' to X'FF' unassigned
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 BND.ADDR server bound address
o BND.PORT server bound port in network octet order
o COOKIE extra data used by UDP ASSOCIATE
The BIND request is used in protocols which require the client to Fields marked RESERVED (RSV) must be set to X'00'.
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 If the chosen method includes encapsulation for purposes
use the BIND request only to establish secondary connections after a of authentication, integrity and or confidentiality, the
primary connection is established using CONNECT. Usually, then, replies are encapsulated in the method-dependant encapsu-
DST.PORT and DST.ADDR in a BIND request header would be the same as lation.
those used in the primary connection, though this is not required.
In a similar fashion to CONNECT, the SOCKS server may use DST.PORT In a reply, the BND.ADDR and BND.PORT fields are the
and DST.ADDR in evaluating the BIND request. SOCKS server address and port number of the outbound con-
nection for a CONNECT request, and contain the SOCKS
server bind() address for a BIND request.
Two replies are sent from the SOCKS server to the client during a The BIND request is used in protocols which require the
BIND operation. The first is sent after the server creates and binds client to accept connections from the server. FTP is a
a new socket. The BND.PORT field contains the port number assigned in well-known example, which uses the primary client-to-
the bind() call. The BND.ADDR field contains the associated IP server connection for commands and status reports, but
address. The client will typicallly use these pieces of information may use a server-to-client connection for transferring
to notify (via the primary or control connection) the application data on demand (e.g. LS, GET, PUT).
server of the `rendezvous point'. The second reply occurs only after
the anticipated incoming connection succeeds or fails. In the second
reply, only the REP field is meaningful.
When a reply (CODE value other than X'0') indicates a failure, the It is expected that the client side of an application
SOCKS server will terminate the TCP connection shortly after sending protocol will use the BIND request only to establish sec-
the reply. ondary connections after a primary connection is estab-
lished using CONNECT. In is expected that a SOCKS server
will use DST.ADDR and DST.PORT in evaluating the BIND
request.
6. Procedure for UDP-based clients 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 typi-
cally use these pieces of information to notify (via the
primary or control connection) the application server of
the `rendezvous point'. The second reply occurs only
after the anticipated incoming connection succeeds or
fails. In the second reply, the BND.PORT and BND.ADDR
fields contain the address and port number of the
connecting host.
With UDP-based clients, there is no notion of a connection, so each In the reply to a CONNECT, BND.PORT contains the port
datagram that is to be carried by a SOCKS-UDP server must carry number that the server assigned to connect to the target
destination and authentication information with it. A UDP-based host, while BND.ADDR contains the associated IP address.
client must send its datagrams to the SOCKS-UDP server at UDP port The supplied BND.ADDR is often different from the IP
1080. Each UDP datagram carries a SOCKS request header with it: address that the client uses to reach the SOCKS server,
since such servers are often multi-homed.
+-----+------+-----+----------+----------+-----+-----+------/ The UDP ASSOCIATE request is used to establish an associ-
| 8 | 8 | 8 | 16 | var | 4 | 4 | 8 / ation within the UDP relay process to handle UDP data-
| VER | ATYP | CMD | DST.PORT | DST.ADDR | ULN | ILN | ALEN / grams. In the reply to a UDP ASSOCIATE request, the
| | | | | | | | / BND.PORT and BND.ADDR fields indicate the port num-
+-----+------+-----+----------+----------+-----+-----+------/ ber/address where the client may send UDP request packets
to be relayed. The DST.ADDR and DST.PORT fields are
ignored in a UDP ASSOCIATE request. Once a UDP ASSOCIATE
request has been processed, the SOCKS server MUST termi-
nate the connection. The COOKIE field is used in the com-
putation of a Message Authentication Code by the UDP
relay server. The SOCKS server MUST set this field to a
random value. The association created by the UDP ASSOCI-
ATE request has a specific and site or implementation
dependant lifetime.
/---------+-----------+----------+ When a reply (REP value other than X'00') indicates a
/ var | var | var | failure, the SOCKS server MUST terminate the TCP connec-
/ SRC.USR | SRC.IDENT | SRC.AUTH | tion shortly after sending the reply. This must be no
/ | | | more than 10 seconds after detecting the condition that
/---------+-----------+----------+ caused a failure.
Where: If the reply code (REP value of X'00') indicates a suc-
cess, 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 pur-
poses of integrity, authentication and or confidential-
ity, 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.
o VER protocol version: X'05' 7. Procedure for UDP-based clients
o ATYP address type of following address 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. Each UDP datagram
carries a UDP request header with it:
IP V4 address: X'01' +-----+------+----------+----------+---------+----------+
IP V5 address: X'02' |FRAG | ATYP | DST.ADDR | DST.PORT | MAC | DATA |
DOMAINNAME: X'03' +-----+------+----------+----------+---------+----------+
IPNG address: X'04' | 1 | 1 | Variable | 2 | 8 to 20 | Variable |
+-----+------+----------+----------+---------+----------+
The fields in the UDP request header are:
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.ADDR desired destination address
o DST.PORT desired destination port
o MAC Message Authentication Code
o DST.PORT desired destination port in network byte order 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.
o CMD command: RELAY X'03' 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 ASSO-
CIATE. It MUST drop any datagrams arriving from any
source IP address other than the one recorded for the
particular association.
o ULN length of SRC.USR field in bytes: 4 bits Related to each UDP association is a pair of unsigned
32-bit counters. These counters are used to assist in
computing the current value of the MAC field. The MAC
(Message Authentication Code) field contains a message-
digest computation of:
o ILN length of SRC.IDENT field in bytes: 4 bits o the XCOOKIE digest
o the counter
o the ATYP
o the DST.ADDR (in network octet order)
o the DST.PORT (in network octet order)
o the DATA
o the XCOOKIE digest
o ALEN length of SRC.AUTH field in bytes: 8 bits Each algorithm uses a different length of residue after
computing the digest function. For MD5 with 8-octet
compression, the residue is formed by taking octets
0,2,4,6,8,10,12,14 of the digest, and concatenating them
into an 8-octet string. Similarly for SHA, octets
0,2,4,6,8,10,12,14,16,18 are concatenated to form a
10-octet string. For algorithms that don't specify a
compression, the complete digest is used.
o SRC.USR username as known to the client-side operating system The value for the XCOOKIE digest is determined by a mes-
o SRC.IDENT identifier as known to the authentication system sage-digest consisting of:
o SRC.AUTH authenticator as known to the authentication system o the method-dependant authentication key material
(if any, else 8 octets of X'AA')
o the COOKIE from the UDP ASSOCIATE request
o the method-dependant authentication key material
(if any, else 8 octets of X'AA')
When a SOCKS-UDP server decides to RELAY a UDP datagram, it does so The method-dependant authentication key material MUST be
silently, without any notification to the requesting client. at least 8 octets in length.
Similarly, it will drop datagrams it cannot or will not RELAY. When a
SOCKS-UDP server receives a reply datagram from a remote host, it
will encapsulate that datagram using the standard SOCKS request
header, and use the DST.ADDR and DST.PORT fields to give the
originating host address and port number. When a SOCKS-UDP server
receives a RELAY request from a client, it establishes a temporary
association between the client address/port and a port on the SOCKS-
UDP server. This temporary association is used to allow UDP reply
datagrams to be correctly relayed back to the requesting UDP client.
The timer related to this association is implementation dependant,
but must be at least five minutes.
7. Authentication and identification information The sender increments its counter after sending the data-
gram, while the receiver increments its counter after
receipt. The receiver MUST be prepared to accept data-
grams whose counter value is several units ahead of the
expected value, due to datagram loss. This is typically
implemented by the receiver looking for a MAC match by
repeatedly incrementing its counter value, and looking
for a match. The receiver does this until either there is
a MAC match, or the tolerance has been exceeded The rec-
ommended counter mismatch tolerance is 7 units.The coun-
ters start at zero.
The standard SOCKS request header includes information intended to The FRAG field indicates whether or not this datagram is
identify the originating entity of the corresponding connection one of a number of fragments. The high-order bit indi-
request or datagram relay request. The SRC.USR field is intended as a cates end-of-fragment sequence, while a value of X'00'
low-to-medium confidence mechanism for a SOCKS relay agent to provide indicates that this datagram is standalone. Values
usage auditing information only, and not as an authentication between 1 and 127 indicate the fragment position within a
mechanism. The SRC.IDENT and SRC.AUTH fields are used to carry fragment sequence. The implicit counter value increments
information that a SOCKS relay agent (server) may use to control and on every fragment. Each receiver will have a REASSEMBLY
authenticate access to its relay services.The fundamental notion QUEUE and a REASSEMBLY TIMER associated with these frag-
being that SRC.IDENT carries a unique identity associated with a ments. The reassembly queue must be reinitialized and
requesting entity (typically a person) and SRC.AUTH carries some type the associated fragments abandoned whenever the REASSEM-
of strong proof of that identity. In this way, the SOCKS relay agent BLY TIMER expires, or a new datagram arrives carrying a
may make decisions about access controls based on a strong notion of FRAG field whose value is less than the highest FRAG
the identity of the entity requesting access. value processed for this fragment sequence. The reassem-
bly timer MUST be no less than 5 seconds. It is strongly
recommended that fragmentation be avoided by applications
wherever possible.
In one implementation, the SRC.IDENT field carries a unique Implementation of fragmentation is optional; an implemen-
identifier that has associated with it a secret key that is shared tation that does not support fragmentation MUST drop any
between the relay agent and the requesting entity. The corresponding datagram whose FRAG field is other than X'00'.
SRC.AUTH field contains time-varying information that is computed
based on the shared secret key and a strong one-way hash of the
time-varying data. In this implementation the shared secret key has a
specific and relatively short lifetime; `out-of-band' techniques are
used from time to time to assign a new secret key. In this way, the
secret key acts much like a session key in Kerberos.
Another implementation may choose to use the SRC.IDENT and SRC.AUTH The UDP relay server MUST drop any datagrams for which
fields to carry information produced by so-called smart card the MAC value is outside of the acceptable range.
technology to authenticate access. Repeated occurrences of invalid MAC values should cause
the UDP relay server to destroy the association.
Another implementation may choose to carry the operating system The programming interface for a SOCKS-aware UDP MUST
username in SRC.IDENT and the corresponding access password in report an available buffer space for UDP datagrams that
SRC.AUTH. In this way, the authentication provided is no weaker than is smaller than the actual space provided by the operat-
that provided by the FTP protocol. ing system:
8. Encrypted connections o if ATYP is X'01' - 16 octets smaller
o if ATYP is X'03' - 272 octets smaller
o if ATYP is X'04' - 28 octets smaller
The TCP SOCKS server may return a connection-success reply with the The ASSOCIATION established with a UDP ASSOCIATE request
encryption-type (ET) field set non-zero. If this is the case, then has a specific lifetime. It is strongly recommended that
the SOCKS server expects that all data transferred on the connection this lifetime be extended by the lifetime value every
after the initial SOCKS connect request will be encrypted in a time a valid datagram arrives from the client at the UDP
mutually agreed upon key using the algorithm specified by the SOCKS relay server.
server. In order to make this work, the server expects the data
stream to be encapsulated into a series of encrypted payloads as
follows:
+------+-------+-----+---------------------------------------------------+ 8. Security Considerations
| 8 | 128 | 16 | var | |
| PLEN | AUTHN | SSN | DATA | PAD |
| | | | | |
+------+-------+-----+---------------------------------------------------+
The AUTHN field is 16-bytes long, and is expected to contain the This document describes a protocol for the application-
cryptographic checksum (message digest) of the AUTHN, SSN and DATA layer traversal of IP network firewalls. The security of
fields prepended with the key associated with this connection. When such traversal is highly dependant on the particular
computing this checksum, the AUTHN field is set to all X'00'. The SSN authentication and encapsulation methods used in a par-
field is a unique sequence number for each encrypted payload, this is ticular implementation.
an unsigned 16-bit value transmitted in network byte order.
The receiver of an encrypted payload shall use the PLEN field, The protection for relayed UDP data when an authentica-
appropriately rounded for the blocksize of the encryption algorithm tion method doesn't supply suitable keying material is
in use, to determine the number of bytes of encrypted data that quite weak. Careful consideration should be given to
follow. This is necessary, since the transport in use (TCP) is a selection of authentication methods when a firewall is
stream protocol, and does not preserve I/O boundaries across a expected to relay UDP data using this protocol.
connection.
The receiver of an encrypted payload for which the received AUTHN 9. References
field fails to match the computed value of AUTHN must immediately
terminate the connection, and log an error to the system log.
Similarly, if a received SSN doesn't increment the current received
SSN, the payload is a replay, and must terminate the connection.
Since the encryption is bidirectional, the SOCKS server uses the same [1] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Secu-
encapsulation technique when sending encrypted data towards the rity Symposium
client.
9. References [2] Rivest, Ron. RFC1321, "The MD5 Message-Digest Algo-
[1] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Security Symposium rithm"
[2] Leech, M., et al, "Socks Protocol Version 4" RFCXXXX [3] FIPS180-1, "Secure Hash Standard", NIST Publication
Authors Address Authors Address
Marcus Leech, Bell-Northern Research Marcus Leech
Bell-Northern Research
P.O. Box 3511, Stn. C, P.O. Box 3511, Stn. C,
Ottawa, ON Ottawa, ON
CANADA K1Y 4H7 CANADA K1Y 4H7
Email: mleech@bnr.ca Email: mleech@bnr.ca
Phone: (613) 763-9145 Phone: (613) 763-9145
 End of changes. 80 change blocks. 
244 lines changed or deleted 333 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/