[ftpext] 1st post; miscellaneous FTP additions.

["Alun Jones" <[e-mail]>]

First, thanks to everyone here for starting up another FTP extensions
Working Group. I enjoyed the last one and look forward to hearing much more
on the ways we can move FTP forward.

 

Having read the mailing list archives to date, here are a relatively random
list of observations:

1.       I found this mailing list through a rather random reading of the
IETF mailing list. Pure chance. Should this WG perhaps reach out to members
of the previous WG's mailing list to let them know that there is a new WG to
which they might wish to subscribe? [Or was there an announcement that I
simply missed?]

2.       I would very much like to see us address not only new and
interesting features, but some of the issues that cause enterprises to avoid
using FTP. Particularly, I note that there's a perception that FTP is
unsecure, that it's not standard (peculiarly enough, SFTP is given as the
standard alternative, despite not actually having any standards
documentation), that it's inefficient (not sure what is meant by that), that
it requires massive firewall holes, and that it frequently fails through
firewalls even if you think you have the right holes open. To that end:

a.       I would like to suggest the use of MODE B with the default data
port as common practice. In the absence of errors in communication, or
client-requested aborts, this works well through existing firewalls, as well
as with TLS, is portable to IPv6, has been a standard since at least RFC 959
days, and only requires that clients request and support MODE B as an
option. Some steps to improve this would include:

                                                               i.
Document how MODE B should recover from client-requested aborts, even if the
recovery is simply "close all connections and try again".

                                                             ii.
Augment MODE B - for instance, specify options to state that TYPE I, STRU F,
can avoid sending REST markers in the data stream.

b.      Where port assignments are made, use random port assignments as
specified in the recent BCP draft
http://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-randomization/ to
improve protection against port guessing. Are there any standard protocols
to use to open firewall holes in relation to existing traffic? UPnP springs
to mind, but if there are any other protocols we could use as FTP server /
client authors to open these ports (or avoid having to), it is important
that we document the use of these for FTP.

c.       To address storage security of transferred files, it may be
appropriate to add commands and responses for the following cases:

                                                               i.
Client requests that server receive next STOR / STOU as sensitive file, and
stores it in encrypted storage (with affirmative response if it can do this)

                                                             ii.      Server
refuses to send file in response to RETR until client asserts that it will
be storing it in encrypted storage.

3.       It was suggested earlier in the mailing list that a command be
provided for encrypting passwords in transit in some way. While I agree with
the general sentiment that TLS should be used for such cases (because the
password is generally only sensitive because of the data it protects, and
therefore the commands and data should be encrypted and integrity-protected
also), there is, or was, a standard for SASL passwords in FTP - I simply
can't find it right now.

4.       Keeping firewalls open through long data transfers can adequately
be achieved using the NOOP command at regular intervals, or if that command
is not supported, the STAT command, which is already documented to give a
user-readable status during a data transfer.

5.       GSSAPI FTP as defined in RFC 2228 should be deprecated, as it does
not provide for separate encryption contexts between the command and data
ports - because they share an encryption context, if a command is sent
during a transfer, the synchronization is lost, and all further data and
commands are garbled and unreadable.

6.       FTP URIs don't work as documented. I have yet to see a single
client implementation that treats "ftp://example.com/foo" as an invitation
to connect to example.com and issue the "CWD foo" command - they all issue
"CWD /foo". Clinging to ancient documentation that is always ignored seems
to be a waste of time. Deprecate the old behaviour, and as crappy as it may
be, adopt and accept the behaviour that "all paths are from the root unless
they begin with a dot. (ftp://example.com/./foo)"

 

Well, that's enough to be getting on with - let me know if any of these
ideas are worth considering, or should be discarded immediately.

 

Thanks again for setting this list up,

 

Alun Jones

[Author, WFTPD and WFTPD Pro - http://www.wftpd.com]