idnits 2.17.1 draft-olteanu-intarea-socks-6-02.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 (March 05, 2018) is 2244 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-26 -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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: September 6, 2018 March 05, 2018 7 SOCKS Protocol Version 6 8 draft-olteanu-intarea-socks-6-02 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 September 6, 2018. 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 . . . . . . . . . . . . . . . . . . . . 5 59 3. Mode of operation . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Connection Requests . . . . . . . . . . . . . . . . . . . . . 6 61 5. Version Mismatch Replies . . . . . . . . . . . . . . . . . . 7 62 6. Authentication Replies . . . . . . . . . . . . . . . . . . . 8 63 7. Operation Replies . . . . . . . . . . . . . . . . . . . . . . 9 64 7.1. Handling CONNECT . . . . . . . . . . . . . . . . . . . . 10 65 7.2. Handling BIND . . . . . . . . . . . . . . . . . . . . . . 11 66 7.3. Handling UDP ASSOCIATE . . . . . . . . . . . . . . . . . 11 67 8. SOCKS Options . . . . . . . . . . . . . . . . . . . . . . . . 11 68 8.1. Socket options . . . . . . . . . . . . . . . . . . . . . 11 69 8.1.1. TFO options . . . . . . . . . . . . . . . . . . . . . 12 70 8.1.2. Multipath TCP options . . . . . . . . . . . . . . . . 13 71 8.1.3. MPTCP Scheduler options . . . . . . . . . . . . . . . 14 72 8.2. Authentication Method options . . . . . . . . . . . . . . 14 73 8.3. Authentication Data options . . . . . . . . . . . . . . . 15 74 8.4. Idempotence options . . . . . . . . . . . . . . . . . . . 16 75 8.4.1. Requesting a fresh token window . . . . . . . . . . . 17 76 8.4.2. Spending a token . . . . . . . . . . . . . . . . . . 18 77 8.4.3. Handling Token Window Advertisements . . . . . . . . 19 78 8.5. Salt options . . . . . . . . . . . . . . . . . . . . . . 19 79 9. Username/Password Authentication . . . . . . . . . . . . . . 20 80 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 81 10.1. Large requests . . . . . . . . . . . . . . . . . . . . . 20 82 10.2. Replay attacks . . . . . . . . . . . . . . . . . . . . . 21 83 10.3. Identical request profiling . . . . . . . . . . . . . . 21 84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 85 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 86 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 13.1. Normative References . . . . . . . . . . . . . . . . . . 22 88 13.2. Informative References . . . . . . . . . . . . . . . . . 22 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 91 1. Introduction 93 Versions 4 and 5 [RFC1928] of the SOCKS protocol were developed two 94 decades ago and are in widespread use for circuit level gateways or 95 as circumvention tools, and enjoy wide support and usage from various 96 software, such as web browsers, SSH clients, and proxifiers. 98 However, their design needs an update in order to take advantage of 99 the new features of transport protocols, such as TCP Fast Open 100 [RFC7413], or to better assist newer transport protocols, such as 101 MPTCP [RFC6824]. 103 One of the main issues faced by SOCKS version 5 is that, when taking 104 into account the TCP handshake, method negotiation, authentication, 105 connection request and grant, it may take up to 5 RTTs for a data 106 exchange to take place at the application layer. This is especially 107 costly in networks with a large delay at the access layer, such as 108 3G, 4G, or satelite. 110 The desire to reduce the number of RTTs manifests itself in the 111 design of newer security protocols. TLS version 1.3 112 [I-D.ietf-tls-tls13] defines a zero round trip (0-RTT) handshake mode 113 for connections if the client and server had previously communicated. 115 TCP Fast Open [RFC7413] is a TCP option that allows TCP to send data 116 in the SYN and receive a response in the first ACK, and aims at 117 obtaining a data response in one RTT. The SOCKS protocol needs to 118 concern itself with at least two TFO deployment scenarios: First, 119 when TFO is available end-to-end (at the client, at the proxy, and at 120 the server); second, when TFO is active between the client and the 121 proxy, but not at the server. 123 This document describes the SOCKS protocol version 6. The key 124 improvements over SOCKS version 5 are: 126 o The client sends as much information upfront as possible, and does 127 not wait for the authentication process to conclude before 128 requesting the creation of a socket. 130 o The connection request also mimics the semantics of TCP Fast Open 131 [RFC7413]. As part of the connection request, the client can 132 supply the potential payload for the initial SYN that is sent out 133 to the server. 135 o The protocol can be extended via options without breaking 136 backward-compatibility. 138 o The protocol can leverage the aforementioned options to support 139 0-RTT authentication schemes. 141 1.1. Revision log 143 Typos and minor clarifications are not listed. 145 draft-02 146 o Made support for Idempotence options mandatory for proxies. 148 o Clarified what happens when proxies can not or will not issue 149 tokens. 151 o Limited token windows to 2^31 - 1. 153 o Fixed definition of "less than" for tokens. 155 o NOOP commands now trigger Operation Replies. 157 o Renamed Authentication options to Authentication Data options. 159 o Authentication Data options are no longer mandatory. 161 o Authentication methods are now advertised via options. 163 o Shifted some Request fields. 165 o Option range for vendor-specific options. 167 o Socket options. 169 o Password authentication. 171 o Salt options. 173 draft-01 175 o Added this section. 177 o Support for idempotent commands. 179 o Removed version numbers from operation replies. 181 o Request port number for SOCKS over TLS. Deprecate encryption/ 182 encapsulation within SOCKS. 184 o Added Version Mismatch Replies. 186 o Renamed the AUTH command to NOOP. 188 o Shifted some fields to make requests and operation replies easier 189 to parse. 191 2. Requirements language 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in [RFC2119]. 197 3. Mode of operation 199 CLIENT PROXY 201 +------------------------+ 202 | Authentication methods | Request 203 --------> Command code +------------------------------> 204 | Address | 205 | Port | 206 | Options | 207 | Initial data | 208 +------------------------+ 210 +-----------------------+ 211 Authentication reply | Type | 212 <----------------------------------+ Method <----- 213 | Options | 214 +-----------------------+ 216 <-------------------(Authentication protocol)------------------> 218 +-----------------------+ 219 Operation reply | Reply code | 220 <--------------------+ Bind address <------------------ 221 | Bind port | 222 | Options | 223 | Initial data offset | 224 +-----------------------+ 226 Figure 1: The SOCKS version 6 protocol message exchange 228 When a TCP-based client wishes to establish a connection to a server, 229 it must open a TCP connection to the appropriate SOCKS port on the 230 SOCKS proxy. The client then enters a negotiation phase, by sending 231 the request in figure Figure 1, that contains, in addition to fields 232 present in SOCKS 5 [RFC1928], fields that facilitate low RTT usage 233 and faster authentication negotiation. 235 Next, the server sends an authentication reply. If the request did 236 not contain the necessary authentication information, the proxy 237 indicates an authentication method that must proceed. This may 238 trigger a longer authentication sequence that could include tokens 239 for ulterior faster authentications. The part labeled 240 "Authentication protocol" is specific to the authentication method 241 employed and is not expected to be employed for every connection 242 between a client and its proxy server. The authentication protocol 243 typically takes up 1 RTT or more. 245 If the authentication is successful, an operation reply is generated 246 by the proxy. It indicates whether the proxy was successful in 247 creating the requested socket or not. 249 In the fast case, when authentication is properly set up, the proxy 250 attempts to create the socket immediately after the receipt of the 251 request, thus achieving an operational conection in one RTT (provided 252 TFO functionality is available at the client, proxy, and server). 254 4. Connection Requests 256 The client starts by sending a request to the proxy. 258 +---------------+---------+------+---------+----------+ 259 | Version | Command | Port | Address | Address | 260 | Major | Minor | Code | | Type | | 261 +-------+-------+---------+------+---------+----------+ 262 | 1 | 1 | 1 | 2 | 1 | Variable | 263 +-------+-------+---------+------+---------+----------+ 264 +-----------+----------+--------------+--------------+ 265 | Number of | Options | Initial Data | Initial Data | 266 | Options | | Size | | 267 +-----------+----------+--------------+--------------+ 268 | 1 | Variable | 2 | Variable | 269 +-----------+----------+--------------+--------------+ 271 Figure 2: SOCKS 6 Request 273 o Version: The major byte MUST be set to 0x06, and the minor byte 274 MUST be set to 0x00. 276 o Command Code: 278 * 0x00 NOOP: authenticate the client and do nothing. 280 * 0x01 CONNECT: requests the establishment of a TCP connection. 282 * 0x02 BIND: requests the establishment of a TCP port binding. 284 * 0x03 UDP ASSOCIATE: requests a UDP port association. 286 o Address Type: 288 * 0x01: IPv4 290 * 0x03: Domain Name 292 * 0x04: IPv6 294 o Address: this field's format depends on the address type: 296 * IPv4: a 4-byte IPv4 address 298 * Domain Name: one byte that contains the length of the FQDN, 299 followed by the FQDN itself. The string is not NUL-terminated. 301 * IPv6: a 16-byte IPv6 address 303 o Port: the port in network byte order. 305 o Number of Options: the number of SOCKS options that appear in the 306 Options field. 308 o Options: see Section 8. 310 o Initial Data Size: A two-byte number in network byte order. In 311 case of NOOP, BIND or UDP ASSOCIATE, this field MUST be set to 0. 312 In case of CONNECT, this is the number of bytes of initial data 313 that are supplied in the following field. 315 o Initial Data: The first octets of the data stream. 317 Clients can advertise their supported authentication methods by 318 including an Authentication Method option (see Section 8.2). 320 The server MAY truncate the initial data to an arbitrary size and 321 disregard the rest. This is will be communicated later to the 322 client, should the authentication process be successful (see 323 Section 7). As such, server implementations do not have to buffer 324 the initial data while waiting for the (potentially malicious) client 325 to authenticate. 327 5. Version Mismatch Replies 329 Upon receipt of a request starting with a version number other than 330 6.0, the proxy sends the following response: 332 +---------------+ 333 | Version | 334 | Major | Minor | 335 +-------+-------+ 336 | 1 | 1 | 337 +-------+-------+ 339 Figure 3: SOCKS 6 Version Mismatch Reply 341 o Version: The major byte MUST be set to 0x06, and the minor byte 342 MUST be set to 0x00. 344 A client MUST close the connection after receiving such a reply. 346 6. Authentication Replies 348 Upon receipt of a valid request, the proxy sends an Authentication 349 Reply: 351 +---------------+------+--------+-----------+----------+ 352 | Version | Type | Method | Number of | Options | 353 | Major | Minor | | | Options | | 354 +-------+-------+------+--------+-----------+----------+ 355 | 1 | 1 | 1 | 1 | 1 | Variable | 356 +-------+-------+------+--------+-----------+----------+ 358 Figure 4: SOCKS 6 Authentication Reply 360 o Version: The major byte MUST be set to 0x06, and the minor byte 361 MUST be set to 0x00. 363 o Type: 365 * 0x00: authentication successful. 367 * 0x01: further authentication needed. 369 o Method: The chosen authentication method. 371 o Number of Options: the number of SOCKS options that appear in the 372 Options field. 374 o Options: see Section 8. 376 Multihomed clients SHOULD cache the chosen method on a per-interface 377 basis and SHOULD NOT include Authentication Data options related to 378 any other methods in further requests originating from the same 379 interface. 381 If the server signals that further authentication is needed and 382 selects "No Acceptable Methods", the client MUST close the 383 connection. 385 The client and proxy begin a method-specific negotiation. During 386 such negotiations, the proxy MAY supply information that allows the 387 client to authenticate a future request using an Authentication Data 388 option. The client and proxy SHOULD NOT negotiate the encryption of 389 the application data. Descriptions of such negotiations are beyond 390 the scope of this memo. 392 7. Operation Replies 394 After the authentication negotiations are complete, the server sends 395 an Operation Reply: 397 +-------+---------+------+----------+--------------+ 398 | Reply | Address | Bind | Bind | Initial Data | 399 | Code | Type | Port | Address | Offset | 400 +-------+---------+------+----------+--------------+ 401 | 1 | 1 | 2 | Variable | 2 | 402 +-------+---------+------+----------+--------------+ 403 +-----------+----------+ 404 | Number of | Options | 405 | Options | | 406 +-----------+----------+ 407 | 1 | Variable | 408 +-----------+----------+ 410 Figure 5: SOCKS 6 Operation Reply 412 o Reply Code: 414 * 0x00: Succes 416 * 0x01: General SOCKS server failure 418 * 0x02: Connection not allowed by ruleset 420 * 0x03: Network unreachable 422 * 0x04: Host unreachable 424 * 0x05: Connection refused 425 * 0x06: TTL expired 427 * 0x07: Command not supported 429 * 0x08: Address type not supported 431 o Address Type: 433 * 0x01: IPv4 435 * 0x03: Domain Name 437 * 0x04: IPv6 439 o Bind Address: the proxy bound address in the following format: 441 * IPv4: a 4-byte IPv4 address 443 * Domain Name: one byte that contains the length of the FQDN, 444 followed by the FQDN itself. The string is not NUL-terminated. 446 * IPv6: a 16-byte IPv6 address 448 o Bind Port: the proxy bound port in network byte order. 450 o Number of Options: the number of SOCKS options that appear in the 451 Options field. 453 o Options: see Section 8. 455 o Initial Data Offset: A two-byte number in network byte order. In 456 case of BIND or UDP ASSOCIATE, this field MUST be set to 0. In 457 case of CONNECT, it represents the offset in the plain data stream 458 from which the client is expected to continue sending data. 460 If the proxy returns a reply code other than "Success", the client 461 MUST close the connection. 463 If the client issued an NOOP command, the client MUST close the 464 connection after receiving the Operation Reply. 466 7.1. Handling CONNECT 468 In case the client has issued a CONNECT request, data can now pass. 469 The client MUST resume the data stream at the offset indicated by the 470 Initial Data Offset field. 472 7.2. Handling BIND 474 In case the client has issued a BIND request, it must wait for a 475 second Operation reply from the proxy, which signifies that a host 476 has connected to the bound port. The Bind Address and Bind Port 477 fields contain the address and port of the connecting host. 478 Afterwards, application data may pass. 480 7.3. Handling UDP ASSOCIATE 482 The relay of UDP packets is handled exactly as in SOCKS 5 [RFC1928]. 484 8. SOCKS Options 486 SOCKS options have the following format: 488 +---------------+-------------+ 489 | Kind | Length | Option Data | 490 +------+--------+-------------+ 491 | 1 | 1 | Variable | 492 +------+--------+-------------+ 494 Figure 6: SOCKS 6 Option 496 o Kind: MUST be allocated by IANA. (See Section 11.) 498 o Length: The length of the option. 500 o Option Data: The contents are specific to each option kind. 502 8.1. Socket options 504 Socket options are be used by clients to alter the behavior of the 505 sockets created by the proxy. A socket option can affect either the 506 proxy's socket on the client-proxy leg or on the proxy-server leg. 507 Clients can only place Socket options inside SOCKS Requests. 509 Proxies MAY include Socket options in their Operation Replies to 510 signal their sockets' behavior. Said options MAY be unsolicited, i. 511 e. the proxy MAY send them to signal behaviour that was not 512 explicitly requested by the client. 514 +---------------+--------+--------+------+----------+ 515 | Kind | Length | Leg | Level | Code | Data | 516 +------+--------+--------+--------+------+----------+ 517 | 1 | 1 | 2 bits | 6 bits | 1 | Variable | 518 +------+--------+--------+--------+------+----------+ 520 Figure 7: Socket Option 522 o Kind: MUST be allocated by IANA. (See Section 11.) 524 o Length: The length of the option. 526 o Leg: 528 * 0x1: Client-Proxy Leg 530 * 0x2: Proxy-Server Leg 532 * 0x3: Both Legs 534 o Level: 536 * 0x01: Socket 538 * 0x02: IPv4 540 * 0x03: IPv6 542 * 0x04: TCP 544 * 0x05: UDP 546 o Code: Option code 548 o Data: Option-specific data 550 8.1.1. TFO options 552 +---------------+--------+--------+------+ 553 | Kind | Length | Leg | Level | Code | 554 +------+--------+--------+--------+------+ 555 | 1 | 1 | 2 bits | 6 bits | 1 | 556 +------+--------+--------+--------+------+ 558 Figure 8: TFO Option 560 o Kind: MUST be allocated by IANA. (See Section 11.) 562 o Length: MUST be 4. 564 o Leg: MUST be 0x2 (Proxy-Server Leg). 566 o Level: 0x04 (TCP). 568 o Code: 0x17 570 If a SOCKS Request contains a TFO option, the proxy SHOULD attempt to 571 use TFO in case of a CONNECT command, or accept TFO in case of a BIND 572 command. Otherwise, the proxy MUST NOT attempt to use TFO in case of 573 a CONNECT command, or accept TFO in case of a BIND command. 575 In case of a CONNECT command, the proxy MAY include a TFO option in 576 the Operation reply if TFO was attempted, the operation succeded and 577 the remote server supports TFO. In case of a BIND command, the proxy 578 MAY include a TFO option in the first Operation reply to signal that 579 it will accept an incoming TFO connection. 581 8.1.2. Multipath TCP options 583 In case of a CONNECT command, the proxy can inform the client that 584 the connection to the server is an MPTCP connection. 586 +---------------+--------+--------+------+ 587 | Kind | Length | Leg | Level | Code | 588 +------+--------+--------+--------+------+ 589 | 1 | 1 | 2 bits | 6 bits | 1 | 590 +------+--------+--------+--------+------+ 592 Figure 9: Multipath TCP Option 594 o Kind: MUST be allocated by IANA. (See Section 11.) 596 o Length: 4. 598 o Leg: MUST be 0x2 (Proxy-Server Leg). 600 o Level: 0x04 (TCP). 602 o Code: 0x2a 604 8.1.3. MPTCP Scheduler options 606 In case of a CONNECT or BIND command, a client can use an MPTCP 607 Scheduler option to indicate its preferred scheduler for the 608 connection. 610 A proxy can use an MPTCP Scheduler option to inform the client about 611 what scheduler is in use. 613 +---------------+--------+--------+------+-----------+ 614 | Kind | Length | Leg | Level | Code | Scheduler | 615 +------+--------+--------+--------+------+-----------+ 616 | 1 | 1 | 2 bits | 6 bits | 1 | 1 | 617 +------+--------+--------+--------+------+-----------+ 619 Figure 10: MPTCP Scheduler Option 621 o Kind: MUST be allocated by IANA. (See Section 11.) 623 o Length: MUST be 5. 625 o Leg: Either 0x01, 0x02, or 0x03 (Client-Proxy, Proxy-Client or 626 Both legs). 628 o Level: 0x04 (TCP). 630 o Code: 0x2b 632 o Scheduler: 634 * 0x00: Default 636 * 0x01: Round-Robin 638 * 0x02: Redundant 640 8.2. Authentication Method options 642 Authentication Method options are used by clients to advertise 643 supported authentication methods. They can be part of SOCKS 644 Requests. 646 +---------------+----------+ 647 | Kind | Length | Methods | 648 +------+--------+----------+ 649 | 1 | 1 | Variable | 650 +------+--------+----------+ 652 Figure 11: Authentication Method Option 654 o Kind: MUST be allocated by IANA. (See Section 11.) 656 o Length: The length of the option. 658 o Methods: One byte per advertised method. Method numbers are 659 assigned by IANA. 661 Clients MUST support the "No authentication required" method. 662 Clients MAY omit advertising the "No authentication required" option. 664 8.3. Authentication Data options 666 Authentication Data options carry method-specific authentication 667 data. They can be part of SOCKS Requests and Authentication Replies. 669 Authentication Data options have the following format: 671 +---------------+--------+---------------------+ 672 | Kind | Length | Method | Authentication Data | 673 +------+--------+--------+---------------------+ 674 | 1 | 1 | 1 | Variable | 675 +------+--------+--------+---------------------+ 677 Figure 12: Authentication Data Option 679 o Kind: MUST be allocated by IANA. (See Section 11.) 681 o Length: The length of the option. 683 o Method: The number of the authentication method. These numbers 684 are assigned by IANA. 686 o Authentication Data: The contents are specific to each method. 688 Clients MAY omit advertising authentication methods for which they 689 have included at least an Authentication Data option. 691 8.4. Idempotence options 693 To protect against duplicate SOCKS Requests, authenticated clients 694 can request, and then spend, idempotence tokens. A token can only be 695 spent on a single SOCKS request. 697 Tokens are 4-byte unsigned integers in a modular 4-byte space. 698 Therefore, if x and y are tokens, x is less than y if 0 < (y - x) < 699 2^31 in unsigned 32-bit arithmetic. 701 Proxies grant contiguous ranges of tokens called token windows. 702 Token windows are defined by their base (the first token in the 703 range) and size. Windows can be shifted (i. e. have their base 704 increased, while retaining their size) unilaterally by the proxy. 706 Requesting and spending tokens is done via Idempotence options: 708 +---------------+------+-------------+ 709 | Kind | Length | Type | Option Data | 710 +------+--------+------+-------------+ 711 | 1 | 1 | 1 | Variable | 712 +------+--------+------+-------------+ 714 Figure 13: Idempotence Option 716 o Kind: MUST be allocated by IANA. (See Section 11.) 718 o Length: The length of the option. 720 o Type: 722 * 0x00: Token Request 724 * 0x01: Token Window Advertisement 726 * 0x02: Token Expenditure 728 * 0x03: Token Expenditure Reply 730 o Option Data: The contents are specific to each type. 732 All proxy implementations MUST support Idempotetence options, even if 733 they do not issue token windows. 735 8.4.1. Requesting a fresh token window 737 A client can obtain a fresh window of tokens by sending a Token 738 Request option as part of a SOCKS Request: 740 +---------------+------+-------------+ 741 | Kind | Length | Type | Window Size | 742 +------+--------+------+-------------+ 743 | 1 | 1 | 1 | 4 | 744 +------+--------+------+-------------+ 746 Figure 14: Token Request 748 o Kind: MUST be allocated by IANA. (See Section 11.) 750 o Length: 7 752 o Type: 0x00 (Token Request) 754 o Window Size: The requested window size. 756 If a token window is issued, the proxy then includes a Token Window 757 Advertisement option in the corresponding Operation Reply: 759 +---------------+------+-------------+-------------+ 760 | Kind | Length | Type | Window Base | Window Size | 761 +------+--------+------+-------------+-------------+ 762 | 1 | 1 | 1 | 4 | 4 | 763 +------+--------+------+-------------+-------------+ 765 Figure 15: Token Window Advertisement 767 o Kind: MUST be allocated by IANA. (See Section 11.) 769 o Length: 11 771 o Type: 0x01 (Token Grant) 773 o Window Base: The first token in the window. 775 o Window Size: The window size. This value SHOULD be lower or equal 776 to the requested window size. Window sizes MUST be less than 777 2^31. 779 If no token window is issued, the proxy MUST silently ignore the 780 Token Request. 782 8.4.2. Spending a token 784 The client can attempt to spend a token by including a Token 785 Expenditure option in its SOCKS request: 787 +---------------+------+-------+ 788 | Kind | Length | Type | Token | 789 +------+--------+------+-------+ 790 | 1 | 1 | 1 | 4 | 791 +------+--------+------+-------+ 793 Figure 16: Token Expenditure 795 o Kind: MUST be allocated by IANA. (See Section 11.) 797 o Length: 7 799 o Type: 0x02 (Token Expenditure) 801 o Token: The token being spent. 803 Clients SHOULD prioritize spending the smaller tokens. 805 The server responds by sending a Token Expenditure Reply option as 806 part of the Operation Reply: 808 +---------------+------+---------------+ 809 | Kind | Length | Type | Response Code | 810 +------+--------+------+---------------+ 811 | 1 | 1 | 1 | 1 | 812 +------+--------+------+---------------+ 814 Figure 17: Token Expenditure Response 816 o Kind: MUST be allocated by IANA. (See Section 11.) 818 o Length: 4 820 o Type: 0x03 (Token Expenditure Response) 822 o Response Code: 824 * 0x00: Success: The token was spent successfully. 826 * 0x01: No Window: The proxy does not have a token window 827 associated with the client. 829 * 0x02: Out of Window: The token is not within the window. 831 * 0x03: Duplicate: The token has already been spent. 833 If eligible, the token is spent as soon as the client authenticates. 834 If the token is not eligible for spending, the proxy MUST NOT attempt 835 to honor the client's SOCKS Request; further, it MUST indicate a 836 General SOCKS server failure in the Operation Reply. 838 Proxy implementations SHOULD also send a Token Window Advertisement 839 if: 841 o the token is out of window, or 843 o by the proxy's internal logic, successfully spending the token 844 caused the window to shift. 846 Proxy implementations SHOULD NOT shift the window's base beyond the 847 highest unspent token. 849 Proxy implementations MAY include a Token Window Advertisement in any 850 Operation Reply. 852 8.4.3. Handling Token Window Advertisements 854 Even though the proxy increases the window's base monotonically, 855 there is no mechanism whereby a SOCKS client can receive the Token 856 Window Advertisements in order. As such, clients SHOULD disregard 857 unsollicited Token Window Advertisements with a Window Base less than 858 the previously known value. 860 8.5. Salt options 862 Clients can use Salt options so that otherwise identical requests are 863 unique. (See Section 10.3.) 865 +---------------+------+ 866 | Kind | Length | Salt | 867 +------+--------+------+ 868 | 1 | 1 | 4 | 869 +------+--------+------+ 871 Figure 18: Salt Option 873 o Kind: MUST be allocated by IANA. (See Section 11.) 875 o Length: 6 876 o Salt: An arbitrary value. 878 Proxies MUST silently ignore Salt options. 880 9. Username/Password Authentication 882 Username/Password authentication is carried out as in [RFC1929]. 884 Clients can also attempt to authenticate by placing the Username/ 885 Password request in an Authentication Data Option, provided that it 886 is no longer than 252 bytes. 888 +---------------+--------+---------------------------+ 889 | Kind | Length | Method | Username/Password request | 890 +------+--------+--------+---------------------------+ 891 | 1 | 1 | 1 | Variable | 892 +------+--------+--------+---------------------------+ 894 Figure 19: Password authentication via a SOCKS Option 896 o Kind: MUST be allocated by IANA. (See Section 11.) 898 o Length: The length of the option. 900 o Method: 0x02 (Username/Password). 902 o Username/Password request: The Username/Password request, as 903 described in [RFC1929]. 905 10. Security Considerations 907 10.1. Large requests 909 Given the format of the request message, a malicious client could 910 craft a request that is in excess of 100 KB and proxies could be 911 prone to DDoS attacks. 913 To mitigate such attacks, proxy implementations SHOULD be able to 914 incrementally parse the requests. Proxies MAY close the connection 915 to the client if: 917 o the request is not fully received after a certain timeout, or 919 o the number of options exceeds an imposed hard cap, or 921 o the total size of the options exceeds an imposed hard cap, or 922 o the size of the initial data excedes a hard cap. 924 Further, the server MAY choose not to buffer any initial data beyond 925 what would be expected to fit in a TFO SYN's payload. 927 10.2. Replay attacks 929 In TLS 1.3, early data (which is likely to contain a full SOCKS 930 request) is prone to replay attacks. 932 While Token Expenditure options can be used to mitigate replay 933 attacks, the initial Token Request is still vulnerable. As such, 934 client implementations SHOULD NOT make use of TLS early data when 935 sending a Token Request. 937 10.3. Identical request profiling 939 If sent via TLS early data, identical SOCKS requests can also be 940 identical on the wire. An attacker with the capability to capture a 941 client's SOCKS traffic can attempt to profile it by identifying 942 identical requests. 944 A client can use Salt options to make all of its requests unique. 946 11. IANA Considerations 948 This document requests that IANA allocate 1-byte option codes for 949 SOCKS 6 options. Further, this document requests option codes for: 951 o Socket options 953 o Authentication Method options 955 o Authentication Data options 957 o Idempotence options 959 o Salt options 961 o Vendor-specific options 963 This document also requests that IANA allocate a port for SOCKS over 964 TLS. 966 12. Acknowledgements 968 The protocol described in this draft builds upon and is a direct 969 continuation of SOCKS 5 [RFC1928]. 971 13. References 973 13.1. Normative References 975 [RFC1929] Leech, M., "Username/Password Authentication for SOCKS 976 V5", RFC 1929, DOI 10.17487/RFC1929, March 1996, 977 . 979 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 980 Requirement Levels", BCP 14, RFC 2119, 981 DOI 10.17487/RFC2119, March 1997, 982 . 984 13.2. Informative References 986 [I-D.ietf-tls-tls13] 987 Rescorla, E., "The Transport Layer Security (TLS) Protocol 988 Version 1.3", draft-ietf-tls-tls13-26 (work in progress), 989 March 2018. 991 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 992 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 993 DOI 10.17487/RFC1928, March 1996, 994 . 996 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 997 "TCP Extensions for Multipath Operation with Multiple 998 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 999 . 1001 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1002 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1003 . 1005 Authors' Addresses 1007 Vladimir Olteanu 1008 University Politehnica of Bucharest 1010 Email: vladimir.olteanu@cs.pub.ro 1011 Dragos Niculescu 1012 University Politehnica of Bucharest 1014 Email: dragos.niculescu@cs.pub.ro