idnits 2.17.1 draft-ietf-aft-socks-protocol-v5-00.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-27) 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 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 a Security Considerations 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 84 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 10 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 132 has weird spacing: '... field speci...' == Line 134 has weird spacing: '...ess, if it i...' == Line 135 has weird spacing: '...ecifies a ve...' == Line 137 has weird spacing: '...address field...' == Line 141 has weird spacing: '...2' the lengt...' == (79 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: '1' is defined on line 381, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 383, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Socks Protocol Version 5 2 INTERNET-DRAFT 3 Expires: April 24, 1995 M. Leech 4 M. Ganis 5 Y. Lee 6 R. Kuris 7 D. Koblas 8 SOCKS Protocol Version 5 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft document valid for a maximum of six months 18 and may be updated, replaced or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress". 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 26 Rim). 28 Acknowledgments 30 This memo describes a protocol that is an evolution of the previous 31 version of the protocol, version 4. This new protocol stems from 32 active discussions and prototype implementations. The key 33 contributors are: Marcus Leech: Bell-Northern Research, David Koblas: 34 Independent Consultant, Ying-Da Lee: NEC Systems Laboratory, Lamont 35 Jones: Hewlett-Packard, Ron Kuris: Unify Corporation, Matt Ganis: 36 International Business Machines. 38 1. Introduction 40 The use of network firewalls, systems that effectively isolate an 41 organizations internal network structure from an exterior network, 42 such as the INTERNET is becoming increasingly popular. These firewall 43 systems typically act as application-layer gateways between networks, 44 usually offering controlled TELNET, FTP, and SMTP access. With the 45 emergence of more sophisticated application layer protocols designed 46 to facilitate global information discovery, there exists a need to 47 provide a general framework for these protocols to transparently and 48 securely traverse a firewall. 50 There exists, also, a need for strong authentication of such 51 traversal in as fine-grained a mannner as is practical. This 52 requirement stems from the realization that client-server 53 relationships emerge between the networks of various organizations, 54 and that such relationships need to be controlled and often strongly 55 authenticated. 57 The protocol described here is designed to provide a framework for 58 client-server applications in both the TCP and UDP domains to 59 conveniently and securely use the services of a network firewall. 61 2. Existing practice 63 There currently exists a protocol, SOCKS Version 4, that provides for 64 unsecured firewall traversal for TCP-based client-server 65 applications, including TELNET, FTP and the popular information- 66 discovery protocols such as HTTP, WAIS and GOPHER. 68 This protocol extends the SOCKS Version 4 model to include UDP, and 69 extends the protocol header to include provisions for generalized 70 strong authentication schemes, and extends the addressing scheme to 71 encompass domain-name and extended IP addresses. The implementation 72 of the SOCKS protocol typically involves the recompilation or 73 relinking of TCP-based client applications to use the appropriate 74 encapsulation routines in the SOCKS library. 76 3. Procedure for TCP-based clients 78 When a TCP-based client wishes to establish a connection to an object 79 that is reachable only via a firewall (such determination is left up 80 to the implementation), it must open a TCP connection to the 81 appropriate SOCKS port on the SOCKS server system. The SOCKS service 82 is conventionally located on TCP port 1080. If the connection request 83 succeeds, the client sends a request to the server with its desired 84 destination address, destination port, and authentication 85 information. The SOCKS server evaluates the information, and either 86 establishes the appropriate connection or denies it. 88 The SOCKS request is formed as follows: 90 +-----+------+-----+----------+----------+-----+-----+------/ 91 | 8 | 8 | 8 | 16 | var | 4 | 4 | 8 / 92 | VER | ATYP | CMD | DST.PORT | DST.ADDR | ULN | ILN | ALEN / 93 | | | | | | | | / 94 +-----+------+-----+----------+----------+-----+-----+------/ 95 /---------+-----------+----------+ 96 / var | var | var | 97 / SRC.USR | SRC.IDENT | SRC.AUTH | 98 / | | | 99 /---------+-----------+----------+ 101 Where: 103 o VER protocol version: X'05' 105 o ATYP address type of following address 107 IP V4 address: X'01' 108 IP V5 address: X'02' 109 DOMAINNAME: X'03' 110 IPNG address: X'04' 112 o DST.ADDR desired destination address 114 o DST.PORT desired destination port in network byte order 116 o CMD command: CONNECT X'01' BIND X'02' 118 o ULN length of SRC.USR field in bytes: 4 bits 120 o ILN length of SRC.IDENT field in bytes: 4 bits 122 o ALEN length of SRC.AUTH field in bytes: 8 bits 124 o SRC.USR username as known to the client-side operating system 126 o SRC.IDENT identifier as known to the authentication system 128 o SRC.AUTH authenticator as known to the authentication system 130 4. Addressing 132 In an address field (DST.ADDR, BND.ADDR), the ATYP field specifies 133 the type of address contained within the field. If ATYP is X'01', the 134 address is version-4 IP address, if it is X'02', then the field 135 specifies a version-5 IP address (that is, IP protocol version 4/5, 136 not SOCKS protocol version 4/5). If the ATYP field is X'03', then the 137 address field contains a DNS-style domain name, if it is X'04' then 138 the field specifies an IPNG address. 140 If the ATYP field is X'01', the length of BND.ADDR is 4 bytes, if 141 X'02' the length is 8 bytes. If the ATYP field is X'03', then the 142 first byte of the BND.ADDR specifies the length, in bytes, of the 143 rest of the field. 145 5. Replies 147 The SOCKS request information is sent by the client as soon as it has 148 established a connection to the SOCKS server. The server evaluates 149 the request, and returns a reply formed as follows: 151 +-----+------+-----+----------+----------+ 152 | 8 | 8 | 8 | 16 | var | 153 | VER | ATYP | REP | BND.PORT | BND.ADDR | 154 | | | | | | 155 +-----+------+-----+----------+----------+ 156 || 157 \/ 158 +---------------+ 159 | 3 | 1 | 4 | 160 | ET | R | CODE | 161 | | | | 162 +----+---+------+ 164 o VER protocol version: X'05' 166 o ATYP address type of following address 168 IP V4 address: X'01' 169 IP V5 address: X'02' 170 DOMAINNAME: X'03' 171 IPNG address: X'04' 173 o BND.ADDR server bound address 175 o BND.PORT server bound port in network byte order 177 o REP Reply field: 179 The reply field is broken up into a 3 subfields: 181 ET encryption type: 3 bits 183 X'0' unencrypted 184 X'1' DES 185 X'2' IDEA 186 X'3' PRIVATE_1 187 X'4' PRIVATE_2 188 X'5' PRIVATE_3 190 R reply bit: always set for replies 192 CODE reason code 4 bits: 194 X'0' succeeded 195 X'1' general failure 196 X'2' bad/unknown identifier 197 X'3' connection not allowed by ruleset 198 X'4' authentication failure 199 X'5' identifier explicitly blocked 201 In a reply, the BND.ADDR and BND.PORT fields are the SOCKS server 202 address and port number of the outbound connection for a CONNECT 203 request, and contain the SOCKS server bind() address for a BIND 204 request. If a reply contains a non-zero ET subfield, the server 205 expects that there will be a bi-directional encryption of user-data 206 on this connection using the encryption type specified in the ET 207 subfield. It is expected that the server and client have already 208 negotiated the appropriate key in an `out-of-band' process. It is 209 typically the case that the same key that is used for authentication 210 is used for encryption. 212 The BIND request is used in protocols which require the client to 213 accept connections from the server. FTP is a well-known example, 214 which uses the primary client-to-server connection for commands and 215 status reports, but may use a server-to-client connection for 216 transferring data on demand (e.g. LS, GET, PUT). 218 It is expected that the client side of an application protocol will 219 use the BIND request only to establish secondary connections after a 220 primary connection is established using CONNECT. Usually, then, 221 DST.PORT and DST.ADDR in a BIND request header would be the same as 222 those used in the primary connection, though this is not required. 224 In a similar fashion to CONNECT, the SOCKS server may use DST.PORT 225 and DST.ADDR in evaluating the BIND request. 227 Two replies are sent from the SOCKS server to the client during a 228 BIND operation. The first is sent after the server creates and binds 229 a new socket. The BND.PORT field contains the port number assigned in 230 the bind() call. The BND.ADDR field contains the associated IP 231 address. The client will typicallly use these pieces of information 232 to notify (via the primary or control connection) the application 233 server of the `rendezvous point'. The second reply occurs only after 234 the anticipated incoming connection succeeds or fails. In the second 235 reply, only the REP field is meaningful. 237 When a reply (CODE value other than X'0') indicates a failure, the 238 SOCKS server will terminate the TCP connection shortly after sending 239 the reply. 241 6. Procedure for UDP-based clients 243 With UDP-based clients, there is no notion of a connection, so each 244 datagram that is to be carried by a SOCKS-UDP server must carry 245 destination and authentication information with it. A UDP-based 246 client must send its datagrams to the SOCKS-UDP server at UDP port 247 1080. Each UDP datagram carries a SOCKS request header with it: 249 +-----+------+-----+----------+----------+-----+-----+------/ 250 | 8 | 8 | 8 | 16 | var | 4 | 4 | 8 / 251 | VER | ATYP | CMD | DST.PORT | DST.ADDR | ULN | ILN | ALEN / 252 | | | | | | | | / 253 +-----+------+-----+----------+----------+-----+-----+------/ 255 /---------+-----------+----------+ 256 / var | var | var | 257 / SRC.USR | SRC.IDENT | SRC.AUTH | 258 / | | | 259 /---------+-----------+----------+ 261 Where: 263 o VER protocol version: X'05' 265 o ATYP address type of following address 267 IP V4 address: X'01' 268 IP V5 address: X'02' 269 DOMAINNAME: X'03' 270 IPNG address: X'04' 272 o DST.ADDR desired destination address 274 o DST.PORT desired destination port in network byte order 276 o CMD command: RELAY X'03' 278 o ULN length of SRC.USR field in bytes: 4 bits 280 o ILN length of SRC.IDENT field in bytes: 4 bits 282 o ALEN length of SRC.AUTH field in bytes: 8 bits 284 o SRC.USR username as known to the client-side operating system 285 o SRC.IDENT identifier as known to the authentication system 287 o SRC.AUTH authenticator as known to the authentication system 289 When a SOCKS-UDP server decides to RELAY a UDP datagram, it does so 290 silently, without any notification to the requesting client. 291 Similarly, it will drop datagrams it cannot or will not RELAY. When a 292 SOCKS-UDP server receives a reply datagram from a remote host, it 293 will encapsulate that datagram using the standard SOCKS request 294 header, and use the DST.ADDR and DST.PORT fields to give the 295 originating host address and port number. When a SOCKS-UDP server 296 receives a RELAY request from a client, it establishes a temporary 297 association between the client address/port and a port on the SOCKS- 298 UDP server. This temporary association is used to allow UDP reply 299 datagrams to be correctly relayed back to the requesting UDP client. 300 The timer related to this association is implementation dependant, 301 but must be at least five minutes. 303 7. Authentication and identification information 305 The standard SOCKS request header includes information intended to 306 identify the originating entity of the corresponding connection 307 request or datagram relay request. The SRC.USR field is intended as a 308 low-to-medium confidence mechanism for a SOCKS relay agent to provide 309 usage auditing information only, and not as an authentication 310 mechanism. The SRC.IDENT and SRC.AUTH fields are used to carry 311 information that a SOCKS relay agent (server) may use to control and 312 authenticate access to its relay services.The fundamental notion 313 being that SRC.IDENT carries a unique identity associated with a 314 requesting entity (typically a person) and SRC.AUTH carries some type 315 of strong proof of that identity. In this way, the SOCKS relay agent 316 may make decisions about access controls based on a strong notion of 317 the identity of the entity requesting access. 319 In one implementation, the SRC.IDENT field carries a unique 320 identifier that has associated with it a secret key that is shared 321 between the relay agent and the requesting entity. The corresponding 322 SRC.AUTH field contains time-varying information that is computed 323 based on the shared secret key and a strong one-way hash of the 324 time-varying data. In this implementation the shared secret key has a 325 specific and relatively short lifetime; `out-of-band' techniques are 326 used from time to time to assign a new secret key. In this way, the 327 secret key acts much like a session key in Kerberos. 329 Another implementation may choose to use the SRC.IDENT and SRC.AUTH 330 fields to carry information produced by so-called smart card 331 technology to authenticate access. 333 Another implementation may choose to carry the operating system 334 username in SRC.IDENT and the corresponding access password in 335 SRC.AUTH. In this way, the authentication provided is no weaker than 336 that provided by the FTP protocol. 338 8. Encrypted connections 340 The TCP SOCKS server may return a connection-success reply with the 341 encryption-type (ET) field set non-zero. If this is the case, then 342 the SOCKS server expects that all data transferred on the connection 343 after the initial SOCKS connect request will be encrypted in a 344 mutually agreed upon key using the algorithm specified by the SOCKS 345 server. In order to make this work, the server expects the data 346 stream to be encapsulated into a series of encrypted payloads as 347 follows: 349 +------+-------+-----+---------------------------------------------------+ 350 | 8 | 128 | 16 | var | | 351 | PLEN | AUTHN | SSN | DATA | PAD | 352 | | | | | | 353 +------+-------+-----+---------------------------------------------------+ 355 The AUTHN field is 16-bytes long, and is expected to contain the 356 cryptographic checksum (message digest) of the AUTHN, SSN and DATA 357 fields prepended with the key associated with this connection. When 358 computing this checksum, the AUTHN field is set to all X'00'. The SSN 359 field is a unique sequence number for each encrypted payload, this is 360 an unsigned 16-bit value transmitted in network byte order. 362 The receiver of an encrypted payload shall use the PLEN field, 363 appropriately rounded for the blocksize of the encryption algorithm 364 in use, to determine the number of bytes of encrypted data that 365 follow. This is necessary, since the transport in use (TCP) is a 366 stream protocol, and does not preserve I/O boundaries across a 367 connection. 369 The receiver of an encrypted payload for which the received AUTHN 370 field fails to match the computed value of AUTHN must immediately 371 terminate the connection, and log an error to the system log. 372 Similarly, if a received SSN doesn't increment the current received 373 SSN, the payload is a replay, and must terminate the connection. 375 Since the encryption is bidirectional, the SOCKS server uses the same 376 encapsulation technique when sending encrypted data towards the 377 client. 379 9. References 381 [1] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Security Symposium 383 [2] Leech, M., et al, "Socks Protocol Version 4" RFCXXXX 385 Authors Address 387 Marcus Leech, Bell-Northern Research 388 P.O. Box 3511, Stn. C, 389 Ottawa, ON 390 CANADA K1Y 4H7 392 Email: mleech@bnr.ca 394 Phone: (613) 763-9145