draft-ietf-aft-socks-pro-v5-01.txt   draft-ietf-aft-socks-pro-v5-02.txt 
AFT Working Group William Perry AFT Working Group Marc VanHeyningen
draft-ietf-aft-socks-pro-v5-01 Aventail, Corp. draft-ietf-aft-socks-pro-v5-02 Aventail Corp.
SOCKS Protocol Version 5 SOCKS Protocol Version 5
Status of this Memo Status of this Memo
This document is a submission to the IETF Authenticated Firewall This document is a submission to the IETF Authenticated Firewall
Traversal (AFT) Working Group. Comments are solicited and should be Traversal (AFT) Working Group. Comments are solicited and should be
addressed to the working group mailing list (aft@socks.nec.com) or to addressed to the working group mailing list (aft@socks.nec.com) or to
the editor. the editor.
This document is an Internet-Draft. Internet Drafts are working This document is an Internet-Draft. Internet Drafts are working
skipping to change at page 1, line 47 skipping to change at page 1, line 47
contributors are: contributors are:
o Marcus Leech: Bell-Northern Research o Marcus Leech: Bell-Northern Research
o David Koblas: Independent Consultant o David Koblas: Independent Consultant
o Ying-Da Lee: NEC Systems Laboratory o Ying-Da Lee: NEC Systems Laboratory
o LaMont Jones: Hewlett-Packard Company o LaMont Jones: Hewlett-Packard Company
o Ron Kuris: Unify Corporation o Ron Kuris: Unify Corporation
o Matt Ganis: International Business Machines o Matt Ganis: International Business Machines
o David Blob: NEC USA o David Blob: NEC USA
o Wei Lu: NEC USA. o Wei Lu: NEC USA.
o William Perry: Aventail
o Dave Chouinard: Intel
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 such as the INTERNET is becoming increasingly popular. These
firewall systems typically act as application-layer gateways between firewall systems typically act as application-layer gateways between
networks, usually offering controlled TELNET, FTP, and SMTP access. networks, usually offering controlled TELNET, FTP, and SMTP access.
With the emergence of more sophisticated application layer protocols With the emergence of more sophisticated application layer protocols
designed to facilitate global information discovery, there exists a designed to facilitate global information discovery, there exists a
need to provide a general framework for these protocols to need to provide a general framework for these protocols to
transparently and securely traverse a firewall. transparently and securely traverse a firewall.
skipping to change at page 3, line 49 skipping to change at page 3, line 51
+----+--------+ +----+--------+
If the selected METHOD is X'FF', none of the methods listed by the If the selected METHOD is X'FF', none of the methods listed by the
client are acceptable, and the client MUST close the connection. client are acceptable, and the client MUST close the connection.
The values currently defined for METHOD are: The values currently defined for METHOD are:
o X'00' NO AUTHENTICATION REQUIRED o X'00' NO AUTHENTICATION REQUIRED
o X'01' GSSAPI o X'01' GSSAPI
o X'02' USERNAME/PASSWORD o X'02' USERNAME/PASSWORD
o X'03' to X'7F' IANA ASSIGNED o X'03' CHAP
o X'04' to X'7F' IANA ASSIGNED
o X'80' to X'FE' RESERVED FOR PRIVATE METHODS o X'80' to X'FE' RESERVED FOR PRIVATE METHODS
o X'FF' NO ACCEPTABLE METHODS o X'FF' NO ACCEPTABLE METHODS
The client and server then enter a method-specific sub-negotiation. The client and server then enter a method-specific sub-negotiation.
Descriptions of the method-dependent sub-negotiations appear in Descriptions of the method-dependent sub-negotiations appear in
separate memos. separate memos.
Developers of new METHOD support for this protocol should contact Developers of new METHOD support for this protocol should contact
IANA for a METHOD number. The ASSIGNED NUMBERS document should be IANA for a METHOD number. The ASSIGNED NUMBERS document should be
referred to for a current list of METHOD numbers and their referred to for a current list of METHOD numbers and their
corresponding protocols. corresponding protocols.
skipping to change at page 4, line 14 skipping to change at page 4, line 18
The client and server then enter a method-specific sub-negotiation. The client and server then enter a method-specific sub-negotiation.
Descriptions of the method-dependent sub-negotiations appear in Descriptions of the method-dependent sub-negotiations appear in
separate memos. separate memos.
Developers of new METHOD support for this protocol should contact Developers of new METHOD support for this protocol should contact
IANA for a METHOD number. The ASSIGNED NUMBERS document should be IANA for a METHOD number. The ASSIGNED NUMBERS document should be
referred to for a current list of METHOD numbers and their referred to for a current list of METHOD numbers and their
corresponding protocols. corresponding protocols.
Compliant implementations SHOULD support GSSAPI and MUST support Compliant implementations MUST support CHAP, SHOULD support
USERNAME/PASSWORD authentication methods. USERNAME/PASSWORD and MAY support GSSAPI authentication methods.
As with other TCP application data, out of band data is normally
proxied to the SOCKS server as out of band data; note that
implementations may be limited to handling a single byte of such data
at a time. Authentication methods which define some content
encapsulation SHOULD define a method-specific mechanism for proxying
out of band data.
4. Requests 4. Requests
Once the method-dependent subnegotiation has completed, the client Once the method-dependent subnegotiation has completed, the client
sends the request details. If the negotiated method includes sends the request details. If the negotiated method includes
encapsulation for purposes of integrity checking and/or encapsulation for purposes of integrity checking and/or
confidentiality, these requests MUST be encapsulated in the method- confidentiality, these requests MUST be encapsulated in the method-
dependent encapsulation. dependent encapsulation.
The SOCKS request is formed as follows: The SOCKS request is formed as follows:
skipping to change at page 4, line 42 skipping to change at page 5, line 5
Where: Where:
o VER protocol version: X'05' o VER protocol version: X'05'
o CMD o CMD
o CONNECT X'01' o CONNECT X'01'
o BIND X'02' o BIND X'02'
o UDP ASSOCIATE X'03' o UDP ASSOCIATE X'03'
o X'04' to X'7F' IANA ASSIGNED o X'04' to X'7F' IANA ASSIGNED
o X'80' to X'FF' RESERVED FOR PRIVATE METHODS o X'80' to X'FF' RESERVED FOR PRIVATE METHODS
o FLAG command dependent flag o FLAG command dependent flag (defaults to X'00')
o ATYP address type of following address o ATYP address type of following address
o IP V4 address: X'01' o IP V4 address: X'01'
o DOMAINNAME: X'03' o DOMAINNAME: X'03'
o IP V6 address: X'04' o IP V6 address: X'04'
o DST.ADDR desired destination address o DST.ADDR desired destination address
o DST.PORT desired destination port in network octet o DST.PORT desired destination port in network octet
order order
The SOCKS server will typically evaluate the request based on The SOCKS server will typically evaluate the request based on
source and destination addresses, and return one or more reply source and destination addresses, and return one or more reply
messages, as appropriate for the request type. messages, as appropriate for the request type.
5. Addressing 5. Addressing
In an address field (DST.ADDR, BND.ADDR), the ATYP field specifies In an address field (DST.ADDR, BND.ADDR), the ATYP field specifies
the type of address contained within the field: the type of address contained within the field:
o X'01' o X'01'
the address is a version-4 IP address, with a length of 4 octets The address is a version-4 IP address, with a length of 4 octets.
o X'03' o X'03'
the address field contains a fully-qualified domain name. The first The address field contains a fully-qualified domain name. The first
octet of the address field contains the number of octets of name that octet of the address field contains the number of octets of name that
follow, there is no terminating NUL octet. follow, there is no terminating NUL octet.
o X'04' o X'04'
the address is a version-6 IP address, with a length of 16 octets. The address is a version-6 IP address, with a length of 16 octets.
6. Replies 6. Replies
The SOCKS request information is sent by the client as soon as it has The SOCKS request information is sent by the client as soon as it has
established a connection to the SOCKS server, and completed the established a connection to the SOCKS server, and completed the
authentication negotiations. The server evaluates the request, and authentication negotiations. The server evaluates the request, and
returns a reply formed as follows: returns a reply formed as follows:
+----+-----+------+------+----------+----------+ +----+-----+------+------+----------+----------+
|VER | REP | FLAG | ATYP | BND.ADDR | BND.PORT | |VER | REP | FLAG | ATYP | BND.ADDR | BND.PORT |
skipping to change at page 7, line 9 skipping to change at page 7, line 20
SOCKS server assigned to listen for an incoming connection. The SOCKS server assigned to listen for an incoming connection. The
BND.ADDR field contains the associated IP address. The client will BND.ADDR field contains the associated IP address. The client will
typically use these pieces of information to notify (via the primary typically use these pieces of information to notify (via the primary
or control connection) the application server of the rendezvous or control connection) the application server of the rendezvous
address. The second reply occurs only after the anticipated incoming address. The second reply occurs only after the anticipated incoming
connection succeeds or fails. connection succeeds or fails.
In the second reply, the BND.PORT and BND.ADDR fields contain the In the second reply, the BND.PORT and BND.ADDR fields contain the
address and port number of the connecting host. address and port number of the connecting host.
UDP ASSOCIATE 7. UDP procedure
UDP ASSOCIATE requests
The UDP ASSOCIATE request is used to establish an association within The UDP ASSOCIATE request is used to establish an association within
the UDP relay process to handle UDP datagrams. The DST.ADDR and the UDP relay process to handle UDP datagrams. The DST.ADDR and
DST.PORT fields contain the address and port that the client expects 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 to use to send UDP datagrams on for the association. The server MAY
use this information to limit access to the association. If the 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 client is not in possesion of the information at the time of the UDP
ASSOCIATE, the client MUST use address type X'01' with a port number ASSOCIATE, the client MUST use address type X'01' with a port number
and address of all zeros. and address of all zeros.
A UDP association terminates when the TCP connection that the UDP A UDP association terminates when the TCP connection that the UDP
ASSOCIATE request arrived on terminates. ASSOCIATE request arrived on terminates.
In the reply to a UDP ASSOCIATE request, the BND.PORT and BND.ADDR Flag bits in the request and reply are defined as follows:
fields indicate the port number/address where the client MUST send
UDP request messages to be relayed (unless the UDP relaying is done
in the TCP channel as specified by the TCP RELAY flag).
NOTE: The current UDP ASSOCIATE command is not powerful enough for INTERFACE REQUEST X'01'
many newer protocols, and does not handle multicast traffic at all. USECLIENTSPORT X'04'
A proposal to address these issues is available [Ch97].
If the USECLIENTSPORT bit is set in the flag field of the request, the
server SHOULD use interact with the application server using the same
port the client used in the request, and set the USECLIENTSPORT bit in
the flag field of the reply to acknowledge having done so.
If the INTERFACE REQUEST bit is set in the flag field of the request,
the server may indicate its support for this extension by setting this
bit in the reply. If both client and server support this feature, the
client MAY send interface-request subcommands, described below, during
the UDP association.
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 Reply Processing
When a reply (REP value other than X'00') indicates a failure, the When a reply (REP value other than X'00') indicates a failure, the
SOCKS server MUST terminate the TCP connection shortly after sending SOCKS server MUST terminate the TCP connection shortly after sending
the reply. This must be no more than 10 seconds after detecting the the reply. This must be no more than 10 seconds after detecting the
condition that caused a failure. condition that caused a failure.
If the reply code (REP value of X'00') indicates a success, and the 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 request was either a BIND or a CONNECT, the client may now start
passing data. If the selected authentication method supports passing data. If the selected authentication method supports
encapsulation for the purposes of integrity, authentication and/or encapsulation for the purposes of integrity, authentication and/or
confidentiality, the data are encapsulated using the method-dependent confidentiality, the data are encapsulated using the method-dependent
encapsulation. Similarly, when data arrives at the SOCKS server for encapsulation. Similarly, when data arrives at the SOCKS server for
the client, the server MUST encapsulate the data as appropriate for the client, the server MUST encapsulate the data as appropriate for
the authentication method in use. the authentication method in use.
UDP Control Channel UDP Control Channel
A UDP association terminates when the TCP connection that the UDP A UDP association terminates when the TCP connection that the UDP
ASSOCIATE request arrived on terminates. ASSOCIATE request arrived on terminates. If the flag negotiation
indicated mutual support for it, the client may send INTERFACE-REQUEST
commands to learn the external address information for the UDP
assocaiation with respect to a particular destination.
7. Procedure for UDP-based clients Such requests are formatted as follows:
+----+-----+------+------+----------+------+------+----------+
|RSV | SUB | FLAG | ATYP | ADDR | PORT | SIZE | DATA |
+----+-----+------+------+----------+------+------+----------+
| 1 | 1 | 1 | 1 | Variable | 2 | 4 | Variable |
+----+-----+------+------+----------+------+------+----------+
The fields in the CONTROL CHANNEL packet are:
o RSV Reserved X'00'
o SUB Subcommand
o INTERFACE DATA: X'01'
o FLAG A subcommand dependent flag (normally X'00')
o ATYP address type of following addresses:
o IP V4 address: X'01'
o DOMAINNAME: X'03'
o IP V6 address: X'04'
o ADDR any address information
o PORT any port information
o SIZE the size (in octets) of data in network order
o DATA user data
Replies to INTERFACE DATA commands are structured the same way as
ordinary SOCKS replies, as per section 6.
UDP packet structure
A UDP-based client MUST send its datagrams to the UDP relay server at 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 the UDP port indicated by BND.PORT in the reply to the UDP ASSOCIATE
request. If the selected authentication method provides request. If the selected authentication method provides
encapsulation for the purposes of authenticity, integrity, and/or encapsulation for the purposes of authenticity, integrity, and/or
confidentiality, the datagram MUST be encapsulated using the confidentiality, the datagram MUST be encapsulated using the
appropriate encapsulation. Each UDP datagram carries a UDP request appropriate encapsulation. Each UDP datagram carries a UDP request
header with it: header with it:
+------+------+------+----------+----------+----------+ +------+------+------+----------+----------+----------+
skipping to change at page 9, line 22 skipping to change at page 10, line 27
traversal of IP network firewalls. The security of such traversal is traversal of IP network firewalls. The security of such traversal is
highly dependent on the particular authentication and encapsulation highly dependent on the particular authentication and encapsulation
methods provided in a particular implementation, and selected during methods provided in a particular implementation, and selected during
negotiation between SOCKS client and SOCKS server. negotiation between SOCKS client and SOCKS server.
Careful consideration should be given by the administrator to the Careful consideration should be given by the administrator to the
selection of authentication methods. selection of authentication methods.
9. References 9. References
[Ch97] Chouinard, D., "SOCKS V5 UDP and Multicast Extensions", [CHAP] VanHeyningen, M., "Challenge-Handshake Authentication
July 1997, work in progress. Protocol for SOCKS V5," work in progress.
[RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R. Koblas, D., & [RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R. Koblas, D., &
Jones, L., "SOCKS Protocol V5," April 1996. Jones, L., "SOCKS Protocol V5," April 1996.
[RFC 1929] Leech, M., "Username/Password Authentication for SOCKS V5,"
March 1996.
[RFC 1961] McMahon, P., "GSS-API Authentication Method for SOCKS
Version 5," June 1996.
[SOCKS] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Security [SOCKS] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Security
Symposium. Symposium.
Author's Address Author's Address
William M. Perry Marc VanHeyningen
Aventail, Corp. Aventail Corporation
117 South Main Street, Suite 400 117 South Main Street, Suite 400
Seattle, WA 98104 Seattle, WA 98104
Phone: +1 (206) 777-5615 Phone: +1 (206) 215-1111
Email: wmperry@aventail.com Email: marcvh@aventail.com
 End of changes. 19 change blocks. 
23 lines changed or deleted 83 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/