idnits 2.17.1 draft-olteanu-intarea-socks-6-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 02, 2018) is 2117 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Area Working Group V. Olteanu 3 Internet-Draft D. Niculescu 4 Intended status: Experimental University Politehnica of Bucharest 5 Expires: January 3, 2019 July 02, 2018 7 SOCKS Protocol Version 6 8 draft-olteanu-intarea-socks-6-03 10 Abstract 12 The SOCKS protocol is used primarily to proxy TCP connections to 13 arbitrary destinations via the use of a proxy server. Under the 14 latest version of the protocol (version 5), it takes 2 RTTs (or 3, if 15 authentication is used) before data can flow between the client and 16 the server. 18 This memo proposes SOCKS version 6, which reduces the number of RTTs 19 used, takes full advantage of TCP Fast Open, and adds support for 20 0-RTT authentication. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 3, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Revision log . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Requirements language . . . . . . . . . . . . . . . . . . . . 6 59 3. Mode of operation . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5. Version Mismatch Replies . . . . . . . . . . . . . . . . . . 9 62 6. Authentication Replies . . . . . . . . . . . . . . . . . . . 9 63 7. Operation Replies . . . . . . . . . . . . . . . . . . . . . . 10 64 7.1. Handling CONNECT . . . . . . . . . . . . . . . . . . . . 12 65 7.2. Handling BIND . . . . . . . . . . . . . . . . . . . . . . 12 66 7.3. Handling UDP ASSOCIATE . . . . . . . . . . . . . . . . . 12 67 8. SOCKS Options . . . . . . . . . . . . . . . . . . . . . . . . 12 68 8.1. Stack options . . . . . . . . . . . . . . . . . . . . . . 13 69 8.1.1. TFO options . . . . . . . . . . . . . . . . . . . . . 14 70 8.1.2. Multipath TCP options . . . . . . . . . . . . . . . . 14 71 8.1.3. MPTCP Scheduler options . . . . . . . . . . . . . . . 15 72 8.2. Authentication Method options . . . . . . . . . . . . . . 16 73 8.3. Authentication Data options . . . . . . . . . . . . . . . 16 74 8.4. Idempotence options . . . . . . . . . . . . . . . . . . . 17 75 8.4.1. Requesting a fresh token window . . . . . . . . . . . 18 76 8.4.2. Spending a token . . . . . . . . . . . . . . . . . . 19 77 8.4.3. Handling Token Window Advertisements . . . . . . . . 21 78 9. Username/Password Authentication . . . . . . . . . . . . . . 21 79 10. TCP Fast Open on the Client-Proxy Leg . . . . . . . . . . . . 21 80 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 81 11.1. Large requests . . . . . . . . . . . . . . . . . . . . . 22 82 11.2. Replay attacks . . . . . . . . . . . . . . . . . . . . . 22 83 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 84 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 85 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 86 14.1. Normative References . . . . . . . . . . . . . . . . . . 23 87 14.2. Informative References . . . . . . . . . . . . . . . . . 23 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 90 1. Introduction 92 Versions 4 and 5 [RFC1928] of the SOCKS protocol were developed two 93 decades ago and are in widespread use for circuit level gateways or 94 as circumvention tools, and enjoy wide support and usage from various 95 software, such as web browsers, SSH clients, and proxifiers. 96 However, their design needs an update in order to take advantage of 97 the new features of transport protocols, such as TCP Fast Open 98 [RFC7413], or to better assist newer transport protocols, such as 99 MPTCP [RFC6824]. 101 One of the main issues faced by SOCKS version 5 is that, when taking 102 into account the TCP handshake, method negotiation, authentication, 103 connection request and grant, it may take up to 5 RTTs for a data 104 exchange to take place at the application layer. This is especially 105 costly in networks with a large delay at the access layer, such as 106 3G, 4G, or satelite. 108 The desire to reduce the number of RTTs manifests itself in the 109 design of newer security protocols. TLS version 1.3 110 [I-D.ietf-tls-tls13] defines a zero round trip (0-RTT) handshake mode 111 for connections if the client and server had previously communicated. 113 TCP Fast Open [RFC7413] is a TCP option that allows TCP to send data 114 in the SYN and receive a response in the first ACK, and aims at 115 obtaining a data response in one RTT. The SOCKS protocol needs to 116 concern itself with at least two TFO deployment scenarios: First, 117 when TFO is available end-to-end (at the client, at the proxy, and at 118 the server); second, when TFO is active between the client and the 119 proxy, but not at the server. 121 This document describes the SOCKS protocol version 6. The key 122 improvements over SOCKS version 5 are: 124 o The client sends as much information upfront as possible, and does 125 not wait for the authentication process to conclude before 126 requesting the creation of a socket. 128 o The connection request also mimics the semantics of TCP Fast Open 129 [RFC7413]. As part of the connection request, the client can 130 supply the potential payload for the initial SYN that is sent out 131 to the server. 133 o The protocol can be extended via options without breaking 134 backward-compatibility. 136 o The protocol can leverage the aforementioned options to support 137 0-RTT authentication schemes. 139 1.1. Revision log 141 Typos and minor clarifications are not listed. 143 draft-03 144 o Shifted some fields in the Operation Reply to make it easier to 145 parse. 147 o Added connection attempt timeout response code to Operation 148 Replies. 150 o Proxies send an additional Authentication Reply after the 151 authentication phase. (Useful for token window advertisements.) 153 o Renamed the section "Connection Requests" to "Requests" 155 o Clarified the fact that proxies don't need to support any command 156 in particular. 158 o Added the section "TCP Fast Open on the Client-Proxy Leg" 160 o Options: 162 * Added constants for option kinds 164 * Salt options removed, along with the relevant section from 165 Security Considerations. (TLS 1.3 Makes AEAD mandatory.) 167 * Limited Authentication Data options to one per method. 169 * Relaxed proxy requirements with regard to handling multiple 170 Authentication Data options. (When the client violates the 171 above bullet point.) 173 * Removed interdependence between Authentication Method and 174 Authentication Data options. 176 * Clients SHOULD omit advertising the "No authentication 177 required" option. (Was MAY.) 179 * Idempotence options: 181 + Token Window Advertisements are now part of successful 182 Authentication Replies (so that the proxy-server RTT has no 183 impact on their timeliness). 185 + Proxies can't advetise token windows of size 0. 187 + Tweaked token expenditure response codes. 189 + Support no longer mandatory on the proxy side. 191 * Revamped Socket options 192 + Renamed Socket options to Stack options. 194 + Banned contradictory socket options. 196 + Added socket level for generic IP. Removed the "socket" 197 socket level. 199 + Stack options no longer use option codes from setsockopt(). 201 + Changed MPTCP Scheduler constants. 203 draft-02 205 o Made support for Idempotence options mandatory for proxies. 207 o Clarified what happens when proxies can not or will not issue 208 tokens. 210 o Limited token windows to 2^31 - 1. 212 o Fixed definition of "less than" for tokens. 214 o NOOP commands now trigger Operation Replies. 216 o Renamed Authentication options to Authentication Data options. 218 o Authentication Data options are no longer mandatory. 220 o Authentication methods are now advertised via options. 222 o Shifted some Request fields. 224 o Option range for vendor-specific options. 226 o Socket options. 228 o Password authentication. 230 o Salt options. 232 draft-01 234 o Added this section. 236 o Support for idempotent commands. 238 o Removed version numbers from operation replies. 240 o Request port number for SOCKS over TLS. Deprecate encryption/ 241 encapsulation within SOCKS. 243 o Added Version Mismatch Replies. 245 o Renamed the AUTH command to NOOP. 247 o Shifted some fields to make requests and operation replies easier 248 to parse. 250 2. Requirements language 252 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 253 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 254 document are to be interpreted as described in [RFC2119]. 256 3. Mode of operation 258 CLIENT PROXY 260 +------------------------+ 261 | Authentication methods | Request 262 --------> Command code +------------------------------> 263 | Address | 264 | Port | 265 | Options | 266 | Initial data | 267 +------------------------+ 269 +-----------------------+ 270 Authentication reply | Type | 271 <----------------------------------+ Method <----- 272 | Options | 273 +-----------------------+ 275 <-------------------(Authentication protocol)------------------> 277 +-----------------------+ 278 Operation reply | Reply code | 279 <--------------------+ Bind address <------------------ 280 | Bind port | 281 | Options | 282 | Initial data offset | 283 +-----------------------+ 285 Figure 1: The SOCKS version 6 protocol message exchange 287 When a TCP-based client wishes to establish a connection to a server, 288 it must open a TCP connection to the appropriate SOCKS port on the 289 SOCKS proxy. The client then enters a negotiation phase, by sending 290 the request in figure Figure 1, that contains, in addition to fields 291 present in SOCKS 5 [RFC1928], fields that facilitate low RTT usage 292 and faster authentication negotiation. 294 Next, the server sends an authentication reply. If the request did 295 not contain the necessary authentication information, the proxy 296 indicates an authentication method that must proceed. This may 297 trigger a longer authentication sequence that could include tokens 298 for ulterior faster authentications. The part labeled 299 "Authentication protocol" is specific to the authentication method 300 employed and is not expected to be employed for every connection 301 between a client and its proxy server. The authentication protocol 302 typically takes up 1 RTT or more. 304 If the authentication is successful, an operation reply is generated 305 by the proxy. It indicates whether the proxy was successful in 306 creating the requested socket or not. 308 In the fast case, when authentication is properly set up, the proxy 309 attempts to create the socket immediately after the receipt of the 310 request, thus achieving an operational conection in one RTT (provided 311 TFO functionality is available at the client, proxy, and server). 313 4. Requests 315 The client starts by sending a request to the proxy. 317 +---------------+---------+------+---------+----------+ 318 | Version | Command | Port | Address | Address | 319 | Major | Minor | Code | | Type | | 320 +-------+-------+---------+------+---------+----------+ 321 | 1 | 1 | 1 | 2 | 1 | Variable | 322 +-------+-------+---------+------+---------+----------+ 323 +-----------+----------+--------------+--------------+ 324 | Number of | Options | Initial Data | Initial Data | 325 | Options | | Size | | 326 +-----------+----------+--------------+--------------+ 327 | 1 | Variable | 2 | Variable | 328 +-----------+----------+--------------+--------------+ 330 Figure 2: SOCKS 6 Request 332 o Version: The major byte MUST be set to 0x06, and the minor byte 333 MUST be set to 0x00. 335 o Command Code: 337 * 0x00 NOOP: authenticate the client and do nothing. 339 * 0x01 CONNECT: requests the establishment of a TCP connection. 341 * 0x02 BIND: requests the establishment of a TCP port binding. 343 * 0x03 UDP ASSOCIATE: requests a UDP port association. 345 o Address Type: 347 * 0x01: IPv4 349 * 0x03: Domain Name 351 * 0x04: IPv6 353 o Address: this field's format depends on the address type: 355 * IPv4: a 4-byte IPv4 address 357 * Domain Name: one byte that contains the length of the FQDN, 358 followed by the FQDN itself. The string is not NUL-terminated. 360 * IPv6: a 16-byte IPv6 address 362 o Port: the port in network byte order. 364 o Number of Options: the number of SOCKS options that appear in the 365 Options field. 367 o Options: see Section 8. 369 o Initial Data Size: A two-byte number in network byte order. In 370 case of NOOP, BIND or UDP ASSOCIATE, this field MUST be set to 0. 371 In case of CONNECT, this is the number of bytes of initial data 372 that are supplied in the following field. 374 o Initial Data: The first octets of the data stream. 376 Clients can advertise their supported authentication methods by 377 including an Authentication Method option (see Section 8.2). 379 The server MAY truncate the initial data to an arbitrary size and 380 disregard the rest. This is will be communicated later to the 381 client, should the authentication process be successful (see 382 Section 7). As such, server implementations do not have to buffer 383 the initial data while waiting for the (potentially malicious) client 384 to authenticate. 386 5. Version Mismatch Replies 388 Upon receipt of a request starting with a version number other than 389 6.0, the proxy sends the following response: 391 +---------------+ 392 | Version | 393 | Major | Minor | 394 +-------+-------+ 395 | 1 | 1 | 396 +-------+-------+ 398 Figure 3: SOCKS 6 Version Mismatch Reply 400 o Version: The major byte MUST be set to 0x06, and the minor byte 401 MUST be set to 0x00. 403 A client MUST close the connection after receiving such a reply. 405 6. Authentication Replies 407 Upon receipt of a valid request, the proxy sends an Authentication 408 Reply: 410 +---------------+------+--------+-----------+----------+ 411 | Version | Type | Method | Number of | Options | 412 | Major | Minor | | | Options | | 413 +-------+-------+------+--------+-----------+----------+ 414 | 1 | 1 | 1 | 1 | 1 | Variable | 415 +-------+-------+------+--------+-----------+----------+ 417 Figure 4: SOCKS 6 Authentication Reply 419 o Version: The major byte MUST be set to 0x06, and the minor byte 420 MUST be set to 0x00. 422 o Type: 424 * 0x00: authentication successful. 426 * 0x01: further authentication needed. 428 o Method: The chosen authentication method. 430 o Number of Options: the number of SOCKS options that appear in the 431 Options field. 433 o Options: see Section 8. 435 Multihomed clients SHOULD cache the chosen method on a per-interface 436 basis and SHOULD NOT include Authentication Data options related to 437 any other methods in further requests originating from the same 438 interface. 440 If the server signals that further authentication is needed and 441 selects "No Acceptable Methods", the client MUST close the 442 connection. 444 The client and proxy begin a method-specific negotiation. During 445 such negotiations, the proxy MAY supply information that allows the 446 client to authenticate a future request using an Authentication Data 447 option. The client and proxy SHOULD NOT negotiate the encryption of 448 the application data. Descriptions of such negotiations are beyond 449 the scope of this memo. When the negotiation is complete (either 450 successfully or unsuccessfully), the proxy sends another 451 Authentication Reply. 453 7. Operation Replies 455 After the authentication negotiations are complete, the server sends 456 an Operation Reply: 458 +-------+--------------+------+---------+----------+ 459 | Reply | Initial Data | Bind | Address | Bind | 460 | Code | Offset | Port | Type | Address | 461 +-------+--------------+------+---------+----------+ 462 | 1 | 2 | 2 | 1 | Variable | 463 +-------+--------------+------+---------+----------+ 464 +-----------+----------+ 465 | Number of | Options | 466 | Options | | 467 +-----------+----------+ 468 | 1 | Variable | 469 +-----------+----------+ 471 Figure 5: SOCKS 6 Operation Reply 473 o Reply Code: 475 * 0x00: Succes 476 * 0x01: General SOCKS server failure 478 * 0x02: Connection not allowed by ruleset 480 * 0x03: Network unreachable 482 * 0x04: Host unreachable 484 * 0x05: Connection refused 486 * 0x06: TTL expired 488 * 0x07: Command not supported 490 * 0x08: Address type not supported 492 * 0x09: Connection attempt timed out 494 o Initial Data Offset: A two-byte number in network byte order. In 495 case of BIND or UDP ASSOCIATE, this field MUST be set to 0. In 496 case of CONNECT, it represents the offset in the plain data stream 497 from which the client is expected to continue sending data. 499 o Bind Port: the proxy bound port in network byte order. 501 o Address Type: 503 * 0x01: IPv4 505 * 0x03: Domain Name 507 * 0x04: IPv6 509 o Bind Address: the proxy bound address in the following format: 511 * IPv4: a 4-byte IPv4 address 513 * Domain Name: one byte that contains the length of the FQDN, 514 followed by the FQDN itself. The string is not NUL-terminated. 516 * IPv6: a 16-byte IPv6 address 518 o Number of Options: the number of SOCKS options that appear in the 519 Options field. 521 o Options: see Section 8. 523 Proxy implementations MAY support any subset of the client commands 524 listed in Section 4. 526 If the proxy returns a reply code other than "Success", the client 527 MUST close the connection. 529 If the client issued an NOOP command, the client MUST close the 530 connection after receiving the Operation Reply. 532 7.1. Handling CONNECT 534 In case the client has issued a CONNECT request, data can now pass. 535 The client MUST resume the data stream at the offset indicated by the 536 Initial Data Offset field. 538 7.2. Handling BIND 540 In case the client has issued a BIND request, it must wait for a 541 second Operation reply from the proxy, which signifies that a host 542 has connected to the bound port. The Bind Address and Bind Port 543 fields contain the address and port of the connecting host. 544 Afterwards, application data may pass. 546 7.3. Handling UDP ASSOCIATE 548 The relay of UDP packets is handled exactly as in SOCKS 5 [RFC1928]. 550 8. SOCKS Options 552 SOCKS options have the following format: 554 +---------------+-------------+ 555 | Kind | Length | Option Data | 556 +------+--------+-------------+ 557 | 1 | 1 | Variable | 558 +------+--------+-------------+ 560 Figure 6: SOCKS 6 Option 562 o Kind: MUST be allocated by IANA. (See Section 12.) 564 o Length: The length of the option. 566 o Option Data: The contents are specific to each option kind. 568 Unless otherwise noted, client and proxy implementations MAY omit 569 supporting any of the options described in this document. Upon 570 encountering an unsupported option, a SOCKS endpoint MUST silently 571 ignore it. 573 8.1. Stack options 575 Stack options can be used by clients to alter the behavior of the 576 protocols on top of which SOCKS is running, as well the protcols used 577 by the proxy to communicate with the remote server (i.e. IP, TCP, 578 UDP). A Stack option can affect either the proxy's protocol on the 579 client-proxy leg or on the proxy-server leg. Clients can only place 580 Stack options inside SOCKS Requests. 582 Proxies MAY include Stack options in their Operation Replies to 583 signal their behavior. Said options MAY be unsolicited, i. e. the 584 proxy MAY send them to signal behaviour that was not explicitly 585 requested by the client. 587 Stack options that are part of the same message MUST NOT contradict 588 one another. 590 +---------------+--------+--------+------+----------+ 591 | Kind | Length | Leg | Level | Code | Data | 592 +------+--------+--------+--------+------+----------+ 593 | 1 | 1 | 2 bits | 6 bits | 1 | Variable | 594 +------+--------+--------+--------+------+----------+ 596 Figure 7: Stack Option 598 o Kind: 0x01 (Stack option) 600 o Length: The length of the option. 602 o Leg: 604 * 0x1: Client-Proxy Leg 606 * 0x2: Proxy-Server Leg 608 * 0x3: Both Legs 610 o Level: 612 * 0x01: IP 614 * 0x02: IPv4 616 * 0x03: IPv6 617 * 0x04: TCP 619 * 0x05: UDP 621 o Code: Option code 623 o Data: Option-specific data 625 8.1.1. TFO options 627 +---------------+--------+--------+------+ 628 | Kind | Length | Leg | Level | Code | 629 +------+--------+--------+--------+------+ 630 | 1 | 1 | 2 bits | 6 bits | 1 | 631 +------+--------+--------+--------+------+ 633 Figure 8: TFO Option 635 o Kind: 0x01 (Stack option) 637 o Length: MUST be 4. 639 o Leg: MUST be 0x2 (Proxy-Server Leg). 641 o Level: 0x04 (TCP). 643 o Code: 0x01 645 If a SOCKS Request contains a TFO option, the proxy SHOULD attempt to 646 use TFO in case of a CONNECT command, or accept TFO in case of a BIND 647 command. Otherwise, the proxy MUST NOT attempt to use TFO in case of 648 a CONNECT command, or accept TFO in case of a BIND command. 650 In case of a CONNECT command, the proxy MAY include a TFO option in 651 the Operation reply if TFO was attempted, the operation succeded and 652 the remote server supports TFO. In case of a BIND command, the proxy 653 MAY include a TFO option in the first Operation reply to signal that 654 it will accept an incoming TFO connection. 656 8.1.2. Multipath TCP options 658 In case of a CONNECT command, the proxy can inform the client that 659 the connection to the server is an MPTCP connection. 661 +---------------+--------+--------+------+ 662 | Kind | Length | Leg | Level | Code | 663 +------+--------+--------+--------+------+ 664 | 1 | 1 | 2 bits | 6 bits | 1 | 665 +------+--------+--------+--------+------+ 667 Figure 9: Multipath TCP Option 669 o Kind: 0x01 (Stack option) 671 o Length: 4. 673 o Leg: MUST be 0x2 (Proxy-Server Leg). 675 o Level: 0x04 (TCP). 677 o Code: 0x02 679 8.1.3. MPTCP Scheduler options 681 In case of a CONNECT or BIND command, a client can use an MPTCP 682 Scheduler option to indicate its preferred scheduler for the 683 connection. 685 A proxy can use an MPTCP Scheduler option to inform the client about 686 what scheduler is in use. 688 +---------------+--------+--------+------+-----------+ 689 | Kind | Length | Leg | Level | Code | Scheduler | 690 +------+--------+--------+--------+------+-----------+ 691 | 1 | 1 | 2 bits | 6 bits | 1 | 1 | 692 +------+--------+--------+--------+------+-----------+ 694 Figure 10: MPTCP Scheduler Option 696 o Kind: 0x01 (Stack option) 698 o Length: MUST be 5. 700 o Leg: Either 0x01, 0x02, or 0x03 (Client-Proxy, Proxy-Client or 701 Both legs). 703 o Level: 0x04 (TCP). 705 o Code: 0x03 706 o Scheduler: 708 * 0x01: Default 710 * 0x02: Round-Robin 712 * 0x03: Redundant 714 8.2. Authentication Method options 716 Authentication Method options are used by clients to advertise 717 supported authentication methods. They can be part of SOCKS 718 Requests. 720 +---------------+----------+ 721 | Kind | Length | Methods | 722 +------+--------+----------+ 723 | 1 | 1 | Variable | 724 +------+--------+----------+ 726 Figure 11: Authentication Method Option 728 o Kind: 0x02 (Authentication Method option) 730 o Length: The length of the option. 732 o Methods: One byte per advertised method. Method numbers are 733 assigned by IANA. 735 Clients MUST support the "No authentication required" method. 736 Clients SHOULD omit advertising the "No authentication required" 737 option. 739 8.3. Authentication Data options 741 Authentication Data options carry method-specific authentication 742 data. They can be part of SOCKS Requests and Authentication Replies. 744 Authentication Data options have the following format: 746 +---------------+--------+---------------------+ 747 | Kind | Length | Method | Authentication Data | 748 +------+--------+--------+---------------------+ 749 | 1 | 1 | 1 | Variable | 750 +------+--------+--------+---------------------+ 752 Figure 12: Authentication Data Option 754 o Kind: 0x03 (Authentication Data option) 756 o Length: The length of the option. 758 o Method: The number of the authentication method. These numbers 759 are assigned by IANA. 761 o Authentication Data: The contents are specific to each method. 763 Clients SHOULD only place one Authentication Data option per 764 authentication method. Server implementations MAY silently ignore 765 all Authentication Data options for the same method aside from an 766 arbitrarily chosen one. 768 8.4. Idempotence options 770 To protect against duplicate SOCKS Requests, authenticated clients 771 can request, and then spend, idempotence tokens. A token can only be 772 spent on a single SOCKS request. 774 Tokens are 4-byte unsigned integers in a modular 4-byte space. 775 Therefore, if x and y are tokens, x is less than y if 0 < (y - x) < 776 2^31 in unsigned 32-bit arithmetic. 778 Proxies grant contiguous ranges of tokens called token windows. 779 Token windows are defined by their base (the first token in the 780 range) and size. Windows can be shifted (i. e. have their base 781 increased, while retaining their size) unilaterally by the proxy. 783 Requesting and spending tokens is done via Idempotence options: 785 +---------------+------+-------------+ 786 | Kind | Length | Type | Option Data | 787 +------+--------+------+-------------+ 788 | 1 | 1 | 1 | Variable | 789 +------+--------+------+-------------+ 791 Figure 13: Idempotence Option 793 o Kind: 0x04 (Idempotence option) 795 o Length: The length of the option. 797 o Type: 799 * 0x00: Token Request 801 * 0x01: Token Window Advertisement 803 * 0x02: Token Expenditure 805 * 0x03: Token Expenditure Reply 807 o Option Data: The contents are specific to each type. 809 8.4.1. Requesting a fresh token window 811 A client can obtain a fresh window of tokens by sending a Token 812 Request option as part of a SOCKS Request: 814 +---------------+------+-------------+ 815 | Kind | Length | Type | Window Size | 816 +------+--------+------+-------------+ 817 | 1 | 1 | 1 | 4 | 818 +------+--------+------+-------------+ 820 Figure 14: Token Request 822 o Kind: MUST be allocated by IANA. (See Section 12.) 824 o Length: 7 826 o Type: 0x00 (Token Request) 828 o Window Size: The requested window size. 830 If a token window is issued, the proxy then includes a Token Window 831 Advertisement option in the corresponding successful Authentication 832 Reply: 834 +---------------+------+-------------+-------------+ 835 | Kind | Length | Type | Window Base | Window Size | 836 +------+--------+------+-------------+-------------+ 837 | 1 | 1 | 1 | 4 | 4 | 838 +------+--------+------+-------------+-------------+ 840 Figure 15: Token Window Advertisement 842 o Kind: 0x04 (Idempotence option) 844 o Length: 11 846 o Type: 0x01 (Token Grant) 848 o Window Base: The first token in the window. 850 o Window Size: The window size. This value SHOULD be lower or equal 851 to the requested window size. Window sizes MUST be less than 852 2^31. Window sizes MUST NOT be 0. 854 If no token window is issued, the proxy MUST silently ignore the 855 Token Request. 857 8.4.2. Spending a token 859 The client can attempt to spend a token by including a Token 860 Expenditure option in its SOCKS request: 862 +---------------+------+-------+ 863 | Kind | Length | Type | Token | 864 +------+--------+------+-------+ 865 | 1 | 1 | 1 | 4 | 866 +------+--------+------+-------+ 868 Figure 16: Token Expenditure 870 o Kind: 0x04 (Idempotence option) 872 o Length: 7 874 o Type: 0x02 (Token Expenditure) 876 o Token: The token being spent. 878 Clients SHOULD prioritize spending the smaller tokens. 880 The server responds by sending a Token Expenditure Reply option as 881 part of the Operation Reply: 883 +---------------+------+---------------+ 884 | Kind | Length | Type | Response Code | 885 +------+--------+------+---------------+ 886 | 1 | 1 | 1 | 1 | 887 +------+--------+------+---------------+ 889 Figure 17: Token Expenditure Response 891 o Kind: 0x04 (Idempotence option) 893 o Length: 4 895 o Type: 0x03 (Token Expenditure Response) 897 o Response Code: 899 * 0x01: Success: The token was spent successfully. 901 * 0x02: No Window: The proxy does not have a token window 902 associated with the client. 904 * 0x03: Out of Window: The token is not within the window. 906 * 0x04: Duplicate: The token has already been spent. 908 If eligible, the token is spent as soon as the client authenticates. 909 If the token is not eligible for spending, the proxy MUST NOT attempt 910 to honor the client's SOCKS Request; further, it MUST indicate a 911 General SOCKS server failure in the Operation Reply. 913 Proxy implementations SHOULD also send a Token Window Advertisement 914 if: 916 o the token is out of window, or 918 o by the proxy's internal logic, successfully spending the token 919 caused the window to shift. 921 Proxy implementations SHOULD NOT shift the window's base beyond the 922 highest unspent token. 924 Proxy implementations MAY include a Token Window Advertisement in any 925 Authentication Reply that indicates success. 927 8.4.3. Handling Token Window Advertisements 929 Even though the proxy increases the window's base monotonically, 930 there is no mechanism whereby a SOCKS client can receive the Token 931 Window Advertisements in order. As such, clients SHOULD disregard 932 unsollicited Token Window Advertisements with a Window Base less than 933 the previously known value. 935 9. Username/Password Authentication 937 Username/Password authentication is carried out as in [RFC1929]. 939 Clients can also attempt to authenticate by placing the Username/ 940 Password request in an Authentication Data Option, provided that it 941 is no longer than 252 bytes. 943 +---------------+--------+---------------------------+ 944 | Kind | Length | Method | Username/Password request | 945 +------+--------+--------+---------------------------+ 946 | 1 | 1 | 1 | Variable | 947 +------+--------+--------+---------------------------+ 949 Figure 18: Password authentication via a SOCKS Option 951 o Kind: MUST be allocated by IANA. (See Section 12.) 953 o Length: The length of the option. 955 o Method: 0x02 (Username/Password). 957 o Username/Password request: The Username/Password request, as 958 described in [RFC1929]. 960 10. TCP Fast Open on the Client-Proxy Leg 962 TFO breaks TCP semantics, causing replays of the data in the SYN's 963 payload under certain rare circumstances [RFC7413]. A replayed SOCKS 964 Request could itself result in a replayed connection on behalf of the 965 client. 967 As such, client implementations SHOULD NOT use TFO on the client- 968 proxy leg unless: * The protocol running on top of SOCKS tolerates 969 the risks of TFO, or * The SYN's payload does not contain any 970 application data (so that no data is replayed to the server, even 971 though duplicate connections are still possible), or * The client 972 uses Idempotence Options, making replays impossible, or * SOCKS is 973 running on top of TLS and Early Data is not used. 975 11. Security Considerations 977 11.1. Large requests 979 Given the format of the request message, a malicious client could 980 craft a request that is in excess of 100 KB and proxies could be 981 prone to DDoS attacks. 983 To mitigate such attacks, proxy implementations SHOULD be able to 984 incrementally parse the requests. Proxies MAY close the connection 985 to the client if: 987 o the request is not fully received after a certain timeout, or 989 o the number of options exceeds an imposed hard cap, or 991 o the total size of the options exceeds an imposed hard cap, or 993 o the size of the initial data excedes a hard cap. 995 Further, the server MAY choose not to buffer any initial data beyond 996 what would be expected to fit in a TFO SYN's payload. 998 11.2. Replay attacks 1000 In TLS 1.3, early data (which is likely to contain a full SOCKS 1001 request) is prone to replay attacks. 1003 While Token Expenditure options can be used to mitigate replay 1004 attacks, the initial Token Request is still vulnerable. As such, 1005 client implementations SHOULD NOT make use of TLS early data when 1006 sending a Token Request. 1008 12. IANA Considerations 1010 This document requests that IANA allocate 1-byte option kinds for 1011 SOCKS 6 options. Further, this document requests the following 1012 option kinds: 1014 o Stack options: 0x01 1016 o Authentication Method options: 0x02 1018 o Authentication Data options: 0x03 1020 o Idempotence options: 0x04 1022 o A range for vendor-specific options 1023 This document also requests that IANA allocate a port for SOCKS over 1024 TLS. 1026 13. Acknowledgements 1028 The protocol described in this draft builds upon and is a direct 1029 continuation of SOCKS 5 [RFC1928]. 1031 14. References 1033 14.1. Normative References 1035 [RFC1929] Leech, M., "Username/Password Authentication for SOCKS 1036 V5", RFC 1929, DOI 10.17487/RFC1929, March 1996, 1037 . 1039 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1040 Requirement Levels", BCP 14, RFC 2119, 1041 DOI 10.17487/RFC2119, March 1997, 1042 . 1044 14.2. Informative References 1046 [I-D.ietf-tls-tls13] 1047 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1048 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 1049 March 2018. 1051 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 1052 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 1053 DOI 10.17487/RFC1928, March 1996, 1054 . 1056 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1057 "TCP Extensions for Multipath Operation with Multiple 1058 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1059 . 1061 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1062 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1063 . 1065 Authors' Addresses 1067 Vladimir Olteanu 1068 University Politehnica of Bucharest 1070 Email: vladimir.olteanu@cs.pub.ro 1071 Dragos Niculescu 1072 University Politehnica of Bucharest 1074 Email: dragos.niculescu@cs.pub.ro