Subject: Ftp-WG: PROXY mode

From: Jeffrey Altman <[email-masked]>
Date: Tue, 26 Jun 2001 07:33:40 -0500

> Other 
> =====
> 
> The server-server part of the passive mechanism can be used in a security 
> attack (see draft-ietf-ftpext-sec-consider-02.txt) - "Bounce Attack".  It 
> may be perfectly acceptable for a server to refuse PASV connections to a 
> host that is not the owner of the control connection, in which case the 
> server-server stuff may be irrelevant.
> 
> My personal guess is that a client's ablility to do server-server is a 
> pretty powerful tool that is understood by a few people who will fight for 
> it forever.  But in practice it is little used and can cause problems. 
> 
> Please also note that pretty much all ftp security extensions (RFC 2228, 
> draft-murray-auth-ftp-ssl-07.txt, etc ...) forbid server-server file 
> transfer.  This is for practical rather than pure security reasons.
> 
> Cheers,
> Paul

Server to Server file transfers are very powerful.  They are also
secure when used with appropriate authentication methods such as 
GSSAPI Kerberos 5 User to User mode.

 Jeffrey Altman * Sr.Software Designer      C-Kermit 7.1 Alpha available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 [email-masked]          OpenSSL.  SSH soon to follow.

---

From: "Gregory A Lundberg" <[email-masked]>
Date: Tue, 26 Jun 2001 07:53:53 -0500

> GSSAPI Kerberos 5 User to User mode.

Yes, it's powerful.  Yes, it should stay there; not specifically for
server-to-server transfers but as a side-effect of having both PORT and PASV
commands.  To do away with server-to-server transfers we have to eliminate
the PORT command, abandoning support for virtually all legacy clients.

Yes, it's infrequently used.  I get a dozen or so questions a year
concerning server-to-server transfers.  I'd say that puts it far down below
the 1% mark, but the sites who've asked me about it push a LOT of traffic
and it makes things a lot easier for them to use a central control client
rather than having to push update scripts around to all their machines.

GSSAPI and such not do not "secure" the problems with the PORT command, nor
can or do they forbid it; at best, they tell us that we cannot their
features and still expect cryptographic methods to operate over the data
channel.  Most likely, using GSSAPI simply means the client has properly
authenticated itself to the server it is using to attack other hosts.
That's nice only in that it assists administrators in tracking down the
culprit, but does nothing to actually prevent the activity.

What we've done in WU-FTPD is make the default such that a client cannot
issue a PORT command specifying a destination address different than the
apparent source address on the control connection.  This kills
server-to-server transfers, so we then added a configuration option which
re-enables a client's ability to specify a different destination address.
Yes, this slightly increased the number of support questions, but not
appreciably; most of the new questions were from NAT'd clients which were
not following RFC 1579 by default.  I've found questions such as the one
which prompted this discussion to stem usually come from our changes and a
NAT'd client running afoul of each other.

--

Gregory A Lundberg              WU-FTPD Development Group
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195