|There are a three crypto methods in place for FTP. They are SFTP, FTPS and "FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet" better known as AS3 (what I am calling FTPSX below). AS3 is an EDIINT effort.
There are some confusing factors about SFTP. Note that all three have been referred to as SFTP, so there is some room for confusion. They are all slightly different from each other. That is, there are a few terms that are exact but mean different things. So you need to be sure what SFTP is being addressed. The market should know what they are buying and what client they purchase is using what protocol or TDTWG would need to define which client they should use.
In the label headers below, I gave each a name that fits best regards to .
1. SFTP can mean RFC 4217 "Securing FTP with TLS". This has also been called Secure FTP. This can be thought of as FTPS (like HTTPS in method). TLS is a development of the Netscape Communication. RFC 4217 also uses the commands of RFC 2228 as defined in AS3 (FTPSX) below through TLS. This protocol can be used with AS3, (FTPSX) below Internet MIME encapsulation. In addition to AS3, here is a list of other products using this protocol: http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html#client
2. SFTP can also mean securing FTP by "The Secure Shell (SSH) Protocol Architecture", RFC4251 with the "SSH File Transfer Protocol, draft-ietf-secsh-filexfer-13.txt" and "draft-ietf-secsh-scp-sftp-ssh-uri-03.txt" This is really the best definition of SFTP in my opinion. SSH alone employs public/private key technology for authenticating and encrypting sessions between user accounts on distributed hosts on the Internet.
SFTP specifically means SSH File Transfer Protocol. SSH comes from the UNIX world and is a secure shell. There are programs that just run this SSH alone, with limited functionality. SSH was a DOS window-type application on Windows and of course UNIX style command prompt in UNIX (putty.exe is a popular SSH-only terminal client- http://www.socsci.umn.edu/ssrf/doc/ssh.html). Lately SSH FTP (SFTP) has come with a GUI and drag and drop technology. SSH itself has some issues with man in the middle attacks and the ability to recognize these is up to the user (some GUI/API's may handled this automatically). A man in the middle attack is an event where someone puts up a server such as a proxy that intercepts messages. SSH1 had this problem, SSH2 solved this issue.
Free SFTP client using SSH: http://winscp.net/eng/download.php (SCP in WinSCP means Secure Copy Protocol and is bundled with SSH or SFTP) ... Confused yet?
SFTP (SSH FTP) is defined by draft-ietf-secsh-filexfer-13.txt and draft-ietf-secsh-scp-sftp-ssh-uri-03.txt (a URI scheme). It's not IETF approved (nor is draft-ietf-secsh-filexfer-13.txt, which documents the protocol). SSH or secure shell was originally designed as a secure method for remote login (still in use today). This would act similar to telnet or SNMP (simple network management protocol) in many aspects.
3. SFTP can be confused with Simple File Transfer Protocol, the same acronym as SSH File Transfer Protocol. Simple FTP is something completely different than Secure FTP.
Historically, the term "SFTP" was used to describe port-numbers (refers to port 115), with usage described in RFC 913, which is declared Historic (This probably was not used in real applications)
Simple File Transfer Protocol, (RFC 913), was proposed as an (unsecured) file transfer protocol with a level of complexity intermediate between TFTP (Trivial File Transfer Protocol was first defined in 1980 and is a very simple file transfer protocol, with the functionality of a very basic form of FTP) and FTP. TFTP runs on a UDP port 69 as opposed to an TCP/IP port of 21 for FTP. SFTP in number 2 above uses TCP/IP port 22 or 23 typically.
SFTP was never widely accepted on the Internet, and is now assigned Historic status by the IETF. It runs through port 115, and often receives the acronym of SFTP.
4. AS3 is also a secure FTP protocol and uses "FTP Security Extensions", RFC 2228" as referenced by "FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet, draft-ietf-ediint-as3-04.txtbut" It is not typically called SFTP, however it is. This basically creates a bi-directional communication between server and client to handshake and negotiate the connection through sequenced commands. Once the connection is secure, then the data is sent through the channel. This is not the same as FTPS above, but has similar properties. Different levels of access can be achieved with
C - Clear
S - Safe
E - Confidential
P - Private
commands (typically sent in the GUI; not manually).
From RFC 2228:
"If unprotected commands are allowed on any connection, then an attacker could insert a command on the control stream, and the server would have no way to know that it was invalid. In order to prevent such attacks, once a security data exchange completes successfully, if the security mechanism supports integrity, then integrity (via the MIC or ENC command, and 631 or 632 reply) must be used, until the CCC command is issued to enable non-integrity protected control channel messages. The CCC command itself must be integrity protected."
The great thing about AS3 (FTPSX) is that the server is specialized to provide non-repudiation of receipt and guaranteed delivery which the others are not.
Standard FTP is RFC 959
Comparison of SFTP clients: http://en.wikipedia.org/wiki/List_of_SFTP_clients
Comparison of SFTP Servers: http://en.wikipedia.org/wiki/List_of_SFTP_servers
Considerations (for your questions below):
1. Will the hosted SFTP server allow any other type of access, such as standard FTP? or other direct or indirect access?
2. What considerations have been made for man-in-the middle attacks? - A server setup to redirect and intercept packets, possibly altering contents or running crypto algorithms on captured data while fording the original on to its destination. Another method is the hacker assuming or pretending to be the host.
3. Does the secure software (SFTP) use the latest version of SSH? SSH2 applies a keyed message authentication code (MACs) based on SHA1 and MD5 crypto algorithms.
SSH1 uses port forwarding, basically you login securely to port 22 with SSH and that machine forwards file transfers to another machine on Port 21. SSH2 does not use this method. The "not secure" could have come from implementations of SSH1.
4. Which SFTP is TDTWG thinking of deploying? This must be made very specific and clear in light of the above ambiguity. They must know the strengths and weaknesses of each above to make a decision.
5. SFTP it is a high level protocol, it will be in common use, whereas AS3 for example, has specific MIME headers that are required within it, packets that are routed to a server that supports AS3 may have an advantage over packets that are more common as a hacker deterrent. SFTP will also have encrypted MINE headers.
6. If SFTP is used and the data is critical, the data should NOT remain on the communications server, especially if it is in the DMZ. If the information, such as account, name, address, etc. is still useful in years to come, even though encrypted, it should be moved off as even encrypted files can eventually be hacked with enough time and computer power. Like you said, you would not want to be liable for putting a CR out of business. This really depends on a lot of variables and probability becomes greater as time moves forward.
7. As a protocol most above are fine as long as everyone is controlled through SFTP versions. I do believe that SFTP with SSH is backward compatible from SSH2 to SSH1. An SSH2 server can accept SSH1 packets. Configurations to allow and disallow functionality would have to be investigated. Meaning you would hve to insure, for example, that each client used SSH2.