From ftp-wg-owner@hethmon.com Wed Nov 7 10:07:10 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 KAA10246 for ; Wed, 7 Nov 2001 10:07:09 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011107101157-40995-9 ; Wed, 07 Nov 2001 10:11:57 -0500 Received: from d06lmsgate-4.uk.ibm.COM ([195.212.29.4] [195.212.29.4]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011107101148-44723-8 ; Wed, 07 Nov 2001 10:11:52 -0500 Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate-4.uk.ibm.COM (1.0.0) with ESMTP id OAA133160 for ; Wed, 7 Nov 2001 14:52:15 GMT Received: from d06ml035.portsmouth.uk.ibm.com (d06ml035_cs0 [9.180.35.16]) by d06relay02.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id fA7F3O6140214 for ; Wed, 7 Nov 2001 15:03:24 GMT 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.8 |June 18, 2001) at 07/11/2001 15:03:23, Serialize complete at 07/11/2001 15:03:23 Content-Type: text/plain; charset="us-ascii" Date: Wed, 7 Nov 2001 10:11:54 -0500 X-OldDate: Wed, 7 Nov 2001 15:03:25 +0000 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: I-D ACTION:draft-fordh-ftp-ssl-firewall-00.txt I draw your attention to this: Comments and suggestions gratefully received. (to me, not the list please) 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 http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html ----- Forwarded by Paul V Ford-Hutchinson/UK/IBM on 07/11/2001 03:00 PM ----- Internet-Drafts@ietf.org Sent by: nsyracus@cnri.reston.va.us 07/11/2001 12:05 PM Please respond to Internet-Drafts To: IETF-Announce: ; cc: Subject: I-D ACTION:draft-fordh-ftp-ssl-firewall-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : FTP/TLS Friendly Firewalls Author(s) : P. Ford-Hutchinson Filename : draft-fordh-ftp-ssl-firewall-00.txt Pages : 13 Date : 06-Nov-01 This document discusses some of the issues with running FTP, secured with TLS as defined in [FTP-TLS], through firewalls. FTP is known to be a bit of a problem for firewalls (see [RFC-1579] for a discussion of normal FTP and firewalls). Some of the problems have been fixed by adding intelligence into the firewall. With secured FTP, where the control connection is encrypted, some of these techniques fail. Whilst this document confines itself to issues of FTP over TLS, the issues will probably be relevant for most secured FTP protocols that conform to [RFC-2228]. Some of the discussions will also be relevant to any protocol that firewalls do clever things with. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fordh-ftp-ssl-firewall-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-fordh-ftp-ssl-firewall-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-fordh-ftp-ssl-firewall-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://ftp.ietf.org/internet-drafts/draft-fordh-ftp-ssl-firewall-00.txt From ftp-wg-owner@hethmon.com Wed Nov 7 10:33:56 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 KAA11936 for ; Wed, 7 Nov 2001 10:33:55 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011107103851-2813-9 ; Wed, 07 Nov 2001 10:38:51 -0500 Received: from watsun.cc.columbia.edu ([128.59.39.2] [128.59.39.2]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011107103846-43590-8 ; Wed, 07 Nov 2001 10:38:47 -0500 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id KAA16338 for FTPEXT Working Group ; Wed, 7 Nov 2001 10:31:32 -0500 (EST) In-Reply-To: Your message of Wed, 7 Nov 2001 10:11:54 -0500 Message-ID: Date: Wed, 7 Nov 2001 10:38:48 -0500 X-OldDate: Wed, 7 Nov 2001 10:31:32 EST 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: I-D ACTION:draft-fordh-ftp-ssl-firewall-00.txt I'm looking at it now. I would point out that it can be generalized to describe FTP secured with any AUTH type, not just TLS. > I draw your attention to this: > > Comments and suggestions gratefully received. (to me, not the list > please) > > 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 > http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html > > ----- Forwarded by Paul V Ford-Hutchinson/UK/IBM on 07/11/2001 03:00 PM > ----- > Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 Beta 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 Fri Nov 9 10:28:44 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 KAA15231 for ; Fri, 9 Nov 2001 10:28:44 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011109103047-2011-13 ; Fri, 09 Nov 2001 10:30:48 -0500 Received: from PostMail ([210.71.181.206] [210.71.181.206]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011109103042-39368-11 ; Fri, 09 Nov 2001 10:30:43 -0500 Received: from pchome by tpts6.seed.net.tw with SMTP id JH9ZwvPjj44tKPO0V9Skak; Fri, 09 Nov 2001 23:25:41 +0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_Wo7skhckThuNiN3OJ0LnmQ4hOxrP" X-Mailer: Ppq0m120BDAlx5jVq11uoAFBD X-Priority: 3 X-MSMail-Priority: Normal Date: Fri, 9 Nov 2001 10:30:44 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Net5.Online.FortuneTelling To: LuckyPeople Subject: Ftp-WG: Net5 Online FortuneTelling This is a multi-part message in MIME format. ------=_NextPart_Wo7skhckThuNiN3OJ0LnmQ4hOxrP Content-Type: multipart/alternative; boundary="----=_NextPart_Wo7skhckThuNiN3OJ0LnmQ4hOxrPAA" ------=_NextPart_Wo7skhckThuNiN3OJ0LnmQ4hOxrPAA Content-Type: text/html; charset="big5" Content-Transfer-Encoding: base64 PGh0bWw+DQo8ZnJhbWVzZXQgcm93cz0qIGZyYW1lYm9yZGVyPSJOTyIgYm9yZGVyPSIwIiBmcmFt ZXNwYWNpbmc9IjAiIGNvbHM9Kj4NCjxmcmFtZSBzY3JvbGxpbmc9InllcyIgc3JjPSJodHRwOi8v d3d3Lm5ldHM1LmNvbS9BRC9uZXdzLmh0bSI+DQo8L2ZyYW1lc2V0Pg0KPC9odG1sPg== ------=_NextPart_Wo7skhckThuNiN3OJ0LnmQ4hOxrPAA-- ------=_NextPart_Wo7skhckThuNiN3OJ0LnmQ4hOxrP-- From ftp-wg-owner@hethmon.com Tue Nov 27 14:14:35 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 OAA19180 for ; Tue, 27 Nov 2001 14:14:34 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011127141423-62163-9 ; Tue, 27 Nov 2001 14:14:23 -0500 Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1] [202.28.96.1]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011127141417-52858-8 ; Tue, 27 Nov 2001 14:14:18 -0500 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fARJ6Y002869; Wed, 28 Nov 2001 02:06:35 +0700 (ICT) In-Reply-To: <20011127023256.D8299@fysh.org> References: <20011127023256.D8299@fysh.org> <200111262100.QAA00874@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <2867.1006887994@brandenburg.cs.mu.OZ.AU> Date: Tue, 27 Nov 2001 14:14:20 -0500 X-OldDate: Wed, 28 Nov 2001 02:06:34 +0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: Zefram Subject: Ftp-WG: Re: Last Call: Extensions to FTP to Proposed Standard Date: Tue, 27 Nov 2001 02:32:56 +0000 From: Zefram Message-ID: <20011127023256.D8299@fysh.org> Thanks for the comments. I'm quoting almost your entire message for the benefit of the ftpext WG list ... | There are a couple of unclarities in the specification that should be | cleaned up: | | Section 2.4 states that "unless stated to the contrary, any reply to any | FTP command ... may be of the multi-line format". It doesn't say what | counts as stating to the contrary, except to say that ABNF indicating a | single-line response format is not sufficient to require a single-line | response. This makes those parts of the specification that provide a | more restricted syntax for certain replies ambiguous: it isn't clear | where multi-line responses are permitted. This happens in section 3.1 | (defining a successful MDTM reply) and 4.1 (SIZE): both give ABNF that | on its face allows only for a single-line reply, and in neither case | is the applicability of 2.4's implicit multi-line reply rule explicitly | addressed. Neither section says what a valid multi-line success reply | (to MDTM or SIZE) would look like. I guess that multi-line replies aren't | intended to be permitted in this case, but in the light of section 2.4 | it's unclear. Shouldn't we instead have an explicit note in cases where | an ABNF rule is intended to be taken *non*-literally? I'm not sure about that, though SIZE and MDTM should both say that only one line is permitted I think. After the last call has ended, and working group permitting, I will fix that (along with anything else discovered that needs fixing). I'll see if there are any others. But in the general case, any ftp response, can be multi-line (which certainly applies to all of the error responses) so I don't think that changing the sense of the comment in 2.4 would be the right solution. It might also be worth asking whether there is really any reason for the SIZE, MDTM commands, etc, to actually be restricted to one line replies, provided that however many lines are generated, just the required information is returned. | Section 3.1, on the MDTM command, says "Attempts to query the modification | time of files that are unable to be retrieved generate undefined | responses.". The phrase "undefined responses" sounds like it permits | what would otherwise be violations of the protocol, such that the client | cannot correctly infer any information from what happens later in the | session, and in fact that the client cannot determine whether this has | happened. That wasn't the intent, perhaps this could be clarified. Clearly though, I think, it is only the response generated that is undefined, nothing that would affect the rest of the session (that is, it doesn't say it has an undefined effect, just generates an undefined response). But more than that, the intent is that the syntax would still be correctly generated, but that the value returned might be rubbish - and yes, without the client having any way to tell that it happened. | Sections 3.1 and 3.2 go on to provide perfectly sensible ways | of handling error conditions within the protocol, so "undefined responses" | seem unnecessary. No, the expectation is that the server is not required to check whether the object for which the mod time is requested has a sensible mod time to return. If the underlying OS generates an error, then the server will generally reply with an error code. If not, but simply returns some value which isn't what would normally be considered as a modification time, then the server is allowed to simply send that back to the client, it doesn't have to test whether the value it obtained is rational or not. | Probably the "undefined responses" sentence should be | removed or modified, perhaps to something like "Attempts ... may generate | either errors or successful responses that might not be meaningful.". That is more or less what "generate undefined responses" was intended to convey. That is, you'll get a response, but what that response might be isn't defined... | If "undefined responses" was intended to permit some other historical | behaviour, the limits of such behaviour should be specified. Certainly, the MTDM (and SIZE) sections (and stream mode restart) are just intended to document functions that have been in ftp servers for 15 years or so now, both so their functionality can be reliably used, and so others know exactly what is required to implement them. About the only limit that I can see being reasonable here is that if a response that looks like a success response is generated, then it should conform to the syntax. kre