draft-ietf-aft-socks-pro-v5-03.txt   draft-ietf-aft-socks-pro-v5-04.txt 
AFT Working Group Marc VanHeyningen AFT Working Group Marc VanHeyningen
draft-ietf-aft-socks-pro-v5-03 Aventail Corp. draft-ietf-aft-socks-pro-v5-04 Aventail Corp.
Expires August 22, 1999 22 February 1999
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 an Internet-Draft and is in full conformance with
Traversal (AFT) Working Group. Comments are solicited and should be all provisions of Section 10 of RFC2026.
addressed to the working group mailing list (aft@socks.nec.com) or to
the editor.
This document is an Internet-Draft. Internet Drafts are working Internet-Drafts are working documents of the Internet Engineering
documents of the Internet Engineering Task Force (IETF), its areas, Task Force (IETF), its areas, and its working groups. Note that
and its working Groups. Note that other groups may also distribute other groups may also distribute working documents as Internet-
working documents as Internet Drafts. Drafts.
Internet-Drafts draft documents are valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other
time. It is inappropriate to use Internet-Drafts as reference documents at any time. It is inappropriate to use Internet-
material or to cite them other than as "work in progress." Drafts as reference material or to cite them other than as "work
in progress."
To view the entire list of current Internet-Drafts, please check The list of current Internet-Drafts can be accessed at
the "1id-abstracts.txt" listing contained in the Internet-Drafts http://www.ietf.org/ietf/1id-abstracts.txt
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Distribution of this memo is unlimited The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Acknowledgments This document is a submission to the IETF Authenticated Firewall
Traversal (AFT) Working Group. Comments are solicited and should
be addressed to the working group mailing list (aft@socks.nec.com)
or to the editor.
This memo describes a protocol that is an evolution of the previous Abstract
version of the protocol, version 4[SOCKS]. This new protocol stems
from active discussions and prototype implementations. The key
contributors are:
o Marcus Leech: Bell-Northern Research This document is a revision of RFC 1928, the SOCKS version 5
o David Koblas: Independent Consultant protocol. SOCKS is a generic proxying protocol for traversing
o Ying-Da Lee: NEC Systems Laboratory firewalls and other trust boundaries; version 5 of the protocol
o LaMont Jones: Hewlett-Packard Company adds new features such as authentication and UDP support. Changes
o Ron Kuris: Unify Corporation from the RFC in this draft include formatting cleanups,
o Matt Ganis: International Business Machines authentication clarification, and fixing UDP-related problems
o David Blob: NEC USA found during implementation.
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
skipping to change at page 4, line 19 skipping to change at page 4, line 14
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 NO AUTHENTICATION REQUIRED and Compliant implementations MUST support NO AUTHENTICATION REQUIRED and
CHAP, SHOULD support USERNAME/PASSWORD and MAY support GSSAPI GSSAPI, SHOULD support USERNAME/PASSWORD and MAY support CHAP.
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 5, line 4 skipping to change at page 4, line 46
| 1 | 1 | 1 | 1 | Variable | 2 | | 1 | 1 | 1 | 1 | Variable | 2 |
+----+-----+------+------+----------+----------+ +----+-----+------+------+----------+----------+
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 IANA Reserved X'04' to X'7F'
o X'80' to X'FF' RESERVED FOR PRIVATE METHODS o Private methods X'80' to X'FF'
o FLAG command dependent flag (defaults to X'00') 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 (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:
skipping to change at page 6, line 24 skipping to change at page 6, line 16
o X'07' Command not supported o X'07' Command not supported
o X'08' Address type not supported o X'08' Address type not supported
o X'09' Invalid address o X'09' Invalid address
o X'0A' to X'FF' unassigned o X'0A' to X'FF' unassigned
o FLAG command dependent flag o FLAG command dependent flag
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 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 (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 Reply Processing
When a reply indicates a failure (REP value other than X'00',) the When a reply indicates a failure (REP value other than X'00',) 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
skipping to change at page 8, line 52 skipping to change at page 8, line 45
|RSV | SUB | FLAG | ATYP | ADDR | PORT | |RSV | SUB | FLAG | ATYP | ADDR | PORT |
+----+-----+------+------+----------+------+ +----+-----+------+------+----------+------+
| 1 | 1 | 1 | 1 | Variable | 2 | | 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 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 destination address information o ADDR destination address information
o PORT destination port information o PORT destination port information (network octet order)
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
confidentiality, the datagram MUST be encapsulated using the confidentiality, the datagram MUST be encapsulated using the
skipping to change at page 9, line 32 skipping to change at page 9, line 25
header with it: header with it:
+------+------+------+----------+----------+----------+ +------+------+------+----------+----------+----------+
| FLAG | FRAG | ATYP | DST.ADDR | DST.PORT | DATA | | FLAG | FRAG | ATYP | DST.ADDR | DST.PORT | DATA |
+------+------+------+----------+----------+----------+ +------+------+------+----------+----------+----------+
| 2 | 1 | 1 | Variable | 2 | Variable | | 2 | 1 | 1 | Variable | 2 | Variable |
+------+------+------+----------+----------+----------+ +------+------+------+----------+----------+----------+
The fields in the UDP request header are: The fields in the UDP request header are:
o FLAG Reserved X'0000' o FLAG Reserved (currently X'0000')
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 (network octet order)
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; it must be set to X'00'. 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,
skipping to change at page 10, line 30 skipping to change at page 10, line 22
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.
Acknowledgments
This memo describes a protocol that is an evolution of the previous
version of the protocol, version 4[SOCKS]. This new protocol stems
from active discussions and prototype implementations. The key
contributors are:
o Marcus Leech: Bell-Northern Research
o David Koblas: Independent Consultant
o Ying-Da Lee: NEC Systems Laboratory
o LaMont Jones: Hewlett-Packard Company
o Ron Kuris: Unify Corporation
o Matt Ganis: International Business Machines
o David Blob: NEC USA
o Wei Lu: NEC USA.
o William Perry: Aventail
o Dave Chouinard: Intel
10. 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.
[GSSAPI] Margrave, D., "GSS-API Authentication Method for SOCKS
Version 5," 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
skipping to change at line 488 skipping to change at line 499
Author's Address Author's Address
Marc VanHeyningen Marc VanHeyningen
Aventail Corporation Aventail Corporation
808 Howell Streeet; Suite 200 808 Howell Streeet; Suite 200
Seattle, WA 98101 Seattle, WA 98101
Phone: +1 (206) 215-1111 Phone: +1 (206) 215-1111
Email: marcvh@aventail.com Email: marcvh@aventail.com
--
Marc VanHeyningen marcvh@aventail.com
Internet Security Architect
Aventail http://www.aventail.com/
 End of changes. 21 change blocks. 
50 lines changed or deleted 62 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/