From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 1 09:50:22 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29836 for ; Mon, 1 Apr 2002 09:50:21 -0500 (EST) Received: (qmail 29005 invoked by uid 605); 1 Apr 2002 14:50:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28998 invoked from network); 1 Apr 2002 14:50:17 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 1 Apr 2002 14:50:17 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Apr 2002 09:51:26 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA242@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: RE: SFTP File open modes Date: Mon, 1 Apr 2002 09:51:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list Since both the client and server access files, you can not put the responsibility for doing conversions on either and "solve" the problem. Requiring the client to do it means that the client must know about all possible formats. You can say that encoding conversions are the responsibility of the reader (or writer, take your pick) of the file if a common wire format is agreed upon for certain types of files. (Text in this discussion.) > -----Original Message----- > From: nico [mailto:nico@verizon.net] > Sent: Friday, March 29, 2002 10:13 PM > To: Richard Whalen > Cc: 'ietf-ssh@netbsd.org' > Subject: Re: SFTP File open modes > > > > How many well-known and often utilized ways of encoding ASCII > text files > are there (answer: two)? Is an ASCII mode as you suggest likely to be > useful? Or do we want a mode for UTF-8 and UTF-16, EBCEDIC, and so on? > > Perhaps it would be best to add an operation by which the > client can ask > the server for a given file's content type and encoding. The server's > response should indicate whether it knows, whether it knows > for certain > and, if it knows at all, what the content type is. > > All encoding conversions though should be left to the client though. > > IMHO. Cheers, > > Nico > > On Wed, Mar 27, 2002 at 02:36:06PM -0500, Richard Whalen wrote: > > The current specification of SFTP states that files are > always opened in > > "binary" mode - no translations between different character > sets and newline > > encodings. > > [...] > > > ---------------------- > > Richard Whalen > > Process Software > > 508-879-6994 > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 1 09:53:38 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00048 for ; Mon, 1 Apr 2002 09:53:37 -0500 (EST) Received: (qmail 497 invoked by uid 605); 1 Apr 2002 14:53:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 472 invoked from network); 1 Apr 2002 14:53:34 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 1 Apr 2002 14:53:34 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Apr 2002 09:54:47 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA243@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: RE: Additional thoughts on text transfers Date: Mon, 1 Apr 2002 09:54:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list Text files are still in high usage, even with new (often proprietary) formats that may not be converted. Source code for programs are generally stored as text files, and the input for programs may be text files as well. > -----Original Message----- > From: Markus Friedl [mailto:markus@openbsd.org] > Sent: Saturday, March 30, 2002 11:39 AM > To: Richard Whalen > Cc: 'ietf-ssh@netbsd.org' > Subject: Re: Additional thoughts on text transfers > > > On Fri, Mar 29, 2002 at 08:50:05AM -0500, Richard Whalen wrote: > > Since modern day files may be encoded in a variety of > textual formats the > > client and server need to come to an agreement on a format > when exchanging > > text files. > > Modern day files are binary documents (pdf, doc, viruses), so no > conversions is necessary. SFTP is slim and simple, you can do text > conversion in you client application based on suffix-heuristics, > for example. > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 1 10:34:47 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01878 for ; Mon, 1 Apr 2002 10:34:46 -0500 (EST) Received: (qmail 20071 invoked by uid 605); 1 Apr 2002 15:32:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20059 invoked from network); 1 Apr 2002 15:32:53 -0000 Received: from watsun.cc.columbia.edu (128.59.39.2) by mail.netbsd.org with SMTP; 1 Apr 2002 15:32:53 -0000 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id KAA25947; Mon, 1 Apr 2002 10:32:51 -0500 (EST) Date: Mon, 1 Apr 2002 10:32:51 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Richard Whalen Cc: "'ietf-ssh@netbsd.org'" Subject: RE: Additional thoughts on text transfers In-Reply-To: Your message of Mon, 1 Apr 2002 09:54:44 -0500 Message-ID: Sender: ietf-ssh-owner@netbsd.org Precedence: list Richard: Many of us in the community have raised these issues before. The vast majority of the SSH development community is on Unix. The vast majority of the rest is on Windows. Between the two groups they do not see this as an issue because they are not affected by the scale of the M x N problem which is alleviated by defining a standard on the wire representation for End of Line. The way things are now you are expected to solve this problem in the client by knowing based upon the type of the host you are communicating with how the End of Line is represented. Some people suggest that you should download the file first in binary and then perform the conversion with external tools. Of course, that assumes the receiver is aware of the End of Line representation for both the server and client operating system. The Kermit Project has decided to address this problem by not recommending the use of SFTP. Instead we have modified C-Kermit 8.0 to allow it to be installed as a SSH Subsystem for the purpose of file transfer. Of course, you can still use it to just send files across the SSH terminal session as well. Kermit protocol provides you with recursive directory tree transfers; conversion of pathname formats if necessary; automatic recognition of text or binary mode based upon the content of the file (not just extensions which mean different things to different operating systems); as well as many other features. For details see http://www.kermit-project.org/skermit.html - Jeff > Text files are still in high usage, even with new (often proprietary) > formats that may not be converted. > > Source code for programs are generally stored as text files, and the input > for programs may be text files as well. > > > > -----Original Message----- > > From: Markus Friedl [mailto:markus@openbsd.org] > > Sent: Saturday, March 30, 2002 11:39 AM > > To: Richard Whalen > > Cc: 'ietf-ssh@netbsd.org' > > Subject: Re: Additional thoughts on text transfers > > > > > > On Fri, Mar 29, 2002 at 08:50:05AM -0500, Richard Whalen wrote: > > > Since modern day files may be encoded in a variety of > > textual formats the > > > client and server need to come to an agreement on a format > > when exchanging > > > text files. > > > > Modern day files are binary documents (pdf, doc, viruses), so no > > conversions is necessary. SFTP is slim and simple, you can do text > > conversion in you client application based on suffix-heuristics, > > for example. > > > Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. Interfaces with OpenSSH From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 1 11:14:30 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03269 for ; Mon, 1 Apr 2002 11:14:29 -0500 (EST) Received: (qmail 13530 invoked by uid 605); 1 Apr 2002 16:14:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13523 invoked from network); 1 Apr 2002 16:14:25 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 1 Apr 2002 16:14:25 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Apr 2002 11:15:38 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA245@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: RE: Additional thoughts on text transfers Date: Mon, 1 Apr 2002 11:15:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list The attitude of "the only systems that matter are Unix and Windows" will prevent the SSH File Transfer Protocol from advancing past its current state as I believe that it is technically flawed in its current state. I am willing to follow the procedures in RFC 2026 if necessary. ---------------------- Richard Whalen Process Software > -----Original Message----- > From: Jeffrey Altman [mailto:jaltman@columbia.edu] > Sent: Monday, April 01, 2002 10:33 AM > To: Richard Whalen > Cc: 'ietf-ssh@netbsd.org' > Subject: RE: Additional thoughts on text transfers > > > Richard: > > Many of us in the community have raised these issues before. The vast > majority of the SSH development community is on Unix. The vast > majority of the rest is on Windows. Between the two groups they do > not see this as an issue because they are not affected by the scale of > the M x N problem which is alleviated by defining a standard on the > wire representation for End of Line. > - Jeff > Text files are still in high usage, even with new (often proprietary) > formats that may not be converted. > > Source code for programs are generally stored as text files, and the input > for programs may be text files as well. > > > > -----Original Message----- > > From: Markus Friedl [mailto:markus@openbsd.org] > > Sent: Saturday, March 30, 2002 11:39 AM > > To: Richard Whalen > > Cc: 'ietf-ssh@netbsd.org' > > Subject: Re: Additional thoughts on text transfers > > > > > > On Fri, Mar 29, 2002 at 08:50:05AM -0500, Richard Whalen wrote: > > > Since modern day files may be encoded in a variety of > > textual formats the > > > client and server need to come to an agreement on a format > > when exchanging > > > text files. > > > > Modern day files are binary documents (pdf, doc, viruses), so no > > conversions is necessary. SFTP is slim and simple, you can do text > > conversion in you client application based on suffix-heuristics, > > for example. > > > Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. Interfaces with OpenSSH From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 1 16:55:19 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16454 for ; Mon, 1 Apr 2002 16:55:18 -0500 (EST) Received: (qmail 7555 invoked by uid 605); 1 Apr 2002 21:55:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7541 invoked from network); 1 Apr 2002 21:55:14 -0000 Received: from uria.its.uu.se (130.238.7.14) by mail.netbsd.org with SMTP; 1 Apr 2002 21:55:14 -0000 Received: from dns.ekonomikum.uu.se ([130.238.166.240]:56772 "EHLO r3.ekonomikum.uu.se") by uria.its.uu.se with ESMTP id convert rfc822-to-8bit; Mon, 1 Apr 2002 23:55:00 +0200 Received: (from pont@localhost) by r3.ekonomikum.uu.se (8.10.2+Sun/8.10.2) id g31LsvX28297; Mon, 1 Apr 2002 23:54:57 +0200 (MEST) X-Authentication-Warning: r3.ekonomikum.uu.se: pont set sender to pont@soua.net using -f From: Pontus Skoeld To: Richard Whalen Cc: "'ietf-ssh@netbsd.org'" Subject: Re: Additional thoughts on text transfers References: <63D30D6E10CFD11190A90000F805FE86040AA245@lespaul.process.com> Date: 01 Apr 2002 23:54:57 +0200 In-Reply-To: <63D30D6E10CFD11190A90000F805FE86040AA245@lespaul.process.com> Message-ID: Lines: 54 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8BIT Richard Whalen writes: > The attitude of "the only systems that matter are Unix and Windows" will > prevent the SSH File Transfer Protocol from advancing past its current state > as I believe that it is technically flawed in its current state. I don't think that is really the problem. In my mind, the difference is between what people expect sftp to do for them. A lot of people want ftp, but with an s for secure. Others want something that solves any problem they might have. Certain others don't know (I belong there, but I'm rather sure that I don't want ftp). I think we need to decide what sftp should do (or even if we are the ones to design it or if it belongs to another area). Having said that, I actually think the protocol is quite well designed. Moreover, I consider it to be a remote file system protocol rather than a file-transfer protocol. And to address the current issue; I don't want a "text-mode" for sftp. I believe it will not solve, but create problems. On some systems, it's only a matter of policy (and hence impossible for the sftp-implementation to know) what character sets are used, so we can't reasonably expect servers to handle conversion to wire format. I see the chances of this helping more than it breaks as very slim. We might be able to handle EOL-conversion, but handling that alone doesn't help much, the user would still (likely) need to convert the text, so we may as well leave it be. And ASCII/Binary has been a constant headache with ftp, I don't see why it wouldn't cause the same problems in sftp. To me, the proper solution is to let the user convert the file if necessary, which, as Marcus pointed out and my own experiences tells me, is rather seldom nowadays. One thing we might consider (though I'm not certain what I think of it myself) is adding an extension to the file attributes, allowing the declaration of the file contents and character set and anything else you'd want to know (think Content-Type with certain bonuses). This would allow for easy conversion if necessary (supposedly most often by the client). In short; I recognize the problem, I just don't think the file transfer protocol should be responsible for fixing it. /Pontus -- Pontus Sköld, see for more information. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 1 17:03:42 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16607 for ; Mon, 1 Apr 2002 17:03:41 -0500 (EST) Received: (qmail 12015 invoked by uid 605); 1 Apr 2002 22:03:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12006 invoked from network); 1 Apr 2002 22:03:39 -0000 Received: from watsun.cc.columbia.edu (128.59.39.2) by mail.netbsd.org with SMTP; 1 Apr 2002 22:03:39 -0000 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id RAA19310; Mon, 1 Apr 2002 17:03:29 -0500 (EST) Date: Mon, 1 Apr 2002 17:03:29 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Pontus Skoeld Cc: Richard Whalen , "'ietf-ssh@netbsd.org'" Subject: Re: Additional thoughts on text transfers In-Reply-To: Your message of 01 Apr 2002 23:54:57 +0200 Message-ID: Sender: ietf-ssh-owner@netbsd.org Precedence: list > I see the chances of this helping more than it breaks as very slim. We > might be able to handle EOL-conversion, but handling that alone > doesn't help much, the user would still (likely) need to convert the > text, so we may as well leave it be. > > To me, the proper solution is to let the user convert the file if > necessary, which, as Marcus pointed out and my own experiences tells > me, is rather seldom nowadays. > I think it is more to the point that the developers of SFTP rarely perform transfers that require EOL conversion. These are certainly not my customers. I don't believe that SFTP meets the requirements of my customers but then my customers can use Kermit Protocol so I don't feel so strongly about it. Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. Interfaces with OpenSSH From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 1 17:06:04 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16650 for ; Mon, 1 Apr 2002 17:06:02 -0500 (EST) Received: (qmail 13856 invoked by uid 605); 1 Apr 2002 22:06:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13849 invoked from network); 1 Apr 2002 22:06:01 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 1 Apr 2002 22:06:01 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id AAA11919; Tue, 2 Apr 2002 00:05:55 +0200 (MEST) Date: Tue, 2 Apr 2002 00:05:54 +0200 From: Markus Friedl To: Jeffrey Altman Cc: Pontus Skoeld , Richard Whalen , "'ietf-ssh@netbsd.org'" Subject: Re: Additional thoughts on text transfers Message-ID: <20020401220554.GA1839@faui02> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Apr 01, 2002 at 05:03:29PM -0500, Jeffrey Altman wrote: > I don't believe that SFTP meets the requirements of > my customers but then my customers can use Kermit Protocol so I don't > feel so strongly about it. yes, it's easy. want something simple? use sftp. want all the bells and whistles? use kermit. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 1 17:13:11 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16823 for ; Mon, 1 Apr 2002 17:13:10 -0500 (EST) Received: (qmail 18357 invoked by uid 605); 1 Apr 2002 22:13:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18350 invoked from network); 1 Apr 2002 22:13:08 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 1 Apr 2002 22:13:08 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id AAA16788; Tue, 2 Apr 2002 00:13:01 +0200 (MEST) Date: Tue, 2 Apr 2002 00:13:01 +0200 From: Markus Friedl To: Bill Sommerfeld Cc: Jeffrey Altman , Pontus Skoeld , Richard Whalen , "'ietf-ssh@netbsd.org'" Subject: Re: Additional thoughts on text transfers Message-ID: <20020401221301.GB1839@faui02> References: <20020401220554.GA1839@faui02> <200204012205.g31M5rss019813@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200204012205.g31M5rss019813@thunk.east.sun.com> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Apr 01, 2002 at 05:05:53PM -0500, Bill Sommerfeld wrote: > [wg chair hat off] > > > yes, it's easy. want something simple? use sftp. > > actually, sftp is really complex compared to scp. but unlike scp it works for transfering files with newlines in the name and it allows the client to select the files it wants to download ... From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 1 17:13:44 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16836 for ; Mon, 1 Apr 2002 17:13:43 -0500 (EST) Received: (qmail 18746 invoked by uid 605); 1 Apr 2002 22:13:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15732 invoked from network); 1 Apr 2002 22:08:46 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 1 Apr 2002 22:08:46 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA24545; Mon, 1 Apr 2002 14:07:33 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09853; Mon, 1 Apr 2002 17:07:32 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g31M5rss019813; Mon, 1 Apr 2002 17:05:53 -0500 (EST) Message-Id: <200204012205.g31M5rss019813@thunk.east.sun.com> From: Bill Sommerfeld To: Markus Friedl cc: Jeffrey Altman , Pontus Skoeld , Richard Whalen , "'ietf-ssh@netbsd.org'" Subject: Re: Additional thoughts on text transfers In-Reply-To: Your message of "Tue, 02 Apr 2002 00:05:54 +0200." <20020401220554.GA1839@faui02> Reply-to: sommerfeld@east.sun.com Date: Mon, 01 Apr 2002 17:05:53 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list [wg chair hat off] > yes, it's easy. want something simple? use sftp. actually, sftp is really complex compared to scp. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 1 18:46:28 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19212 for ; Mon, 1 Apr 2002 18:46:26 -0500 (EST) Received: (qmail 4196 invoked by uid 605); 1 Apr 2002 23:46:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4189 invoked from network); 1 Apr 2002 23:46:22 -0000 Received: from iron.ibs.com.au (202.14.182.249) by mail.netbsd.org with SMTP; 1 Apr 2002 23:46:22 -0000 Received: from xenon.mel.ibs.com.au (xenon.mel.ibs.com.au [10.3.0.3]) by iron.ibs.com.au (Postfix) with ESMTP id C490516C85; Tue, 2 Apr 2002 09:46:20 +1000 (EST) Date: Tue, 2 Apr 2002 09:55:39 +1000 (EST) From: Damien Miller X-X-Sender: djm@xenon.mel.ibs.com.au To: Richard Whalen Cc: "'ietf-ssh@netbsd.org'" Subject: RE: Additional thoughts on text transfers In-Reply-To: <63D30D6E10CFD11190A90000F805FE86040AA243@lespaul.process.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, 1 Apr 2002, Richard Whalen wrote: > Text files are still in high usage, even with new (often proprietary) > formats that may not be converted. How/why can filexfer be expected to know about all these? -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 1 20:27:51 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20903 for ; Mon, 1 Apr 2002 20:27:51 -0500 (EST) Received: (qmail 18751 invoked by uid 605); 2 Apr 2002 01:27:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18724 invoked from network); 2 Apr 2002 01:27:15 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 2 Apr 2002 01:27:15 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA28276 for ; Mon, 1 Apr 2002 17:27:14 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.38]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id RAA07044 for ; Mon, 1 Apr 2002 17:27:48 -0800 (PST) Received: from brora (brora.Eng.Sun.COM [129.146.86.207]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g321RD7p736403 for ; Mon, 1 Apr 2002 17:27:13 -0800 (PST) Message-Id: <200204020127.g321RD7p736403@jurassic.eng.sun.com> Date: Mon, 1 Apr 2002 17:26:31 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: RE: Additional thoughts on text transfers To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 3pFPgHzYktjXa0mDJkBcKg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_54 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >On Mon, 1 Apr 2002, Richard Whalen wrote: > >> Text files are still in high usage, even with new (often proprietary) >> formats that may not be converted. > >How/why can filexfer be expected to know about all these? The only person that knows what they want for a given file is the end user of that file. I really don't want the protocol doing stuff like that on mybehalf, particularly if I'm going to subsequently check anything about the file hasn't changed - doing a EOL conversion changes the size and certainly the MD5 digest of the file. I think that implemenations that care about adding a conversion process for EOL can do that outside of the filexfer protocol. One proposal I have heard was that the server could use extensions to say what the EOL mechanism was on that given server, however this might not always work well for MacOS X because it uses both Mac and UNIX style depending on who created the file. It is issues like this that continually make me think that the security area is the wrong place in IETF to try and solve this problem. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 1 21:06:45 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21753 for ; Mon, 1 Apr 2002 21:06:44 -0500 (EST) Received: (qmail 8591 invoked by uid 605); 2 Apr 2002 02:06:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8497 invoked from network); 2 Apr 2002 02:06:40 -0000 Received: from watsun.cc.columbia.edu (128.59.39.2) by mail.netbsd.org with SMTP; 2 Apr 2002 02:06:40 -0000 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id VAA18691; Mon, 1 Apr 2002 21:05:47 -0500 (EST) Date: Mon, 1 Apr 2002 21:05:47 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Damien Miller Cc: Richard Whalen , "'ietf-ssh@netbsd.org'" Subject: RE: Additional thoughts on text transfers In-Reply-To: Your message of Tue, 2 Apr 2002 09:55:39 +1000 (EST) Message-ID: Sender: ietf-ssh-owner@netbsd.org Precedence: list > On Mon, 1 Apr 2002, Richard Whalen wrote: > > > Text files are still in high usage, even with new (often proprietary) > > formats that may not be converted. > > How/why can filexfer be expected to know about all these? > > -d > > The Kermit Project implemented in C-Kermit 8.0 algorithms for examining files that can determine if the file is 7-bit text, 8-bit text, UTF-8, or UCS2/UCS4 with various byte orderings. These algorithms are highly accurate and do not rely on any proprietary knowledge of file naming conventions or operating system attributes. If the file is text it will be transfered as such, if it is not it is transfered as binary. The only text files that cannot be transfered with conversions are those that include mixtures of text and binary. These files must be transfered as binary as we do not translate only portions of files. I'm not aware of any other tool that allows automated mid-stream translation. - Jeff Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. Interfaces with OpenSSH From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 1 21:15:18 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21853 for ; Mon, 1 Apr 2002 21:15:17 -0500 (EST) Received: (qmail 12652 invoked by uid 605); 2 Apr 2002 02:15:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12644 invoked from network); 2 Apr 2002 02:15:04 -0000 Received: from iron.ibs.com.au (202.14.182.249) by mail.netbsd.org with SMTP; 2 Apr 2002 02:15:04 -0000 Received: from xenon.mel.ibs.com.au (xenon.mel.ibs.com.au [10.3.0.3]) by iron.ibs.com.au (Postfix) with ESMTP id 7B4AA16C85; Tue, 2 Apr 2002 12:15:03 +1000 (EST) Date: Tue, 2 Apr 2002 12:24:22 +1000 (EST) From: Damien Miller X-X-Sender: djm@xenon.mel.ibs.com.au To: Jeffrey Altman Cc: Richard Whalen , "'ietf-ssh@netbsd.org'" Subject: RE: Additional thoughts on text transfers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, 1 Apr 2002, Jeffrey Altman wrote: > > On Mon, 1 Apr 2002, Richard Whalen wrote: > > > > > Text files are still in high usage, even with new (often proprietary) > > > formats that may not be converted. > > > > How/why can filexfer be expected to know about all these? > > The Kermit Project implemented in C-Kermit 8.0 algorithms for > examining files that can determine if the file is 7-bit text, 8-bit > text, UTF-8, or UCS2/UCS4 with various byte orderings. These > algorithms are highly accurate and do not rely on any proprietary > knowledge of file naming conventions or operating system attributes. > If the file is text it will be transfered as such, if it is not it is > transfered as binary. > > The only text files that cannot be transfered with conversions are > those that include mixtures of text and binary. These files must be > transfered as binary as we do not translate only portions of files. > I'm not aware of any other tool that allows automated mid-stream > translation. That kinda proves the point that I was trying to make - that the format decision and processing can be built into the clients (or servers) and not into the protocol itself. filexfer's beauty is its simplicity as a binary-only file transfer protocol. IMO it should be burdened with application level cruft that can be better handled in the application. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Apr 2 00:16:50 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27403 for ; Tue, 2 Apr 2002 00:16:49 -0500 (EST) Received: (qmail 26218 invoked by uid 605); 2 Apr 2002 05:16:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26211 invoked from network); 2 Apr 2002 05:16:45 -0000 Received: from watsun.cc.columbia.edu (128.59.39.2) by mail.netbsd.org with SMTP; 2 Apr 2002 05:16:45 -0000 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id AAA22957; Tue, 2 Apr 2002 00:16:20 -0500 (EST) Date: Tue, 2 Apr 2002 0:16:19 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Damien Miller Cc: Richard Whalen , "'ietf-ssh@netbsd.org'" Subject: RE: Additional thoughts on text transfers In-Reply-To: Your message of Tue, 2 Apr 2002 12:24:22 +1000 (EST) Message-ID: Sender: ietf-ssh-owner@netbsd.org Precedence: list > That kinda proves the point that I was trying to make - that the format > decision and processing can be built into the clients (or servers) and not > into the protocol itself. No it doesn't. It provies that it must be built into the protocol. The N x M problem is not the number of types of files. The problem is that client on system A does not know the required format for the server on system B. > filexfer's beauty is its simplicity as a binary-only file transfer > protocol. IMO it should be burdened with application level cruft that > can be better handled in the application. The whole point of IETF protocols are to leave the system specific details on the system. The format of data sent on the network is to be transparent to the systems. Some systems might be required to do more work than others. But under no circumstances should a system be required to know what other systems sharing the network require. The biggest problem with the FTP protocol is that although efforts were made to establish system independent network formats for data transfer it did not do enough to specify system independent file system representations and methods for querying timestamps, sizes, attributes, ... Therefore, each client was required to build a table of the capabilities and output formats for directory listings so that they could be parsed for end user display. SFTP takes care of these hard parts. What it is missing is the definition of network representations for TEXT and RECORD based files. Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. Interfaces with OpenSSH From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Apr 2 03:11:38 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09473 for ; Tue, 2 Apr 2002 03:11:37 -0500 (EST) Received: (qmail 7536 invoked by uid 605); 2 Apr 2002 08:11:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7529 invoked from network); 2 Apr 2002 08:11:34 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 2 Apr 2002 08:11:34 -0000 Received: from folly.informatik.uni-erlangen.de (root@faui02.informatik.uni-erlangen.de [131.188.30.102]) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) with ESMTP id KAA06226; Tue, 2 Apr 2002 10:11:25 +0200 (MEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 805034471; Tue, 2 Apr 2002 10:11:10 +0200 (CEST) Date: Tue, 2 Apr 2002 10:11:10 +0200 From: Markus Friedl To: Jeffrey Altman Cc: Damien Miller , Richard Whalen , "'ietf-ssh@netbsd.org'" Subject: Re: Additional thoughts on text transfers Message-ID: <20020402081110.GE11392@folly> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Apr 02, 2002 at 12:16:19AM -0500, Jeffrey Altman wrote: > > That kinda proves the point that I was trying to make - that the format > > decision and processing can be built into the clients (or servers) and not > > into the protocol itself. > > No it doesn't. It provies that it must be built into the protocol. Then why does everybody write lines and lines of email instead of writing a draft using the mechanisms provided by draft-ietf-secsh-filexfer-02.txt From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Apr 2 08:59:16 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15234 for ; Tue, 2 Apr 2002 08:59:16 -0500 (EST) Received: (qmail 18449 invoked by uid 605); 2 Apr 2002 13:59:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18440 invoked from network); 2 Apr 2002 13:59:12 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 2 Apr 2002 13:59:12 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id <2DKJ5GDJ>; Tue, 2 Apr 2002 09:00:26 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA248@lespaul.process.com> From: Richard Whalen To: "'Markus Friedl'" Cc: "'ietf-ssh@netbsd.org'" Subject: RE: Additional thoughts on text transfers Date: Tue, 2 Apr 2002 09:00:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list > -----Original Message----- > From: Markus Friedl [mailto:markus@openbsd.org] > Sent: Tuesday, April 02, 2002 3:11 AM > To: Jeffrey Altman > Cc: Damien Miller; Richard Whalen; 'ietf-ssh@netbsd.org' > Subject: Re: Additional thoughts on text transfers > > > On Tue, Apr 02, 2002 at 12:16:19AM -0500, Jeffrey Altman wrote: > > > That kinda proves the point that I was trying to make - > that the format > > > decision and processing can be built into the clients (or > servers) and not > > > into the protocol itself. > > > > No it doesn't. It provies that it must be built into the protocol. > > Then why does everybody write lines and lines of email instead of > writing a draft using the mechanisms provided by > draft-ietf-secsh-filexfer-02.txt > The mechanisms provided by draft-ietf-secsh-filexfer-02.txt fall short of what is needed to provide a text transfer mechanism. The file attributes mechanism has plenty of flexibilty to present information about the type of information in the file, and whether or not any translations can be provided. Right now it says nothing about the type and that no translations are available. The OPEN/READ/WRITE mechanism is where the problem lies. It specifies particular bytes from the file, and on some systems those bytes may contain a mixture of actual data and system specific details. When those system specific details are transfered to a dissimilar system they become at best useless. In the worst case they make the entire file useless, as programs on the second system do not know to ignore the system specific details and declare the file to be corrupt. ---------------------- Richard Whalen Process Software From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Apr 2 09:13:09 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15960 for ; Tue, 2 Apr 2002 09:13:09 -0500 (EST) Received: (qmail 27608 invoked by uid 605); 2 Apr 2002 14:13:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27526 invoked from network); 2 Apr 2002 14:13:04 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 2 Apr 2002 14:13:04 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id QAA23545; Tue, 2 Apr 2002 16:13:01 +0200 (MEST) Date: Tue, 2 Apr 2002 16:13:01 +0200 From: Markus Friedl To: Richard Whalen Cc: "'ietf-ssh@netbsd.org'" Subject: Re: Additional thoughts on text transfers Message-ID: <20020402141300.GA15007@faui02> References: <63D30D6E10CFD11190A90000F805FE86040AA248@lespaul.process.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63D30D6E10CFD11190A90000F805FE86040AA248@lespaul.process.com> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Apr 02, 2002 at 09:00:25AM -0500, Richard Whalen wrote: > The OPEN/READ/WRITE mechanism is where the problem lies. It specifies > particular bytes from the file, and on some systems those bytes may contain > a mixture of actual data and system specific details. But when the server sends different data in READ replies (depending on the client system) then the data get be corrupted, i.e. the MD5 of the data would not match among different clients. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Apr 2 09:22:08 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16332 for ; Tue, 2 Apr 2002 09:22:07 -0500 (EST) Received: (qmail 4671 invoked by uid 605); 2 Apr 2002 14:22:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4641 invoked from network); 2 Apr 2002 14:22:05 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 2 Apr 2002 14:22:05 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id <2DKJ5GFP>; Tue, 2 Apr 2002 09:23:19 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA249@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: RE: Additional thoughts on text transfers Date: Tue, 2 Apr 2002 09:23:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list > -----Original Message----- > From: Markus Friedl [mailto:markus@openbsd.org] > Sent: Tuesday, April 02, 2002 9:13 AM > To: Richard Whalen > Cc: 'ietf-ssh@netbsd.org' > Subject: Re: Additional thoughts on text transfers > > > On Tue, Apr 02, 2002 at 09:00:25AM -0500, Richard Whalen wrote: > > The OPEN/READ/WRITE mechanism is where the problem lies. > It specifies > > particular bytes from the file, and on some systems those > bytes may contain > > a mixture of actual data and system specific details. > > But when the server sends different data in READ replies (depending on > the client system) then the data get be corrupted, i.e. the MD5 of the > data would not match among different clients. > With a defined text transfer mechanism the server would send the same data to all requests for the file in text mode (as long as the file has not been changed). The MD5 of the data would match with proper handling of the carriage control information. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Apr 2 10:28:45 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19044 for ; Tue, 2 Apr 2002 10:28:44 -0500 (EST) Received: (qmail 11767 invoked by uid 605); 2 Apr 2002 15:28:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11736 invoked from network); 2 Apr 2002 15:28:38 -0000 Received: from watsun.cc.columbia.edu (128.59.39.2) by mail.netbsd.org with SMTP; 2 Apr 2002 15:28:38 -0000 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id KAA17487; Tue, 2 Apr 2002 10:28:27 -0500 (EST) Date: Tue, 2 Apr 2002 10:28:26 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Markus Friedl Cc: Damien Miller , Richard Whalen , "'ietf-ssh@netbsd.org'" Subject: Re: Additional thoughts on text transfers In-Reply-To: Your message of Tue, 2 Apr 2002 10:11:10 +0200 Message-ID: Sender: ietf-ssh-owner@netbsd.org Precedence: list > On Tue, Apr 02, 2002 at 12:16:19AM -0500, Jeffrey Altman wrote: > > > That kinda proves the point that I was trying to make - that the format > > > decision and processing can be built into the clients (or servers) and not > > > into the protocol itself. > > > > No it doesn't. It provies that it must be built into the protocol. > > Then why does everybody write lines and lines of email instead of > writing a draft using the mechanisms provided by > draft-ietf-secsh-filexfer-02.txt > For a very simple reason: up until the last six months or so the only significant deployment of SSH v2 and SFTP was on Unix or Windows. Therefore, the only developers working on the protocol were people that didn't care about this functionality. I must assume that Process Software is now implementing SSHv2 on OpenVMS. Therefore, there is now someone that might care enough to take the responsibility of authorship. However, as Richard points out the IESG is perfectly capable and often willing to impose design requirements on a working group if they believe that the protocol that has been designed does not provide for operating system independence. Another reason is that people do not like to step on other people's toes. I'm sure Richard would rather work with the I-D authors to come up with a design that try to figure it out himself. As for myself, this has been a very bad year and a half financially. I have been unable to attend IETF meetings or even participate on mailing lists at any significant level due to the economic realities of keeping my co-workers employed. That means I'm not spending my time writing I-Ds for protocols I haven't implemented (yet). That doesn't mean I won't point out periodicly when a protocol design is flawed. Perhaps in two months I will have time to implement and then extend SFTP. In the meantime, the protocol should define alternate modes other than Binary. To keep things simply you probably want to have two variations for sending text files. The first (TEXT) simply uses a standard EOL indicator (CR-LF). The second (UTF8-TEXT) uses the standard EOL indicator (CR-LF) and indicates that the data is being sent as UTF8 allowing the receiver to translate it to a local character-set if that is possible. The choice of which mode is to be used is always made by the sender. If the receiver does not understand the mode, the incoming stream should be treated as a binary stream to allow for later translation by external tools. - Jeff Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. Interfaces with OpenSSH From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Apr 2 11:14:25 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21012 for ; Tue, 2 Apr 2002 11:14:24 -0500 (EST) Received: (qmail 10888 invoked by uid 605); 2 Apr 2002 16:14:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10881 invoked from network); 2 Apr 2002 16:14:21 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 2 Apr 2002 16:14:21 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id <2DKJ5GQ7>; Tue, 2 Apr 2002 11:15:35 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA24C@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: RE: Additional thoughts on text transfers Date: Tue, 2 Apr 2002 11:15:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list > -----Original Message----- > From: Jeffrey Altman [mailto:jaltman@columbia.edu] > Sent: Tuesday, April 02, 2002 10:28 AM > To: Markus Friedl > Cc: Damien Miller; Richard Whalen; 'ietf-ssh@netbsd.org' > Subject: Re: Additional thoughts on text transfers > > > > On Tue, Apr 02, 2002 at 12:16:19AM -0500, Jeffrey Altman wrote: > > > > That kinda proves the point that I was trying to make - > that the format > > > > decision and processing can be built into the clients > (or servers) and not > > > > into the protocol itself. > > > > > > No it doesn't. It provies that it must be built into the > protocol. > > > > Then why does everybody write lines and lines of email instead of > > writing a draft using the mechanisms provided by > > draft-ietf-secsh-filexfer-02.txt > > > > For a very simple reason: > > up until the last six months or so the only significant deployment > of SSH v2 and SFTP was on Unix or Windows. Therefore, the only > developers working on the protocol were people that didn't > care about > this functionality. > > I must assume that Process Software is now implementing SSHv2 on > OpenVMS. Therefore, there is now someone that might care enough to > take the responsibility of authorship. However, as Richard points > out the IESG is perfectly capable and often willing to impose design > requirements on a working group if they believe that the protocol that > has been designed does not provide for operating system independence. Process Software recently shipped SSH2 & SCP2 with MultiNet 4.4, based on the F-Secure 2.4.0 build 15 code. We are currently working on integrating the F-Secure 3.1.0 code with TCPware (the version number will probably be 5.6), which is expected to ship this summer (Northern Hemisphere). We found the extended attribute mechanism in SFTP to be very flexible for maintaining the VMS file attributes when transferring files between VMS systems. We determined before we went to Beta test that a binary only transfer mechanism would not meet our customer needs for transferring text files. We can determine which files may be translatable, and have provided a translation mechanism. These mechanisms work well when the file is accessed sequentially, but are ad-hoc (environment variables). I have not started prototyping any protocols due to time constraints. Exchanging ideas via email on how to deal with the text transfer problem has been useful to help figure out what might have to be added to the protocol. I don't know whether or not I will be able to travel to IETF, I do have time to work on this via email. ---------------------- Richard Whalen Process Software From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Apr 3 04:14:25 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27765 for ; Wed, 3 Apr 2002 04:14:22 -0500 (EST) Received: (qmail 16602 invoked by uid 605); 3 Apr 2002 09:14:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16595 invoked from network); 3 Apr 2002 09:14:19 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 3 Apr 2002 09:14:19 -0000 Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.9.3/8.9.3) with ESMTP id BAA29322 for ; Wed, 3 Apr 2002 01:14:13 -0800 Received: from vger.corp.google.com (vger.corp.google.com [10.3.4.85]) by moma.corp.google.com (8.9.3/8.9.3) with ESMTP id BAA22691 for ; Wed, 3 Apr 2002 01:14:13 -0800 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id g339ED902067 for ietf-ssh@netbsd.org; Wed, 3 Apr 2002 01:14:13 -0800 Date: Wed, 3 Apr 2002 01:14:13 -0800 From: Frank Cusack To: ietf-ssh@netbsd.org Subject: kbdinteract-03 Message-ID: <20020403011413.D1697@google.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I will submit the attached in 2 days if there are no objections. The only substantive change from my previous email (of ~ 2 months ago) is to change MUST to SHOULD in almost every aspect of client UI. /fc --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pwplus.txt" Network Working Group F. Cusack INTERNET-DRAFT Google, Inc. Expires October 2, 2002 M. Forssen Appgate AB April 2, 2002 Generic Message Exchange Authentication For SSH Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at . The list of Internet-Draft Shadow Directories can be accessed at . This Internet-Draft will expire on October 2, 2002. Abstract SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard. The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s). F. Cusack, M. Forssen Expires 2 October 2002 [Page 1] Internet Draft SSH Generic Interactive Authentication April 2, 2002 1. Introduction The SSH authentication protocol is a general-purpose user authentication protocol. It is intended to be run over the SSH transport layer protocol [SSH-TRANS]. The protocol assumes that the underlying protocols provide integrity and confidentiality protection. This document describes a general purpose authentication method for the SSH protocol. This method is suitable for interactive authentication methods which do not need any special software support on the client side. Instead all authentication data should be entered via the keyboard. The major goal of this method is to allow the SSH client to have little or no knowledge of the specifics of the underlying authentication mechanism(s) used by the SSH server. This will allow the server to arbitrarily select or change the underlying authentication mechanism(s) without having to update client code. The name for this authentication method is "keyboard-interactive". This document should be read only after reading the SSH architecture document [SSH-ARCH] and the SSH authentication document [SSH-USERAUTH]. This document freely uses terminology and notation from both documents without reference or further explanation. This document also describes some of the client interaction with the user in obtaining the authentication information. While this is somewhat out of the scope of a protocol specification, it is still described here since some aspects of the protocol are specifically designed based on user interface issues, and omitting this information may lead to incompatible or awkward implementations. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. Rationale Currently defined authentication methods for SSH are tightly coupled with the underlying authentication mechanism. This makes it difficult to add new mechanisms for authentication as all clients must be updated to support the new mechanism. With the generic method defined here, clients will not require code changes to support new authentication mechanisms, and if a separate authentication layer is used, such as [PAM], then the server may not need any code changes either. This presents a significant advantage to other methods, such as the F. Cusack, M. Forssen Expires 2 October 2002 [Page 2] Internet Draft SSH Generic Interactive Authentication April 2, 2002 "password" method (defined in [SSH-USERAUTH]), as new (presumably stronger) methods may be added "at will" and system security can be transparently enhanced. Challenge-response and One Time Password mechanisms are also easily supported with this authentication method. This authentication method is however limited to authentication mechanisms which do not require any special code, such as hardware drivers or password mangling, on the client. 3. Protocol Exchanges The client initiates the authentication with a SSH_MSG_USERAUTH_REQUEST message. The server then requests authentication information from the client with a SSH_MSG_USERAUTH_INFO_REQUEST message. The client obtains the information from the user and then responds with a SSM_MSG_USERAUTH_INFO_RESPONSE message. The server MUST NOT send another SSH_MSG_USERAUTH_INFO_REQUEST before it has received the answer from the client. 3.1 Initial Exchange The authentication starts with the client sending the following packet: byte SSH_MSG_USERAUTH_REQUEST string user name (ISO-10646 UTF-8) string service name (US-ASCII) string "keyboard-interactive" (US-ASCII) string language tag (as defined in [RFC-3066]) string submethods (ISO-10646 UTF-8) The language tag is deprecated and SHOULD be the empty string. It may be removed in a future revision of this specification. The server SHOULD instead select the language used based on the tags communicated during key exchange [SSH-TRANS]. If the language tag is not the empty string, the server SHOULD use the specified language for any messages sent to the client as part of this protocol. The language tag SHOULD NOT be used for language selection for messages outside of this protocol. The language to be used if the server does not support the requested language is implementation-dependent. The submethods field is included so the user can give a hint of which actual methods he wants to use. It is a a comma-separated list of F. Cusack, M. Forssen Expires 2 October 2002 [Page 3] Internet Draft SSH Generic Interactive Authentication April 2, 2002 authentication submethods (software or hardware) which the user prefers. If the client has knowledge of the submethods preferred by the user, presumably through a configuration setting, it MAY use the submethods field to pass this information to the server. Otherwise it MUST send the empty string. The actual names of the submethods is something which the user and the server needs to agree upon. Server interpretation of the submethods field is implementation- dependent. One possible implementation strategy of the submethods field on the server is that, unless the user may use multiple different submethods, the server ignores this field. If the user may authenticate using one of several different submethods the server should treat the submethods field as a hint on which submethod the user wants to use this time. Note that when this message is sent to the server, the client has not yet prompted the user for a password, and so that information is NOT included with this initial message (unlike the "password" method). The server MUST reply with either a SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or SSH_MSG_USERAUTH_INFO_REQUEST message. The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message if the failure is based on the user name or service name; instead it SHOULD send SSH_MSG_USERAUTH_INFO_REQUEST message(s) which look just like the one(s) which would have been sent in cases where authentication should proceed, and then send the failure message (after a suitable delay, as described below). The goal is to make it impossible to find valid usernames by just comparing the results when authenticating as different users. 3.2 Information Requests Requests are generated from the server using the SSH_MSG_USERAUTH_INFO_REQUEST message. The server may send as many requests as are necessary to authenticate the client; the client MUST be prepared to handle multiple exchanges. However the server MUST NOT ever have more than one SSH_MSG_USERAUTH_INFO_REQUEST message outstanding. That is, it may not send another request before the client has answered. F. Cusack, M. Forssen Expires 2 October 2002 [Page 4] Internet Draft SSH Generic Interactive Authentication April 2, 2002 The SSH_MSG_USERAUTH_INFO_REQUEST message is defined as follows: byte SSH_MSG_USERAUTH_INFO_REQUEST string name (ISO-10646 UTF-8) string instruction (ISO-10646 UTF-8) string language tag (as defined in [RFC-3066]) int num-prompts string prompt[1] (ISO-10646 UTF-8) boolean echo[1] ... string prompt[num-prompts] (ISO-10646 UTF-8) boolean echo[num-prompts] The server SHOULD take into consideration that some clients may not be able to properly display a long name or prompt field (see next section), and limit the lengths of those fields if possible. For example, instead of an instruction field of "Enter Password" and a prompt field of "Password for user23@host.domain: ", a better choice might be an instruction field of "Password authentication for user23@host.domain" and a prompt field of "Password: ". It is expected that this authentication method would typically be backended by [PAM] and so such choices would not be possible. The name and instruction fields MAY be empty strings, the client MUST be prepared to handle this correctly. The prompt field(s) MUST NOT be empty strings. The language tag SHOULD describe the language used in the textual fields. If the server does not know the language used, or if multiple languages are used, the language tag MUST be the empty string. The num-prompts field may be `0', in which case there will be no prompt/echo fields in the message, but the client SHOULD still display the name and instruction fields (as described below). 3.3 User Interface Upon receiving a request message, the client SHOULD prompt the user as follows: A command line interface (CLI) client SHOULD print the name and instruction (if non-empty), adding newlines. Then for each prompt in turn, the client SHOULD display the prompt and read the user input. A graphical user interface (GUI) client has many choices on how to prompt the user. One possibility is to use the name field (possibly F. Cusack, M. Forssen Expires 2 October 2002 [Page 5] Internet Draft SSH Generic Interactive Authentication April 2, 2002 prefixed with the application's name) as the title of a dialog window in which the prompt(s) are presented. In that dialog window, the instruction field would be a text message, and the prompts would be labels for text entry fields. All fields SHOULD be presented to the user, for example an implementation SHOULD NOT discard the name field because its windows lack titles; it SHOULD instead find another way to display this information. If prompts are presented in a dialog window, then the client SHOULD NOT present each prompt in a separate window. All clients MUST properly handle an instruction field with embedded newlines. They SHOULD also be able to display at least 30 characters for the name and prompts. If the server presents names or prompts longer than 30 characters, the client MAY truncate these fields to the length it can display. If the client does truncate any fields, there MUST be an obvious indication that such truncation has occured. The instruction field SHOULD NOT be truncated. Clients SHOULD use control character filtering as discussed in [SSH-ARCH] to avoid attacks by including terminal control characters in the fields to be displayed. For each prompt, the corresponding echo field indicates whether or not the user input should be echoed as characters are typed. Clients SHOULD correctly echo/mask user input for each prompt independently of other prompts in the request message. If a client does not honor the echo field for whatever reason, then the client MUST err on the side of masking input. A GUI client might like to have a checkbox toggling echo/mask. Clients SHOULD NOT add any additional characters to the prompt such as ": " (colon-space); the server is responsible for supplying all text to be displayed to the user. Clients MUST also accept empty responses from the user and pass them on as empty strings. 3.4 Information Responses After obtaining the requested information from the user, the client MUST respond with a SSH_MSG_USERAUTH_INFO_RESPONSE message. The format of the SSH_MSG_USERAUTH_INFO_RESPONSE message is as follows: byte SSH_MSG_USERAUTH_INFO_RESPONSE int num-responses string response[1] (ISO-10646 UTF-8) ... string response[num-responses] (ISO-10646 UTF-8) F. Cusack, M. Forssen Expires 2 October 2002 [Page 6] Internet Draft SSH Generic Interactive Authentication April 2, 2002 Note that the responses are encoded in ISO-10646 UTF-8. It is up to the server how it interprets the responses and validates them. However, if the client reads the responses in some other encoding (e.g., ISO 8859-1), it MUST convert the responses to ISO-10646 UTF-8 before transmitting. If the num-responses field does not match the num-prompts field in the request message, the server MUST send a failure message. In the case that the server sends a `0' num-prompts field in the request message, the client MUST send a response message with a `0' num-responses field. The responses must be ordered as the prompts were ordered. That is, response[n] must be the answer to prompt[n]. After receiving the response, the server MUST send either a SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another SSH_MSG_USERAUTH_INFO_REQUEST message. If the server fails to authenticate the user (through the underlying authentication mechanism(s)), it SHOULD NOT send another request message(s) in an attempt to obtain new authentication data, instead it SHOULD send a failure message. The only time the server should send multiple request messages is if additional authentication data is needed (i.e., because there are multiple underlying authentication mechanisms that must be used to authenticate the user). If the server intends to respond with a failure message, it MAY delay for an implementation-dependent time before sending to the client. It is suspected that implementations are likely to make the time delay a configurable, a suggested default is 2 seconds. 4. Authentication Examples Here are two example exchanges between a client and server. The first is an example of a challenge/response implementation. This is an authentication that is not otherwise possible with other authentication methods. C: byte SSH_MSG_USERAUTH_REQUEST C: string "user23" C: string "ssh-userauth" C: string "keyboard-interactive" C: string "" C: string "" F. Cusack, M. Forssen Expires 2 October 2002 [Page 7] Internet Draft SSH Generic Interactive Authentication April 2, 2002 S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string "CRYPTOCard Authentication" S: string "The challenge is '14315716'" S: string "en-US" S: int 1 S: string "Response: " S: boolean TRUE [Client prompts user for password] C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 1 C: string "6d757575" S: byte SSH_MSG_USERAUTH_SUCCESS The second example is of a standard password authentication, in this case the user's password is expired. C: byte SSH_MSG_USERAUTH_REQUEST C: string "user23" C: string "ssh-userauth" C: string "keyboard-interactive" C: string "en-US" C: string "" S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string "Password Authentication" S: string "" S: string "en-US" S: int 1 S: string "Password: " S: boolean FALSE [Client prompts user for password] C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 1 C: string "password" F. Cusack, M. Forssen Expires 2 October 2002 [Page 8] Internet Draft SSH Generic Interactive Authentication April 2, 2002 S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string "Password Expired" S: string "Your password has expired." S: string "en-US" S: int 2 S: string "Enter new password: " S: boolean FALSE S: string "Enter it again: " S: boolean FALSE [Client prompts user for new password] C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 2 C: string "newpass" C: string "newpass" S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string "Password changed" S: string "Password successfully changed for user23." S: string "en-US" S: int 0 [Client displays message to user] C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 0 S: byte SSH_MSG_USERAUTH_SUCCESS 5. Protocol constants The following method-specific constants are used with this authentication method: SSH_MSG_USERAUTH_INFO_REQUEST 60 SSH_MSG_USERAUTH_INFO_RESPONSE 61 6. References [PAM] Samar, V., Schemers, R., "Unified Login With Pluggable Authentication Modules (PAM)", OSF RFC 86.0, October 1995 F. Cusack, M. Forssen Expires 2 October 2002 [Page 9] Internet Draft SSH Generic Interactive Authentication April 2, 2002 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997. [RFC-2279] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2279, October 1996. [RFC-3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [SSH-ARCH] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and Lehtinen, S., "SSH Protocol Architecture", work in progress, draft-ietf-secsh-architecture-12.txt, January, 2002. [SSH-CONNECT] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and Lehtinen, S., "SSH Connection Protocol", work in progress, draft-ietf-secsh-connect-15.txt, January, 2002. [SSH-TRANS] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and Lehtinen, S., "SSH Transport Layer Protocol", work in progress, draft-ietf-secsh-transport-14.txt, March, 2002. [SSH-USERAUTH] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and Lehtinen, S., "SSH Authentication Protocol", work in progress, draft-ietf-secsh-userauth-15.txt, February, 2002. F. Cusack, M. Forssen Expires 2 October 2002 [Page 10] Internet Draft SSH Generic Interactive Authentication April 2, 2002 7. Author's Addresses Frank Cusack Google, Inc. 2400 Bayshore Parkway Mountain View, CA 94043 Email: frank@google.com Martin Forssen Appgate AB Stora Badhusgatan 18-20 SE-411 21 Gothenburg SWEDEN Email: maf@appgate.com F. Cusack, M. Forssen Expires 2 October 2002 [Page 11] --sdtB3X0nJg68CQEu-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Apr 3 07:56:40 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01435 for ; Wed, 3 Apr 2002 07:56:39 -0500 (EST) Received: (qmail 28169 invoked by uid 605); 3 Apr 2002 12:56:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28161 invoked from network); 3 Apr 2002 12:56:04 -0000 Received: from out009pub.verizon.net (HELO out009.verizon.net) (206.46.170.131) by mail.netbsd.org with SMTP; 3 Apr 2002 12:56:04 -0000 Received: from pool-162-84-147-41.ny5030.east.verizon.net ([162.84.147.58]) by out009.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020403125603.MHAI18349.out009.verizon.net@pool-162-84-147-41.ny5030.east.verizon.net>; Wed, 3 Apr 2002 06:56:03 -0600 Received: by pool-162-84-147-41.ny5030.east.verizon.net (sSMTP sendmail emulation); Wed, 3 Apr 2002 07:56:06 -0500 Date: Wed, 3 Apr 2002 07:56:05 -0500 From: nico To: Richard Whalen Cc: "'ietf-ssh@netbsd.org'" Subject: Re: SFTP File open modes Message-ID: <20020403075605.A3436@NICO> References: <63D30D6E10CFD11190A90000F805FE86040AA242@lespaul.process.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <63D30D6E10CFD11190A90000F805FE86040AA242@lespaul.process.com>; from Whalenr@process.com on Mon, Apr 01, 2002 at 09:51:18AM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list This can work: - clients (optinally) tell the server the content-type/encoding of any files the clients open for writing, with an option available for the client to specify that no conversions must take place (the content-type/encoding may be useful even if no conversions are allowed or possible) - servers (optionally) tell the clients the content-type/encoding of any files that the clients open for reading - both clients and servers are allowed to perform conversions before/after the file xfer, but neither is required to; clients are responsible for any conversions when they read files and servers are responsible for any conversions on files written to by clients. - VMS servers, for example, would set the file type and record lengths appropriately when clients write ASCII text to them, and Windows servers might convert LF to CR/LF when clients write Unix ASCII text. Similarly for clients. - perhaps an additional message by which clients/servers can tell each other what content-type/encoding they intend to convert a given file would be useful as well The only new requirement imposed by the above on implementations is that they parse the new open message file attrs. The spec would absolutely not require that implementations support any kinds of conversions. The file xfer protocol would be left pretty much alone - only the file open protocol would be modified, and then only in a way that makes sense. Besides, this can be done with new file attribute definitions. The protocol can already handle this. Cheers, Nico On Mon, Apr 01, 2002 at 09:51:18AM -0500, Richard Whalen wrote: > Since both the client and server access files, you can not put the > responsibility for doing conversions on either and "solve" the problem. > Requiring the client to do it means that the client must know about all > possible formats. > > You can say that encoding conversions are the responsibility of the reader > (or writer, take your pick) of the file if a common wire format is agreed > upon for certain types of files. (Text in this discussion.) > > > -----Original Message----- > > From: nico [mailto:nico@verizon.net] > > Sent: Friday, March 29, 2002 10:13 PM > > To: Richard Whalen > > Cc: 'ietf-ssh@netbsd.org' > > Subject: Re: SFTP File open modes > > > > > > > > How many well-known and often utilized ways of encoding ASCII > > text files > > are there (answer: two)? Is an ASCII mode as you suggest likely to be > > useful? Or do we want a mode for UTF-8 and UTF-16, EBCEDIC, and so on? > > > > Perhaps it would be best to add an operation by which the > > client can ask > > the server for a given file's content type and encoding. The server's > > response should indicate whether it knows, whether it knows > > for certain > > and, if it knows at all, what the content type is. > > > > All encoding conversions though should be left to the client though. > > > > IMHO. Cheers, > > > > Nico > > > > On Wed, Mar 27, 2002 at 02:36:06PM -0500, Richard Whalen wrote: > > > The current specification of SFTP states that files are > > always opened in > > > "binary" mode - no translations between different character > > sets and newline > > > encodings. > > > > [...] > > > > > ---------------------- > > > Richard Whalen > > > Process Software > > > 508-879-6994 > > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Apr 3 08:17:49 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02296 for ; Wed, 3 Apr 2002 08:17:48 -0500 (EST) Received: (qmail 7725 invoked by uid 605); 3 Apr 2002 13:17:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7718 invoked from network); 3 Apr 2002 13:17:47 -0000 Received: from watsun.cc.columbia.edu (128.59.39.2) by mail.netbsd.org with SMTP; 3 Apr 2002 13:17:47 -0000 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id IAA00869; Wed, 3 Apr 2002 08:17:42 -0500 (EST) Date: Wed, 3 Apr 2002 8:17:42 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: nico Cc: Richard Whalen , "'ietf-ssh@netbsd.org'" Subject: Re: SFTP File open modes In-Reply-To: Your message of Wed, 3 Apr 2002 07:56:05 -0500 Message-ID: Sender: ietf-ssh-owner@netbsd.org Precedence: list Nico: With all due respect, the only entity that can determine the file type is the system that is sending the file. What mode the receiver chooses to store the file with is irrelevant. - Jeff > > This can work: > > - clients (optinally) tell the server the content-type/encoding of any > files the clients open for writing, with an option available for the > client to specify that no conversions must take place (the > content-type/encoding may be useful even if no conversions are > allowed or possible) > > - servers (optionally) tell the clients the content-type/encoding of > any files that the clients open for reading > > - both clients and servers are allowed to perform conversions > before/after the file xfer, but neither is required to; clients are > responsible for any conversions when they read files and servers are > responsible for any conversions on files written to by clients. > > - VMS servers, for example, would set the file type and record lengths > appropriately when clients write ASCII text to them, and Windows > servers might convert LF to CR/LF when clients write Unix ASCII text. > Similarly for clients. > > - perhaps an additional message by which clients/servers can tell each > other what content-type/encoding they intend to convert a given file > would be useful as well > > The only new requirement imposed by the above on implementations is that > they parse the new open message file attrs. The spec would absolutely > not require that implementations support any kinds of conversions. > > The file xfer protocol would be left pretty much alone - only the file > open protocol would be modified, and then only in a way that makes > sense. > > Besides, this can be done with new file attribute definitions. The > protocol can already handle this. > > Cheers, > > Nico > > > On Mon, Apr 01, 2002 at 09:51:18AM -0500, Richard Whalen wrote: > > Since both the client and server access files, you can not put the > > responsibility for doing conversions on either and "solve" the problem. > > Requiring the client to do it means that the client must know about all > > possible formats. > > > > You can say that encoding conversions are the responsibility of the reader > > (or writer, take your pick) of the file if a common wire format is agreed > > upon for certain types of files. (Text in this discussion.) > > > > > -----Original Message----- > > > From: nico [mailto:nico@verizon.net] > > > Sent: Friday, March 29, 2002 10:13 PM > > > To: Richard Whalen > > > Cc: 'ietf-ssh@netbsd.org' > > > Subject: Re: SFTP File open modes > > > > > > > > > > > > How many well-known and often utilized ways of encoding ASCII > > > text files > > > are there (answer: two)? Is an ASCII mode as you suggest likely to be > > > useful? Or do we want a mode for UTF-8 and UTF-16, EBCEDIC, and so on? > > > > > > Perhaps it would be best to add an operation by which the > > > client can ask > > > the server for a given file's content type and encoding. The server's > > > response should indicate whether it knows, whether it knows > > > for certain > > > and, if it knows at all, what the content type is. > > > > > > All encoding conversions though should be left to the client though. > > > > > > IMHO. Cheers, > > > > > > Nico > > > > > > On Wed, Mar 27, 2002 at 02:36:06PM -0500, Richard Whalen wrote: > > > > The current specification of SFTP states that files are > > > always opened in > > > > "binary" mode - no translations between different character > > > sets and newline > > > > encodings. > > > > > > [...] > > > > > > > ---------------------- > > > > Richard Whalen > > > > Process Software > > > > 508-879-6994 > > > > > > Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. Interfaces with OpenSSH From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Apr 3 09:26:01 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04111 for ; Wed, 3 Apr 2002 09:26:00 -0500 (EST) Received: (qmail 10109 invoked by uid 605); 3 Apr 2002 14:26:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10102 invoked from network); 3 Apr 2002 14:25:59 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 3 Apr 2002 14:25:59 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id <2DKJ52B8>; Wed, 3 Apr 2002 09:27:14 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA251@lespaul.process.com> From: Richard Whalen To: "'nico'" Cc: "'ietf-ssh@netbsd.org'" Subject: RE: SFTP File open modes Date: Wed, 3 Apr 2002 09:27:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list > -----Original Message----- > From: nico [mailto:nico@verizon.net] > Sent: Wednesday, April 03, 2002 7:56 AM > To: Richard Whalen > Cc: 'ietf-ssh@netbsd.org' > Subject: Re: SFTP File open modes > > > > This can work: > : > > - both clients and servers are allowed to perform conversions > before/after the file xfer, but neither is required to; clients are > responsible for any conversions when they read files and > servers are > responsible for any conversions on files written to by clients. > This needs to be defined in the terms of the file reader and file writer as clients and servers could be acting in either way upon a file. ---------------------- Richard Whalen Process Software From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Apr 3 22:05:26 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23005 for ; Wed, 3 Apr 2002 22:05:25 -0500 (EST) Received: (qmail 20170 invoked by uid 605); 4 Apr 2002 03:05:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20161 invoked from network); 4 Apr 2002 03:05:24 -0000 Received: from out005slb.verizon.net (HELO out005.verizon.net) (206.46.170.17) by mail.netbsd.org with SMTP; 4 Apr 2002 03:05:24 -0000 Received: from pool-162-84-147-41.ny5030.east.verizon.net ([162.84.147.156]) by out005.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020404030440.SJOQ15947.out005.verizon.net@pool-162-84-147-41.ny5030.east.verizon.net>; Wed, 3 Apr 2002 21:04:40 -0600 Received: by pool-162-84-147-41.ny5030.east.verizon.net (sSMTP sendmail emulation); Wed, 3 Apr 2002 22:05:22 -0500 Date: Wed, 3 Apr 2002 22:05:21 -0500 From: nico To: Richard Whalen Cc: "'Markus Friedl'" , "'ietf-ssh@netbsd.org'" Subject: Re: Additional thoughts on text transfers Message-ID: <20020403220521.A3216@NICO> References: <63D30D6E10CFD11190A90000F805FE86040AA248@lespaul.process.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <63D30D6E10CFD11190A90000F805FE86040AA248@lespaul.process.com>; from Whalenr@process.com on Tue, Apr 02, 2002 at 09:00:25AM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Apr 02, 2002 at 09:00:25AM -0500, Richard Whalen wrote: > > Then why does everybody write lines and lines of email instead of > > writing a draft using the mechanisms provided by > > draft-ietf-secsh-filexfer-02.txt > > > > The mechanisms provided by draft-ietf-secsh-filexfer-02.txt fall short of > what is needed to provide a text transfer mechanism. > > The file attributes mechanism has plenty of flexibilty to present > information about the type of information in the file, and whether or not > any translations can be provided. Right now it says nothing about the type > and that no translations are available. I don't see why the attributes wouldn't suffice for the case of ASCII text files: Unix client: open(some file, write|create|trunc, attrs: {..., content-type: text, encoding: ASCII, eol: LF, ...}, ...) VMS server: OK, handle client: write(handle, ...) client: write(handle, ...) .. server: OK server: OK .. client: close(handle) server: OK server: client: open(some other file, read) server: OK, handle client: stat(handle) server: OK, attrs: ... content-type: test, encoding: ASCII, eol: X, ... client: read(handle,...) .. client: close(handle) server: OK Note that the VMS server has to select some sort of EOL marker, preferably LF :) > The OPEN/READ/WRITE mechanism is where the problem lies. It specifies > particular bytes from the file, and on some systems those bytes may contain > a mixture of actual data and system specific details. When those system > specific details are transfered to a dissimilar system they become at best > useless. In the worst case they make the entire file useless, as programs on > the second system do not know to ignore the system specific details and > declare the file to be corrupt. If the issue is primarily about VMS text files being record-oriented with variable length records, one record per line with no EOL characters, I think that problem can be dealt with as above. But if you want to generally support record-oriented files, both with fixed- and variable-sized records, then the file xfer protocol does, indeed, need to specifically support such semantics. But then, the necessary changes might be few, particularly if random-access can be maintained even when reading/writing files with variable record sizes. A canonical file format (preferably as a stream of octets) is needed for checksumming. Perhaps SFTP should move to a different working group :) > ---------------------- > Richard Whalen > Process Software Cheers, Nico From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 4 04:06:55 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07341 for ; Thu, 4 Apr 2002 04:06:51 -0500 (EST) Received: (qmail 28889 invoked by uid 605); 4 Apr 2002 09:06:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28869 invoked from network); 4 Apr 2002 09:06:38 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 4 Apr 2002 09:06:38 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 16t3CP-0006Wb-00; Thu, 04 Apr 2002 10:06:29 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <20020403220521.A3216@NICO> Subject: Re: Additional thoughts on text transfers Message-Id: Date: Thu, 04 Apr 2002 10:06:29 +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list nico wrote: > I don't see why the attributes wouldn't suffice for the case of ASCII > text files: [...] > client: write(handle, ...) > client: write(handle, ...) > .. > server: OK > server: OK > .. > client: close(handle) > server: OK > server: record boundaries where the LF characters were in the original> If I'm reading that right, you seem to be suggesting that the server should store the whole file in memory until the client closes it. Wouldn't this be hideously unpleasant to do with big files? Simon -- Simon Tatham "Imagine what the world would be like if there were no hypothetical situations..." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 4 09:25:52 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15606 for ; Thu, 4 Apr 2002 09:25:51 -0500 (EST) Received: (qmail 19202 invoked by uid 605); 4 Apr 2002 14:25:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19195 invoked from network); 4 Apr 2002 14:25:47 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 4 Apr 2002 14:25:47 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id <2DKJ5J82>; Thu, 4 Apr 2002 09:27:02 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA259@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: RE: Additional thoughts on text transfers Date: Thu, 4 Apr 2002 09:26:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list > -----Original Message----- > From: nico [mailto:nico@verizon.net] > Sent: Wednesday, April 03, 2002 10:05 PM > To: Richard Whalen > Cc: 'Markus Friedl'; 'ietf-ssh@netbsd.org' > Subject: Re: Additional thoughts on text transfers > > > On Tue, Apr 02, 2002 at 09:00:25AM -0500, Richard Whalen wrote: > > > Then why does everybody write lines and lines of email instead of > > > writing a draft using the mechanisms provided by > > > draft-ietf-secsh-filexfer-02.txt > > > > > > > The mechanisms provided by draft-ietf-secsh-filexfer-02.txt > fall short of > > what is needed to provide a text transfer mechanism. > > > > The file attributes mechanism has plenty of flexibilty to present > > information about the type of information in the file, and > whether or not > > any translations can be provided. Right now it says > nothing about the type > > and that no translations are available. > > I don't see why the attributes wouldn't suffice for the case of ASCII > text files: > > Unix client: open(some file, write|create|trunc, attrs: {..., > content-type: > text, encoding: ASCII, eol: LF, ...}, ...) > > VMS server: OK, handle > > client: write(handle, ...) > client: write(handle, ...) > .. > server: OK > server: OK > .. > client: close(handle) > server: OK > server: record boundaries where the LF characters were in the original> > > client: open(some other file, read) > server: OK, handle > client: stat(handle) > server: OK, attrs: ... content-type: test, encoding: ASCII, > eol: X, ... > client: read(handle,...) > .. > client: close(handle) > server: OK > > > A canonical file format (preferably as a stream of octets) is > needed for > checksumming. > > Perhaps SFTP should move to a different working group :) > > > ---------------------- > > Richard Whalen > > Process Software > > > Cheers, > > Nico > Your example for writing a file is reasonable, though the READ & WRITE operations have not be defined to allow conversion of data upon storage. Writing files in the local format when there is a defined text format is the easy case though. How do you read a file that is stored in a local format and needs to be delivered in a defined text format? The idea of exchanging a checksum to verify that a file has been completely transferred is good; it could eliminate the need to process the file in the defined transfer method to get the exact size to check to see if the complete file has been received. ---------------------- Richard Whalen Process Software From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 4 09:46:31 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16750 for ; Thu, 4 Apr 2002 09:46:30 -0500 (EST) Received: (qmail 1128 invoked by uid 605); 4 Apr 2002 14:46:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1121 invoked from network); 4 Apr 2002 14:46:29 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 4 Apr 2002 14:46:29 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id <2DKJ5J9Q>; Thu, 4 Apr 2002 09:47:44 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA25A@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: RE: SFTP owner, group and mode flags... Date: Thu, 4 Apr 2002 09:47:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list > -----Original Message----- > From: Joseph Galbraith [mailto:galb-list@vandyke.com] > Sent: Thursday, March 21, 2002 10:35 AM > To: Richard Whalen; ietf-ssh@netbsd.org > Subject: Re: SFTP owner, group and mode flags... > > > > The proposals for changes to the method in which user & > group information > > and ACLs sound good. I agree with the general idea of > using mechanisms > that > > have been developed in existing RFCs. > > > > >* Change the mode field to a type field, which indicates > > > the type of the file, and make it a byte field. > > > > I don't understand what you are talking about here. The > only place that I > > could find the word "mode" used in the document was in the > mention that > > files are always opened in binary mode. (Which I think is > an error.) > > Sorry, I should have been more explicit here. > > What I'm saying is that currently there are > two pieces of information in permissions > field: > > * The type of file (directory, normal, special, etc.) > * And the access rights for the owner, the group, and > everyone. > > I was proposing that we split this. We still need a type > field. This information could be encoded as a BYTE, > with enumerations defined in the draft. > > The access rights information would be encoded as an ACL. > > - Joseph > I basically agree with the above, but the way that access rights have been specified does not specify all operations that could be performed on a file. The FTP working group has come up with a set of ten permission indicators that they are using in their new MLSx commands (machine formatted listings), I think that it would be a good idea to consider the same methods. The latest draft can be found at http://www.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-15.txt ---------------------- Richard Whalen Process Software From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Apr 5 08:58:55 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04914 for ; Fri, 5 Apr 2002 08:58:54 -0500 (EST) Received: (qmail 1598 invoked by uid 605); 5 Apr 2002 13:58:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1589 invoked from network); 5 Apr 2002 13:58:50 -0000 Received: from intern12.lnk.telstra.net (HELO shitei.mindrot.org) (139.130.53.38) by mail.netbsd.org with SMTP; 5 Apr 2002 13:58:50 -0000 Received: from mothra.mindrot.org (mothra.mindrot.org [203.44.118.225]) by shitei.mindrot.org (Postfix) with ESMTP id 2C239EA91; Fri, 5 Apr 2002 23:58:20 +1000 (EST) Received: from localhost (djm@localhost) by mothra.mindrot.org (8.11.6/8.11.6) with ESMTP id g35DnmV07563; Fri, 5 Apr 2002 23:49:49 +1000 X-Authentication-Warning: mothra.mindrot.org: djm owned process doing -bs Date: Fri, 5 Apr 2002 23:49:46 +1000 (EST) From: Damien Miller To: Richard Whalen Cc: "'Markus Friedl'" , "'ietf-ssh@netbsd.org'" Subject: RE: Additional thoughts on text transfers In-Reply-To: <63D30D6E10CFD11190A90000F805FE86040AA248@lespaul.process.com> Message-ID: X-Paranoia: just because you're paranoid doesn't mean they aren't out to get you MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 2 Apr 2002, Richard Whalen wrote: > > > No it doesn't. It provies that it must be built into the protocol. > > > > Then why does everybody write lines and lines of email instead of > > writing a draft using the mechanisms provided by > > draft-ietf-secsh-filexfer-02.txt > > The mechanisms provided by draft-ietf-secsh-filexfer-02.txt fall short of > what is needed to provide a text transfer mechanism. Huh? The draft includes a clear and easy to use extension mechanism, what is wrong with that? -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Apr 5 09:08:23 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05217 for ; Fri, 5 Apr 2002 09:08:23 -0500 (EST) Received: (qmail 5420 invoked by uid 605); 5 Apr 2002 14:08:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5413 invoked from network); 5 Apr 2002 14:08:21 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 5 Apr 2002 14:08:21 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id <2DKJ5LTG>; Fri, 5 Apr 2002 09:09:37 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA260@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: RE: Additional thoughts on text transfers Date: Fri, 5 Apr 2002 09:09:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list > -----Original Message----- > From: Damien Miller [mailto:djm@mindrot.org] > Sent: Friday, April 05, 2002 8:50 AM > To: Richard Whalen > Cc: 'Markus Friedl'; 'ietf-ssh@netbsd.org' > Subject: RE: Additional thoughts on text transfers > > > On Tue, 2 Apr 2002, Richard Whalen wrote: > > > > > No it doesn't. It provies that it must be built into > the protocol. > > > > > > Then why does everybody write lines and lines of email instead of > > > writing a draft using the mechanisms provided by > > > draft-ietf-secsh-filexfer-02.txt > > > > The mechanisms provided by draft-ietf-secsh-filexfer-02.txt > fall short of > > what is needed to provide a text transfer mechanism. > > Huh? The draft includes a clear and easy to use extension mechanism, > what is wrong with that? > > -d > Yes, the draft does have an well defined extension mechanism. And I can define text transfer operations for the implementation of the SFTP server that my company provides. But that doesn't help the users who may use a variety of different implementations, as none of those other implementations will have the text transfer extension. ---------------------- Richard Whalen Process Software From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Apr 5 09:10:02 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05254 for ; Fri, 5 Apr 2002 09:10:02 -0500 (EST) Received: (qmail 6506 invoked by uid 605); 5 Apr 2002 14:10:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6470 invoked from network); 5 Apr 2002 14:09:59 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 5 Apr 2002 14:09:59 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id QAA19809; Fri, 5 Apr 2002 16:09:56 +0200 (MEST) Date: Fri, 5 Apr 2002 16:09:56 +0200 From: Markus Friedl To: Richard Whalen Cc: "'ietf-ssh@netbsd.org'" Subject: Re: Additional thoughts on text transfers Message-ID: <20020405140956.GC19890@faui02> References: <63D30D6E10CFD11190A90000F805FE86040AA260@lespaul.process.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63D30D6E10CFD11190A90000F805FE86040AA260@lespaul.process.com> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Apr 05, 2002 at 09:09:34AM -0500, Richard Whalen wrote: > Yes, the draft does have an well defined extension mechanism. > > And I can define text transfer operations for the implementation of the SFTP > server that my company provides. But that doesn't help the users who may > use a variety of different implementations, as none of those other > implementations will have the text transfer extension. if an extension makes sense, then others will pick it up. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 8 09:51:23 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23632 for ; Mon, 8 Apr 2002 09:51:23 -0400 (EDT) Received: (qmail 26217 invoked by uid 605); 8 Apr 2002 13:51:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26205 invoked from network); 8 Apr 2002 13:51:20 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 8 Apr 2002 13:51:20 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23572; Mon, 8 Apr 2002 09:51:06 -0400 (EDT) Message-Id: <200204081351.JAA23572@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-auth-kbdinteract-03.txt Date: Mon, 08 Apr 2002 09:51:05 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : Generic Message Exchange Authentication For SSH Author(s) : M. Forssen, F. Cusack Filename : draft-ietf-secsh-auth-kbdinteract-03.txt Pages : 11 Date : 05-Apr-02 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard. The major goal of this method is to allow the SSH client to have little or no knowledge of the underlying authentication mechanism(s) used by the SSH server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-auth-kbdinteract-03.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-ietf-secsh-auth-kbdinteract-03.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-ietf-secsh-auth-kbdinteract-03.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020405102036.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-auth-kbdinteract-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-auth-kbdinteract-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020405102036.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Apr 9 12:26:32 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11280 for ; Tue, 9 Apr 2002 12:26:32 -0400 (EDT) Received: (qmail 22817 invoked by uid 605); 9 Apr 2002 16:26:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22810 invoked from network); 9 Apr 2002 16:26:26 -0000 Received: from ip15293.peostamis.belvoir.army.mil (HELO rcposv010.eis.army.mil) (128.190.152.93) by mail.netbsd.org with SMTP; 9 Apr 2002 16:26:26 -0000 Received: by ip15293.peostamis.belvoir.army.mil with Internet Mail Service (5.5.2655.55) id <2RRGCD08>; Tue, 9 Apr 2002 12:26:14 -0400 Message-ID: <88AB06281E1D0F4E86DEF6C486C58C75142A19@ip15293.peostamis.belvoir.army.mil> From: "Blaine, Les CPR / TLA" To: lavasani@connect.org.uk, haruyama@klab.org Cc: ietf-ssh@netbsd.org Subject: SSh 3.1p1 Date: Tue, 9 Apr 2002 12:26:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list Has OpenSSh v3.1p1 been tested on HPUX 11.x in trusted mode using shadow passwords? Regards- Les Blaine Suite 210 8500 Cinder Bed Road Newington, VA 22122 703-428-0668 x273 Desk 703-428-0686 FAX les.blaine@peostamis.belvoir.army.mil LeslieBlaine@netscape.net The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Apr 10 09:39:31 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18886 for ; Wed, 10 Apr 2002 09:39:30 -0400 (EDT) Received: (qmail 23346 invoked by uid 605); 10 Apr 2002 13:39:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23253 invoked from network); 10 Apr 2002 13:38:59 -0000 Received: from intern12.lnk.telstra.net (HELO shitei.mindrot.org) (139.130.53.38) by mail.netbsd.org with SMTP; 10 Apr 2002 13:38:59 -0000 Received: from mothra.mindrot.org (mothra.mindrot.org [203.44.118.225]) by shitei.mindrot.org (Postfix) with ESMTP id 59AC1E924; Wed, 10 Apr 2002 23:47:32 +1000 (EST) Received: from localhost (djm@localhost) by mothra.mindrot.org (8.11.6/8.11.6) with ESMTP id g3ADcsc01154; Wed, 10 Apr 2002 23:38:55 +1000 X-Authentication-Warning: mothra.mindrot.org: djm owned process doing -bs Date: Wed, 10 Apr 2002 23:38:52 +1000 (EST) From: Damien Miller To: "Blaine, Les CPR / TLA" Cc: "lavasani@connect.org.uk" , "haruyama@klab.org" , "ietf-ssh@netbsd.org" Subject: Re: SSh 3.1p1 In-Reply-To: <88AB06281E1D0F4E86DEF6C486C58C75142A19@ip15293.peostamis.belvoir.army.mil> Message-ID: X-Paranoia: just because you're paranoid doesn't mean they aren't out to get you MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 9 Apr 2002, Blaine, Les CPR / TLA wrote: > > Has OpenSSh v3.1p1 been tested on HPUX 11.x in trusted mode using shadow > passwords? This is the wrong list for implementation questions, you need openssh-unix-dev@mindrot.org -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Apr 10 12:32:32 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24666 for ; Wed, 10 Apr 2002 12:32:31 -0400 (EDT) Received: (qmail 23207 invoked by uid 605); 10 Apr 2002 16:32:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23198 invoked from network); 10 Apr 2002 16:32:28 -0000 Received: from pns1.brandenburg.de (194.76.232.136) by mail.netbsd.org with SMTP; 10 Apr 2002 16:32:28 -0000 Received: from www1.brandenburg.de (www1.brandenburg.de [194.76.232.130]) by pns1.brandenburg.de (8.9.3 (PHNE_24419)/8.9.3) with ESMTP id SAA19945 for ; Wed, 10 Apr 2002 18:32:21 +0200 (METDST) Received: by www1.brandenburg.de; id SAA25430; Wed, 10 Apr 2002 18:32:19 +0200 (METDST) Received: from unknown(10.128.9.41) by www1.brandenburg.de via smap (V5.5) id xma025410; Wed, 10 Apr 02 18:32:05 +0200 Received: from lvnbb.brandenburg.de (hp-www.ldspdm.ldsbb.lvnbb.de [10.128.9.41]) by hp-www.ldspdm.ldsbb.lvnbb.de (8.11.1/8.11.1) with SMTP id g3AGW7w19482 for ; Wed, 10 Apr 2002 18:32:07 +0200 (METDST) Received: from GATEWAYS-Message_Server by lvnbb.brandenburg.de with Novell_GroupWise; Wed, 10 Apr 2002 18:32:06 +0200 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Wed, 10 Apr 2002 18:31:04 +0200 From: "Stephan Hendl" To: , , , Cc: Subject: Antw: SSh 3.1p1 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA24666 Hi Markus, it has bin tested by me against HP/UX 11.0 in the mode "trusted system" and worked well. Since PAM-authentification is default in 11.00 you must not activate it via the configure switch "--with-pam". If you like I can send you a depot-file and the prndg-package by Lutz Jaenicke as a depot as well because I compiled the ssh with use of it for generating entropie. regards Stephan >>> 10.04.2002 12.17 Uhr >>> Has OpenSSh v3.1p1 been tested on HPUX 11.x in trusted mode using shadow passwords? Regards- Les Blaine Suite 210 8500 Cinder Bed Road Newington, VA 22122 703-428-0668 x273 Desk 703-428-0686 FAX les.blaine@peostamis.belvoir.army.mil LeslieBlaine@netscape.net The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. _______________________________________________ openssh-unix-dev@mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 11 15:29:15 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10819 for ; Thu, 11 Apr 2002 15:29:15 -0400 (EDT) Received: (qmail 21496 invoked by uid 605); 11 Apr 2002 19:28:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21474 invoked from network); 11 Apr 2002 19:28:45 -0000 Received: from ip15293.peostamis.belvoir.army.mil (HELO rcposv010.eis.army.mil) (128.190.152.93) by mail.netbsd.org with SMTP; 11 Apr 2002 19:28:45 -0000 Received: by ip15293.peostamis.belvoir.army.mil with Internet Mail Service (5.5.2655.55) id <2RRGC1V7>; Thu, 11 Apr 2002 15:28:44 -0400 Message-ID: <88AB06281E1D0F4E86DEF6C486C58C75142B8D@ip15293.peostamis.belvoir.army.mil> From: "Blaine, Les CPR / TLA" To: Damien Miller Cc: lavasani@connect.org.uk, haruyama@klab.org, ietf-ssh@netbsd.org Subject: RE: SSh 3.1p1 Date: Thu, 11 Apr 2002 15:28:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list Thanks. I repost. -----Original Message----- From: Damien Miller [mailto:djm@mindrot.org] Sent: Wednesday, April 10, 2002 9:39 AM To: Blaine, Les CPR / TLA Cc: lavasani@connect.org.uk; haruyama@klab.org; ietf-ssh@netbsd.org Subject: Re: SSh 3.1p1 On Tue, 9 Apr 2002, Blaine, Les CPR / TLA wrote: > > Has OpenSSh v3.1p1 been tested on HPUX 11.x in trusted mode using shadow > passwords? This is the wrong list for implementation questions, you need openssh-unix-dev@mindrot.org -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 11 15:39:23 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11268 for ; Thu, 11 Apr 2002 15:39:22 -0400 (EDT) Received: (qmail 29345 invoked by uid 605); 11 Apr 2002 19:39:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29336 invoked from network); 11 Apr 2002 19:39:21 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 11 Apr 2002 19:39:21 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05636 for ; Thu, 11 Apr 2002 12:39:20 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21383 for ; Thu, 11 Apr 2002 15:39:19 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g3BJbLss001873 for ; Thu, 11 Apr 2002 15:37:21 -0400 (EDT) Message-Id: <200204111937.g3BJbLss001873@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: Joyce Reynolds: re: Last Call: SSH Protocol Architecture to Proposed Standard Reply-to: sommerfeld@east.sun.com Date: Thu, 11 Apr 2002 15:37:21 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list RFC editor signs off. ------- Forwarded Message From sommerfeld-request@east.sun.com Thu Apr 11 15:35:07 2002 Return-Path: From: Joyce Reynolds Received: (from jkrey@localhost) by akamai.isi.edu (8.8.7/8.8.6) id TAA03067; Thu, 11 Apr 2002 19:28:51 GMT Date: Thu, 11 Apr 2002 19:28:51 GMT Message-Id: <200204111928.TAA03067@akamai.isi.edu> To: iesg@ietf.org Subject: re: Last Call: SSH Protocol Architecture to Proposed Standard Cc: rfc-editor@rfc-editor.org, sommerfeld@east.sun.com, ylo@ssh.com, kivinen@ssh.com, tri@ssh.com, sjl@ssh.com X-Sun-Charset: US-ASCII Content-Length: 379 IESG: The RFC Editor has reviewed the following Internet-Drafts which are in Last Call: and has no comments or concerns with regards to the publication of these documents. Joyce K. Reynolds (on behalf of RFC Editor staff) ------- End of Forwarded Message From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Apr 27 22:56:23 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00550 for ; Sat, 27 Apr 2002 22:56:22 -0400 (EDT) Received: (qmail 20109 invoked by uid 605); 28 Apr 2002 02:56:16 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20020428025616.20108.qmail@mail.netbsd.org> Received: (qmail 20102 invoked from network); 28 Apr 2002 02:56:15 -0000 Received: from unknown (HELO emztd249.com) (213.251.168.108) by mail.netbsd.org with SMTP; 28 Apr 2002 02:56:15 -0000 From: "mrs mobutu" Reply-To: westephens6000@justice.com To: ietf-ssh@netbsd.org Date: Sun, 28 Apr 2002 04:59:56 +0200 X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA00550 FROM:MRS. M SESE-SEKO DEAR FRIEND. I AM MRS. MARIAM SESE-SEKO WIDOW OF LATE PRESIDENT MOBUTU SESE-SEKO OF ZAIRE? NOW KNOWN AS DEMOCRATIC REPUBLIC OF CONGO (DRC). I AM MOVED TO WRITE YOU THIS LETTER, THIS WAS IN CONFIDENCE CONSIDERING MY PRESENT CIRCUMSTANCE AND SITUATION. I ESCAPED ALONG WITH MY HUSBAND AND TWO OF OUR SONS TIMOTHY AND BASHER OUT OF DEMOCRATIC REPUBLIC OF CONGO (DRC) TO ABIDJAN,COTE D'IVOIRE WHERE MY FAMILY AND I SETTLED, WHILE WE LATER MOVED TO SETTLED IN MORROCO WHERE MY HUSBAND LATER DIED OF CANCER DISEASE. HOWEVER DUE TO THIS SITUATION WE DECIDED TO CHANGED MOST OF MY HUSBAND'S BILLIONS OF DOLLARS DEPOSITED IN SWISS BANK AND OTHER COUNTRIES INTO OTHER FORMS OF MONEY CODED FOR SAFE PURPOSE BECAUSE THE NEW HEAD OF STATE OF (DR) MR LAURENT KABILA HAS MADE ARRANGEMENT WITH THE SWISS GOVERNMENT AND OTHER EUROPEAN COUNTRIES TO FREEZE ALL MY LATE HUSBAND'STREASURES DEPOSITED IN SOME EUROPEAN COUNTRIES. HENCE MY CHILDREN AND I DECIDED LAYING LOW IN AFRICA TO STUDY THE SITUATION TILL WHEN THINGS GETS BETTER, LIKE NOW THAT PRESIDENT KABILA IS DEAD AND THE SON TAKING OVER(JOSEPH KABILA). ONE OF MY LATE HUSBAND'S CHATEAUX IN SOUTHERN FRANCE WAS CONFISCATED BY THE FRENCH GOVERNMENT, AND AS SUCH I HAD TO CHANGE MY IDENTITY SO THAT MY INVESTMENT WILL NOT BE TRACED AND CONFISCATED. I HAVE DEPOSITED THE SUM OF ONE HUNDRED MLLION UNITED STATE DOLLARS (US$75,000,000,00.) WITH A SECURITY COMPANY , FOR SAFEKEEPING. THE FUNDS ARE SECURITY CODED TO PREVENT THEM FROM KNOWING THE CONTENT. WHAT I WANT YOU TO DO IS TO INDICATE YOUR INTEREST THAT YOU WILL ASSIST US BY RECEIVING THE MONEY ON OUR BEHALF IN EUROPE. I WANT YOU TO ASSIST IN INVESTING THIS MONEY, BUT I WILL NOT WANT MY IDENTITY REVEALED. I WILL ALSO WANT TO BUY PROPERTIES AND STOCK IN MULTI-NATIONAL COMPANIES AND TO ENGAGE IN OTHER SAFE AND NON-SPECULATIVE INVESTMENTS. MAY I AT THIS POINT EMPHASISE THE HIGH LEVEL OF CONFIDENTIALITY, WHICH THIS BUSINESS DEMANDS, AND HOPE YOU WILL NOT BETRAY THE TRUST AND CONFIDENCE, WHICH I REPOSE IN YOU IN CONCLUSION, IN THE EVENT YOU ARE INTRESTED TO ASSIST US I WILL LIKE YOU TO CONTACT MY LAWYER WHO I HAVE STATIONED IN HOLLAND TO WITHNESS THE TRANSACTION TO IS CONCLUTION.YOU CAN REACH HIM ON IS DIRECT LINE WHICH IS +31-612-480 860 OR VIA MAIL WESTEPHENS6000@JUSTICE.COM.HIS NAME IS STEPHENS AND I HAVE THE FALL TRUST IN HIME. I SINCERELY WILL APPRECAITE YOUR ACKNOWLEDGMENT AS SOON AS POSSIBLE. BEST REGARDS, MRS M. SESE SEKO