idnits 2.17.1 draft-ietf-ftpext-data-connection-assurance-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (May 2002) is 8014 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: 'RFC1123' is defined on line 627, but no explicit reference was found in the text == Unused Reference: 'IANA' is defined on line 717, but no explicit reference was found in the text == Unused Reference: 'RFC952' is defined on line 738, but no explicit reference was found in the text == Unused Reference: 'RFC2373' is defined on line 741, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1700 (Obsoleted by RFC 3232) -- Obsolete informational reference (is this intentional?): RFC 2373 (Obsoleted by RFC 3513) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FTPEXT Working Group G. Lundberg 3 Internet-Draft WU-FTPD Development Group 4 Expiration Date: November 28, 2002 May 2002 6 FTP Data Connection Assurance 7 draft-ietf-ftpext-data-connection-assurance-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents 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 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 To view the list of IETF Internet-Draft Mirror Sites, see 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2002). All Rights Reserved. 34 Abstract 36 This document specifies an extension to the File Transfer Protocol 37 (FTP) by which a user and server can exchange data port connection 38 information which may then be used to provide connection assurance. 40 Two new commands are introduced. Through use of these commands and 41 their replies, the user and server exchange information allowing 42 verification of the socket addresses for a data connection prior to 43 actual data transmission over the connection. 45 Implementation of this extension is RECOMMENDED. 47 Table of Contents 49 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. ACTIVE ESTABLISH (ESTA) . . . . . . . . . . . . . . . . . . . 5 52 3. PASSIVE ESTABLISH (ESTP) . . . . . . . . . . . . . . . . . . . 8 53 4. Connection Management . . . . . . . . . . . . . . . . . . . . 11 54 5. FEAT Response . . . . . . . . . . . . . . . . . . . . . . . . 12 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 57 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 58 Normative References . . . . . . . . . . . . . . . . . . . . . 14 59 Informative References . . . . . . . . . . . . . . . . . . . . 14 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 61 Annex A - Address Family Numbers . . . . . . . . . . . . . . . 16 62 Annex B - Network Address Formats . . . . . . . . . . . . . . 16 63 Annex C - Examples of Use . . . . . . . . . . . . . . . . . . 16 64 C.1 PORT Mode . . . . . . . . . . . . . . . . . . . . . . . 17 65 C.2 PASV Mode . . . . . . . . . . . . . . . . . . . . . . . 18 66 C.3 Server-to-Server Mode . . . . . . . . . . . . . . . . . 19 67 Annex D - Implementation Considerations . . . . . . . . . . . 21 68 D.1 Interactively Finding the Specified Connection . . . . 21 69 D.2 Automatically Finding the Specified Connection . . . . 22 70 D.3 Using a Common Passive Socket . . . . . . . . . . . . . 22 71 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 24 73 1. Introduction 75 The intention of this protocol extension is to address the security 76 issue involved with the problem of a race condition in the existing 77 File Transfer Protocol [DS, CERT2]. This condition allows an 78 attacker the ability to receive unauthorized transmissions from, or 79 transmit unauthorized information to, the passive party of a file 80 transfer. The attack makes use of the timing window between when the 81 passive socket is prepared and when an active connection to that 82 passive socket actually occurs. 84 The security industry identifier for this issue is CVE-1999-0351 85 [CVE]. 87 The problem is fairly well known within the FTP community and has 88 been discussed for some time [DS]. Since it does not pose a direct 89 threat to the security of hosts on the Internet, and generally 90 presents only limited inconvenience to users, little attention has 91 been paid to the issue. It is, however, a growing concern to a 92 number of private, corporate and governmental users who desire 93 assurance that their information is delivered only to the intended 94 recipients yet who are unwilling to sacrifice availability or inter- 95 operability by use of cryptographic methods [RFC2228, MURRAY]. The 96 fact that the FTP makes no attempt to prevent, or even provide a 97 means to detect, these events is unacceptable. 99 Several independent implementations of attacks making use of this 100 window are known to exist [KS, JG], and at least one event has been 101 claimed to have occurred against a vendor site to obtain unauthorized 102 copies of potentially proprietary information. To date, all known 103 attacks depend upon weaknesses in TCP implementations, but with the 104 relatively small number of TCP ports and advances in distributed 105 attack methods this condition cannot be expected to continue. 107 To fully understand the problem, and the solution presented, a basic 108 understanding of some features of the FTP is required. 110 The FTP model [RFC959] uses two communication channels: the data 111 connection is responsible for exchanging files and other data; the 112 control connection provides control and synchronization of the data 113 connection and transmissions over it. While the control connection 114 exists throughout the lifetime of an FTP session, data connections 115 are often transitory, existing only for the duration of a single file 116 transfer. 118 The FTP model is usually presented as two processes: the User-FTP 119 implementation and the Server-FTP implementation. Each of these 120 processes are further separated into the protocol interpreter (PI) 121 and the data transfer process (DTP). A Server-FTP always implements 122 both a PI and a DTP. The User-FTP, however, may implement only a PI; 123 using an external process as its DTP (as is the case, for example, in 124 a server-to-server transfer). 126 Existing FTP commands [RFC959, RFC1639, RFC2428] allow the user to 127 determine which end-point has responsibility for actively initiating 128 the data connection. The other end-point passively awaits this 129 connection. To cause the Server-DTP to operate in passive mode, the 130 user sends a PASV, LPSV or EPSV command, requesting the Server-DTP 131 create a passive socket and report the address assigned. To cause 132 the Server-DTP to operate in active mode, the user creates (or 133 obtains through other means) a passive socket and communicates its 134 address to the Server-FTP process through the PORT, LPRT or EPRT 135 commands. 137 The user actively initiates the data connection immediately prior to 138 issuing the data transfer command. (It may do so any time after 139 receipt of the reply to the PASV, LPSV or EPSV command, and must do 140 so prior to issuing the data transfer command.) The Server-FTP 141 process must initiate the data connection upon receipt of the data 142 transfer command and prior to issuing a reply to that command. 144 The delay involved, between the creation of the passive socket and 145 establishment of the data connection using it, presents a window 146 during which an attacker can actively establish a connection to the 147 passive socket. 149 Unfortunately, the FTP provides no means to assure that the active 150 socket is the one intended; the passive participant simply accepts 151 the first connection presented. While all parties have knowledge of 152 the address assigned to the passive socket, only the process actively 153 initiating the connection knows the address of the active socket. 154 Without some means of communicating this information to all parties, 155 there is insufficient information to judge whether the connection 156 originated from the intended participant. 158 The protocol presented is intended to provide just that: a means to 159 exchange active socket address information. 161 In the development of the protocol specified in this document, 162 several alternatives were considered. 164 The STAT command [RFC959] could be issued by the user to discover the 165 address of the active socket. The format of the reply to the STAT 166 command, however, is not well defined; to be usable, a consistent, 167 machine readable response is needed. Requiring the reply to the STAT 168 command to provide the necessary information in a usable fashion 169 would cause inter-operation problems with existing implementations, 170 and is only a partial solution since it does not address the needs of 171 the Server-FTP process when operating in passive mode. 173 Some existing Server-FTP implementations attempt to reduce the impact 174 of the problem by placing requirements upon which remote socket 175 addresses they will accept [GL]. These requirements violate the 176 spirit, if not the letter, of the FTP specifications, negatively 177 impacting its usability, and can raise complex configuration issues 178 for server administrators. In addition, these methods are only a 179 partial solution since they do not address the needs of the user. 181 [DS] suggests exchanging verification information over the control 182 and data connections, however doing so would prevent inter- 183 operability with existing implementations. Existing specifications 184 [RFC2228, MURRAY] can provide just such a solution but are not widely 185 deployed and, to assure connection integrity, do not inter-operate 186 with existing (non-cryptographic) implementations. 188 What is required is a solution which addresses the problem for all 189 parties, operates with little added overhead and minimal (optimally, 190 no) configuration requirements, does not break inter-operability with 191 existing implementations, and which is straightforward to deploy, 192 without the processing overhead and potential legal issues involved 193 with cryptographic methods. 195 The new commands presented here provide for the exchange the active 196 socket address between the user and the Server-FTP process. This 197 presents both parties (or, in the case of server-to-server transfers, 198 all three parties) with the information necessary to evaluate the 199 connection end-points prior to commencing transmission. 201 When reading the following specifications, the key words "MUST", 202 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 203 "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 204 described in RFC 2119 [RFC2119]. 206 2. ACTIVE ESTABLISH (ESTA) 208 The user should issue the ESTA command before issuing any other data 209 transfer command when the Server-DTP is in active mode and a usable 210 data connection is not already present. 212 This command instructs the Server-DTP to immediately establish a 213 connection from its data port to the currently selected passive 214 address, and to report back to the user the address information for 215 the active socket actually used on the new connection. 217 The active socket on the connection is the local address. In 218 [POSIX], for example, this is the value returned via the getsockname 219 function; which may differ from the address requested by the bind 220 function. 222 The user must have already prepared a passive socket to accept the 223 connection, and communicated the address information for that socket 224 to the Server-FTP process using the PORT, LPRT or EPRT command. For 225 a server-to-server transfer, this means the user must have already 226 successfully instructed the other, passive Server-DTP to prepare the 227 passive socket. 229 If the Server-DTP has already accepted an established data connection 230 to the passive socket, it should report the local address for that 231 connection. Thus, the ESTA command is repeatable, and may be issued 232 to either server in a server-to-server transfer at any time that the 233 user wishes the server to report the local address it observes on the 234 fully established data connection. 236 The establishment of the connection may take some time, and the 237 Server-DTP may make several attempts before reporting a failure. The 238 implementation should include a time out limiting the duration of the 239 connection attempts. The Server-FTP process should be capable of 240 accepting the ABOR command during this period, and should interpret 241 the ABOR command as a request to cease the connection attempt or 242 close the connection if the attempt has already succeeded. 244 The ESTA command is analogous to the PASV, LPSV and EPSV commands, 245 and returns a result formatted the same as that which would be 246 produced by the EPSV command [RFC2428] (even if the EPSV command is 247 not implemented). 249 The format of the ESTA command is: 251 ESTA 253 The ESTA command takes no arguments. 255 Possible replies to the ESTA command, and their meanings, include: 257 225 Data connection open; no transfer in progress. 258 421 Service not available, closing control connection. 259 425 Can't open data connection. 260 500 Syntax error, command unrecognized. 261 501 Syntax error in parameters or arguments. 262 502 Command not implemented. 263 520 Requested action not taken; DTP is in passive mode. 265 With the exception of response code 225, the User-FTP process must 266 not depend upon the actual text (if any) included with the reply. 268 A Server-FTP process which does not implement the ESTA command will 269 reply with either response code 500 or 502. For compatibility with 270 existing implementations, the User-FTP process must be prepared for 271 this reply. It should be possible to proceed with the data transfer. 272 Local site policy, however, may dictate refusal to continue 273 communication with implementations which do not support ESTA. 275 The response code 520 indicates that the Server-DTP was unable to 276 accept a connection from the passive socket because it is operating 277 in passive mode and does not have the address of a remote passive 278 socket to connect to. This should not occur if there is already a 279 fully established data connection. 281 The response code 425 indicates that the Server-DTP was unable to 282 establish a connection to the passive socket. This should not occur 283 if there is already a fully established data connection. In [POSIX], 284 for example, this would occur when the connect function returns an 285 error indication; possible causes might include a refused connection, 286 an unreachable passive socket address, time-out, resource depletion, 287 or internal implementation errors. 289 Response code 225 indicates that the Server-DTP has established a 290 connection to the passive socket, or already had a fully established 291 data connection. 293 The Server-FTP process must format the text of reply for response 294 code 225 in a manner similar to a positive completion reply to the 295 EPSV command (even if the EPSV command is not actually implemented). 296 Unlike the EPSV reply, the Server-FTP process must include the full 297 protocol address information actually observed on the data connection 298 for the local socket in the ESTA report. 300 Upon receipt of reply 225, the user's DTP should accept the 301 connection from the passive socket and then the User-FTP process 302 should compare the information provided with the reply against that 303 obtained locally from the established connection. 305 If the two do not exactly match, the user should terminate the data 306 connection by issuing the ABOR command, and should not proceed to 307 issue a data transfer command. 309 For a server-to-server transfer, the information provided in the 310 response to ESTA should be compared with the information provided in 311 the response to the ESTP command. For the User-FTP process, the 312 information provided in the response to ESTA should be compared 313 against the remote address observed on the fully established data 314 connection. In [POSIX], for example, this is the value returned via 315 the address argument to the accept function. 317 The format of the response code 225 reply is: 319 225 () 321 The unformatted text portion of the reply () may be any 322 message, and may be omitted. If present, it must be separated from 323 the formatted portion of the reply by at least one space character. 325 The formatted portion of the reply must be enclosed in parentheses, 326 formatted exactly as the arguments to the ESTP command (below), and 327 has the same meaning. 329 Following the separating space and parenthesis, a delimiter character 330 () must be specified. The delimiter character must be one octet 331 in range 33 to 126, inclusive. The character "|" (ASCII 124) is 332 recommended; unless it coincides with a character needed to encode 333 the arguments. 335 Note that the discussion which follows presumes the use of TCP over 336 an Internet Protocol but should not be taken as a requirement that 337 only those protocols may be used: from the point of view of the ESTA 338 command, any protocol is acceptable. The number and meaning of any 339 arguments which follow is protocol-specific; this memo 340 specifies the arguments for TCP over the Internet Protocols in use at 341 the time of its writing. 343 The protocol argument () must be an address family number 344 assigned by the IANA. This number indicates the protocol to be used 345 (and, implicitly, the number, meaning, and maximum lengths, of the 346 remaining arguments). 348 The network address argument () is a protocol-specific string 349 representation of the network address for the active socket observed 350 on the connection. Refer to Annex B for the formats required for the 351 Internet Protocols. 353 The port number argument () must be the string representation 354 of the number of the TCP port used by the active socket observed on 355 the connection. 357 3. PASSIVE ESTABLISH (ESTP) 359 The user should issue the ESTP command before issuing any other data 360 transfer command when the Server-DTP has been placed in passive mode 361 and a usable data connection is not already present. 363 This command instructs the Server-DTP to accept a connection from the 364 passive socket listening on its data port, and to report back to the 365 user the address information for the active socket observed on the 366 new connection. 368 The active socket observed on the connection is the remote address. 369 In [POSIX], for example, this is the value returned via the address 370 argument to the accept function. 372 The user must have already established an active connection to the 373 Server-DTP using the address and port information previously obtained 374 from the PASV, LPSV or EPSV command. For a server-to-server 375 transfer, this means the user must have already successfully 376 instructed the other, active Server-DTP to establish the connection. 378 If the Server-DTP has already accepted an established data connection 379 from the passive socket, it should report the remote address for that 380 connection. Thus, the ESTP command is repeatable, and may be issued 381 to either server in a server-to-server transfer at any time that the 382 user wishes the server to report the remote address it observes on 383 the fully established data connection. 385 The Server-DTP must not await new connections on the passive socket. 386 The ESTP command indicates the user believes an established 387 connection already exists. If this is not the case, the Server-DTP 388 must immediately report this fact. 390 The ESTP command is analogous to the PORT, LPRT and EPRT commands, 391 and requires a parameter formatted the same as that which would be 392 provided with the EPRT command [RFC2428] (even if the EPRT command is 393 not implemented). The protocol, network address and port information 394 provided with the command must be that of the active socket. 396 In a server-to-server transfer, the address of the active socket is 397 returned in the response to the ESTA command. For the User-FTP 398 process, this address is the local information observed on the 399 established active connection. In [POSIX], for example, this is the 400 value returned via the getsockname function; which may differ from 401 the address requested by the bind function. 403 The format of the ESTP command is: 405 ESTP 407 The ESTP command keyword must be followed by a single space character 408 (ASCII 32). Following the space, a delimiter character () must be 409 specified. The delimiter character must be one octet in range 33 to 410 126, inclusive. The character "|" (ASCII 124) is recommended; unless 411 it coincides with a character needed to encode the arguments. 413 Note that the command format shown, and the discussion which follows, 414 presume the use of TCP over an Internet Protocol but should not be 415 taken as a requirement that only those protocols may be used: from 416 the point of view of the ESTP command, any protocol is acceptable. 417 The number and meaning of any arguments which follow is 418 protocol-specific; this memo specifies the arguments for TCP over the 419 Internet Protocols in use at the time of its writing. 421 The protocol argument () must be an address family number 422 assigned by the IANA. This number indicates the protocol to be used 423 (and, implicitly, the number, meaning, and maximum lengths, of the 424 remaining arguments). 426 The network address argument () is a protocol-specific string 427 representation of the network address for the active socket observed 428 on the connection. Refer to Annex B for the formats required for the 429 Internet Protocols. 431 The port number argument () must be the string representation 432 of the number of the TCP port used by the active socket observed on 433 the connection. 435 Possible replies to the ESTP command, and their meanings, include: 437 225 Data connection open; no transfer in progress. 438 421 Service not available, closing control connection. 439 425 Can't open data connection. 440 500 Syntax error, command unrecognized. 441 501 Syntax error in parameters or arguments. 442 502 Command not implemented. 443 520 Requested action not taken; DTP is in active mode. 445 With the exception of response code 225, the User-FTP process must 446 not depend upon the actual text (if any) included with the reply. 448 A Server-FTP process which does not implement the ESTP command will 449 reply with either response code 500 or 502. For compatibility with 450 existing implementations, the User-FTP process must be prepared for 451 this reply. It should be possible to proceed with the data transfer. 452 Local site policy, however, may dictate refusal to continue 453 communication with implementations which do not support ESTP. 455 The response code 520 indicates that the Server-DTP was unable to 456 accept a connection from the passive socket because it is operating 457 in active mode and there is no passive socket. This should not occur 458 if there is already a fully established data connection. 460 The response code 425 indicates that the Server-DTP was unable to 461 accept a connection from the passive socket. This should not occur 462 if there is already a fully established data connection. In [POSIX], 463 for example, this would occur when the accept function returns an 464 error indication; possible causes might include an aborted 465 connection, resource depletion, or internal implementation errors. 467 Response code 225 indicates that the Server-DTP has accepted a 468 passive data connection, or already had a fully established data 469 connection. 471 The Server-FTP process must format the text of reply for response 472 code 225 in a manner similar to a positive completion reply to the 473 EPSV command (even if the EPSV command is not actually implemented). 474 Unlike the EPSV reply, the Server-FTP process must include the full 475 protocol address information actually observed on the data connection 476 for the remote socket in the ESTP report. 478 Upon receipt of reply 225, the User-FTP process should compare the 479 information provided with the reply against that obtained locally 480 from the established connection. 482 If the two do not exactly match, the user should terminate the data 483 connection by issuing the ABOR command, and should not proceed to 484 issue a data transfer command. 486 The format of the response code 225 reply is: 488 225 () 490 The unformatted text portion of the reply () may be any 491 message, and may be omitted. If present, it must be separated from 492 the formatted portion of the reply by at least one space character. 494 The formatted portion of the reply must be enclosed in parentheses, 495 formatted exactly as the arguments to the ESTP command, and has the 496 same meaning. 498 4. Connection Management 500 Implementations should, for the purposes of connection management, 501 treat the ESTA and ESTP commands as data transfer commands. As data 502 transfer commands, the addition of the ESTA and ESTP commands does 503 not significantly change connection management requirements. 505 Since these commands leave the connection established, but unused, a 506 subsequent data transfer command should not cause establishment of a 507 new data connection; the implementation should see that it has an 508 established connection suitable for use with the desired data 509 transfer and proceed to use that connection. 511 5. FEAT Response 513 The specifications for the ESTA and ESTP commands provide the means 514 to reliably determine the Server-FTP process's support for the 515 commands. 517 The user may issue a FEAT command [RFC2389] prior to use of the ESTA 518 or ESTP command. This may allow the user to determine if the Server- 519 FTP process supports these commands. However, since deployment of 520 Server-FTP implementations which support the FEAT command is not yet 521 wide-spread, the user should not rely upon implementation of the FEAT 522 command to indicate implementation of the ESTA and ESTP commands. 524 A Server-FTP which implements the ESTA and ESTP commands may (from 525 the point of view of this specification) implement the FEAT command. 526 If so, it must include, in the response to the FEAT command, a 527 feature line indicating support for the ESTA and ESTP commands. 529 The feature line must be formatted as: 531 ESTA 533 As specified in [RFC2389], the feature-name text, "ESTA," is not case 534 sensitive, but should be transmitted in upper-case, and the feature 535 line must begin with a single space character and end with a normal 536 Telnet end-of-line sequence. 538 At this time, options are not envisioned for either command. To 539 allow separate options for ESTA and ESTP, the user should also accept 540 the text "ESTP" as indicating support for both commands. The user, 541 however, should accept options on the FEAT response and discard any 542 it does not recognize. When options appear, they must be separated 543 from the feature-name text by exactly one space character. 545 6. IANA Considerations 547 The specifications in this memo make reference to assignment lists 548 currently maintained by the Internet Assigned Numbers Authority 549 (IANA); no new assignments are specified, and no new assignment lists 550 are required. 552 The list of valid feature names sent in response to the FTP FEAT 553 command is believed to be first-come first-served, and managed 554 outside the control of the IANA. 556 Specific examples taken from IANA-maintained lists at the time of 557 this writing are for illustrative and informative purposes only. 559 7. Security Issues 561 The ESTP command, and the replies to both ESTA and ESTP, contain 562 network addressing information which could be used to gather 563 information about internal network architectures. However, since 564 similar information is already transmitted on the FTP control 565 connection, it presents no risk not already present in the FTP. 567 The intention of this protocol extension is to address the security 568 issue involved with the problem of a race condition in the existing 569 File Transfer Protocol [DS, CERT2]. This condition allows an 570 attacker the ability to receive unauthorized transmissions from, or 571 transmit unauthorized information to, the passive party of a file 572 transfer. The attack makes use of the timing window between when the 573 passive socket is prepared and when an active connection to that 574 passive socket actually occurs. 576 The security industry identifier for this issue is CVE-1999-0351 577 [CVE]. 579 Denial of Service attacks can make use of this issue. The described 580 protocol is equally susceptible to Denial of Service attacks. It 581 can, however, make their effect much more apparent since data 582 transfers will fail where they may have incorrectly appeared to have 583 succeeded without these protocol extensions. 585 The described protocol does not address the issue of "FTP Bounce" 586 (CVE-1999-0017); where an attacker, via the control connection, 587 instructs the Server-DTP to actively establish a data connection to a 588 third party [CERT1]. 590 The protocol presented also makes no attempt to secure the actual 591 data transmission; it only provides a means to determine the proper 592 data connection has been established prior to initiating data 593 transfer over that channel. Alternatives, such as provided by the 594 FTP Security Extensions [RFC2228, MURRAY], should be considered when 595 data security is an issue. Unfortunately, these methods are not, as 596 yet, widely deployed. ([MURRAY] is a work in process. Wide spread 597 deployment, if it occurs at all, will be some time in the future.) 598 The extensions provided by this protocol provide added measures which 599 can compliment those alternatives, but cannot replace them. 601 The use of any Network Address Translation scheme, or certain proxy 602 implementations, may render this protocol unusable. The protocol 603 involves the transmission of network address information over the FTP 604 control connection. Address translators, including proxy 605 implementations which do not implement this protocol, can cause a 606 mismatch between the information transmitted and the address actually 607 observed at the communication channel end-point. 609 Acknowledgments 611 The following people provided significant assistance with the 612 analysis of the problem, the proposed solution, and the preparation 613 of this document: 615 The members of vulnerability handling team at the CERT 616 Coordination Center. 618 Paul Ford-Hutchinson of IBM UK Ltd. 620 Ian Willis of Sun Microsystems. 622 Normative References 624 [RFC959] J. Postel and J. Reynolds, "FILE TRANSFER PROTOCOL 625 (FTP)", STD 9, RFC 959, October 1985. 627 [RFC1123] IETF, "Requirements for Internet Hosts -- Application and 628 Support", STD 3, RFC 1123, October 1989. 630 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 631 Requirements Levels", RFC 2119, BCP 14, March 1997. 633 [RFC2389] P. Hethmon and R. Elz, "Feature negotiation mechanism for 634 the File Transfer Protocol", RFC 2389, August 1998. 636 [RFC2428] M. Allman, S. Ostermann and C. Metz, "FTP Extensions for 637 IPv6 and NATs", RFC 2428, September 1998. 639 Informative References 641 [RFC1639] D. Piscitello, "FTP Operation Over Big Address Records 642 (FOOBAR)", RFC 1639, June 1994. 644 [RFC2228] M. Horowitz and S. Lunt, "FTP Security Extensions", RFC 645 2228, October 1997. 647 [MURRAY] P. Ford-Hutchinson, et al, "Securing FTP with TLS", IETF 648 Internet-Draft, Work in process. 650 [POSIX] IEEE and The Open Group, "Base Specifications, Issue 6", 651 IEEE Std 1003.1-2001, January 2001. 653 The following references are only available electronically. The URL 654 given for each is believed to be the "original source." At least one 655 is known to be no longer available from that source. All documents 656 cited, however, are widely mirrored and known to be readily located 657 using search engines. 659 [DS] D. Sacerdote, "Some problems with the File Transfer 660 Protocol, a failure of common implementations, and 661 suggestions for repair.", 662 http://www.secnet.com/papers/ftp-paper.html, April 1996. 664 [CERT1] CERT Coordination Center, "Problems with the FTP PORT 665 Command or Why You Don't Want Just Any PORT in a Storm", 666 http://www.cert.org/tech_tips/ftp_port_attacks.html, 667 April 1998. 669 [JG] J. Gerber, "FTP PASV "Pizza Thief" Exploit", 670 http://www.infowar.com/iwftp/iw_sec/iw_sec_01.txt, 671 February 1999. 673 [GL] G. Lundberg, "Security update for wu-ftpd 2.4.2 (beta 18) 674 VR13", ftp://ftp.wu-ftpd.org/pub/wu-ftpd- 675 attic/ANNOUNCE-2.4.2-beta-18-vr14, February 1999. 677 [CVE] Mitre Corp., "Common Vulnerabilities and Exposures", 678 http://cve.mitre.org/, September 1999. 680 [KS] K. Seifried, "Problems with the FTP protocol", 681 http://seifried.org/security/network/20010926-ftp- 682 protocol.html, September 2001. 684 [CERT2] J. Lanza and J. Pickel, "File Transfer Protocol allows 685 data connection hijacking via PASV mode race condition", 686 http://www.kb.cert.org/vuls/id/2558, April 2002. 688 Author's Address 690 Gregory A. Lundberg 691 WU-FTPD Development Group 692 1441 Elmdale Drive 693 Dayton, OH 45409-1615 694 US 696 Phone: +1 937 299 7653 697 Email: lundberg@vr.net 699 Annex A - Address Family Numbers 701 The ESTP command, and the responses to both ESTA and ESTP, make use 702 of the address family number. For informational purposes, the 703 following table shows the assignments for the Internet Protocols as 704 of the writing of this document. Refer to the IANA for a current 705 list of all address family numbers. 707 AF Number Protocol 708 --------- -------- 709 1 Internet Protocol, Version 4 (STD 5, RFC 791) 710 2 Internet Protocol, Version 6 (RFC 2460) 712 Normative References for Address Family Numbers 714 Since publication of [RFC1700], the IANA has moved to an on-line 715 database for management of the assigned numbers. 717 [IANA] IANA, "Protocol Numbers and Assignment Services", 718 http://www.iana.org/numbers.html 720 [RFC1700] J. Reynolds and J Postel, "ASSIGNED NUMBERS", STD 2, 721 RFC 1700, October 1994. 723 Annex B - Network Address Formats 725 The ESTP command, and the responses to both ESTA and ESTP, contain 726 network addresses. Each network protocol has a required form for 727 representation of its addresses. For informational purposes, the 728 following table shows the formats for the Internet Procotols as of 729 the writing of this document. 731 AF Number Address Format Example 732 --------- -------------- ------- 733 1 dotted decimal 132.235.1.2 734 2 IPv6 string 1080::8:800:200C:417A 736 Normative References for Network Address Formats 738 [RFC952] K. Harrenstien, M. Stahl and E. Feinler, "DOD INTERNET 739 HOST TABLE SPECIFICATION", RFC 952, October 1985. 741 [RFC2373] R. Hinden and S. Deering, "IP Version 6 Addressing 742 Architecture", RFC 2373, July 1998. 744 Annex C - Examples of Use 746 The following examples show typical uses of the ESTA and ESTP 747 commands detecting an unauthorized connection to the passive socket. 749 The assumption in these examples is that the TCP implementation on 750 the host will establish multiple connections on a passive socket and 751 return them to the implementation in the order established. Thus, a 752 second active connection will succeed without error. Experience 753 shows this assumption holds true for most existing implementations. 755 The examples all use the following IPv4 addresses, which are assumed 756 routable on the example network without address translation. 758 user 192.168.1.2 760 The user; either actively connecting, passively accepting 761 connections, or not participating in the data transfer. 763 active 172.16.3.4 765 The Server-FTP process actively connecting (PORT mode). The 766 Server-FTP process will use TCP port 20, as assigned by IANA for 767 this purpose. 769 passive 172.16.5.6 771 The Server-FTP process passively accepting connections (PASV 772 mode). 774 attacker 10.7.8.9 776 The attacker actively connecting to the passive socket used in the 777 particular example. The example attacker uses TCP port 20 in a 778 simplistic (and likely successful) attempt to thwart fire-wall 779 filtering rules, and to fool the passive FTP implementation (as 780 well as intrusion detection systems which may be monitoring the 781 traffic) into believing it is an actual Server-FTP implementation. 783 C.1 PORT Mode 785 The user prepares a passive socket and transmits its address to 786 the active Server-DTP. The user's DTP is now listening for 787 connections on that socket. 789 The window for the attacker to connect is now open. 791 user --> active: PORT 192,168,1,2,12,34 793 The attacker connects to the passive socket. 795 active --> user: 200 Okay. 797 The Server-DTP is now prepared to actively establish a connection 798 to the specified passive socket. 800 user --> active: ESTA 802 The Server-DTP establishes the specified connection and returns 803 the address of the active socket (the local address on the Server- 804 DTP). 806 The window for the attacker to connect has now closed. 808 active --> user: 225 Connected from (|1|172.16.3.4|20|) 810 The user's DTP accepts the first connection from the passive 811 socket. In this case, the connection from the attacker. It 812 retrieves the active socket address (the remote address) and 813 compares it to the information returned from the Server-FTP 814 process. 816 Seeing a mismatch, the user immediately terminates the established 817 data connection (to the attacker). Note the passive socket, and 818 the established connection from the Server-DTP queued upon it, 819 remain. 821 In most cases, however, since the passive socket is now "tainted," 822 the user will desire to also close the passive socket. To do so, 823 it must first instruct the Server-FTP process to abort the 824 connection. 826 user --> active: ABOR 828 The Server-DTP closes its data connection. 830 active --> user: 226 Connection closed, abort successful. 832 The user may now close the passive socket and proceed with the 833 remainder of its error-recovery process. 835 C.2 PASV Mode 837 The user requests the Server-DTP create a passive socket and 838 report its address. 840 user --> passive: PASV 842 The Server-DTP prepares the requested passive socket. The Server- 843 DTP is now listening for connections on that socket. 845 The window for the attacker to connect is now open. 847 passive --> user: 227 Listening on 172,16,5,6,78,90 849 The attacker connects to the passive socket. 851 The user establishes the specified connection and sends the 852 address of the active socket (the address local) to the Server-FTP 853 process. 855 The window for the attacker to connect has now closed. 857 user --> passive: ESTP |1|192.168.1.2|43210| 859 The Server-DTP accepts the first connection from the passive 860 socket. In this case, the connection is from the attacker. It 861 retrieves the active socket address (the remote address) and 862 returns it to the user. 864 passive --> user: 225 Connected to (|1|10.7.8.9|20|) 866 The user compares the address returned with the address assigned 867 to its (local) active socket. Seeing a mismatch, it terminates 868 the data connection prior to issuing a command which would 869 actually transmit data. 871 user --> passive: ABOR 873 The Server-DTP closes the data connection (to the attacker). Note 874 the passive socket remains, as does the user's connection queued 875 upon it. 877 passive --> user: 226 Connection closed, abort successful. 879 The user proceeds with error recovery. In most cases, since the 880 passive socket is now "tainted," the user will close its data 881 connection and instruct the Server-FTP process to close the 882 passive socket and prepare another. 884 C.3 Server-to-Server Mode 886 The user requests the Server-DTP create a passive socket and 887 report its address. 889 user --> passive: PASV 890 The Server-DTP prepares the requested passive socket. The Server- 891 DTP is now listening for connections on that socket. 893 The window for the attacker to connect is now open. 895 passive --> user: 227 Listening on 172,16,5,6,78,90 897 The user forwards the passive socket address to the second Server- 898 FTP process. 900 user --> active: PORT 172,16,5,6,78,90 902 The attacker connects to the passive socket. 904 active --> user: 200 Okay. 906 The second Server-DTP is now prepared to actively establish a 907 connection to the specified passive socket. 909 user --> active: ESTA 911 The second Server-DTP establishes the specified connection and 912 returns the address of the active socket (the local address on the 913 Server-DTP). 915 The window for the attacker to connect has now closed. 917 active --> user: 225 Connected from (|1|172.16.3.4|20|) 919 The user forwards this information to the first Server-FTP 920 process, informing it to accept a passive connection. 922 user --> passive: ESTP |1|172.16.3.4|20| 924 The Server-DTP accepts the first connection from the passive 925 socket. In this case, the connection is from the attacker. It 926 retrieves the active socket address (the remote address) and 927 returns it to the user. 929 passive --> user: 225 Connected to (|1|10.7.8.9|20|) 931 The user compares the address returned with the address provided 932 by the second Server-FTP process. Seeing a mismatch, it proceeds 933 to begin error-recovery by instructing the first Server-DTP to 934 close the data connection (to the attacker). 936 user --> passive: ABOR 937 The first Server-DTP closes the data connection (to the attacker). 938 Note the passive socket remains, as does the second Server-DTP's 939 connection queued upon it. 941 passive --> user: 226 Connection closed, abort successful. 943 The user proceeds with error recovery. In most cases, since the 944 passive socket is now "tainted," the user will want to instruct 945 the first Server-FTP process to close the passive socket and 946 prepare another. Before it does so, however, it must instruct the 947 second Server-FTP process to close its data connection. 949 user --> active: ABOR 951 The second Server-DTP closes its data connection. 953 active --> user: 226 Connection closed, abort successful. 955 The user may now instruct the first Server-FTP process to close 956 the passive socket and proceed with the remainder of the error- 957 recovery process. 959 Annex D - Implementation Considerations 961 The ESTA and ESTP commands present some interesting possibilities for 962 implementers; three of which are discussed here. 964 Experience shows the implementation of the TCP passive socket, on 965 most hosts, queues incoming connections. While in the queue, the 966 connections are established and simply not being used by the 967 application. In [POSIX], for example, the accept function removes 968 those connections from the queue, making them available to the 969 application. This operation usually involves no network activity; to 970 the remote end-point, the status of the established connection 971 (queued or accepted) is transparent. 973 The formal specifications of the ESTA and ESTP commands indicate the 974 implementation accepts the first connection queued upon the passive 975 socket. There may, however, be several connections queued. One of 976 them can be expected to be the intended connection. 978 D.1 Interactively Finding the Specified Connection 980 In sessions involving a passive Server-DTP, the user could make use 981 of the (probable) behavior of TCP passive sockets in an attempt to 982 locate the desired data connection. 984 Quite simply, after instructing the passive Server-FTP process to 985 close the data connection (to the attacker), instead of immediately 986 requesting the preparation of a new passive socket, the user could 987 issue another ESTP command. 989 Using this scheme, the user is instructing the passive Server-DTP to 990 step through each connection queued on its passive socket until it 991 (the user) finds one which is acceptable. 993 The danger is that attackers can establish new connections faster 994 than the user can process them interactively. Thus, while this 995 approach is viable, the user must guard against connection floods by 996 imposing a limit (either by time or number of attempts) and 997 proceeding on the basis of the last-accepted, mismatched connection 998 once that limit has been reached. 1000 A user, seeking maximum robustness, may implement this approach. The 1001 Server-FTP process should provide its own guards against connection 1002 flooding, either by using the automatic method outlined next, or by 1003 limiting (by time or attempts) the user's repeated use of the ESTP 1004 command. 1006 D.2 Automatically Finding the Specified Connection 1008 The implementer will note that, when using passive mode, the desired 1009 address is known prior to accepting a connection from the passive 1010 socket. For the user, this address was obtained from the response to 1011 the ESTA command. For the passive Server-DTP it was given with the 1012 ESTP command. 1014 This presents the (rather appealing) possibility of stepping through 1015 each connection queued on the passive socket until one with the 1016 desired address is located. 1018 It has the advantage of not involving any network traffic, as is 1019 required when interactively seeking the correct connection, and could 1020 more quickly reduce resources used (wasted) by the attacker 1021 connections. 1023 Implementations should consider this approach. Since this is being 1024 done with local operations, it is significantly faster than the 1025 interactive approach. Connection floods, however, are still a 1026 possibility which must be guarded against. 1028 D.3 Using a Common Passive Socket 1030 An extension of automatically finding the desired connection is the 1031 possibility of using a common passive socket for all data transfers. 1033 If the implementation issues with this approach can be addressed, it 1034 would greatly reduce the configuration issues faced by fire-wall 1035 administrators, and could significantly enhance both the usability 1036 and security of the FTP. 1038 Basically, the Server-DTP always has a passive socket prepared, and 1039 reports the address of that socket in response to all PASV, LPSV and 1040 EPSV commands. 1042 Those tempted to implement this approach are strongly cautioned to 1043 carefully consider all aspects, some of which are presented here. 1044 The discussion, however, is probably incomplete and bears careful 1045 analysis and further research by implementers. 1047 The most obvious problem is that the implementation needs some means 1048 to queue connections already accepted, but not yet matched to 1049 sessions by the ESTP command. This could place a significant load on 1050 resources, especially when faced with a connection flood, and the 1051 total number of such connections possible may be restricted by host 1052 limitations. 1054 Another problem is that some connections will never be matched. In 1055 terms of the passive race condition, they would represent attackers; 1056 but those connections could simply be the result of failed sessions. 1057 Queue-time limitations and other means might provide the solution to 1058 this problem. 1060 The appeal of this possibility, however, is so great that it bears 1061 further research. If the implementation issues can be properly 1062 addressed, whether through protocol enhancements or through 1063 implementation guidelines, this could become the preferred mode of 1064 use for passive sockets in Server-FTP implementations. 1066 Full Copyright Statement 1068 Copyright (C) The Internet Society (2002). All Rights Reserved. 1070 This document and translations of it may be copied and furnished to 1071 others, and derivative works that comment on or otherwise explain it 1072 or assist in its implementation may be prepared, copied, published 1073 and distributed, in whole or in part, without restriction of any 1074 kind, provided that the above copyright notice and this paragraph are 1075 included on all such copies and derivative works. However, this 1076 document itself may not be modified in any way, such as by removing 1077 the copyright notice or references to The Internet Society or other 1078 Internet organizations, except as needed for the purpose of 1079 developing Internet standards in which case the procedures for 1080 copyrights defined in the Internet Standards process must be 1081 followed, or as required to translate it into languages other than 1082 English. 1084 The limited permissions granted above are perpetual and will not be 1085 revoked by The Internet Society or its successors or assigns. 1087 This document and the information contained herein is provided on an 1088 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1089 TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1090 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1091 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1092 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1094 Acknowledgement 1096 Funding for the RFC Editor function is currently provided by The 1097 Internet Society.