Extensions to FTP (ftpext)

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>

Area Advisor: 

Keith Moore <moore+iesg@cs.utk.edu>

Mailing Lists: 

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/

Description of Working Group: 

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:

Oct 96 

Issue an Internet-Draft covering internationalization issues.

Nov 96 

Issue an Internet-Draft for a standard listing command.

Nov 96 

Issue an Internet-Draft for an extension mechanism.

Feb 97 

Issue a second Internet-Draft for a standard listing command.

Feb 97 

Issue a second Internet-Draft for an extension mechanism.

Mar 97 

Issue an Internet-Draft for IPv6 support, and to remove the necessity of transmitting IP addresses in the FTP protocol for transfers between a client and server.

Mar 97 

Submit the listing and extension mechanism Internet-Drafts to IESG for consideration as Proposed Standards.

Mar 97 

Issue an Internet-Draft for checkpoint/restart.

Apr 97 

Issue a second Internet-Draft for IPv6 support and to remove the necessity of transmitting IP addresses.

Apr 97 

Issue a second Internet-Draft for checkpoint/restart.

May 97 

Submit the IPv6/IP and checkpoint/restart Internet-Drafts to IESG for consideration as Proposed Standards.


· MLST Command and Extensions to FTP 

· Internationalization of the File Transfer Protocol 

· REST Command and Extensions to FTP

No Request For Comments 

Current Meeting Report

Minutes of the Extensions to FTP (FTPEXT) Working Group 

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. 

VI. IPv6 Slides 

---Slide 1--- 

FTP Extensions for Variable Protocol Specification 


April 9, 1997 

Mark Allman and Shawn Ostermann 


Ohio University 


---Slide 2--- 

PORT/PASV Examples 


PASV Command 


---Slide 3--- 


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 


---Slide 4--- 


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--- 


FTP command sent from one machine to another. 

Allows the use of \textit{extended addresses}. 

Format: EPRT <NP>|<TP>|<NA>|<TA> 

<NP> - network protocol 

<TP> - transport protocol 

<NA> - network address 

<TA> - 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: 

IP6 -IPv6 string representations defined in RFC 1884. 

-Example: 1080::8:800:200C:417A 

---Slide 8--- 

Transport Address Formats 


-String representation of decimal port number. 

-Example: 6446 


-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||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 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. 

Text response format: 

(prot1,prot2,...,protN) <text for people> 

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 11--- 


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. 

Example response: 

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). 

---Slide 12--- 

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: 


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. 

---Slide 13--- 

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 


April 9, 1997 

Mark Allman and Shawn Ostermann 


Ohio University 


---Slide 2--- 


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: 


---Slide 4--- 

The Bounce Attack 

Example using FTP to ``attack'' SMTP server on a third machine: 


---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. 

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 6--- 

Restricted Access 

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. 

---Slide 7--- 

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. It is SUGGESTED that FTP clients and servers use alternate encryption mechanisms, such as draft-ietf-cat-ftpsec-09.txt, to prevent eavesdropping. 

---Slide 8--- 

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 is chosen randomly. 


1. I18N Draft  Attendees List

Attendees List