Editor's Note: These minutes have not been edited. Reported by Bill Curtin Minutes for the FTPEXT WG in Memphis The working group chair opened the meeting by proposing an agenda which included discussions on the groups outstanding drafts: security considerations, variable ftp, ftp internationalization, MLST/MLSD, and Restart. - SECURITY CONCIDERATIONS (draft-allman-ftp-sec-consider-01.txt) A presentation of the security considerations document was made by the authors. They explained that the document was based on concerns raised on the mail list. The document recommends ways to reduce security problems and details bounce attacks associated with 3 way connections, access restrictions based on IP addresses, and how to protect passwords against brute force attacks. An example of a bounce attack was presented using the PASV and PORT command to pass a file containing RFC822 commands to the well known port for SMTP thereby fooling the SMTP server as to the origin of the mail message. The recommended solution to this attack was to refuse PORT commands to well known ports (i.e. <1024). A suggestion was made to use a reply code 504 in response to an attempt by the user-FTP to use the PORT command with a port number <1024. It was noted during the description of restricting access based on network address that the server must verify both the control and data connection and that this approach would still be open to a "spoof attack" The recommended solution to a brute force attack on password guessing was to limit attempts to 3-5 and then close the connection. An additional solution was to add in a delay and to use operating system services where available. The group noted that rather then abruptly closing the connection that the server should return a 421 reply. It was also noted that there was still the possibility to using the brute force attack, even with this recommendation, by simply opening up numerous control connections. It was noted that the draft should include sections on port stealing, integrity, and privacy. The suggestion to the latter 2 was to reference the FTP security extensions draft (being progressed through the Common Authentication working group); the recommendation for the former was to avoid assigning port numbers sequentially (i.e. assign them randomly) or to possibly use a cookie passing technique. - FTP Extensions for Variable Protocol Specification The authors noted that RFC959 limits the PORT and PASV command to a 32 bit IPV4 and 16 bit TCP addresses and that this will not work with other network or transport protocols, most notably Ipv6. The authors also noted that the FOOBAR RFC, while removing this restriction still associates specific network and transport protocols. In an attempt to decouple the relationship of the network and transport protocols while not removing functionality defined in RFC959 the authors defined 2 new commands, EPRT and EPSV, to replace the PORT and PASV commands. The format of the EPRT command is: EPRT ||net-addr|||net-addr| The parenthesis and the fields within them must be returned from a EPSV request. It was noted that there may be a problem if EPSV returns a protocol which can not be supported. The group commented that possibly there should be a prior negotiation which could last the entire session or until it was changed. - Internationalization of the File Transfer Protocol (draft-ietf-ftpext- intl-ftp-01.txt) The editor for this draft gave a brief overview on what was contained in the draft (e.g. restriction on 7 bit ASCII dropped, use ISO 10646-1 character set, and use UTF-8 transfer encoding). A description of the changes from the first version of this draft were given: draft restructured to shorten normative portion and added 2 informative appendices; and defined use of space and CRLF characters used in pathnames. It was noted that there were not many comments on the latest version of the draft and that all of the editorial comments had already been changed in the working draft copy. There were 3 outstanding comments to the latest version: Caveat of ISO's adoption of amendment 5 may no longer be necessary because ISO may have already approved the amendment; the code example to check for UTF-8 strings was expanded but needed to be checked; and it might be nice to have a section which dealt with transitional issues and backward compatibility. The presentation finished by asking if this draft should go standards track and if the RFC 1123 tables needed to be updated to include the new features and commands being developed in this and other FTP related drafts. The group seemed to feel that the draft should go to standards track and that a RFC 1123 type table, while not necessary, might be nice. - MLST command and Extensions to FTP (draft-ietf-ftpext-mlst-00.txt) A proposal by the chair to merge the Restart document with the MLST document was presented. The chair noted that all of the authors of the drafts had already concurred with the proposal. The group had no objection. There was a discussion on directory and filename concatenation. It was noted that trend is toward virtual file names and may not be able to concatenate directory and filename. Suggestion to maybe allow directory/filename without doing a CWD. But not the weird things. The author agreed to align the UTC time to the format given in the RESTART draft. The consensus at the meeting was to drop MLST replies over the control connection. It was suggested that the STAT command could be used for the same behavior. A server which supports MLST would use the same format if STAT is used. The author asked if it made sense to allow implementation specific extensions to be case sensitive (i.e. x -vs- X). The group opinion was that extensions should by case insensitive. After some discussion about the need or use of the link "type" fact it was decided that it added no real value and should be removed from the specification. There was a discussion on what use the x value of the "perm" fact has given that there is no guarantee that the file can execute on a given platform. The suggestion is to remove the x value from the draft. There was a discussion on the ability to cache the FEAT command for use in subsequent sessions. The group felt that caching should not be a condoned strategy and that it should not be addressed in the draft. - REST Command and Extensions to FTP (draft-ietf-ftpext-restart-00.txt) It was decided that the REST command must immediately precede the operative command (RETR/STOR). Anywhere else and its effect will be undefined. There was some questions on the need for a manual restart and whether the same results couldn't be achieved by doing an ABOR and later use the SIZE command to get the restart marker. This topic was left for further discussion on the list. ====================================================================== IPv6 Slides ---Slide 1--- FTP Extensions for Variable Protocol Specification draft-allman-ftp-variable-04.txt April 9, 1997 Mark Allman and Shawn Ostermann {mallman,ostermann}@cs.ohiou.edu Ohio University http://jarok.cs.ohiou.edu/ ---Slide 2--- PORT/PASV Examples PORT Command PORT EXAMPLE - FIGURE PASV Command PASV EXAMPLE - FIGURE ---Slide 3--- Introduction FTP [RFC 959] limits addresses to IPv4/TCP -32 bit network address (IP address) -16 bit transport address (TCP port number) This will not work with IPv6 network addresses (128 bits). Piscitello's FOOBAR [RFC 1639] mechanism solves the problem, but... -Network and transport protocols are linked together. -Choosing a network protocol automatically chooses a transport protocol. ---Slide 4--- Goals Design more general versions of the PORT and PASV FTP commands. -Should work over any combination of network and transport protocols supported by a given client/server pair. Maintain all the functionality present in RFC 959. New commands: EPRT and EPSV ---Slide 5--- EPRT FTP command sent from one machine to another. Allows the use of \textit{extended addresses}. Format: EPRT ||| - network protocol - transport protocol - network address - transport address ---Slide 6--- Defined Protocols Protocols MUST be upper-case strings indicating the protocol (and, implicitly, address length) Network Protocols defined in the draft: Text Meaning ---- ------- IP4 Internet Protocol, Version 4 IP6 Internet Protocol, Version 6 Transport Protocols defined in the draft: Text Meaning ---- ------- TCP Transmission Control Protocol RDP Reliable Data Protocol ---Slide 7--- Network Address Formats For each of the following keywords, the address in the EPRT command MUST be in the format given: IP4 -String representation of dotted decimal format address. -Example: 132.235.1.2 IP6 -IPv6 string representations defined in RFC 1884. -Example: 1080::8:800:200C:417A ---Slide 8--- Transport Address Formats TCP -String representation of decimal port number. -Example: 6446 RDP -String representation of decimal port number. -Example: 3684 ---Slide 9--- Default Values The network and transport protocols and the network address have default values if they are not specified in the EPRT command, as follows. Network Protocol - defaults to network protocol used for the control connection Transport Protocol - defaults to the transport protocol used for the control connection Network Address - defaults to the network address of the remote machine on the control connection EPRT Examples: EPRT IP4|TCP|132.235.1.2|6275 EPRT |RDP||5282 EPRT |||6446 ---Slide 10--- Return Codes Upon receipt of a valid EPRT command, a return code of 200 MUST be sent. This is the same return code sent in response to valid PORT commands. The standard return codes 500 and 501 are sufficient to handle most errors (e.g., syntax errors). Two new response codes are needed: -522 - network protocol unknown -523 - transport protocol unknown If the remote host does not support either the network or transport protocol, the error returned should be 522 (invalid network protocol). ---Slide 11--- Return Codes (cont.) The text portion of a 522 or 523 response MUST list the supported protocols followed by an optional human readable description. Text response format: (prot1,prot2,...,protN) The listed protocols MUST be in the form of the protocol keywords defined above. Example responses: 522 (IP4,IP6) supported network protocols 523 (TCP) supported transport protocols ---Slide 12--- EPSV Allows a machine to request a passive connection be setup using the extended address format. The response includes all information needed to setup a data connection using the EPRT command. The new response code 229 MUST be returned when entering passive mode using an extended address. The text portion of the response MUST be of the following format: (|||) ---Slide 13--- EPSV (cont.) The portion enclosed in parenthesis MUST be in the format defined above for EPRT. Example response: 229 (|||6446) Entering Passive Mode Again, as in EPRT, the , and fields may be omitted to assume their default values. The existing standard negative error codes 500 and 501 are sufficient to handle all errors involving EPSV (e.g., syntax errors). ---Slide 14--- Work in Progress As defined in the draft, FTP using EPSV has a problem. -If the response to EPSV contains protocols not supported by the machine issuing the EPSV command, no data connection can be established. This problem can be fixed by appending an argument to the EPSV command that advertises the supported protocols. Example new EPSV command: EPSV IP4,IP6|TCP ---Slide 15--- Work in Progress (cont.) The advertisement of one or both protocols is OPTIONAL. -If an advertisement is not sent, the host sending the EPSV command must be prepared to abort the transfer if the response includes an unsupported protocol. -The ABOR command followed by a new EPSV command (with an advertisement) will need to be sent on the control connection. If the none of the advertised protocols are supported by the host receiving the EPSV command, the existing error code 504 (``command not implemented for that parameter'') MUST be returned. ---Slide 16--- Security Issues Using an extended address increases the scope of the FTP ``bounce attack'' by making it possible to use non-TCP transport protocols to attack servers. A companion Internet Draft discusses FTP security issues in more detail. ====================================================================== FTP Security Slides ---Slide 1--- FTP Security Considerations draft-allman-ftp-sec-consider-01.txt April 9, 1997 Mark Allman and Shawn Ostermann {mallman,ostermann}@cs.ohiou.edu Ohio University http://jarok.cs.ohiou.edu/ ---Slide 2--- Goals Recommend ways to reduce security problems with FTP. The draft currently addresses: -The ``bounce attack'' -Restricting access based on network address. -Protecting passwords. ---Slide 3--- Normal 3-Way FTP Normal 3-way transfer: 3-WAY FTP FIGURE ---Slide 4--- The Bounce Attack Example using FTP to ``attack'' SMTP server on a third machine: BOUNCE ATTACK FIGURE ---Slide 5--- Protecting Against the Bounce Attack TCP port numbers in the range 0-1023 are reserved for well known services. The FTP specification [RFC 959] makes no restrictions on the TCP port number used for the data connection. This allows FTP clients to instruct FTP servers to ``attack'' well-known TCP ports on any host on the network. It is SUGGESTED that servers refuse to open data connections to TCP ports less than 1024. ---Slide 6--- Protecting Against the Bounce Attack (cont.) If a server receives a PORT command containing a TCP port number less than 1024, the SUGGESTED response code is 504 (``command not implemented for that parameter''). Note: This still leaves non-well known servers vulnerable to bounce attacks. The companion Internet-Draft and RFC 1639 (FOOBAR) provide mechanisms to use transport protocols besides TCP. Similar precautions should be taken to protect well-known services when these protocols are used. ---Slide 7--- Restricted Access For some FTP servers, it is desireable to restrict access based on network address. In such situations, a server SHOULD verify both the remote address on the data connection and the remote address on the control connection before transmitting a file. This protects against the case when the control connection is established with a trusted host and the data connection is not. Note that restricting access based on network address leaves a server vulnerable to ``spoof'' attacks. ---Slide 8--- Protecting Passwords To minimize the risk of brute force password guessing through the FTP server, it is SUGGESTED that servers limit the number of attempts to send the correct password to a small number (3-5). -After 3-5 attempts, the server SHOULD close the control connection. It is also SUGGESTED that FTP servers impose a small delay (5 seconds) before responding to invalid PASS commands. If available, mechanisms provided by the operating system to accomplish the above SHOULD be used. ---Slide 9--- Protecting Passwords (cont.) It is SUGGESTED that FTP clients and servers use alternate encryption mechanisms, such as draft-ietf-cat-ftpsec-09.txt, to prevent eavesdropping. ---Slide 10--- Work in Progress Develop a simple and effective way to diminish the chance of port stealing. Some suggestions -A cookie mechanism. -Ensure the TCP port chosen is random.