idnits 2.17.1 draft-ietf-aft-socks-pro-v5-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 130 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 135: '..., and the client MUST close the connec...' RFC 2119 keyword, line 139: '... o X'00' NO AUTHENTICATION REQUIRED...' RFC 2119 keyword, line 156: '... implementations SHOULD support GSSA...' RFC 2119 keyword, line 164: '..., these requests MUST be encapsulated ...' RFC 2119 keyword, line 301: '...n for the association. The server MAY...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 9 has weird spacing: '... This docum...' == Line 10 has weird spacing: '...ted and shoul...' == Line 14 has weird spacing: '... Drafts are ...' == Line 15 has weird spacing: '...cuments of t...' == Line 16 has weird spacing: '... groups may ...' == (125 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (29 July 1997) is 9761 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC 1928' is defined on line 408, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Ch97' -- Possible downref: Non-RFC (?) normative reference: ref. 'SOCKS' Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AFT Working Group William Perry 3 draft-ietf-aft-socks-pro-v5-01 Aventail, Corp. 4 Expire in six months 29 July 1997 6 SOCKS Protocol Version 5 8 Status of this Memo 9 This document is a submission to the IETF Authenticated Firewall 10 Traversal (AFT) Working Group. Comments are solicited and should be 11 addressed to the working group mailing list (aft@socks.nec.com) or to 12 the editor. 14 This document is an Internet-Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet-Drafts draft documents are valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Distribution of this memo is unlimited 32 Acknowledgments 34 This memo describes a protocol that is an evolution of the previous 35 version of the protocol, version 4[SOCKS]. This new protocol stems 36 from active discussions and prototype implementations. The key 37 contributors are: 39 o Marcus Leech: Bell-Northern Research 40 o David Koblas: Independent Consultant 41 o Ying-Da Lee: NEC Systems Laboratory 42 o LaMont Jones: Hewlett-Packard Company 43 o Ron Kuris: Unify Corporation 44 o Matt Ganis: International Business Machines 45 o David Blob: NEC USA 46 o Wei Lu: NEC USA. 48 1. Introduction 49 The use of network firewalls, systems that effectively isolate an 50 organizations internal network structure from an exterior network, 51 such as the INTERNET is becoming increasingly popular. These 52 firewall systems typically act as application-layer gateways between 53 networks, usually offering controlled TELNET, FTP, and SMTP access. 54 With the emergence of more sophisticated application layer protocols 55 designed to facilitate global information discovery, there exists a 56 need to provide a general framework for these protocols to 57 transparently and securely traverse a firewall. 59 There exists, also, a need for strong authentication of such 60 traversal in as fine-grained a manner as is practical. This 61 requirement stems from the realization that client-server 62 relationships emerge between the networks of various organizations, 63 and that such relationships need to be controlled and often strongly 64 authenticated. 66 The protocol described here is designed to provide a framework for 67 client-server applications in both the TCP and UDP domains to 68 conveniently and securely use the services of a network firewall. 69 The protocol is conceptually a "shim-layer" between the application 70 layer and the transport layer, and as such does not provide network- 71 layer gateway services, such as forwarding of ICMP messages. 73 2. Existing practice 75 There currently exists a protocol, SOCKS Version 4, that provides for 76 unsecured firewall traversal for TCP-based client-server 77 applications, including TELNET, FTP and the popular information- 78 discovery protocols such as HTTP, WAIS and GOPHER. 80 This new protocol extends the SOCKS Version 4 model to include UDP, 81 and extends the framework to include provisions for generalized 82 strong authentication schemes, and extends the addressing scheme to 83 encompass domain-name and V6 IP addresses. 85 The implementation of the SOCKS protocol typically involves the 86 recompilation or relinking of TCP-based client applications to use 87 the appropriate encapsulation routines in the SOCKS library. 89 Note: 91 Unless otherwise noted, the decimal numbers appearing in packet- 92 format diagrams represent the length of the corresponding field, in 93 octets. Where a given octet must take on a specific value, the 94 syntax X'hh' is used to denote the value of the single octet in that 95 field. When the word 'Variable' is used, it indicates that the 96 corresponding field has a variable length defined either by an 97 associated (one or two octet) length field, or by a data type field. 99 3. Procedure for TCP-based clients 101 When a TCP-based client wishes to establish a connection to an object 102 that is reachable only via a firewall (such determination is left up 103 to the implementation), it must open a TCP connection to the 104 appropriate SOCKS port on the SOCKS server system. The SOCKS service 105 is conventionally located on TCP port 1080. If the connection 106 request succeeds, the client enters a negotiation for the 107 authentication method to be used, authenticates with the chosen 108 method, then sends a relay request. The SOCKS server evaluates the 109 request, and either establishes the appropriate connection or denies 110 it. 112 The client connects to the server, and sends a version 113 identifier/method selection message: 115 +----+----------+----------+ 116 |VER | NMETHODS | METHODS | 117 +----+----------+----------+ 118 | 1 | 1 | 1 to 255 | 119 +----+----------+----------+ 121 The VER field is set to X'05' for this version of the protocol. The 122 NMETHODS field contains the number of method identifier octets that 123 appear in the METHODS field. 125 The server selects from one of the methods given in METHODS, and 126 sends a METHOD selection message: 128 +----+--------+ 129 |VER | METHOD | 130 +----+--------+ 131 | 1 | 1 | 132 +----+--------+ 134 If the selected METHOD is X'FF', none of the methods listed by the 135 client are acceptable, and the client MUST close the connection. 137 The values currently defined for METHOD are: 139 o X'00' NO AUTHENTICATION REQUIRED 140 o X'01' GSSAPI 141 o X'02' USERNAME/PASSWORD 142 o X'03' to X'7F' IANA ASSIGNED 143 o X'80' to X'FE' RESERVED FOR PRIVATE METHODS 144 o X'FF' NO ACCEPTABLE METHODS 146 The client and server then enter a method-specific sub-negotiation. 148 Descriptions of the method-dependent sub-negotiations appear in 149 separate memos. 151 Developers of new METHOD support for this protocol should contact 152 IANA for a METHOD number. The ASSIGNED NUMBERS document should be 153 referred to for a current list of METHOD numbers and their 154 corresponding protocols. 156 Compliant implementations SHOULD support GSSAPI and MUST support 157 USERNAME/PASSWORD authentication methods. 159 4. Requests 161 Once the method-dependent subnegotiation has completed, the client 162 sends the request details. If the negotiated method includes 163 encapsulation for purposes of integrity checking and/or 164 confidentiality, these requests MUST be encapsulated in the method- 165 dependent encapsulation. 167 The SOCKS request is formed as follows: 169 +----+-----+------+------+----------+----------+ 170 |VER | CMD | FLAG | ATYP | DST.ADDR | DST.PORT | 171 +----+-----+------+------+----------+----------+ 172 | 1 | 1 | 1 | 1 | Variable | 2 | 173 +----+-----+------+------+----------+----------+ 175 Where: 177 o VER protocol version: X'05' 178 o CMD 179 o CONNECT X'01' 180 o BIND X'02' 181 o UDP ASSOCIATE X'03' 182 o X'04' to X'7F' IANA ASSIGNED 183 o X'80' to X'FF' RESERVED FOR PRIVATE METHODS 184 o FLAG command dependent flag 185 o ATYP address type of following address 186 o IP V4 address: X'01' 187 o DOMAINNAME: X'03' 188 o IP V6 address: X'04' 189 o DST.ADDR desired destination address 190 o DST.PORT desired destination port in network octet 191 order 193 The SOCKS server will typically evaluate the request based on 194 source and destination addresses, and return one or more reply 195 messages, as appropriate for the request type. 197 5. Addressing 199 In an address field (DST.ADDR, BND.ADDR), the ATYP field specifies 200 the type of address contained within the field: 202 o X'01' 204 the address is a version-4 IP address, with a length of 4 octets 206 o X'03' 208 the address field contains a fully-qualified domain name. The first 209 octet of the address field contains the number of octets of name that 210 follow, there is no terminating NUL octet. 212 o X'04' 214 the address is a version-6 IP address, with a length of 16 octets. 216 6. Replies 218 The SOCKS request information is sent by the client as soon as it has 219 established a connection to the SOCKS server, and completed the 220 authentication negotiations. The server evaluates the request, and 221 returns a reply formed as follows: 223 +----+-----+------+------+----------+----------+ 224 |VER | REP | FLAG | ATYP | BND.ADDR | BND.PORT | 225 +----+-----+------+------+----------+----------+ 226 | 1 | 1 | 1 | 1 | Variable | 2 | 227 +----+-----+------+------+----------+----------+ 229 Where: 231 o VER protocol version: X'05' 232 o REP Reply field: 233 o X'00' succeeded 234 o X'01' general SOCKS server failure 235 o X'02' connection not allowed by ruleset 236 o X'03' Network unreachable 237 o X'04' Host unreachable 238 o X'05' Connection refused 239 o X'06' TTL expired 240 o X'07' Command not supported 241 o X'08' Address type not supported 243 o X'09' Invalid address 244 o X'0A' to X'FF' unassigned 245 o FLAG command dependent flag 246 o ATYP address type of following address 247 o IP V4 address: X'01' 248 o DOMAINNAME: X'03' 249 o IP V6 address: X'04' 250 o BND.ADDR server bound address 251 o BND.PORT server bound port in network octet order 253 If the chosen method includes encapsulation for purposes of 254 authentication, integrity and/or confidentiality, the replies are 255 encapsulated in the method-dependent encapsulation. 257 CONNECT 259 In the reply to a CONNECT, BND.PORT contains the port number that the 260 server assigned to connect to the target host, while BND.ADDR 261 contains the associated IP address. The supplied BND.ADDR is often 262 different from the IP address that the client uses to reach the SOCKS 263 server, since such servers are often multi-homed. It is expected 264 that the SOCKS server will use DST.ADDR and DST.PORT, and the client- 265 side source address and port in evaluating the CONNECT request. 267 BIND 269 The BIND request is used in protocols which require the client to 270 accept connections from the server. FTP is a well-known example, 271 which uses the primary client-to-server connection for commands and 272 status reports, but may use a server-to-client connection for 273 transferring data on demand (e.g. LS, GET, PUT). 275 It is expected that the client side of an application protocol will 276 use the BIND request only to establish secondary connections after a 277 primary connection is established using CONNECT. DST.ADDR must be 278 the address of the primary connection's destination. DST.PORT should 279 be the requested port (or 0 for a random, unused port). It is 280 expected that a SOCKS server will use DST.ADDR and DST.PORT in 281 evaluating the BIND request. 283 Two replies are sent from the SOCKS server to the client during a 284 BIND operation. The first is sent after the server creates and binds 285 a new socket. The BND.PORT field contains the port number that the 286 SOCKS server assigned to listen for an incoming connection. The 287 BND.ADDR field contains the associated IP address. The client will 288 typically use these pieces of information to notify (via the primary 289 or control connection) the application server of the rendezvous 290 address. The second reply occurs only after the anticipated incoming 291 connection succeeds or fails. 293 In the second reply, the BND.PORT and BND.ADDR fields contain the 294 address and port number of the connecting host. 296 UDP ASSOCIATE 298 The UDP ASSOCIATE request is used to establish an association within 299 the UDP relay process to handle UDP datagrams. The DST.ADDR and 300 DST.PORT fields contain the address and port that the client expects 301 to use to send UDP datagrams on for the association. The server MAY 302 use this information to limit access to the association. If the 303 client is not in possesion of the information at the time of the UDP 304 ASSOCIATE, the client MUST use address type X'01' with a port number 305 and address of all zeros. 307 A UDP association terminates when the TCP connection that the UDP 308 ASSOCIATE request arrived on terminates. 310 In the reply to a UDP ASSOCIATE request, the BND.PORT and BND.ADDR 311 fields indicate the port number/address where the client MUST send 312 UDP request messages to be relayed (unless the UDP relaying is done 313 in the TCP channel as specified by the TCP RELAY flag). 315 NOTE: The current UDP ASSOCIATE command is not powerful enough for 316 many newer protocols, and does not handle multicast traffic at all. 317 A proposal to address these issues is available [Ch97]. 319 Reply Processing 321 When a reply (REP value other than X'00') indicates a failure, the 322 SOCKS server MUST terminate the TCP connection shortly after sending 323 the reply. This must be no more than 10 seconds after detecting the 324 condition that caused a failure. 326 If the reply code (REP value of X'00') indicates a success, and the 327 request was either a BIND or a CONNECT, the client may now start 328 passing data. If the selected authentication method supports 329 encapsulation for the purposes of integrity, authentication and/or 330 confidentiality, the data are encapsulated using the method-dependent 331 encapsulation. Similarly, when data arrives at the SOCKS server for 332 the client, the server MUST encapsulate the data as appropriate for 333 the authentication method in use. 335 UDP Control Channel 337 A UDP association terminates when the TCP connection that the UDP 338 ASSOCIATE request arrived on terminates. 340 7. Procedure for UDP-based clients 342 A UDP-based client MUST send its datagrams to the UDP relay server at 343 the UDP port indicated by BND.PORT in the reply to the UDP ASSOCIATE 344 request. If the selected authentication method provides 345 encapsulation for the purposes of authenticity, integrity, and/or 346 confidentiality, the datagram MUST be encapsulated using the 347 appropriate encapsulation. Each UDP datagram carries a UDP request 348 header with it: 350 +------+------+------+----------+----------+----------+ 351 | FLAG | FRAG | ATYP | DST.ADDR | DST.PORT | DATA | 352 +------+------+------+----------+----------+----------+ 353 | 2 | 1 | 1 | Variable | 2 | Variable | 354 +------+------+------+----------+----------+----------+ 356 The fields in the UDP request header are: 358 o FLAG Reserved X'0000' 359 o FRAG Current fragment number 360 o ATYP address type of following addresses: 361 o IP V4 address: X'01' 362 o DOMAINNAME: X'03' 363 o IP V6 address: X'04' 364 o DST.ADDR desired destination address 365 o DST.PORT desired destination port 366 o DATA user data 368 FRAG is currently unused, and reserved for future work to deal with 369 fragmentation. 371 When a UDP relay server decides to relay a UDP datagram, it does so 372 silently, without any notification to the requesting client. 373 Similarly, it will drop datagrams it cannot or will not relay. When 374 a UDP relay server receives a reply datagram from a remote host, it 375 MUST encapsulate that datagram using the above UDP request header, 376 and any authentication-method-dependent encapsulation. 378 The UDP relay server MUST acquire from the SOCKS server the expected 379 IP address of the client that will send datagrams to the BND.PORT 380 given in the reply to UDP ASSOCIATE. It MUST drop any datagrams 381 arriving from any source IP address other than the one recorded for 382 the particular association. 384 The programming interface for a SOCKS-aware UDP MUST report an 385 available buffer space for UDP datagrams that is smaller than the 386 actual space provided by the operating system: 388 o if ATYP is X'01' - 10+method_dependent octets smaller 389 o if ATYP is X'03' - 262+method_dependent octets smaller 390 o if ATYP is X'04' - 20+method_dependent octets smaller 392 8. Security Considerations 394 This document describes a protocol for the application-layer 395 traversal of IP network firewalls. The security of such traversal is 396 highly dependent on the particular authentication and encapsulation 397 methods provided in a particular implementation, and selected during 398 negotiation between SOCKS client and SOCKS server. 400 Careful consideration should be given by the administrator to the 401 selection of authentication methods. 403 9. References 405 [Ch97] Chouinard, D., "SOCKS V5 UDP and Multicast Extensions", 406 July 1997, work in progress. 408 [RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R. Koblas, D., & 409 Jones, L., "SOCKS Protocol V5," April 1996. 411 [SOCKS] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Security 412 Symposium. 414 Author's Address 416 William M. Perry 417 Aventail, Corp. 418 117 South Main Street, Suite 400 419 Seattle, WA 98104 421 Phone: +1 (206) 777-5615 422 Email: wmperry@aventail.com