draft-ietf-aft-socks-pro-v5-04.txt   draft-ietf-aft-socks-pro-v5-05.txt 
AFT Working Group Marc VanHeyningen AFT Working Group Marc VanHeyningen
draft-ietf-aft-socks-pro-v5-04 Aventail Corp. draft-ietf-aft-socks-pro-v5-05.txt Aventail Corp.
Expires August 22, 1999 22 February 1999 Expires six months from --> June 27, 2000
SOCKS Protocol Version 5 SOCKS Protocol Version 5
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 37
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
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 Traversal (AFT) Working Group. Comments are solicited and should
be addressed to the working group mailing list (aft@socks.nec.com) be addressed to the working group mailing list (aft@socks.nec.com)
or to the editor. or to the editor.
Abstract Abstract
This document is a revision of RFC 1928, the SOCKS version 5 This document is an update to RFC 1928, the SOCKS version 5
protocol. SOCKS is a generic proxying protocol for traversing protocol. SOCKS is a generic proxying protocol for traversing
firewalls and other trust boundaries; version 5 of the protocol firewalls and other trust boundaries; version 5 of the protocol
adds new features such as authentication and UDP support. Changes adds new features such as authentication and UDP support. Changes
from the RFC in this draft include formatting cleanups, from the RFC in this draft include formatting cleanups,
authentication clarification, and fixing UDP-related problems authentication clarification, and fixing UDP-related problems
found during implementation. found during implementation.
1. Introduction 1. Introduction
The use of network firewalls, systems that effectively isolate an The use of network firewalls, systems that effectively isolate an
skipping to change at page 2, line 25 skipping to change at page 2, line 27
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.
The protocol is conceptually a "shim-layer" between the application The protocol is conceptually a "shim-layer" between the application
layer and the transport layer, and as such does not provide network- layer and the transport layer, and as such does not provide network-
layer gateway services, such as forwarding of ICMP messages. layer gateway services, such as forwarding of ICMP messages.
2. Existing practice 2. SOCKS history
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 new protocol extends the SOCKS Version 4 model to include UDP, This new protocol extends the SOCKS Version 4 model to include UDP,
and extends the framework to include provisions for generalized and extends the framework to include provisions for generalized
strong authentication schemes, and extends the addressing scheme to strong authentication schemes, and extends the addressing scheme to
encompass domain-name and V6 IP addresses. encompass domain-name and V6 IP addresses.
The implementation of the SOCKS protocol typically involves the The implementation of the SOCKS protocol typically involves the
recompilation or relinking of TCP-based client applications to use recompilation or relinking of TCP-based client applications to use
the appropriate encapsulation routines in the SOCKS library. the appropriate encapsulation routines in the SOCKS library.
Note: 3. Connection and authentication negotiation
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 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 is conventionally located on TCP port 1080. If the connection
request succeeds, the client enters a negotiation for the request succeeds, the client enters a negotiation for the
authentication method to be used, authenticates with the chosen authentication method to be used, authenticates with the chosen
method, then sends a relay request. The SOCKS server evaluates the method, then sends a relay request. The SOCKS server evaluates the
request, and either establishes the appropriate connection or denies request, and either establishes the appropriate connection or denies
it. it.
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.
The client connects to the server, and sends a version The client connects to the server, and sends a version
identifier/method selection message: identifier/method selection message:
+----+----------+----------+ +----+----------+----------+
|VER | NMETHODS | METHODS | |VER | NMETHODS | METHODS |
+----+----------+----------+ +----+----------+----------+
| 1 | 1 | 1 to 255 | | 1 | 1 | 1 to 255 |
+----+----------+----------+ +----+----------+----------+
The VER field is set to X'05' for this version of the protocol. The The VER field is set to X'05' for this version of the protocol. The
skipping to change at page 3, line 45 skipping to change at page 3, line 50
+----+--------+ +----+--------+
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' CHAP o X'03' to X'7F' IANA ASSIGNED
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. After agreeing on the authentication method, the client and server
then enter a method-specific sub-negotiation. Descriptions of the
Descriptions of the method-dependent sub-negotiations appear in 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 may 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
GSSAPI, SHOULD support USERNAME/PASSWORD and MAY support CHAP. GSSAPI, and SHOULD support USERNAME/PASSWORD. To assure secure
interoperability among multiple GSSAPI implementations, the
As with other TCP application data, out of band data is normally LIPKEY[RFC 2847] mechanism MUST be supported, and mechanism
proxied to the SOCKS server as out of band data; note that negotiation using SPNEGO[RFC 2478] MUST be supported.
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. SOCKS 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 5, line 7 skipping to change at page 5, line 7
o IANA Reserved X'04' to X'7F' o IANA Reserved X'04' to X'7F'
o Private methods X'80' to X'FF' 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 (network octet order) o DST.PORT desired destination port (network octet order)
The SOCKS server will typically evaluate the request based on The SOCKS server will typically evaluate the request based on source
source and destination addresses, and return one or more reply and destination addresses, and return one or more reply messages, as
messages, as appropriate for the request type. 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
octet of the address field contains the number of octets of name that first octet of the address field contains the number of octets of
follow, there is no terminating NUL octet. name that 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. SOCKS 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 |
+----+-----+------+------+----------+----------+ +----+-----+------+------+----------+----------+
| 1 | 1 | 1 | 1 | Variable | 2 | | 1 | 1 | 1 | 1 | Variable | 2 |
skipping to change at page 6, line 22 skipping to change at page 6, line 25
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 (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
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
condition that caused a failure. condition that caused a failure.
If the reply code indicates a success, the client may now start If the reply code indicates a success, 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.
7. TCP Procedure 7. TCP Procedure
CONNECT 7.1. 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, and BND.ADDR contains server assigned to connect to the target host, and BND.ADDR contains
the associated IP address. The supplied BND.ADDR is often different the associated IP address. The supplied BND.ADDR is often different
from the IP address that the client uses to reach the SOCKS server, 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 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 SOCKS server will use DST.ADDR and DST.PORT, and the client-side
source address and port in evaluating the CONNECT request. source address and port in evaluating the CONNECT request.
BIND 7.2. 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
use the BIND request only to establish secondary connections after a use the BIND request only to establish secondary connections after a
primary connection is established using CONNECT. DST.ADDR must be primary connection is established using CONNECT. DST.ADDR contains
the address of the primary connection's destination. DST.PORT should the address of the primary connection's destination. DST.PORT
be the requested port (or 0 for a random, unused port). It is contains the requested port (or 0 for a random, unused port). It is
expected that a SOCKS server will use DST.ADDR and DST.PORT in expected that a SOCKS server will use DST.ADDR and DST.PORT in
evaluating the BIND request. evaluating the BIND request.
Two replies are sent from the SOCKS server to the client during a 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 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 a new socket. The BND.PORT field contains the port number that the
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.
Note: out-of-band data
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.
8. UDP procedure 8. UDP procedure
UDP ASSOCIATE requests 8.1. 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.
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' o INTERFACE REQUEST X'01'
USECLIENTSPORT X'04' o 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,
server SHOULD interact with the application server using the same port the server SHOULD interact with the application server using the same
the client used in the request, and set the USECLIENTSPORT bit in the port the client used in the request, and set the USECLIENTSPORT bit
flag field of the reply to acknowledge having done so. If no port in the flag field of the reply to acknowledge having done so. If no
number was specified in the UDP ASSOCIATE request, this flag is port number was specified in the UDP ASSOCIATE request, this flag is
meaningless and MUST not be used. 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
bit in the reply. If both client and server support this feature, the this bit in the reply. If both client and server support this
client SHOULD send INTERFACE DATA subcommands, described below, during feature, the client SHOULD send INTERFACE DATA subcommands, described
the UDP association. below, during 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
request messages to be relayed. UDP request messages to be relayed.
UDP Control Channel 8.2. 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 SHOULD send INTERFACE DATA indicated mutual support for it, the client SHOULD send INTERFACE
subcommands to learn the external address information for the UDP DATA subcommands to learn the external address information for the
assocaiation with respect to a particular destination. The server, in UDP assocaiation with respect to a particular destination. The
turn, MAY use this information to limit access to the association to server, in turn, MAY use this information to limit access to the
those destination addresses for which it has received INTERFACE DATA association to those destination addresses for which it has received
queries; multiple INTERFACE DATA commands are permitted, and have a INTERFACE DATA queries; multiple INTERFACE DATA commands are
cumulative effect. permitted, and have a cumulative effect.
Such requests are formatted as follows: Such requests are formatted as follows:
+----+-----+------+------+----------+------+ +----+-----+------+------+----------+------+
|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:
skipping to change at page 9, line 4 skipping to change at page 9, line 13
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 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 (network octet order) 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 8.3. 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 33 skipping to change at page 9, line 43
The fields in the UDP request header are: The fields in the UDP request header are:
o FLAG Reserved (currently 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 (network octet order) o DST.PORT desired destination port (network octet order)
o DATA user data o DATA user payload 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,
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
given in the reply to UDP ASSOCIATE. It MUST drop any datagrams given in the reply to UDP ASSOCIATE. It MUST drop any datagrams
arriving from any source IP address other than the one recorded for arriving from any source IP address other than the one recorded for
the particular association. the particular association.
skipping to change at page 10, line 22 skipping to change at page 10, line 35
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 10. 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:
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 William Perry: Aventail
o Dave Chouinard: Intel o Dave Chouinard: Intel
10. References 11. References
[CHAP] VanHeyningen, M., "Challenge-Handshake Authentication
Protocol for SOCKS V5," work in progress.
[GSSAPI] Margrave, D., "GSS-API Authentication Method for SOCKS [GSSAPI] Margrave, D., "GSS-API Authentication Method for SOCKS
Version 5," work in progress. 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," RFC 1928, April 1996.
[RFC 1929] Leech, M., "Username/Password Authentication for SOCKS V5," [RFC 1929] Leech, M., "Username/Password Authentication for SOCKS V5,"
March 1996. RFC 1929, 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," RFC 1961, June 1996.
[RFC 2478] Baize, E. and Pinkas, D., "The Simple and Protected GSS-API
Negotiation Mechanism," RFC 2478, December 1998.
[RFC 2847] Eisler, M., "LIPKEY - A Low Infrastructure Public Key
Mechanism Using SPKM," RFC 2847, June 2000.
[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
808 Howell Streeet; Suite 200 808 Howell Streeet; Suite 200
Seattle, WA 98101 Seattle, WA 98101 USA
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. 38 change blocks. 
80 lines changed or deleted 84 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/