NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Paul Hethmon <phethmon@hethmon.com>
Applications Area Director(s):
Keith Moore <moore+iesg@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Keith Moore <moore+iesg@cs.utk.edu>
General Discussion:ftp-wg@hops.ag.utk.edu
To Subscribe: ftp-wg-request@hops.ag.utk.edu
Archive: hops.ag.utk.edu/ftp-wg/archives/
The goals of this working group are:
· Requirements for internationalization of FTP. The group would make recommendations on what changes/additions FTP needs to better support non-English language users. This is expected to result in an informational guide for design criteria to be used for internationalization of FTP commands. · Define a new command for a uniform directory listing between platforms. This command would provide an alternate to the existing LIST and NLST commands with a command which has a common format between all FTP implementations and which provides the ability to represent non-ASCII filenames. · Recommendations for standards-track protocol extensions to support IPv6 in FTP. The group would evaluate RFC 1639 and recommend, revise, or redo as appropriate. · Define a mechanism for ftp clients and servers to transmit information regarding extensions supported and not supported. A simple method needs to be available for a server to let the client know what extensions are supported. · The group would solicit input from interested parties to submit drafts for better authentication within FTP. The group would be expected to review and make recommendations on the proposals. · Define a standardized method of checkpoint/restart that works for the stream transfer mode. · Define a means of file transfer between a client and server (as opposed to a client mediating a transfer between two servers) which does not require the IP addresses of the endpoints to be transmitted in the FTP protocol. · Solicit a person or persons to write an informational document covering SIZE and MDTM as currently used.
· The following issues are specifically omitted from the working group's charter, but may be added by the Area Directors if time permits, once the above goals have been achieved.
· Compression of files for transmission. · Internationalization of charset conversion for transmission.Goals and Milestones:
· MLST Command and Extensions to FTP
· Internationalization of the File Transfer Protocol
· REST Command and Extensions to FTP
Reported by: Bill Curtin <curtanw@ftm.disa.mil>
The working group chair opened the meeting by proposing an agenda that included discussions on the groups outstanding drafts: security considerations, variable ftp, ftp internationalization, MLST/MLSD, and Restart.
I. Security Considerations (draft-allman-ftp-sec-consider-01.txt)
A presentation of the security considerations document was made by the authors. They explained that the document is 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 is to limit attempts to 3-5 and then close the connection. An additional solution was to add a delay and 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 is still the possibility of 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 two is to reference the FTP Security Extension draft (being progressed through the Common Authentication Working Group); the recommendation for the former is to avoid assigning port numbers sequentially (i.e., assign them randomly) or possibly use a cookie passing technique.
II. 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 two new commands, EPRT and EPSV, to replace the PORT and PASV commands.
The format of the EPRT command is:
EPRT <net-prot>|<trans-prot>|net-addr|<trans-addr The first 3 fields are optional. The last is required in all cases.
The protocol also defines field keywords for the EPRT command as: IP4, IP6, TCP, and RDP. Other keywords will be defined as necessary.
The group commented that the draft needed to clarify that the "|" are being used as field delimiters by the protocol and did not connote the word "or." A suggestion was also made to place a delimiter after the space separating the commands from the fields and to possibly allow the first non-blank character to represent the delimiter. This would allow future network protocols maximum freedom to represent network addresses without concern for colliding with the delimiter defined in this draft.
The format of the EPSV returns information necessary to open a data connection by the EPRT command in the following format:
(<net-prot>|<trans-prot>|net-addr|<trans-addr) <Text to express that server is entering extended passive mode>
The parenthesis and the fields within them must be returned from an EPSV request.
It was noted that there may be a problem if EPSV returns a protocol that can not be supported. The group commented that possibly there should be a prior negotiation that could last the entire session or until it was changed.
III. Internationalization of the File Transfer Protocol (draft-ietf-ftpext-intl-ftp-01.txt)
The editor for this draft gave a brief overview of what is 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 two 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 are three outstanding comments to the latest version: Caveat of ISO's adoption of amendment five 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 needs to be checked; and it might be nice to have a section which deals 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.
IV. 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 already concurred with the proposal. The group had no objection.
There was a discussion on directory and filename concatenation. It was noted that the trend is toward virtual file names and may not be able to concatenate directory and filename. Suggestion to 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 is that extensions should be 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.
V. 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 were 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.
FTP Extensions for Variable Protocol Specification
draft-allman-ftp-variable-04.txt
Mark Allman and Shawn Ostermann
mallman,ostermann}@cs.ohiou.edu
PORT CommandPORT EXAMPLE - FIGURE
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
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
FTP command sent from one machine to another.
Allows the use of \textit{extended addresses}.
Format: EPRT <NP>|<TP>|<NA>|<TA>
Protocols MUST be upper-case strings indicating the protocol (and, implicitly, address length)
Network Protocols defined in the draft:
IP4 Internet Protocol, Version 4
IP6 Internet Protocol, Version 6
Transport Protocols defined in the draft:
TCP Transmission Control Protocol
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
-String representation of decimal port number.
-String representation of decimal port number.
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
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 the transport protocol, the error returned should be 522 (invalid network protocol).
The text portion of a 522 or 523 response MUST list the supported
protocols followed by an optional human readable description.
(prot1,prot2,...,protN) <text for people>
The listed protocols MUST be in the form of the protocol keywords defined above.
522 (IP4,IP6) supported network protocols
523 (TCP) supported transport protocols
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:
(<NP>|<TP>|<NA>|<TA>) <text for people>
The portion enclosed in parenthesis MUST be in the format defined above for EPRT.
229 (|||6446) Entering Passive Mode
Again, as in EPRT, the <NP>, <TP> and <NA> 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).
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.
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 none of the advertised protocols is supported by the host receiving the EPSV command, the existing error code 504 (``command not implemented for that parameter'') MUST be returned.
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.
draft-allman-ftp-sec-consider-01.txt
Mark Allman and Shawn Ostermann
{mallman,ostermann}@cs.ohiou.edu
Recommend ways to reduce security problems with FTP.
The draft currently addresses:
-Restricting access based on network address.
Example using FTP to ``attack'' SMTP server on a third machine:
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.
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.
For some FTP servers, it is desirable 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.
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. It is SUGGESTED that FTP clients and servers use alternate encryption mechanisms, such as draft-ietf-cat-ftpsec-09.txt, to prevent eavesdropping.
Develop a simple and effective way to diminish the chance of port stealing.
-Ensure the TCP port is chosen randomly.