From ftp-wg-owner@hethmon.com Mon Jun 25 15:40:34 2001 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25208 for ; Mon, 25 Jun 2001 15:40:34 -0400 (EDT) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20010625144238-32912-9 ; Mon, 25 Jun 2001 14:42:38 -0500 Received: from e22.nc.us.ibm.com ([32.97.136.228] [32.97.136.228]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20010625144233-45693-8 ; Mon, 25 Jun 2001 14:42:33 -0500 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA76086 for ; Mon, 25 Jun 2001 15:25:59 -0500 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5PJaCc63166 for ; Mon, 25 Jun 2001 15:36:12 -0400 Importance: Normal X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M9_05202001 Beta 2|May 20, 2001) at 06/25/2001 03:36:11 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Date: Mon, 25 Jun 2001 14:42:35 -0500 X-OldDate: Mon, 25 Jun 2001 15:36:11 -0400 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Janet Wolf" To: ftp-wg@hethmon.com Subject: Ftp-WG: PROXY mode One thing I would like to understand about PROXY mode is: is it often implemented? is it often used? How is proxy mode used? I realize it allows a client to send files directly from server to server, but how do folks exploit this capability? Any insights you can provide are very welcome! Thanks! From ftp-wg-owner@hethmon.com Tue Jun 26 06:55:12 2001 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26869 for ; Tue, 26 Jun 2001 06:55:12 -0400 (EDT) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20010626055756-58949-14 ; Tue, 26 Jun 2001 05:57:56 -0500 Received: from d06lmsgate-3.uk.ibm.com ([195.212.29.3] [195.212.29.3]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20010626055752-1607-12 ; Tue, 26 Jun 2001 05:57:53 -0500 Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate-3.uk.ibm.com (1.0.0) with ESMTP id LAA109606 for ; Tue, 26 Jun 2001 11:42:10 +0100 Received: from d06ml035.portsmouth.uk.ibm.com (d06ml035_cs0 [9.180.35.16]) by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5QApB3142826 for ; Tue, 26 Jun 2001 11:51:12 +0100 Importance: Normal MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: X-MIMETrack: Serialize by Router on D06ML035/06/M/IBM(Release 5.0.6 |December 14, 2000) at 26/06/2001 11:50:33, Serialize complete at 26/06/2001 11:50:33 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Jun 2001 05:57:53 -0500 X-OldDate: Tue, 26 Jun 2001 11:48:11 +0100 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Paul V Ford-Hutchinson" To: FTPEXT Working Group Subject: Ftp-WG: PROXY mode I assume, by 'proxy mode' you are referring to the PASV mechanism. How does it work ? Normally, FTP gets the server to connect to the client to initiate the data connection. In passive mode, the connection goes the other way. NORMAL ========= client gets socket() and bind()s (and gets port number from O/S) C>S2 PORT 10,1,1,1,5,5 S2>C 200 text C>S2 STOR filename server2 gets socket S2>C 150 text server2 connect()s to client address/port (from PORT command) data flows and connection is close()d S2>C 226 text PASSIVE ======== C>S1 PASV server1 gets socket() and bind()s to port (and gets port number from O/S) S1>C 227 (10,1,1,2,5,6) client gets socket() C>S1 RETR file client connects to server1 S1>C 150 text data flows and conection is close()d S1>C 226 text So, for server->server file xfer we combine the two ========================================== C>S1 PASV server1 gets socket() and bind()s to port (and gets port number from O/S) S1>C 227 (10,1,1,2,5,6) client forwards to Server 2 C>S2 PORT 10,1,1,2,5,6 S2>C 200 text C>S2 STOR filename server2 gets socket S2>C 150 text C>S1 RETR filename server2 connect()s to server1 address/port (from PORT command) S1>C 150 text data flows and connection is close()d S1>C 226 text S2>C 226 text Server support ============= - PASV is very important fro Firewall Friendly ftp (RFC 1579) and should be implemented in servers for this purpose if for no other reason - PASV for allowing Server-Server file transfer is defined in RFC 959 - PASV must be supported according to RFC 1123 Client Support ============ - A client's support for RFC 1579 is pretty sensible (but some major ones do not) - A client's support for Server-Server file xfer is pretty much QOI issue. (again, many don't) - I have no idea how much the server-server stuff is actually used. 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 -- Paul Ford-Hutchinson : eCommerce application security : paulfordh@uk.ibm.com MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5JL +44 (0)1926 462005 Please respond to FTPEXT Working Group To: ftp-wg@hethmon.com cc: Subject: Ftp-WG: PROXY mode One thing I would like to understand about PROXY mode is: is it often implemented? is it often used? How is proxy mode used? I realize it allows a client to send files directly from server to server, but how do folks exploit this capability? Any insights you can provide are very welcome! Thanks! From ftp-wg-owner@hethmon.com Tue Jun 26 08:30:43 2001 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00177 for ; Tue, 26 Jun 2001 08:30:41 -0400 (EDT) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20010626073342-60882-9 ; Tue, 26 Jun 2001 07:33:42 -0500 Received: from watsun.cc.columbia.edu ([128.59.39.2] [128.59.39.2]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20010626073338-40343-8 ; Tue, 26 Jun 2001 07:33:38 -0500 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id IAA16361; Tue, 26 Jun 2001 08:27:18 -0400 (EDT) In-Reply-To: Your message of Tue, 26 Jun 2001 05:57:53 -0500 Message-ID: Date: Tue, 26 Jun 2001 07:33:40 -0500 X-OldDate: Tue, 26 Jun 2001 8:27:16 EDT Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Jeffrey Altman To: FTPEXT Working Group Subject: Ftp-WG: PROXY mode > 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 kermit-support@kermit-project.org OpenSSL. SSH soon to follow. From ftp-wg-owner@hethmon.com Tue Jun 26 08:50:32 2001 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01061 for ; Tue, 26 Jun 2001 08:50:30 -0400 (EDT) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20010626075356-30917-10 ; Tue, 26 Jun 2001 07:53:56 -0500 Received: from mail.vr.net ([205.133.13.8] [205.133.13.8]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20010626075350-57140-9 ; Tue, 26 Jun 2001 07:53:51 -0500 Received: from osiris (osiris.vr.net [205.133.13.9]) by mail.vr.net (8.10.1/8.10.1) with SMTP id f5QClPb24752 for ; Tue, 26 Jun 2001 08:47:26 -0400 Message-ID: <008e01c0fe3e$23218280$090d85cd@vr.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Date: Tue, 26 Jun 2001 07:53:53 -0500 X-OldDate: Tue, 26 Jun 2001 08:47:12 -0400 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Gregory A Lundberg" To: "FTPEXT Working Group" Subject: Ftp-WG: PROXY mode Content-Transfer-Encoding: 7bit > > 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. 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 lundberg@wu-ftpd.org Kettering, OH 45409-1615 USA 1-800-809-2195 From ftp-wg-owner@hethmon.com Tue Jun 26 09:21:55 2001 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02940 for ; Tue, 26 Jun 2001 09:21:54 -0400 (EDT) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20010626082447-60868-9 ; Tue, 26 Jun 2001 08:24:47 -0500 Received: from watsun.cc.columbia.edu ([128.59.39.2] [128.59.39.2]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20010626082442-40403-8 ; Tue, 26 Jun 2001 08:24:42 -0500 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id JAA17793; Tue, 26 Jun 2001 09:18:23 -0400 (EDT) In-Reply-To: Your message of Tue, 26 Jun 2001 07:53:53 -0500 Message-ID: Date: Tue, 26 Jun 2001 08:24:44 -0500 X-OldDate: Tue, 26 Jun 2001 9:18:22 EDT Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Jeffrey Altman To: FTPEXT Working Group Subject: Ftp-WG: PROXY mode When GSSAPI Kerberos 5 User to User mode is used. The clients credentials are forwarded to each of the FTP daemons. These credentials are then used to authenticate the Server to Server connection. If the authentication fails, the Server to Server connection is denied. How does this not protect the PROXY? > 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 lundberg@wu-ftpd.org > Kettering, OH 45409-1615 USA 1-800-809-2195 > > > 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 kermit-support@kermit-project.org OpenSSL. SSH soon to follow. From ftp-wg-owner@hethmon.com Tue Jun 26 11:41:14 2001 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22731 for ; Tue, 26 Jun 2001 11:41:13 -0400 (EDT) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20010626104343-16421-9 ; Tue, 26 Jun 2001 10:43:43 -0500 Received: from mailgw2.netvision.net.il ([194.90.1.9] [194.90.1.9]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20010626104337-58455-8 ; Tue, 26 Jun 2001 10:43:38 -0500 Received: from netvision.net.il (ras7-p158.jlm.netvision.net.il [62.0.149.158]) by mailgw2.netvision.net.il (8.9.3/8.9.3) with ESMTP id SAA23571 for ; Tue, 26 Jun 2001 18:39:26 +0300 (IDT) Message-ID: <3B38BA2A.641EEA8@netvision.net.il> X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 26 Jun 2001 10:43:40 -0500 X-OldDate: Tue, 26 Jun 2001 18:36:58 +0200 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Yonatan Ben-Ya'akov" To: FTPEXT Working Group Subject: Ftp-WG: unsubscribe Content-Transfer-Encoding: 7bit Jeffrey Altman wrote: > When GSSAPI Kerberos 5 User to User mode is used. The clients > credentials are forwarded to each of the FTP daemons. These > credentials are then used to authenticate the Server to Server > connection. If the authentication fails, the Server to Server > connection is denied. How does this not protect the PROXY? > > > 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 lundberg@wu-ftpd.org > > Kettering, OH 45409-1615 USA 1-800-809-2195 > > > > > > > > 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 > kermit-support@kermit-project.org OpenSSL. SSH soon to follow.