draft-ietf-aft-socks-pro-v5-02.txt   draft-ietf-aft-socks-pro-v5-03.txt 
AFT Working Group Marc VanHeyningen AFT Working Group Marc VanHeyningen
draft-ietf-aft-socks-pro-v5-02 Aventail Corp. draft-ietf-aft-socks-pro-v5-03 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
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.
skipping to change at page 1, line 24 skipping to change at page 1, line 25
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 draft documents are valid for a maximum of six months Internet-Drafts draft documents are valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the To view the entire list of current Internet-Drafts, please check
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow the "1id-abstracts.txt" listing contained in the Internet-Drafts
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
ftp.isi.edu (US West Coast). (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Distribution of this memo is unlimited Distribution of this memo is unlimited
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[SOCKS]. This new protocol stems version of the protocol, version 4[SOCKS]. This new protocol stems
from active discussions and prototype implementations. The key from active discussions and prototype implementations. The key
contributors are: contributors are:
skipping to change at page 4, line 18 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 MUST support CHAP, SHOULD support Compliant implementations MUST support NO AUTHENTICATION REQUIRED and
USERNAME/PASSWORD and MAY support GSSAPI authentication methods. CHAP, SHOULD support USERNAME/PASSWORD and MAY support GSSAPI
authentication methods.
As with other TCP application data, out of band data is normally As with other TCP application data, out of band data is normally
proxied to the SOCKS server as out of band data; note that proxied to the SOCKS server as out of band data; note that
implementations may be limited to handling a single byte of such data implementations may be limited to handling a single byte of such data
at a time. Authentication methods which define some content at a time. Authentication methods which define some content
encapsulation SHOULD define a method-specific mechanism for proxying encapsulation SHOULD define a method-specific mechanism for proxying
out of band data. out of band data.
4. Requests 4. Requests
skipping to change at page 6, line 30 skipping to change at page 6, line 30
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 BND.ADDR server bound address o BND.ADDR server bound address
o BND.PORT server bound port in network octet order o BND.PORT server bound port in network octet order
If the chosen method includes encapsulation for purposes of If the chosen method includes encapsulation for purposes of
authentication, integrity and/or confidentiality, the replies are authentication, integrity and/or confidentiality, the replies are
encapsulated in the method-dependent encapsulation. encapsulated in the method-dependent encapsulation.
Reply Processing
When a reply indicates a failure (REP value other than X'00',) 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 indicates a success, 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. TCP Procedure
CONNECT CONNECT
In the reply to a CONNECT, BND.PORT contains the port number that the 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 server assigned to connect to the target host, and BND.ADDR contains
contains the associated IP address. The supplied BND.ADDR is often the associated IP address. The supplied BND.ADDR is often different
different from the IP address that the client uses to reach the SOCKS from the IP address that the client uses to reach the SOCKS server,
server, since such servers are often multi-homed. It is expected since such servers are often multi-homed. It is expected that the
that the SOCKS server will use DST.ADDR and DST.PORT, and the client- SOCKS server will use DST.ADDR and DST.PORT, and the client-side
side source address and port in evaluating the CONNECT request. source address and port in evaluating the CONNECT request.
BIND BIND
The BIND request is used in protocols which require the client to The BIND request is used in protocols which require the client to
accept connections from the server. FTP is a well-known example, accept connections from the server. FTP is a well-known example,
which uses the primary client-to-server connection for commands and which uses the primary client-to-server connection for commands and
status reports, but may use a server-to-client connection for status reports, but may use a server-to-client connection for
transferring data on demand (e.g. LS, GET, PUT). transferring data on demand (e.g. LS, GET, PUT).
It is expected that the client side of an application protocol will It is expected that the client side of an application protocol will
skipping to change at page 7, line 20 skipping to change at page 7, line 37
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.
7. UDP procedure 8. UDP procedure
UDP ASSOCIATE requests 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
skipping to change at page 7, line 42 skipping to change at page 8, line 11
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.
Flag bits in the request and reply are defined as follows: Flag bits in the request and reply are defined as follows:
INTERFACE REQUEST X'01' INTERFACE REQUEST X'01'
USECLIENTSPORT X'04' USECLIENTSPORT X'04'
If the USECLIENTSPORT bit is set in the flag field of the request, the 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 server SHOULD interact with the application server using the same port
port the client used in the request, and set the USECLIENTSPORT bit in the client used in the request, and set the USECLIENTSPORT bit in the
the flag field of the reply to acknowledge having done so. flag field of the reply to acknowledge having done so. If no port
number was specified in the UDP ASSOCIATE request, this flag is
meaningless and MUST not be used.
If the INTERFACE REQUEST bit is set in the flag field of the request, 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 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 bit in the reply. If both client and server support this feature, the
client MAY send interface-request subcommands, described below, during client SHOULD send INTERFACE DATA subcommands, described below, during
the UDP association. the UDP association.
In the reply to a UDP ASSOCIATE request, the BND.PORT and BND.ADDR 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 fields indicate the port number/address where the client MUST send UDP
request messages to be relayed. 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.
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. If the flag negotiation ASSOCIATE request arrived on terminates. If the flag negotiation
indicated mutual support for it, the client may send INTERFACE-REQUEST indicated mutual support for it, the client SHOULD send INTERFACE DATA
commands to learn the external address information for the UDP subcommands to learn the external address information for the UDP
assocaiation with respect to a particular destination. assocaiation with respect to a particular destination. The server, in
turn, MAY use this information to limit access to the association to
those destination addresses for which it has received INTERFACE DATA
queries; multiple INTERFACE DATA commands are permitted, and have a
cumulative effect.
Such requests are formatted as follows: Such requests are formatted as follows:
+----+-----+------+------+----------+------+------+----------+ +----+-----+------+------+----------+------+
|RSV | SUB | FLAG | ATYP | ADDR | PORT | SIZE | DATA | |RSV | SUB | FLAG | ATYP | ADDR | PORT |
+----+-----+------+------+----------+------+------+----------+ +----+-----+------+------+----------+------+
| 1 | 1 | 1 | 1 | Variable | 2 | 4 | Variable | | 1 | 1 | 1 | 1 | Variable | 2 |
+----+-----+------+------+----------+------+------+----------+ +----+-----+------+------+----------+------+
The fields in the CONTROL CHANNEL packet are: The fields in the CONTROL CHANNEL packet are:
o RSV Reserved X'00' o RSV Reserved X'00'
o SUB Subcommand o SUB Subcommand
o INTERFACE DATA: X'01' o INTERFACE DATA: X'01'
o FLAG A subcommand dependent flag (normally X'00') o FLAG A subcommand dependent flag (normally X'00')
o ATYP address type of following addresses: o ATYP address type of following addresses:
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 ADDR any address information o ADDR destination address information
o PORT any port information o PORT destination 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 Replies to INTERFACE DATA commands are structured the same way as
ordinary SOCKS replies, as per section 6. ordinary SOCKS replies, as per section 6.
UDP packet structure 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
skipping to change at page 9, line 39 skipping to change at page 9, line 43
o FRAG Current fragment number o FRAG Current fragment number
o ATYP address type of following addresses: o ATYP address type of following addresses:
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 o DST.PORT desired destination port
o DATA user data o DATA user data
FRAG is currently unused, and reserved for future work to deal with FRAG is currently unused, and reserved for future work to deal with
fragmentation. fragmentation; it must be set to X'00'.
When a UDP relay server decides to relay a UDP datagram, it does so When a UDP relay server decides to relay a UDP datagram, it does so
silently, without any notification to the requesting client. silently, without any notification to the requesting client.
Similarly, it will drop datagrams it cannot or will not relay. When 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 a UDP relay server receives a reply datagram from a remote host, it
MUST encapsulate that datagram using the above UDP request header, MUST encapsulate that datagram using the above UDP request header,
and any authentication-method-dependent encapsulation. and any authentication-method-dependent encapsulation.
The UDP relay server MUST acquire from the SOCKS server the expected 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 IP address of the client that will send datagrams to the BND.PORT
skipping to change at page 10, line 14 skipping to change at page 10, line 19
the particular association. the particular association.
The programming interface for a SOCKS-aware UDP MUST report an The programming interface for a SOCKS-aware UDP MUST report an
available buffer space for UDP datagrams that is smaller than the available buffer space for UDP datagrams that is smaller than the
actual space provided by the operating system: actual space provided by the operating system:
o if ATYP is X'01' - 10+method_dependent octets smaller 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'03' - 262+method_dependent octets smaller
o if ATYP is X'04' - 20+method_dependent octets smaller o if ATYP is X'04' - 20+method_dependent octets smaller
8. Security Considerations 9. Security Considerations
This document describes a protocol for the application-layer This document describes a protocol for the application-layer
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 10. References
[CHAP] VanHeyningen, M., "Challenge-Handshake Authentication [CHAP] VanHeyningen, M., "Challenge-Handshake Authentication
Protocol for SOCKS V5," 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," [RFC 1929] Leech, M., "Username/Password Authentication for SOCKS V5,"
March 1996. March 1996.
[RFC 1961] McMahon, P., "GSS-API Authentication Method for SOCKS [RFC 1961] McMahon, P., "GSS-API Authentication Method for SOCKS
Version 5," June 1996. 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
Marc VanHeyningen Marc VanHeyningen
Aventail Corporation Aventail Corporation
117 South Main Street, Suite 400 808 Howell Streeet; Suite 200
Seattle, WA 98104 Seattle, WA 98101
Phone: +1 (206) 215-1111 Phone: +1 (206) 215-1111
Email: marcvh@aventail.com Email: marcvh@aventail.com
 End of changes. 17 change blocks. 
52 lines changed or deleted 60 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/