From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 1 12:51:42 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25474 for ; Thu, 1 Nov 2001 12:51:41 -0500 (EST) Received: (qmail 21995 invoked by uid 605); 1 Nov 2001 17:51:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21987 invoked from network); 1 Nov 2001 17:51:40 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 1 Nov 2001 17:51:40 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05870; Thu, 1 Nov 2001 10:51:17 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.105]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id JAA13344; Thu, 1 Nov 2001 09:52:11 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.12.1+Sun/8.12.1) with SMTP id fA1HpUSI593917; Thu, 1 Nov 2001 09:51:30 -0800 (PST) Message-Id: <200111011751.fA1HpUSI593917@jurassic.eng.sun.com> Date: Thu, 1 Nov 2001 09:51:30 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: availability of specifications To: ietf-ssh@netbsd.org, jwn2@qualcomm.com Cc: galb-list@vandyke.com, markus@openbsd.org, ietf-ssh@denisbider.com, mats.andersson@appgate.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: MjjibBdk4kKbrnivhpnkDA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_47 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >Excuse me, I'm just peeking in from outside. > > From all this discussion, it appears none of the drafts have made it >to Marcus or Jeff for consideration by the IESG. Do I have that >right? I'm working on them they will be submitted before the cut of date. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 8 06:25:32 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22347 for ; Thu, 8 Nov 2001 06:25:31 -0500 (EST) Received: (qmail 19168 invoked by uid 605); 8 Nov 2001 11:25:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19161 invoked from network); 8 Nov 2001 11:25:27 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 8 Nov 2001 11:25:27 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id MAA19903; Thu, 8 Nov 2001 12:25:19 +0100 (MET) Date: Thu, 8 Nov 2001 12:25:19 +0100 From: Markus Friedl To: Yavor G Georgiev Cc: ietf-ssh@netbsd.org, openssh-unix-dev@mindrot.org Subject: Re: your mail Message-ID: <20011108122519.A17172@faui02.informatik.uni-erlangen.de> References: <8024670063.20011107173526@rambler.bg> <20011107165225.C1689@faui02.informatik.uni-erlangen.de> <4182487270.20011108093903@rambler.bg> <20011108101028.C966@faui02.informatik.uni-erlangen.de> <13393413040.20011108124109@rambler.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <13393413040.20011108124109@rambler.bg>; from yasho@rambler.bg on Thu, Nov 08, 2001 at 12:41:09PM +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list hi, if i understand you correctly your problem is that you and i disagree about what 'window size' means and what data/length is included in the 'window' if i send a byte SSH_MSG_CHANNEL_DATA uint32 recipient channel string data packet in OpenSSH, i count only the actual size of the data, and not the size of the complete packet as sent on the wire. draft-ietf-secsh-connect-11.txt says: "The window size is decremented by the amount of data sent." i don't think that the additional 1+4+4 bytes (byte,uint32,uint32) should be included in the window size counter. but i could be wrong. perhaps the draft is ambiguous about this. what do other implementations do? i think that only the size of the actual 'payload' data should be included in the window size, because you usually send SSH_MSG_CHANNEL_WINDOW_ADJUST messages if you have consumed the data (e.g. written the data to a socket). when forwarding/consuming the data received on a channel, OpenSSH does no longer know over how many packets this data was originally distributed. so only the length of the payload, the amount of data written to the 'consumer-socket' can be used to caculate the size for SSH_MSG_CHANNEL_WINDOW_ADJUST. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 8 06:40:35 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22474 for ; Thu, 8 Nov 2001 06:40:35 -0500 (EST) Received: (qmail 22557 invoked by uid 605); 8 Nov 2001 11:40:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22550 invoked from network); 8 Nov 2001 11:40:27 -0000 Received: from ns.batm.netissat.bg (HELO mars.batm.netissat.bg) (212.72.192.133) by mail.netbsd.org with SMTP; 8 Nov 2001 11:40:27 -0000 Received: (qmail 14871 invoked from network); 8 Nov 2001 22:44:31 -0000 Received: from io.batm.netissat.bg (192.168.0.13) by ns.batm.netissat.bg with SMTP; 8 Nov 2001 22:44:31 -0000 Date: Thu, 8 Nov 2001 13:34:43 +0100 From: Yavor G Georgiev X-Mailer: The Bat! (v1.46d) Personal Reply-To: Yavor G Georgiev X-Priority: 3 (Normal) Message-ID: <1496627312.20011108133443@rambler.bg> To: Markus Friedl CC: ietf-ssh@netbsd.org, openssh-unix-dev@mindrot.org Subject: Re[2]: your mail In-reply-To: <20011108122519.A17172@faui02.informatik.uni-erlangen.de> References: <8024670063.20011107173526@rambler.bg> <20011107165225.C1689@faui02.informatik.uni-erlangen.de> <4182487270.20011108093903@rambler.bg> <20011108101028.C966@faui02.informatik.uni-erlangen.de> <13393413040.20011108124109@rambler.bg> <20011108122519.A17172@faui02.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Hello Markus, Thursday, November 08, 2001, 12:25:19 PM, you wrote: MF> hi, MF> if i understand you correctly your problem is that you and i disagree MF> about what 'window size' means and what data/length is included in the MF> 'window' MF> if i send a MF> byte SSH_MSG_CHANNEL_DATA MF> uint32 recipient channel MF> string data MF> packet in OpenSSH, i count only the actual size of the data, MF> and not the size of the complete packet as sent on the wire. MF> draft-ietf-secsh-connect-11.txt says: MF> "The window size is decremented by the amount of data sent." MF> i don't think that the additional 1+4+4 bytes (byte,uint32,uint32) MF> should be included in the window size counter. but i could be wrong. MF> perhaps the draft is ambiguous about this. MF> what do other implementations do? MF> i think that only the size of the actual 'payload' data should be MF> included in the window size, because you usually send MF> SSH_MSG_CHANNEL_WINDOW_ADJUST messages if you have consumed the data MF> (e.g. written the data to a socket). MF> when forwarding/consuming the data received on a channel, OpenSSH does MF> no longer know over how many packets this data was originally MF> distributed. so only the length of the payload, the amount of data MF> written to the 'consumer-socket' can be used to caculate the size for MF> SSH_MSG_CHANNEL_WINDOW_ADJUST. MF> -m Yes you got me right. I assume the data to be the last part in the following example packet: byte SSH_MSG_CHANNEL_DATA uint32 recipient channel string data the one that is type string, which includes 4 more bytes for the length. You asked me about other implementations. I have made many tests with the PuTTY client. It sends window adjustment after every recieved packet. The value of the adjustment is calculated as the data field not the payload of the data. I am totally agreed with you that the draft is ambigious. Can we get some advice from the draft guys - what had they meant ? --- Best regards, Yavor mailto:yasho@rambler.bg From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 8 07:22:23 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23262 for ; Thu, 8 Nov 2001 07:22:22 -0500 (EST) Received: (qmail 27883 invoked by uid 605); 8 Nov 2001 12:22:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27876 invoked from network); 8 Nov 2001 12:22:19 -0000 Received: from ixion.tartarus.org (195.153.205.133) by mail.netbsd.org with SMTP; 8 Nov 2001 12:22:19 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 161oCF-0005Sd-00; Thu, 08 Nov 2001 12:22:15 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <20011108122519.A17172@faui02.informatik.uni-erlangen.de> Subject: Re: your mail Message-Id: Date: Thu, 08 Nov 2001 12:22:15 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Markus Friedl wrote: > what do other implementations do? > > i think that only the size of the actual 'payload' data should be > included in the window size, because you usually send > SSH_MSG_CHANNEL_WINDOW_ADJUST messages if you have consumed the data > (e.g. written the data to a socket). Speaking for PuTTY: I agree with you, and in fact it hadn't occurred to me that there was any other way to do it. -- Simon Tatham What do we want? ROT13! When do we want it? ABJ! From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 8 07:48:40 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23851 for ; Thu, 8 Nov 2001 07:48:40 -0500 (EST) Received: (qmail 1836 invoked by uid 605); 8 Nov 2001 12:48:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1826 invoked from network); 8 Nov 2001 12:48:37 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 8 Nov 2001 12:48:37 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id NAA29394; Thu, 8 Nov 2001 13:48:29 +0100 (MET) Date: Thu, 8 Nov 2001 13:48:29 +0100 From: Markus Friedl To: Yavor G Georgiev Cc: ietf-ssh@netbsd.org, openssh-unix-dev@mindrot.org Subject: Re: your mail Message-ID: <20011108134829.A28973@faui02.informatik.uni-erlangen.de> References: <8024670063.20011107173526@rambler.bg> <20011107165225.C1689@faui02.informatik.uni-erlangen.de> <4182487270.20011108093903@rambler.bg> <20011108101028.C966@faui02.informatik.uni-erlangen.de> <13393413040.20011108124109@rambler.bg> <20011108122519.A17172@faui02.informatik.uni-erlangen.de> <1496627312.20011108133443@rambler.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <1496627312.20011108133443@rambler.bg>; from yasho@rambler.bg on Thu, Nov 08, 2001 at 01:34:43PM +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Nov 08, 2001 at 01:34:43PM +0100, Yavor G Georgiev wrote: > Yes you got me right. > I assume the data to be the last part in the following example packet: > byte SSH_MSG_CHANNEL_DATA > uint32 recipient channel > string data > the one that is type string, which includes 4 more bytes for the > length. i think the 4 string-len bytes should _not_ be included, since it should not matter for the window size whether a payload data of 10 bytes arrives in one or in 4 messages. if you include the 4 bytes in the window size then you count packets. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 8 10:24:00 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28308 for ; Thu, 8 Nov 2001 10:23:59 -0500 (EST) Received: (qmail 2021 invoked by uid 605); 8 Nov 2001 15:22:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1998 invoked from network); 8 Nov 2001 15:22:57 -0000 Received: from penguin-ext.wise.edt.ericsson.se (194.237.142.110) by mail.netbsd.org with SMTP; 8 Nov 2001 15:22:57 -0000 Received: from s35.lmera.ericsson.se (s35.lmera.ericsson.se [150.132.93.136]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fA8FMsC25725 for ; Thu, 8 Nov 2001 16:22:54 +0100 (MET) Received: from lm6067.lmera.ericsson.se (lm6067.lmera.ericsson.se [150.132.106.67]) by s35.lmera.ericsson.se (8.11.6/8.11.6) with ESMTP id fA8FMsR18912 for ; Thu, 8 Nov 2001 16:22:54 +0100 (MET) Received: from lm6067.lmera.ericsson.se (localhost [127.0.0.1]) by lm6067.lmera.ericsson.se (8.8.8+Sun/8.8.8) with ESMTP id QAA12304 for ; Thu, 8 Nov 2001 16:22:51 +0100 (MET) Message-Id: <200111081522.QAA12304@lm6067.lmera.ericsson.se> X-Mailer: exmh version 2.1.1 10/15/1999 From: Mats Gustafsson To: ietf-ssh@netbsd.org Subject: A future for the SSH File Transfer Protocol? X-Face: "Jvcd#l.mM:>5?'t0}i,o+Uk"Y;(zqE6wQR_o04&^Xg!t<9Ts;<[tB2Z'=]GYB9Mzu'XsDS {9hG[sC9lv:h"0]?UN$W7f0YzWpUw\k_Mh.1HM?\l>`LrD}4O[^:}3ZGtC$,a?Cl5~4G_$>=|JeEl(;o#3l; Thu, 8 Nov 2001 10:40:19 -0500 (EST) Received: (qmail 5854 invoked by uid 605); 8 Nov 2001 15:40:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5847 invoked from network); 8 Nov 2001 15:40:16 -0000 Received: from ixion.tartarus.org (195.153.205.133) by mail.netbsd.org with SMTP; 8 Nov 2001 15:40:16 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 161rHq-0007a4-00; Thu, 08 Nov 2001 15:40:14 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <200111081522.QAA12304@lm6067.lmera.ericsson.se> Subject: Re: A future for the SSH File Transfer Protocol? Message-Id: Date: Thu, 08 Nov 2001 15:40:14 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Mats Gustafsson wrote: > The "SSH File Transfer Protocol" draft has expired and I can find > no reference to SFTP in the mailing list archive since August. As far as I can tell there's very little _at all_ in the mailing list archive since August ... > This makes me wonder if there is anyone out there who still sees a > future for SFTP and is working on it. I do. I think it's extremely useful to have a file transfer protocol within the framework of SSH, because most security-conscious people accessing a remote account will already have set up SSH authentication credentials. Moreover, SFTP is a qualitative improvement over SCP, partly because it's more general and can usefully be used for complex automated tasks, partly because it's actually vaguely _possible_ to secure a client against a malicious server (SCP has a wildcard issue that makes this highly inconvenient), and largely because the range of clients you can plausibly write is so much greater. PuTTY's SCP client now uses SFTP as the underlying protocol whenever it can, falling back to the old unreliable SCP only when it has no choice. I might be the only one, however; nobody has shown much interest in answering my clarifying questions or in the extension I proposed (to allow user details to be looked up, so a client could understand `~fred' and also so that the uid->username mapping in the recommended form of the long listing could be done in other contexts as well). Cheers, Simon -- Simon Tatham "What a caterpillar calls the end of the world, a human calls a butterfly." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 8 10:52:01 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28941 for ; Thu, 8 Nov 2001 10:52:00 -0500 (EST) Received: (qmail 8702 invoked by uid 605); 8 Nov 2001 15:51:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8695 invoked from network); 8 Nov 2001 15:51:57 -0000 Received: from watsun.cc.columbia.edu (128.59.39.2) by mail.netbsd.org with SMTP; 8 Nov 2001 15:51:57 -0000 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id KAA07737; Thu, 8 Nov 2001 10:51:55 -0500 (EST) Date: Thu, 8 Nov 2001 10:51:55 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Simon Tatham Cc: ietf-ssh@netbsd.org Subject: Re: A future for the SSH File Transfer Protocol? In-Reply-To: Your message of Thu, 08 Nov 2001 15:40:14 +0000 Message-ID: Sender: ietf-ssh-owner@netbsd.org Precedence: list Why should a client ever have to understand a system dependent alias such as ~fred? The only entity that should need to know how to map ~fred to what it points to is the sender of the file. > > I might be the only one, however; nobody has shown much interest in > answering my clarifying questions or in the extension I proposed (to > allow user details to be looked up, so a client could understand > `~fred' and also so that the uid->username mapping in the > recommended form of the long listing could be done in other contexts > as well). > > Cheers, > Simon > -- > Simon Tatham "What a caterpillar calls the end of the > world, a human calls a butterfly." > Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 Beta available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 8 11:02:51 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29189 for ; Thu, 8 Nov 2001 11:02:50 -0500 (EST) Received: (qmail 12223 invoked by uid 605); 8 Nov 2001 16:02:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12215 invoked from network); 8 Nov 2001 16:02:48 -0000 Received: from ixion.tartarus.org (195.153.205.133) by mail.netbsd.org with SMTP; 8 Nov 2001 16:02:48 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 161rdb-0007ki-00; Thu, 08 Nov 2001 16:02:43 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham In-Reply-To: To: jaltman@columbia.edu Cc: ietf-ssh@netbsd.org Subject: Re: A future for the SSH File Transfer Protocol? Message-Id: Date: Thu, 08 Nov 2001 16:02:43 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Jeffrey Altman wrote: > Why should a client ever have to understand a system dependent alias > such as ~fred? > > The only entity that should need to know how to map ~fred to what it > points to is the sender of the file. Ah; you think it would be better for servers to understand `~fred' at the start of a pathname? Fair enough, I suppose. But the rest of the ethos of SFTP seems to be that whatever alias or synonym you use to refer to a directory, you can always call FXP_REALPATH and get the full canonical name. So in my command-line SFTP client, I don't want to type `cd ~fred' and then have `pwd' just tell me `~fred'; I'd rather get the same behaviour I get at the real shell prompt, where I type `cd ~fred' and `pwd' tells me `/home/fred'. I suppose that could be done just by making the server understand `~fred' at the start of a pathname, and then having the client call FXP_REALPATH("~fred") if it wanted the canonical form; but that starts to eat into the available characters in filenames, which is something SFTP has so far been scrupulous in not doing. So instead, my proposal was to introduce a protocol extension which allowed the client side to request the home directory of a particular user. While I was at it, I also added name<->number mappings for users and groups, on the grounds that it seems silly that a command-line client can list the textual usernames of file owners by printing out the long name field, but a GUI client wanting to split all the details into separate columns has to make do with the numbers. Cheers, Simon -- Simon Tatham "A cynic is a person who smells flowers and immediately looks around for a coffin." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 8 11:07:26 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29365 for ; Thu, 8 Nov 2001 11:07:26 -0500 (EST) Received: (qmail 12748 invoked by uid 605); 8 Nov 2001 16:07:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12740 invoked from network); 8 Nov 2001 16:07:24 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 8 Nov 2001 16:07:24 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 372741; Thu, 08 Nov 2001 09:10:30 -0700 Message-ID: <003201c1686f$73f61450$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: "Mats Gustafsson" , References: <200111081522.QAA12304@lm6067.lmera.ericsson.se> Subject: Re: A future for the SSH File Transfer Protocol? Date: Thu, 8 Nov 2001 09:07:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > The "SSH File Transfer Protocol" draft has expired and I can find > no reference to SFTP in the mailing list archive since August. This > makes me wonder if there is anyone out there who still sees a future > for SFTP and is working on it. Yes, we are working on it. We have a version ready to go that merges in the non-objectional changes from the version that got yanked due to the name change. We are just waiting for a blessing from Bill to submit it. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 8 11:16:00 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29612 for ; Thu, 8 Nov 2001 11:15:59 -0500 (EST) Received: (qmail 14232 invoked by uid 605); 8 Nov 2001 16:15:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14223 invoked from network); 8 Nov 2001 16:15:57 -0000 Received: from watsun.cc.columbia.edu (128.59.39.2) by mail.netbsd.org with SMTP; 8 Nov 2001 16:15:57 -0000 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id LAA11271; Thu, 8 Nov 2001 11:15:55 -0500 (EST) Date: Thu, 8 Nov 2001 11:15:55 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Simon Tatham Cc: ietf-ssh@netbsd.org Subject: Re: A future for the SSH File Transfer Protocol? In-Reply-To: Your message of Thu, 08 Nov 2001 16:02:43 +0000 Message-ID: Sender: ietf-ssh-owner@netbsd.org Precedence: list The reality is that a client should not have any idea what the "realpath" means on the server. This plus the notion of providing access to uid/gid numbers is crazy when the world is not made up entirely of Unix systems. How is FXP_REALPATH("~fred") different then GETHOME("fred") in regards to how you are going to deal with it? > Jeffrey Altman wrote: > > > Why should a client ever have to understand a system dependent alias > > such as ~fred? > > > > The only entity that should need to know how to map ~fred to what it > > points to is the sender of the file. > > Ah; you think it would be better for servers to understand `~fred' > at the start of a pathname? > > Fair enough, I suppose. But the rest of the ethos of SFTP seems to > be that whatever alias or synonym you use to refer to a directory, > you can always call FXP_REALPATH and get the full canonical name. So > in my command-line SFTP client, I don't want to type `cd ~fred' and > then have `pwd' just tell me `~fred'; I'd rather get the same > behaviour I get at the real shell prompt, where I type `cd ~fred' > and `pwd' tells me `/home/fred'. > > I suppose that could be done just by making the server understand > `~fred' at the start of a pathname, and then having the client call > FXP_REALPATH("~fred") if it wanted the canonical form; but that > starts to eat into the available characters in filenames, which is > something SFTP has so far been scrupulous in not doing. So instead, > my proposal was to introduce a protocol extension which allowed the > client side to request the home directory of a particular user. > > While I was at it, I also added name<->number mappings for users and > groups, on the grounds that it seems silly that a command-line > client can list the textual usernames of file owners by printing out > the long name field, but a GUI client wanting to split all the > details into separate columns has to make do with the numbers. > > Cheers, > Simon > -- > Simon Tatham "A cynic is a person who smells flowers and > immediately looks around for a coffin." > Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 Beta available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 8 11:20:39 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29752 for ; Thu, 8 Nov 2001 11:20:39 -0500 (EST) Received: (qmail 15687 invoked by uid 605); 8 Nov 2001 16:20:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15680 invoked from network); 8 Nov 2001 16:20:36 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 8 Nov 2001 16:20:36 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 372761; Thu, 08 Nov 2001 09:23:40 -0700 Message-ID: <004501c16871$4a63eb60$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: "Simon Tatham" , Cc: References: Subject: Re: A future for the SSH File Transfer Protocol? Date: Thu, 8 Nov 2001 09:20:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > While I was at it, I also added name<->number mappings for users and > groups, on the grounds that it seems silly that a command-line > client can list the textual usernames of file owners by printing out > the long name field, but a GUI client wanting to split all the > details into separate columns has to make do with the numbers. I'm definitely interested in this. Can you repost your proposal? I would actually like to eliminate the long listing format (on a per file basis, I think it adds several hundred percent overhead... on a directory with several hundred files in it, over a slow link, this is a not insignificant overhead.) But to do so, we need to provide a way for the client to map uid/gid to names. I'd also like to do something a bit more flexible for uid/gids -- WinNT, which the platform I'm working on, doesn't use simple ints for user identifiers. I'd be tempted to suggest that UIDs be defined as string identifier which would be an opaque data structure to the client. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 8 11:37:30 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00103 for ; Thu, 8 Nov 2001 11:37:29 -0500 (EST) Received: (qmail 17281 invoked by uid 605); 8 Nov 2001 16:37:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17274 invoked from network); 8 Nov 2001 16:37:24 -0000 Received: from ixion.tartarus.org (195.153.205.133) by mail.netbsd.org with SMTP; 8 Nov 2001 16:37:24 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 161sB9-00087V-00; Thu, 08 Nov 2001 16:37:23 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham In-Reply-To: <004501c16871$4a63eb60$2800a8c0@test.vandyke.com> To: Subject: Re: A future for the SSH File Transfer Protocol? Message-Id: Date: Thu, 08 Nov 2001 16:37:23 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list "Joseph Galbraith" wrote: > I'm definitely interested in this. Can you repost your proposal? Certainly. It's available as a text file from http://www.tartarus.org/~simon/ssh/draft-sftp-userdb-00.txt > I would actually like to eliminate the long listing format (on a per > file basis, I think it adds several hundred percent overhead... on a > directory with several hundred files in it, over a slow link, this > is a not insignificant overhead.) Hmm, hadn't thought of that. And compression will only cut it down by so much... > But to do so, we need to provide a way for the client to map uid/gid > to names. ... which would be much more bandwidth-efficient because you only need do the mapping once for each uid mentioned, and in the average directory listing there are many more files than uids. Nice idea. (On the other hand, waiting for the file data to be returned and then looking up the uids will cost you another round trip. If your link is high-bandwidth but high-latency, this approach might lose!) > I'd be tempted to suggest that UIDs be defined as > string identifier > which would be an opaque data structure to the client. But suitable for showing to the user, presumably? The ghastly WinNT security IDs wouldn't be something the average user wanted to see polluting their file listing :-) Cheers, Simon -- Simon Tatham "A cynic is a person who smells flowers and immediately looks around for a coffin." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 8 12:07:25 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00878 for ; Thu, 8 Nov 2001 12:07:24 -0500 (EST) Received: (qmail 24026 invoked by uid 605); 8 Nov 2001 17:07:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24019 invoked from network); 8 Nov 2001 17:07:22 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 8 Nov 2001 17:07:22 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 372862; Thu, 08 Nov 2001 10:10:28 -0700 Message-ID: <001901c16877$d48b7230$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: "Simon Tatham" , References: Subject: Re: A future for the SSH File Transfer Protocol? Date: Thu, 8 Nov 2001 10:06:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > > I would actually like to eliminate the long listing format (on a per > > file basis, I think it adds several hundred percent overhead... on a > > directory with several hundred files in it, over a slow link, this > > is a not insignificant overhead.) > > Hmm, hadn't thought of that. And compression will only cut it down > by so much... > > > But to do so, we need to provide a way for the client to map uid/gid > > to names. > > ... which would be much more bandwidth-efficient because you only > need do the mapping once for each uid mentioned, and in the average > directory listing there are many more files than uids. Nice idea. > > (On the other hand, waiting for the file data to be returned and > then looking up the uids will cost you another round trip. If your > link is high-bandwidth but high-latency, this approach might lose!) True -- on the other hand, you needn't wait until the directory enumeration is complete to begin issuing requests to resolve UIDs. Alternatively, we could automatically include UID resolution information as part of the NAMES packet, avoiding the round trip. Or perhaps there would be an additional flag to the READDIR command specifying whether UID resolution information should be automatically sent. Perhaps a more general mechanism for the client to tell the server what information is important would be appropriate. I've also considered a mechanism for the server to communicate what information is cheaply available and what information is expensive. When using NTFS, for example, security information is costly to look up (looking up owner / group for each file can slow down the file list significantly.) > > I'd be tempted to suggest that UIDs be defined as > > string identifier > > which would be an opaque data structure to the client. > > But suitable for showing to the user, presumably? The ghastly WinNT > security IDs wouldn't be something the average user wanted to see > polluting their file listing :-) True -- they are pretty ugly. However, the thing that is suitable for display is the resolved username. I would actually suggets that the identifier string is a binary blob -- it is only suitable for sending back to the server in order to manipulate the security of a file. Most unix servers would probably put the four byte uid in it. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 8 12:13:54 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01096 for ; Thu, 8 Nov 2001 12:13:53 -0500 (EST) Received: (qmail 24892 invoked by uid 605); 8 Nov 2001 17:13:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24885 invoked from network); 8 Nov 2001 17:13:53 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 8 Nov 2001 17:13:53 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 2CE6482F528; Thu, 8 Nov 2001 18:13:43 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.3/8.8.7) id SAA28230; Thu, 8 Nov 2001 18:13:41 +0100 (MET) To: Markus Friedl Cc: Yavor G Georgiev , ietf-ssh@netbsd.org, openssh-unix-dev@mindrot.org Subject: Re: your mail References: <8024670063.20011107173526@rambler.bg> <20011107165225.C1689@faui02.informatik.uni-erlangen.de> <4182487270.20011108093903@rambler.bg> <20011108101028.C966@faui02.informatik.uni-erlangen.de> <13393413040.20011108124109@rambler.bg> <20011108122519.A17172@faui02.informatik.uni-erlangen.de> <1496627312.20011108133443@rambler.bg> <20011108134829.A28973@faui02.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels Möller) Date: 08 Nov 2001 18:13:40 +0100 In-Reply-To: Markus Friedl's message of "Thu, 8 Nov 2001 13:48:29 +0100" Message-ID: Lines: 19 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Markus Friedl writes: > On Thu, Nov 08, 2001 at 01:34:43PM +0100, Yavor G Georgiev wrote: > > Yes you got me right. > > I assume the data to be the last part in the following example packet: > > byte SSH_MSG_CHANNEL_DATA > > uint32 recipient channel > > string data > > the one that is type string, which includes 4 more bytes for the > > length. > > i think the 4 string-len bytes should _not_ be included, since > it should not matter for the window size whether a payload data > of 10 bytes arrives in one or in 4 messages. I agree with Markus. LSH and openssh have the same behaviour, I think. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 8 12:24:46 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01734 for ; Thu, 8 Nov 2001 12:24:46 -0500 (EST) Received: (qmail 25898 invoked by uid 605); 8 Nov 2001 17:24:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25890 invoked from network); 8 Nov 2001 17:24:43 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 8 Nov 2001 17:24:43 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 372898; Thu, 08 Nov 2001 10:27:49 -0700 Message-ID: <002a01c1687a$40ddc8a0$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: "Markus Friedl" , =?iso-8859-1?Q?Niels_M=F6ller?= Cc: "Yavor G Georgiev" , , References: <8024670063.20011107173526@rambler.bg> <20011107165225.C1689@faui02.informatik.uni-erlangen.de> <4182487270.20011108093903@rambler.bg> <20011108101028.C966@faui02.informatik.uni-erlangen.de> <13393413040.20011108124109@rambler.bg> <20011108122519.A17172@faui02.informatik.uni-erlangen.de> <1496627312.20011108133443@rambler.bg> <20011108134829.A28973@faui02.informatik.uni-erlangen.de> Subject: Re: your mail Date: Thu, 8 Nov 2001 10:24:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit I believe VShell / SecureCRT also only bill the actual length of data against the window size. I do not think that the packet overhead should be included; I believe the current behavior is correct. - Joseph ----- Original Message ----- From: "Niels Möller" To: "Markus Friedl" Cc: "Yavor G Georgiev" ; ; Sent: Thursday, November 08, 2001 10:13 Subject: Re: your mail > Markus Friedl writes: > > > On Thu, Nov 08, 2001 at 01:34:43PM +0100, Yavor G Georgiev wrote: > > > Yes you got me right. > > > I assume the data to be the last part in the following example packet: > > > byte SSH_MSG_CHANNEL_DATA > > > uint32 recipient channel > > > string data > > > the one that is type string, which includes 4 more bytes for the > > > length. > > > > i think the 4 string-len bytes should _not_ be included, since > > it should not matter for the window size whether a payload data > > of 10 bytes arrives in one or in 4 messages. > > I agree with Markus. LSH and openssh have the same behaviour, I think. > > Regards, > /Niels > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 8 12:26:33 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01889 for ; Thu, 8 Nov 2001 12:26:32 -0500 (EST) Received: (qmail 26337 invoked by uid 605); 8 Nov 2001 17:26:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26330 invoked from network); 8 Nov 2001 17:26:30 -0000 Received: from ixion.tartarus.org (195.153.205.133) by mail.netbsd.org with SMTP; 8 Nov 2001 17:26:30 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 161spO-0000Cy-00; Thu, 08 Nov 2001 17:18:58 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham In-Reply-To: <001901c16877$d48b7230$2800a8c0@test.vandyke.com> To: "Joseph Galbraith" Cc: Subject: Re: A future for the SSH File Transfer Protocol? Message-Id: Date: Thu, 08 Nov 2001 17:18:58 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list "Joseph Galbraith" wrote: > Or perhaps there would be an additional flag to the READDIR command > specifying whether UID resolution information should be > automatically sent. > > Perhaps a more general mechanism for the client to tell the server > what information is important would be appropriate. Ooh. Yes, this _does_ sound good; it also solves your other problem (once you've included the user database information to make the long name fields unnecessary, how do you arrange that the long name fields don't get sent anyway and waste all that effort?). Perhaps another extended data type, parallel to ATTRS but used for requests rather than responses? It might look something like this: uint32 flags uint32 extended_count present only if flag SSH_FILEXFER_ATTR_EXTENDED string extended_type ... more extended_type strings so that number of strings equals extended_count So you can set all the same flags that would be set in the returned ATTRS, and request particular types of extended data as well (to preserve extensibility). Except that of course that doesn't _include_ the long name field, because it's not part of ATTRS. Bah. Time for an unprincipled hack to the above, or back to the drawing board? > However, the thing that is suitable for display is the resolved > username. I would actually suggets that the identifier string is a > binary blob -- it is only suitable for sending back to the server in > order to manipulate the security of a file. Oh, I see. Fair enough. So if I wanted to assign ownership of a file to Fred, I'd do a getuserbyname("fred"), and the binary blob that came back would be suitable for using in FXP_(F)SETSTAT. Cheers, Simon -- Simon Tatham "I thought I'd put my foot so far into my mouth I wouldn't be able to sit down without standing up." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Nov 9 15:07:16 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25984 for ; Fri, 9 Nov 2001 15:07:15 -0500 (EST) Received: (qmail 1831 invoked by uid 605); 9 Nov 2001 20:07:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1824 invoked from network); 9 Nov 2001 20:07:12 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 9 Nov 2001 20:07:12 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 374438 for ietf-ssh@netbsd.org; Fri, 09 Nov 2001 13:10:21 -0700 Message-ID: <002101c1695a$b9afe4d0$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: Subject: Meeting in december, new drafts? Date: Fri, 9 Nov 2001 13:11:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit I noticed we don't have a meeting scheduled on the draft agenda. We are planning on meeting aren't we? Will it be a Tuesday meeting again? (I think that was when the last one was.) Also, when are we going to have new core drafts? - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Nov 9 15:13:59 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26193 for ; Fri, 9 Nov 2001 15:13:58 -0500 (EST) Received: (qmail 3054 invoked by uid 605); 9 Nov 2001 20:13:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3047 invoked from network); 9 Nov 2001 20:13:55 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 9 Nov 2001 20:13:55 -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 MAA18800; Fri, 9 Nov 2001 12:13:54 -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 PAA14193; Fri, 9 Nov 2001 15:13:53 -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 fA9KDrVO016788; Fri, 9 Nov 2001 15:13:53 -0500 (EST) Message-Id: <200111092013.fA9KDrVO016788@thunk.east.sun.com> From: Bill Sommerfeld To: "Joseph Galbraith" cc: ietf-ssh@netbsd.org Subject: Re: Meeting in december, new drafts? In-Reply-To: Your message of "Fri, 09 Nov 2001 13:11:32 MST." <002101c1695a$b9afe4d0$2800a8c0@test.vandyke.com> Reply-to: sommerfeld@east.sun.com Date: Fri, 09 Nov 2001 15:13:53 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > I noticed we don't have a meeting scheduled > on the draft agenda. Your friendly neighborhood working group chair has been a bit busy with his day job lately.. > We are planning on meeting aren't we? Will it be a Tuesday meeting > again? (I think that was when the last one was.) yes; as i haven't asked for a meeting slot yet, the secretariat hasn't given me a day.. Send proposed agenda items for the meeting to me, optionally cc:'ing the wg list. > Also, when are we going to have new core > drafts? Darren? - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Nov 9 15:55:17 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27262 for ; Fri, 9 Nov 2001 15:55:16 -0500 (EST) Received: (qmail 10515 invoked by uid 605); 9 Nov 2001 20:55:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10503 invoked from network); 9 Nov 2001 20:55:13 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 9 Nov 2001 20:55:13 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 374503 for ietf-ssh@netbsd.org; Fri, 09 Nov 2001 13:58:21 -0700 Message-ID: <005901c16961$6e997720$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: Subject: uid & gid in sftp Date: Fri, 9 Nov 2001 13:59:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Currently sftp specifies uid and gid as a uint32. Unfortunately, this is an overly simplistic view of the world. (Well, at least my world.) NT uses arbitrary length numbers as it's user identifiers. I would like to proposed that we introduce the following in the next version of the sftp draft: string identifier where identifier is an opaque representation of a user or group. A unix implementation would probably send: uint32 4 uint32 uid for example. I could send something that WinNT could grok. This has some problems still -- the client needs some way to find out what the opaque identifier is for a given user. However, really, the protocol already has this problem. The UID / GID as they stand aren't really very useful, because that might not (probably aren't) correct on the client system. To address this, I think we should look at Simon's sftp extension: http://www.tartarus.org/~simon/ssh/draft-sftp-userdb-00.txt or some other extension that will allow the client to convert from identifiers to something suitable for display to the user and from displayable names back to something suitable for setstat / open / mkdir. Also, and extension like this would allow us to get rid of the longname format in the names structure, which can add several hundred percent overhead, depending on the length of the filename. (Which can be significant in a directory with several hundred files in it over a slow link.) - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Nov 9 15:55:41 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27275 for ; Fri, 9 Nov 2001 15:55:41 -0500 (EST) Received: (qmail 11279 invoked by uid 605); 9 Nov 2001 20:55:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11272 invoked from network); 9 Nov 2001 20:55:37 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 9 Nov 2001 20:55:37 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 374509; Fri, 09 Nov 2001 13:58:46 -0700 Message-ID: <005a01c16961$7d01f8f0$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: "Simon Tatham" , References: Subject: Re: A future for the SSH File Transfer Protocol? Date: Fri, 9 Nov 2001 13:59:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > "Joseph Galbraith" wrote: > > > I'm definitely interested in this. Can you repost your proposal? > > Certainly. It's available as a text file from > > http://www.tartarus.org/~simon/ssh/draft-sftp-userdb-00.txt Whoops -- I didn't realize our conversation on this had wandered off the list. I've actually had a chance to read the proposed extension now -- and realized I actually did read it when you originally posted it :-) Here are some comments (some of which you've seen in the mail that wandered off the list.) > The USER data type, encoding a user database entry, > is defined here: > > uint32 flags > uint32 uid always present > > The `uid' field specifies the numeric user ID of the entry. It MUST > have the same meaning as the numeric user IDs used in the ATTRS > compound data type in the main SFTP protocol. The `uid' field has no > corresponding flag and MUST be present. As I mentioned in my previous mail, NT doesn't use simple 4 byte user identifiers. Given that the UID field MUST be present, I couldn't implement this under NT. So I think we should use the opaque string identifier here as well. (See my previous email to the list "uid & gid in sftp") The same thing applies in the GROUP data type for gid. Also, I would suggest that the requests actually be as follows: uint32 id string sftp-userdb-getuserbyuid@sgt.greenend.org.uk uint32 count count occurrences of uint32 uid and the reply format be: uint32 id uint32 count count occurrences of USER user uid or usernames that don't occur in the resultant list are assumed to have been unresolvable. What do you think? - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Nov 9 18:20:16 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00042 for ; Fri, 9 Nov 2001 18:20:15 -0500 (EST) Received: (qmail 7421 invoked by uid 605); 9 Nov 2001 23:20:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7414 invoked from network); 9 Nov 2001 23:20:13 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 9 Nov 2001 23:20:13 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04964 for ; Fri, 9 Nov 2001 16:19:55 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.81.144]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id PAA21161 for ; Fri, 9 Nov 2001 15:21:02 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.12.1+Sun/8.12.1) with SMTP id fA9NKCei186790 for ; Fri, 9 Nov 2001 15:20:12 -0800 (PST) Message-Id: <200111092320.fA9NKCei186790@jurassic.eng.sun.com> Date: Fri, 9 Nov 2001 15:20:12 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: New requests to support binding port 0 To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: PwKL/Vwo1hi5HmXjEd60MQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_47 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list What was the consensus on Joseph's proposal for tcpip-bind/unbind and deprecation of tcpip-forward/cancel-tcpip-forward. If there is agreement on the proposal shall I include it in the version of the connection draft I'm editing just now ? -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Nov 9 18:29:49 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00270 for ; Fri, 9 Nov 2001 18:29:48 -0500 (EST) Received: (qmail 8613 invoked by uid 605); 9 Nov 2001 23:29:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8606 invoked from network); 9 Nov 2001 23:29:47 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 9 Nov 2001 23:29:47 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10947 for ; Fri, 9 Nov 2001 16:29:29 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.81.144]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id PAA23517 for ; Fri, 9 Nov 2001 15:30:36 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.12.1+Sun/8.12.1) with SMTP id fA9NTkei188681 for ; Fri, 9 Nov 2001 15:29:46 -0800 (PST) Message-Id: <200111092329.fA9NTkei188681@jurassic.eng.sun.com> Date: Fri, 9 Nov 2001 15:29:46 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Pre Review of latest Drafts. To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: R4VHzDlRnckXHx9+q+wwsA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_47 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list Before I submit the latest drafts to the IETF mailing list I'd like to be sure I've included all of the comments (particularly those regarding formating). Since I was unable to attend the last meeting if there was any consensus reached on things that should be in the draft that I haven't changed then please let me know. A copy of each of the drafts can be found at: http://playground.sun.com/~darrenm/secsh-wg/ -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Nov 9 18:30:26 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00304 for ; Fri, 9 Nov 2001 18:30:26 -0500 (EST) Received: (qmail 9908 invoked by uid 605); 9 Nov 2001 23:30:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9889 invoked from network); 9 Nov 2001 23:30:19 -0000 Received: from ixion.tartarus.org (195.153.205.133) by mail.netbsd.org with SMTP; 9 Nov 2001 23:30:19 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 162L6G-0006VM-00; Fri, 09 Nov 2001 23:30:16 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham In-Reply-To: <005a01c16961$7d01f8f0$2800a8c0@test.vandyke.com> To: "Joseph Galbraith" Cc: Subject: Re: A future for the SSH File Transfer Protocol? Message-Id: Date: Fri, 09 Nov 2001 23:30:16 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list I wrote: >> http://www.tartarus.org/~simon/ssh/draft-sftp-userdb-00.txt "Joseph Galbraith" wrote: > Whoops -- I didn't realize our conversation on this > had wandered off the list. Sorry, my fault. It's much more embarrassing to Reply To All when you didn't want to than vice versa, so my MUA errs on the side of caution :-) > As I mentioned in my previous mail, NT doesn't use simple 4 byte > user identifiers. Given that the UID field MUST be present, I > couldn't implement this under NT. Arrgh, yes, you're right of course. And you're also right in pointing out that if we introduce any kind of user identifier that is neither a uid or a name, people will want to do lookups keyed on that and the requests won't generalise. But I don't think _changing_ from numeric UIDs to strings is the way forward - the numeric UIDs are well established in SFTP already and it would be better to give the option of sticking with them. How about this as a redraft? - We modify the USER data type so that the uid field is optional just like the rest of them. Similarly with the GROUP and gid. - Returned USER data structures can encode the NT opaque user identifier blob as an extended data item; either you or I will have to define a name for it. - Instead of separate getuserbyname and getuserbyuid calls, we have a single "getuser" call, whose argument is itself a USER data type. So to look up a user by name, you provide a USER instance which only contains the username field; to look up one by numeric uid you provide only the uid field; and to look up one by their NT opaque user identifier blob, you provide a USER instance containing none of the standard fields and _only_ containing the NT-opaque-user-id extended data item. The getuser call then returns a USER instance with all the other fields filled in. That at once simplifies the protocol and makes it more extensible, in case someone else comes up with yet another weird user ID type. Are you happy with it? Should I do a proper redraft on that basis? (Incidentally I've only just noticed I didn't actually provide values for the SSH_FILEXFER_UDB_GID defines. Must supply those in the redraft :-) > uint32 id > string sftp-userdb-getuserbyuid@sgt.greenend.org.uk > uint32 count > count occurrences of > uint32 uid ... so you can look up more than one at a time? Fair enough, although I'm not sure I see a massive benefit. Of course, under the above scheme that would become uint32 id string "sftp-userdb-getuser@sgt.greenend.org.uk" uint32 count count occurrences of USER user > uid or usernames that don't occur in the resultant list are assumed > to have been unresolvable. Do you not think it would be better to return some sort of error code? I know some people already don't like SFTP because of its paucity of distinguishable error returns; I'm trying to persuade some Cambridge University people to propose a protocol extension that provides more detailed errors. Best not to repeat the same mistakes... Cheers, Simon -- Simon Tatham "Every person has a thinking part that wonders what the part that isn't thinking isn't thinking about." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Nov 9 18:47:19 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00652 for ; Fri, 9 Nov 2001 18:47:18 -0500 (EST) Received: (qmail 14367 invoked by uid 605); 9 Nov 2001 23:47:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14360 invoked from network); 9 Nov 2001 23:47:17 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 9 Nov 2001 23:47:17 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA05356 for ; Fri, 9 Nov 2001 15:47:16 -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 PAA28402 for ; Fri, 9 Nov 2001 15:48:05 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.12.1+Sun/8.12.1) with SMTP id fA9NlFei191830 for ; Fri, 9 Nov 2001 15:47:15 -0800 (PST) Message-Id: <200111092347.fA9NlFei191830@jurassic.eng.sun.com> Date: Fri, 9 Nov 2001 15:47:15 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: A future for the SSH File Transfer Protocol? To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: AE0gbs7fpKOC4OOPplAvow== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_47 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list > - Instead of separate getuserbyname and getuserbyuid calls, we have > a single "getuser" call, whose argument is itself a USER data I hate to say it but this whole SFTP + USERDB is starting to look suspiciously like NFSv2 + NIS ;-) I'd like to suggest that before the group goes any further with SFTP we stop and do a requirements spec. What problem are we really trying to solve for the end user ? In particular is the goal a file transfer protocol along the lines of FTP (as the name would suggest) or is it a file sharing protocol more in line with NFS or CIFS. Some of the suggestions make me thing it is drifting somewhere between the two at the moment (which isn't a bad thing as long as we know what problem we are trying to solve). Why doesn't running the FTP protocol over SSH transport help, (I know about the issues with FTP as a protocol but I think it wouldn't hurt for the wg to document them the a requirements spec). Why doesn't NFSv4 solve their problems either (I think it would in theory be possible to have the SSH protocol stack as a GSS mechanism that NFSv4 could run over). One final thing, if SFTP is truly independent of the SSH transport as the last revision of the draft stated is SECSH-WG really the correct group to be designing it ? What is it about SFTP that makes it suitable for the security area ? Would a group in the applications area be more appropriate ? -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Nov 9 20:22:39 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01820 for ; Fri, 9 Nov 2001 20:22:39 -0500 (EST) Received: (qmail 2483 invoked by uid 605); 10 Nov 2001 01:22:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2476 invoked from network); 10 Nov 2001 01:22:36 -0000 Received: from inet.org (HELO gnat.inet.org) (63.108.254.91) by mail.netbsd.org with SMTP; 10 Nov 2001 01:22:36 -0000 Received: from mosquito.inet.org (unknown [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 472D467103; Fri, 9 Nov 2001 20:26:22 -0500 (EST) Message-Id: <5.1.0.14.2.20011109201240.009fe550@10.30.15.3> X-Sender: rja@10.30.15.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 09 Nov 2001 20:13:35 -0500 To: Darren Moffat From: RJ Atkinson Subject: Re: A future for the SSH File Transfer Protocol? Cc: ietf-ssh@netbsd.org In-Reply-To: <200111092347.fA9NlFei191830@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 18:47 09/11/01, Darren Moffat wrote: >I'd like to suggest that before the group goes any further with SFTP we >stop and do a requirements spec. > >What problem are we really trying to solve for the end user ? Yes please. Lets define the problem and the solution requirements FIRST. No particular objection to SFTP, just want to nail down what we're undertaking before the land gets swampy... Ran rja@inet.org From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Nov 10 04:21:12 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25388 for ; Sat, 10 Nov 2001 04:21:11 -0500 (EST) Received: (qmail 25005 invoked by uid 605); 10 Nov 2001 09:21:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24997 invoked from network); 10 Nov 2001 09:21:09 -0000 Received: from ixion.tartarus.org (195.153.205.133) by mail.netbsd.org with SMTP; 10 Nov 2001 09:21:09 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 162UK4-0005hT-00; Sat, 10 Nov 2001 09:21:08 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <200111092347.fA9NlFei191830@jurassic.eng.sun.com> Subject: Re: A future for the SSH File Transfer Protocol? Message-Id: Date: Sat, 10 Nov 2001 09:21:08 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Darren Moffat wrote: > I'd like to suggest that before the group goes any further with SFTP we > stop and do a requirements spec. > > What problem are we really trying to solve for the end user ? > > In particular is the goal a file transfer protocol along the lines of > FTP (as the name would suggest) or is it a file sharing protocol more > in line with NFS or CIFS. As I see SFTP, its purpose is to allow a useful level of file system access, in a platform-independent manner, _making use of SSH authentication_. In NFS: - you have a single centralised NFS arrangement between the administrators of a pair of machines, and each user gets to make use of that same arrangement. - the admins negotiate a uid mapping, finding something clever to do about uids that aren't matched on the other machine. Alternatively, they arrange to have matching uids everywhere. - each side trusts the other not to abuse that uid mapping; if the client were to make a mistake in enforcement, one of its users might be able to write to a file they aren't supposed to be allowed to. So the server is extending its trust perimeter to include the client's kernel. Whereas in SFTP: - each user who wants filesystem access authenticates separately, so there isn't a need for the admins to cooperate. - uid mapping can be done, if the user feels it would be helpful, but it is informational only, because the real guarantee of the access control being respected on the server is that the sftp-server process doesn't _have_ the privileges to access files it shouldn't. - So if a uid mapping is wrong, there is no security breach. The client user gets confusing information, but it's only the _information_ that is faulty. Access control is still intact. - Hence, the server does not need to trust the client to enforce the access controls: it enforces them itself. All of this is the case _irrespective_ of whether it's being used as a networked file system or an FTP-like file transfer client; the interface presented to the client user is irrelevant. (Although I suppose uid mapping is a bit irrelevant in the latter case :-) Interestingly, of course, one major area of user interfaces for SFTP clients is the Windows Explorer-like drag-and-drop interface - which precisely _does_ blur the user-level distinction between a dedicated file transfer client and a networked file system! > Why doesn't running the FTP protocol over SSH transport help, FTP lacks several _very_ nice features of SFTP: - the ability to retrieve only part of a file (REST is helpful in some situations but doesn't really cut it) - a properly specified, reliably available chmod and chgrp (and I suppose chown, for people mad enough to do it as root :-) - directory listings returned in a machine-readable form - of course, the well-known chaos with multiple network connections In general, it would be very difficult to write a specialised client that would use FTP to perform a specific and complex file manipulation on a remote server. But SFTP makes this easy (not least because it has access to SSH's hands-off authentication), and therefore it's a qualitative improvement over FTP. (Shame about ASCII transfer, of course, but it's an extensible protocol so that can be fixed...) In summary: I see SFTP as being an excellent middle way between NFS and FTP. It's not sysadmin-heavy like NFS, and yet it's way more flexible and more automatable than FTP. The basic structure of the protocol is _exactly_ what I would want to see in a file transfer _or_ filesystem access protocol, and it's highly extensible so its current lack of polish can be seamlessly fixed. Cheers, Simon -- Simon Tatham "A cynic is a person who smells flowers and immediately looks around for a coffin." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Nov 10 13:31:21 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00101 for ; Sat, 10 Nov 2001 13:31:20 -0500 (EST) Received: (qmail 6223 invoked by uid 605); 10 Nov 2001 18:31:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6216 invoked from network); 10 Nov 2001 18:31:18 -0000 Received: from mx04.nexgo.de (151.189.8.80) by mail.netbsd.org with SMTP; 10 Nov 2001 18:31:18 -0000 Received: from localhost (dsl-213-023-060-155.arcor-ip.net [213.23.60.155]) by mx04.nexgo.de (Postfix) with ESMTP id 7250537BBC; Sat, 10 Nov 2001 19:31:17 +0100 (CET) Received: by localhost (Postfix, from userid 31451) id 4467C4385; Sat, 10 Nov 2001 19:30:48 +0100 (CET) Date: Sat, 10 Nov 2001 19:30:47 +0100 From: Markus Friedl To: Darren Moffat Cc: ietf-ssh@netbsd.org, openssh@openbsd.org Subject: Re: New requests to support binding port 0 Message-ID: <20011110193047.A24557@folly> References: <200111092320.fA9NKCei186790@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200111092320.fA9NKCei186790@jurassic.eng.sun.com>; from Darren.Moffat@eng.sun.com on Fri, Nov 09, 2001 at 03:20:12PM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Nov 09, 2001 at 03:20:12PM -0800, Darren Moffat wrote: > What was the consensus on Joseph's proposal for tcpip-bind/unbind and > deprecation of tcpip-forward/cancel-tcpip-forward. > > If there is agreement on the proposal shall I include it in the version of > the connection draft I'm editing just now ? no, i don't think so. i think it was agreed on that at this point we should just remove ambiguites removed from the current drafts. the protocol should not be changed at all. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Nov 10 13:42:48 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00158 for ; Sat, 10 Nov 2001 13:42:48 -0500 (EST) Received: (qmail 10430 invoked by uid 605); 10 Nov 2001 18:42:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10422 invoked from network); 10 Nov 2001 18:42:46 -0000 Received: from mx04.nexgo.de (151.189.8.80) by mail.netbsd.org with SMTP; 10 Nov 2001 18:42:46 -0000 Received: from localhost (dsl-213-023-060-155.arcor-ip.net [213.23.60.155]) by mx04.nexgo.de (Postfix) with ESMTP id A48CF37B7D; Sat, 10 Nov 2001 19:42:45 +0100 (CET) Received: by localhost (Postfix, from userid 31451) id 4C6114385; Sat, 10 Nov 2001 19:42:18 +0100 (CET) Date: Sat, 10 Nov 2001 19:42:17 +0100 From: Markus Friedl To: Darren Moffat Cc: ietf-ssh@netbsd.org, openssh@openbsd.org Subject: Re: A future for the SSH File Transfer Protocol? Message-ID: <20011110194217.B24557@folly> References: <200111092347.fA9NlFei191830@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200111092347.fA9NlFei191830@jurassic.eng.sun.com>; from Darren.Moffat@eng.sun.com on Fri, Nov 09, 2001 at 03:47:15PM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Nov 09, 2001 at 03:47:15PM -0800, Darren Moffat wrote: > What problem are we really trying to solve for the end user ? a very simple protocol for copying files. as simple as RCP, but without the many drawbacks. > In particular is the goal a file transfer protocol along the lines of > FTP (as the name would suggest) or is it a file sharing protocol more > in line with NFS or CIFS. Some of the suggestions make me thing it is > drifting somewhere between the two at the moment (which isn't a bad > thing as long as we know what problem we are trying to solve). no, SFTP is not for sharing files. sftp should not become as bloated. > Why doesn't running the FTP protocol over SSH transport help, > (I know about the issues with FTP as a protocol but I think it wouldn't > hurt for the wg to document them the a requirements spec). because ftp is big, bloated and requires a 2nd connection for transfering files. doing FTP over TCP-forwarding is not the same as SFTP, checking the channel data stream for "PORT" and opening another TCP-forwarding channel adds unnecessary complexity to an SSH implementation. why not just use the 8bit clean channel SSH provides? just ask the SSH vendors about how much SFTP simplified the 'data transfer over SSH' problem? SFTP is simple and can be very easily implented and deployed. i don't understand the problem with SFTP. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Nov 10 13:54:40 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00276 for ; Sat, 10 Nov 2001 13:54:40 -0500 (EST) Received: (qmail 13379 invoked by uid 605); 10 Nov 2001 18:54:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13371 invoked from network); 10 Nov 2001 18:54:39 -0000 Received: from inet.org (HELO gnat.inet.org) (63.108.254.91) by mail.netbsd.org with SMTP; 10 Nov 2001 18:54:39 -0000 Received: from mosquito.inet.org (unknown [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 5BD3567103; Sat, 10 Nov 2001 13:58:45 -0500 (EST) Message-Id: <5.1.0.14.2.20011110134405.009fdaf0@10.30.15.3> X-Sender: rja@10.30.15.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 10 Nov 2001 13:45:41 -0500 To: Markus Friedl From: RJ Atkinson Subject: Re: A future for the SSH File Transfer Protocol? Cc: ietf-ssh@netbsd.org In-Reply-To: <20011110194217.B24557@folly> References: <200111092347.fA9NlFei191830@jurassic.eng.sun.com> <200111092347.fA9NlFei191830@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 13:42 10/11/01, Markus Friedl wrote: >i don't understand the problem with SFTP. Might not be a problem, but folks want to understand the problem SFTP is trying to solve. For example, I'm trying to puzzle out how SFTP is different from SCP and why I would care about that difference (if I knew what it was)... Since this is a standards question, I'm deliberately trimming the distribution to the IETF SECSH list. Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Nov 11 02:11:07 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA22470 for ; Sun, 11 Nov 2001 02:11:07 -0500 (EST) Received: (qmail 17434 invoked by uid 605); 11 Nov 2001 07:11:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17427 invoked from network); 11 Nov 2001 07:11:03 -0000 Received: from guinness.cs.stevens-tech.edu (155.246.89.8) by mail.netbsd.org with SMTP; 11 Nov 2001 07:11:03 -0000 Received: by guinness.cs.stevens-tech.edu (Postfix, from userid 3330) id 5BBD114187F; Sun, 11 Nov 2001 02:11:00 -0500 (EST) Date: Sun, 11 Nov 2001 02:10:59 -0500 From: Thor Simon To: RJ Atkinson , ietf-ssh@netbsd.org Subject: Re: A future for the SSH File Transfer Protocol? Message-ID: <20011111021059.A67036@cs.stevens-tech.edu> References: <200111092347.fA9NlFei191830@jurassic.eng.sun.com> <200111092347.fA9NlFei191830@jurassic.eng.sun.com> <20011110194217.B24557@folly> <5.1.0.14.2.20011110134405.009fdaf0@10.30.15.3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.2.20011110134405.009fdaf0@10.30.15.3>; from rja@inet.org on Sat, Nov 10, 2001 at 01:45:41PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sat, Nov 10, 2001 at 01:45:41PM -0500, RJ Atkinson wrote: > At 13:42 10/11/01, Markus Friedl wrote: > >i don't understand the problem with SFTP. > > Might not be a problem, but folks want to understand > the problem SFTP is trying to solve. > > For example, I'm trying to puzzle out how SFTP > is different from SCP and why I would care about > that difference (if I knew what it was)... > > Since this is a standards question, I'm deliberately > trimming the distribution to the IETF SECSH list. From my point of view, there are three differences: 1) SCP is a lightweight protocol which is constrained in purpose and function to be a replacement for traditional Berkeley Unix 'rcp'; SFTP is a much heavier protocol which tries to provide the functionality of FTP (and perhaps then some) atop the SSHv2 transport layer. 2) SFTP is standards-track; currently, SCP is very much not so. 3) SFTP is actually documented. SCP -- because it's just basically rcp on top of SSH -- is not; there isn't an rcp RFC, not even an informational. Personally, my taste runs much more to a simple file transfer protocol than to a very rich and complex one, but to date the SSH WG has felt otherwise. I've committed to do an informational RFC on the rcp protocol but keep failing to find the time for the last 10% of work to get it out the door; at least then those who cared to implement SCP would have some documentation other than the Berkeley code. Thor From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Nov 11 05:47:13 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA23499 for ; Sun, 11 Nov 2001 05:47:13 -0500 (EST) Received: (qmail 3133 invoked by uid 605); 11 Nov 2001 10:47:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3126 invoked from network); 11 Nov 2001 10:47:12 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 11 Nov 2001 10:47:12 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id LAA17186; Sun, 11 Nov 2001 11:46:58 +0100 (MET) Date: Sun, 11 Nov 2001 11:46:58 +0100 From: Markus Friedl To: RJ Atkinson Cc: ietf-ssh@netbsd.org, openssh@openbsd.org Subject: Re: A future for the SSH File Transfer Protocol? Message-ID: <20011111114658.B16660@faui02.informatik.uni-erlangen.de> References: <200111092347.fA9NlFei191830@jurassic.eng.sun.com> <200111092347.fA9NlFei191830@jurassic.eng.sun.com> <20011110194217.B24557@folly> <5.1.0.14.2.20011110134405.009fdaf0@10.30.15.3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <5.1.0.14.2.20011110134405.009fdaf0@10.30.15.3>; from rja@inet.org on Sat, Nov 10, 2001 at 01:45:41PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sat, Nov 10, 2001 at 01:45:41PM -0500, RJ Atkinson wrote: > At 13:42 10/11/01, Markus Friedl wrote: > >i don't understand the problem with SFTP. > > Might not be a problem, but folks want to understand > the problem SFTP is trying to solve. > > For example, I'm trying to puzzle out how SFTP > is different from SCP and why I would care about > that difference (if I knew what it was)... the RCP/SCP protocol has many drawbacks so SFTP acts as a simple replacement for SCP. recent problems include: error handling in RCP is broken: you send the filesize and the filecontent to the remote host, if there is an readerror during the transfer, you cannot stop the transfer for this file, because the two scp processes might get out of sync. RCP uses \n in the protocol, so you cannot transfer a filename containing newlines. if the remote host is the source of the transfer, the remote host tells the local scp process the filesnames that should be created (e.g. more or different files than requested). with SFTP the local process sends opendir/readdir/read messages and decides what files to copy. and so on. i don't think it's worth using RCP/SCP as a starting point. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Nov 11 05:53:19 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA23531 for ; Sun, 11 Nov 2001 05:53:18 -0500 (EST) Received: (qmail 3821 invoked by uid 605); 11 Nov 2001 10:53:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3814 invoked from network); 11 Nov 2001 10:53:19 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 11 Nov 2001 10:53:19 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id LAA17283; Sun, 11 Nov 2001 11:53:12 +0100 (MET) Date: Sun, 11 Nov 2001 11:53:12 +0100 From: Markus Friedl To: Thor Simon Cc: RJ Atkinson , ietf-ssh@netbsd.org, openssh@openbsd.org Subject: Re: A future for the SSH File Transfer Protocol? Message-ID: <20011111115312.C16660@faui02.informatik.uni-erlangen.de> References: <200111092347.fA9NlFei191830@jurassic.eng.sun.com> <200111092347.fA9NlFei191830@jurassic.eng.sun.com> <20011110194217.B24557@folly> <5.1.0.14.2.20011110134405.009fdaf0@10.30.15.3> <20011111021059.A67036@cs.stevens-tech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20011111021059.A67036@cs.stevens-tech.edu>; from tls@cs.stevens-tech.edu on Sun, Nov 11, 2001 at 02:10:59AM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sun, Nov 11, 2001 at 02:10:59AM -0500, Thor Simon wrote: > 1) SCP is a lightweight protocol which is constrained in purpose and > function to be a replacement for traditional Berkeley Unix 'rcp'; > SFTP is a much heavier protocol which tries to provide the functionality > of FTP (and perhaps then some) atop the SSHv2 transport layer. i don't agree. SFTP fixes the problems in SCP, while FTP is much more complex than SFTP. people are just confused because of the 3 common letters FTP. > Personally, my taste runs much more to a simple file transfer protocol than > to a very rich and complex one, but to date the SSH WG has felt otherwise. that's wrong. SFTP is very simple, all it does is open/read/write/close/opendir/readdir SCP might be simpler, but has too many problems. you should ask vendors who actually tried to implement both. > I've committed to do an informational RFC on the rcp protocol but keep > failing to find the time for the last 10% of work to get it out the door; > at least then those who cared to implement SCP would have some documentation > other than the Berkeley code. it's not worth the trouble. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Nov 11 05:59:55 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA23577 for ; Sun, 11 Nov 2001 05:59:55 -0500 (EST) Received: (qmail 4280 invoked by uid 605); 11 Nov 2001 10:59:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4273 invoked from network); 11 Nov 2001 10:59:55 -0000 Received: from ixion.tartarus.org (195.153.205.133) by mail.netbsd.org with SMTP; 11 Nov 2001 10:59:55 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 162sLC-0004VL-00; Sun, 11 Nov 2001 10:59:54 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <20011111021059.A67036@cs.stevens-tech.edu> Subject: Re: A future for the SSH File Transfer Protocol? Message-Id: Date: Sun, 11 Nov 2001 10:59:54 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Thor Simon wrote: > 2) SFTP is standards-track; currently, SCP is very much not so. > > 3) SFTP is actually documented. SCP -- because it's just basically rcp > on top of SSH -- is not; there isn't an rcp RFC, not even an > informational. Also (4) There is a _standardised_ means of invoking SFTP on a server, which doesn't depend on the client knowing or guessing details of the server setup such as its OS or its PATH or the location of its scp binary, or indeed its command line quoting rules (try SCPing a file with weird characters in the name!). (5) SFTP doesn't require the client to trust the server's wildcard expansion. (Suppose you send a request for "*.c". You would like the server not to be able to send back filenames that don't actually match this pattern, so it can't maliciously overwrite ".bashrc" in the same directory. Sadly in SCP the wildcard matching is done on the server, by the server's rules, and the client doesn't necessarily know what those rules are (even if the end user does and has correctly constructed a wildcard within them). For example, "[ab]*.c" would match extremely different things on a VMS and a Unix system, since in VMS [ab] is a directory specifier and in Unix it's a wildcard! SFTP solves this by not _having_ a means of wildcard matching - the client must request the whole directory, do the matching itself by its own rules, and then request specific files. Another solution would be to standardise a set of wildcard rules, so that the client could validate returned filenames against them. SCP is a _really bad_ protocol. > I've committed to do an informational RFC on the rcp protocol but keep > failing to find the time for the last 10% of work to get it out the door; I hope it treats the above issues carefully! :-) Cheers, Simon -- Simon Tatham "I thought I'd put my foot so far into my mouth I wouldn't be able to sit down without standing up." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Nov 11 14:21:12 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28379 for ; Sun, 11 Nov 2001 14:21:12 -0500 (EST) Received: (qmail 25893 invoked by uid 605); 11 Nov 2001 19:21:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25886 invoked from network); 11 Nov 2001 19:21:10 -0000 Received: from 24-168-215-96.he.cox.rr.com (HELO asd.ppp0.com) (24.168.215.96) by mail.netbsd.org with SMTP; 11 Nov 2001 19:21:10 -0000 Received: from asd.ppp0.com ([127.0.0.1] helo=Fermi.wireless.local) by asd.ppp0.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 1630A9-0003wu-00; Sun, 11 Nov 2001 14:21:01 -0500 Date: Sun, 11 Nov 2001 14:21:02 -0500 Subject: Re: A future for the SSH File Transfer Protocol? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v472) Cc: Darren Moffat , ietf-ssh@netbsd.org, openssh@openbsd.org To: Markus Friedl From: Anthony DeRobertis In-Reply-To: <20011110194217.B24557@folly> Message-Id: <3EA4F732-D6D9-11D5-8E4E-00039355CFA6@suespammers.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.472) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Saturday, November 10, 2001, at 01:42 , Markus Friedl wrote: > On Fri, Nov 09, 2001 at 03:47:15PM -0800, Darren Moffat wrote: >> What problem are we really trying to solve for the end user ? > > a very simple protocol for copying files. > as simple as RCP, but without the many drawbacks. That's called scp, methinks. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Nov 11 14:29:58 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28452 for ; Sun, 11 Nov 2001 14:29:57 -0500 (EST) Received: (qmail 27592 invoked by uid 605); 11 Nov 2001 19:29:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27585 invoked from network); 11 Nov 2001 19:29:57 -0000 Received: from cvs.openbsd.org (199.185.137.3) by mail.netbsd.org with SMTP; 11 Nov 2001 19:29:57 -0000 Received: from cvs.openbsd.org (deraadt@localhost [127.0.0.1]) by cvs.openbsd.org (8.12.1/8.10.1) with ESMTP id fABJZTXU004411; Sun, 11 Nov 2001 12:35:29 -0700 (MST) Message-Id: <200111111935.fABJZTXU004411@cvs.openbsd.org> To: Anthony DeRobertis cc: Markus Friedl , Darren Moffat , ietf-ssh@netbsd.org, openssh@openbsd.org Subject: Re: A future for the SSH File Transfer Protocol? In-reply-to: Your message of "Sun, 11 Nov 2001 14:21:02 EST." <3EA4F732-D6D9-11D5-8E4E-00039355CFA6@suespammers.org> Date: Sun, 11 Nov 2001 12:35:29 -0700 From: Theo de Raadt Sender: ietf-ssh-owner@netbsd.org Precedence: list > On Saturday, November 10, 2001, at 01:42 , Markus Friedl wrote: > > > On Fri, Nov 09, 2001 at 03:47:15PM -0800, Darren Moffat wrote: > >> What problem are we really trying to solve for the end user ? > > > > a very simple protocol for copying files. > > as simple as RCP, but without the many drawbacks. > > That's called scp, methinks. Then you are massively uninformed. scp protocol IS rcp protocol. They are 100% the same, and have 100% the same flaws. Now hush. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Nov 11 16:08:56 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29458 for ; Sun, 11 Nov 2001 16:08:55 -0500 (EST) Received: (qmail 9186 invoked by uid 605); 11 Nov 2001 21:08:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9178 invoked from network); 11 Nov 2001 21:08:54 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 11 Nov 2001 21:08:54 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id WAA07203; Sun, 11 Nov 2001 22:08:46 +0100 (MET) Date: Sun, 11 Nov 2001 22:08:46 +0100 From: Markus Friedl To: Anthony DeRobertis Cc: Darren Moffat , ietf-ssh@netbsd.org, openssh@openbsd.org Subject: Re: A future for the SSH File Transfer Protocol? Message-ID: <20011111220846.A3146@faui02.informatik.uni-erlangen.de> References: <20011110194217.B24557@folly> <3EA4F732-D6D9-11D5-8E4E-00039355CFA6@suespammers.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <3EA4F732-D6D9-11D5-8E4E-00039355CFA6@suespammers.org>; from asd@suespammers.org on Sun, Nov 11, 2001 at 02:21:02PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sun, Nov 11, 2001 at 02:21:02PM -0500, Anthony DeRobertis wrote: > > On Saturday, November 10, 2001, at 01:42 , Markus Friedl wrote: > > > On Fri, Nov 09, 2001 at 03:47:15PM -0800, Darren Moffat wrote: > >> What problem are we really trying to solve for the end user ? > > > > a very simple protocol for copying files. > > as simple as RCP, but without the many drawbacks. > > That's called scp, methinks. sorry, you are wrong. SCP==RCP. scp just runs rcp over ssh. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Nov 11 16:54:11 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29796 for ; Sun, 11 Nov 2001 16:54:10 -0500 (EST) Received: (qmail 17076 invoked by uid 605); 11 Nov 2001 21:54:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17069 invoked from network); 11 Nov 2001 21:54:10 -0000 Received: from 24-168-215-96.he.cox.rr.com (HELO asd.ppp0.com) (24.168.215.96) by mail.netbsd.org with SMTP; 11 Nov 2001 21:54:10 -0000 Received: from asd.ppp0.com ([127.0.0.1] helo=Fermi.wireless.local) by asd.ppp0.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 1632Xv-0004Fp-00; Sun, 11 Nov 2001 16:53:44 -0500 Date: Sun, 11 Nov 2001 16:53:43 -0500 Subject: Re: A future for the SSH File Transfer Protocol? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v472) Cc: Markus Friedl , Darren Moffat , ietf-ssh@netbsd.org, openssh@openbsd.org To: Theo de Raadt From: Anthony DeRobertis In-Reply-To: <200111111935.fABJZTXU004411@cvs.openbsd.org> Message-Id: <934927A1-D6EE-11D5-8CDD-00039355CFA6@suespammers.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.472) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Sunday, November 11, 2001, at 02:35 , Theo de Raadt wrote: > > scp protocol IS rcp protocol. They are 100% the same, and have 100% > the same flaws. IMO, the biggest flaws with rcp are the lack of strong authentication and the lack of encryption. Running rcp over ssh provides both of those. I am aware of the other issues, like file name issues (I've run into them myself); and things like the remote side handling expansions can be checked on the local side. I don't consider that nearly as important as the first two. There are also some problems with passing metadata (I'm on a Mac at the moment), but those can also be taken care of. Now, if sftp is to be more like FTP than rcp, I'd understand that. But I don't think 'rcp without flaws' is a very good spec of what you're doing. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Nov 11 20:07:34 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01360 for ; Sun, 11 Nov 2001 20:07:34 -0500 (EST) Received: (qmail 6538 invoked by uid 605); 12 Nov 2001 01:07:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6531 invoked from network); 12 Nov 2001 01:07:29 -0000 Received: from intern12.lnk.telstra.net (HELO shitei.mindrot.org) (139.130.53.38) by mail.netbsd.org with SMTP; 12 Nov 2001 01:07:29 -0000 Received: from mothra.mindrot.org (mothra.mindrot.org [203.44.118.225]) by shitei.mindrot.org (Postfix) with ESMTP id E106C2DF0E; Mon, 12 Nov 2001 12:07:25 +1100 (EST) Received: from localhost (djm@localhost) by mothra.mindrot.org (8.11.6/8.11.6) with ESMTP id fAC17Pt26862; Mon, 12 Nov 2001 12:07:25 +1100 X-Authentication-Warning: mothra.mindrot.org: djm owned process doing -bs Date: Mon, 12 Nov 2001 12:07:25 +1100 (EST) From: Damien Miller To: Anthony DeRobertis Cc: Theo de Raadt , Markus Friedl , Darren Moffat , , Subject: Re: A future for the SSH File Transfer Protocol? In-Reply-To: <934927A1-D6EE-11D5-8CDD-00039355CFA6@suespammers.org> 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 Sun, 11 Nov 2001, Anthony DeRobertis wrote: > > On Sunday, November 11, 2001, at 02:35 , Theo de Raadt wrote: > > > > > scp protocol IS rcp protocol. They are 100% the same, and have 100% > > the same flaws. > > IMO, the biggest flaws with rcp are the lack of strong > authentication and the lack of encryption. These have already been mentioned: - Inability to use \n in file names - Poor error handling - Serverside globbing - To be secure a client needs to second-guess the paths sent from the server. I'll add these: - Inability to do basic filesystem operations (e.g. rename) - Inability to access parts of files, or continue aborted transfers > Running rcp over ssh provides both of those. I am aware of the > other issues, like file name issues (I've run into them myself); > and things like the remote side handling expansions can be > checked on the local side. I don't consider that nearly as > important as the first two. You really want to have a protocol which forces clients to include code to protect from a hostile server? That is asking for insecure implementations. >There are also some problems with > passing metadata (I'm on a Mac at the moment), but those can > also be taken care of. If we are going to change a 10+ y/o protocol, why not just write a new one without the (many) inherent flaws. Even better, why not just tweak the one that has _already been written and implemented_. > Now, if sftp is to be more like FTP than rcp, I'd understand > that. But I don't think 'rcp without flaws' is a very good spec > of what you're doing. Why are we discussing requirements on somethings that is already specified and widely deployed? -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Nov 11 21:10:01 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01861 for ; Sun, 11 Nov 2001 21:10:00 -0500 (EST) Received: (qmail 13563 invoked by uid 605); 12 Nov 2001 02:09:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13556 invoked from network); 12 Nov 2001 02:09:56 -0000 Received: from 24-168-215-96.he.cox.rr.com (HELO asd.ppp0.com) (24.168.215.96) by mail.netbsd.org with SMTP; 12 Nov 2001 02:09:56 -0000 Received: from asd.ppp0.com ([127.0.0.1] helo=Fermi.wireless.local) by asd.ppp0.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 1636XE-0005IX-00; Sun, 11 Nov 2001 21:09:16 -0500 Date: Sun, 11 Nov 2001 21:09:17 -0500 Subject: Re: A future for the SSH File Transfer Protocol? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v472) Cc: Theo de Raadt , Markus Friedl , Darren Moffat , , To: Damien Miller From: Anthony DeRobertis In-Reply-To: Message-Id: <471E1760-D712-11D5-BA6F-00039355CFA6@suespammers.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.472) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Sunday, November 11, 2001, at 08:07 , Damien Miller wrote: > > - Inability to do basic filesystem operations (e.g. rename) > - Inability to access parts of files, or continue aborted transfers Those are issues, especially the second. But that's not rcp anymore. > > You really want to have a protocol which forces clients to include code > to protect from a hostile server? I think, by definition, cryptographic implementations must. And we've certainly seen a bunch of mistakes (ssh1, for example). I think that's a lot harder than making sure returned file names match the glob. But, sure, if we didn't have to do that, that'd be great. I just wanted to point out that is not a fatal flaw. > If we are going to change a 10+ y/o protocol, why not just > write a new one > without the (many) inherent flaws. Even better, why not just > tweak the one > that has _already been written and implemented_. No problem with either of those. > > Why are we discussing requirements on somethings that is already > specified and widely deployed? Because we're talking about extending it? I'd think would be a good idea to specify what is being accomplished by the protocol before extending it. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 12 06:42:44 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA24789 for ; Mon, 12 Nov 2001 06:42:43 -0500 (EST) Received: (qmail 17098 invoked by uid 605); 12 Nov 2001 11:42:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17091 invoked from network); 12 Nov 2001 11:42:37 -0000 Received: from unknown (HELO maddog.corp.storability.com) (4.42.136.48) by mail.netbsd.org with SMTP; 12 Nov 2001 11:42:37 -0000 Received: (from dbutts@localhost) by maddog.corp.storability.com (8.10.2+Sun/8.10.2) id fACBgC413973; Mon, 12 Nov 2001 06:42:12 -0500 (EST) Date: Mon, 12 Nov 2001 06:42:12 -0500 From: David Butts To: ietf-ssh@netbsd.org Subject: Re: A future for the SSH File Transfer Protocol? Message-ID: <20011112064212.A13764@storability.com> References: <200111092347.fA9NlFei191830@jurassic.eng.sun.com> <200111092347.fA9NlFei191830@jurassic.eng.sun.com> <20011110194217.B24557@folly> <5.1.0.14.2.20011110134405.009fdaf0@10.30.15.3> <20011111021059.A67036@cs.stevens-tech.edu> <20011111115312.C16660@faui02.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011111115312.C16660@faui02.informatik.uni-erlangen.de> User-Agent: Mutt/1.3.19i Sender: ietf-ssh-owner@netbsd.org Precedence: list Hello, all- At the risk of making a fool of myself, I'd like to wade in here. On Sun, Nov 11, 2001 at 11:53:12AM +0100, Markus Friedl wrote: > On Sun, Nov 11, 2001 at 02:10:59AM -0500, Thor Simon wrote: > > 1) SCP is a lightweight protocol which is constrained in purpose and > > function to be a replacement for traditional Berkeley Unix 'rcp'; > > SFTP is a much heavier protocol which tries to provide the functionality > > of FTP (and perhaps then some) atop the SSHv2 transport layer. > > i don't agree. SFTP fixes the problems in SCP, while FTP > is much more complex than SFTP. people are just confused > because of the 3 common letters FTP. The one advantage I know of that SCP has over SFTP is the ability to restrict the source/target of a transfer with -f/-t. That is, IMHO, invaluable for any kind of batch copy process. Without it, it becomes much more difficult to prevent someone who has stolen a private key from overwriting an authorized_keys file. If there is an equivalent means of restricting SFTP, then I'll certainly use it, but without it, I can't give up SCP. > > Personally, my taste runs much more to a simple file transfer protocol than > > to a very rich and complex one, but to date the SSH WG has felt otherwise. > > that's wrong. SFTP is very simple, all it does is > open/read/write/close/opendir/readdir > > SCP might be simpler, but has too many problems. Again, at the risk of belaboring the point, I actually consider SCP's lack of flexibility to be a feature, since I use it in order to restrict access. The two complement each other nicely, at least from my perspective as a user, and I would miss SCP if it went away. David From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 12 08:16:13 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27890 for ; Mon, 12 Nov 2001 08:16:12 -0500 (EST) Received: (qmail 1043 invoked by uid 605); 12 Nov 2001 13:16:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1019 invoked from network); 12 Nov 2001 13:16:01 -0000 Received: from ixion.tartarus.org (195.153.205.133) by mail.netbsd.org with SMTP; 12 Nov 2001 13:16:01 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 163GwQ-0004Xi-00; Mon, 12 Nov 2001 13:15:58 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <20011112064212.A13764@storability.com> Subject: Re: A future for the SSH File Transfer Protocol? Message-Id: Date: Mon, 12 Nov 2001 13:15:58 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list David Butts wrote: > The one advantage I know of that SCP has over SFTP is the ability > to restrict the source/target of a transfer with -f/-t. That is, > IMHO, invaluable for any kind of batch copy process. Without it, > it becomes much more difficult to prevent someone who has stolen > a private key from overwriting an authorized_keys file. If there > is an equivalent means of restricting SFTP, then I'll certainly > use it, but without it, I can't give up SCP. This sounds like an excellent idea and I can easily think of four or five uses for such a feature myself, but surely it's nothing to do with the _protocol_? From the protocol point of view, you can attempt to do exactly the same set of things, and you either get told Access Denied or Yeah, All Right. -- Simon Tatham "I'm going to pull his head off. Ear by ear." - a games teacher From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 12 12:29:17 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12098 for ; Mon, 12 Nov 2001 12:29:16 -0500 (EST) Received: (qmail 15620 invoked by uid 605); 12 Nov 2001 17:29:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15613 invoked from network); 12 Nov 2001 17:29:13 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 12 Nov 2001 17:29:13 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20481; Mon, 12 Nov 2001 10:28:55 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.89.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id JAA24924; Mon, 12 Nov 2001 09:30:04 -0800 (PST) Received: from Sun.COM (dsl-192-32.Eng.Sun.COM [129.146.192.32]) by jurassic.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fACHSteh437267; Mon, 12 Nov 2001 09:29:11 -0800 (PST) Message-ID: <3BF00827.7030102@Sun.COM> Date: Mon, 12 Nov 2001 09:34:31 -0800 From: Darren J Moffat User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Damien Miller CC: ietf-ssh@netbsd.org Subject: Re: A future for the SSH File Transfer Protocol? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Damien Miller wrote: > Why are we discussing requirements on somethings that is already > specified and widely deployed? Because there is discussion on the ietf-ssh list about extending and chaning some of the functionality. In particular how the SFTP protocol deals with the identity of the user. Currently a uint32_t is used to send a "UID" which is fine for UNIX since that is what most systems use as the uid, however it is not fine for NT. In parallel with this it has been proposed that the long output goes away in favour of the client having to build it themselves from the information it gets from the server. To that end there has been proposals to change this area of the protocol and augment it with a method for the client to translate the opaque uid into a name suitable for display. The rational being that the mapping maybe different on the client than on the server. My concern was that this is starting to get into the area and issues of NFS and NIS: NFS does transfer NIS does name id mappings. I fully agree that SCP is not suitable and neither is FTP over SSH but before we go changing a lot of things I think it would be a good idea to document where the end goal is so that we know when we are done and we know if we are changing things because people really need that functionality. On the whol SFTP is a decent protocol but there are a few little warts that need to be tidied up I just wanted to make sure that in tidying these up SFTP didn't turn into a file sharing protocol and starting becoming a poor mans NFS or CIFS. I have no problem with documenting the protocol as it stands just now just conern about where it seemed to be heading. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 12 13:24:24 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14142 for ; Mon, 12 Nov 2001 13:24:24 -0500 (EST) Received: (qmail 23137 invoked by uid 605); 12 Nov 2001 18:24:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23130 invoked from network); 12 Nov 2001 18:24:20 -0000 Received: from p101-46.acedsl.com (HELO tp.databus.com) (160.79.101.46) by mail.netbsd.org with SMTP; 12 Nov 2001 18:24:20 -0000 Received: (from barney@localhost) by tp.databus.com (8.11.6/8.11.4) id fACIO2t01936 for ietf-ssh@netbsd.org; Mon, 12 Nov 2001 13:24:02 -0500 (EST) (envelope-from barney) Date: Mon, 12 Nov 2001 13:24:02 -0500 From: Barney Wolff To: ietf-ssh@netbsd.org Subject: Re: A future for the SSH File Transfer Protocol? Message-ID: <20011112132402.A1885@tp.databus.com> References: <3BF00827.7030102@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BF00827.7030102@Sun.COM>; from Darren.Moffat@Sun.COM on Mon, Nov 12, 2001 at 09:34:31AM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Nov 12, 2001 at 09:34:31AM -0800, Darren J Moffat wrote: > > To that end there has been proposals to change this area of > the protocol and augment it with a method for the client to translate > the opaque uid into a name suitable for display. The rational being > that the mapping maybe different on the client than on the server. It strikes me that the whole notion of internal uid is the wrong way to go and just makes life complex for both client and server. I'd propose instead that all conversation be in terms of external user/group names. If people really want to optimize directory listings, something I'm not at all convinced is worthwhile, I'd propose doing it the way DNS does it, with the first appearance of a name being the full string and subsequent appearances being back-references. What is the point of making the client ever deal with the server's internal uid's? -- Barney Wolff "Nonetheless, ease and peace had left this people still curiously tough. They were, if it came to it, difficult to daunt or to kill; and they were, perhaps, so unwearyingly fond of good things not least because they could, when put to it, do without them, and could survive rough handling by grief, foe, or weather in a way that astonished those who did not know them well and looked no further than their bellies and their well-fed faces." J.R.R.T. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 12 13:46:28 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14888 for ; Mon, 12 Nov 2001 13:46:27 -0500 (EST) Received: (qmail 25275 invoked by uid 605); 12 Nov 2001 18:46:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25268 invoked from network); 12 Nov 2001 18:46:23 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 12 Nov 2001 18:46:23 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02981; Mon, 12 Nov 2001 11:46:04 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id KAA24378; Mon, 12 Nov 2001 10:47:14 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.12.1+Sun/8.12.1) with SMTP id fACIkLei451684; Mon, 12 Nov 2001 10:46:21 -0800 (PST) Message-Id: <200111121846.fACIkLei451684@jurassic.eng.sun.com> Date: Mon, 12 Nov 2001 10:46:21 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: A future for the SSH File Transfer Protocol? To: ietf-ssh@netbsd.org, barney@databus.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ros7X5SsdEQR7amWtp3Paw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_47 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >On Mon, Nov 12, 2001 at 09:34:31AM -0800, Darren J Moffat wrote: >> >> To that end there has been proposals to change this area of >> the protocol and augment it with a method for the client to translate >> the opaque uid into a name suitable for display. The rational being >> that the mapping maybe different on the client than on the server. > >It strikes me that the whole notion of internal uid is the wrong way >to go and just makes life complex for both client and server. I'd >propose instead that all conversation be in terms of external >user/group names. If people really want to optimize directory listings, I agree and this is why I said SFTP was starting to look like NFS + NIS, if this is a file transfer protocol it shouldn't need this information particularly if it is expected not to make any sense in the clients domain anyway. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 13 03:53:16 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18153 for ; Tue, 13 Nov 2001 03:53:15 -0500 (EST) Received: (qmail 19226 invoked by uid 605); 13 Nov 2001 08:53:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19219 invoked from network); 13 Nov 2001 08:53:10 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 13 Nov 2001 08:53:10 -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 JAA09404; Tue, 13 Nov 2001 09:53:02 +0100 (MET) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 2E96E43CF; Tue, 13 Nov 2001 09:52:35 +0100 (CET) Date: Tue, 13 Nov 2001 09:52:35 +0100 From: Markus Friedl To: Anthony DeRobertis Cc: Theo de Raadt , Darren Moffat , ietf-ssh@netbsd.org, openssh@openbsd.org Subject: Re: A future for the SSH File Transfer Protocol? Message-ID: <20011113095235.A11677@folly> References: <200111111935.fABJZTXU004411@cvs.openbsd.org> <934927A1-D6EE-11D5-8CDD-00039355CFA6@suespammers.org> <20011112212803.A24610@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011112212803.A24610@folly>; from markus on Mon, Nov 12, 2001 at 09:28:03PM +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sun, Nov 11, 2001 at 04:53:43PM -0500, Anthony DeRobertis wrote: > > On Sunday, November 11, 2001, at 02:35 , Theo de Raadt wrote: > > > > > scp protocol IS rcp protocol. They are 100% the same, and have 100% > > the same flaws. > > IMO, the biggest flaws with rcp are the lack of strong > authentication and the lack of encryption. this is a problem in your rcp client but not in the rcp protocol. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 13 03:53:40 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18164 for ; Tue, 13 Nov 2001 03:53:39 -0500 (EST) Received: (qmail 19582 invoked by uid 605); 13 Nov 2001 08:53:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19575 invoked from network); 13 Nov 2001 08:53:37 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 13 Nov 2001 08:53:37 -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 JAA09414; Tue, 13 Nov 2001 09:53:12 +0100 (MET) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id A3C9543ED; Tue, 13 Nov 2001 09:52:45 +0100 (CET) Date: Tue, 13 Nov 2001 09:52:45 +0100 From: Markus Friedl To: Anthony DeRobertis Cc: Damien Miller , Theo de Raadt , Darren Moffat , ietf-ssh@netbsd.org, openssh@openbsd.org Subject: Re: A future for the SSH File Transfer Protocol? Message-ID: <20011113095245.B11677@folly> References: <471E1760-D712-11D5-BA6F-00039355CFA6@suespammers.org> <20011112213135.B24610@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011112213135.B24610@folly>; from markus on Mon, Nov 12, 2001 at 09:31:35PM +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sun, Nov 11, 2001 at 09:09:17PM -0500, Anthony DeRobertis wrote: > > On Sunday, November 11, 2001, at 08:07 , Damien Miller wrote: > > > > - Inability to do basic filesystem operations (e.g. rename) > > - Inability to access parts of files, or continue aborted transfers > > Those are issues, especially the second. But that's not rcp anymore. > > > > You really want to have a protocol which forces clients to include code > > to protect from a hostile server? > > I think, by definition, cryptographic implementations must. but cryptography is not relevant for sftp/scp. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 13 04:21:11 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18338 for ; Tue, 13 Nov 2001 04:21:10 -0500 (EST) Received: (qmail 23862 invoked by uid 605); 13 Nov 2001 09:21:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23855 invoked from network); 13 Nov 2001 09:21:08 -0000 Received: from ixion.tartarus.org (195.153.205.133) by mail.netbsd.org with SMTP; 13 Nov 2001 09:21:08 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 163Zkh-0000Uu-00; Tue, 13 Nov 2001 09:21:07 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <20011112132402.A1885@tp.databus.com> Subject: Re: A future for the SSH File Transfer Protocol? Message-Id: Date: Tue, 13 Nov 2001 09:21:07 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Barney Wolff wrote: > It strikes me that the whole notion of internal uid is the wrong way > to go and just makes life complex for both client and server. I'd > propose instead that all conversation be in terms of external > user/group names. Yep, I'd sign up for that. Only trouble is, it would need an incompatible protocol change. But if the politics of that can be plausibly managed, it sounds like a good simplification. (It wouldn't _completely_ remove the purpose of my extension, because I'd still like to be able to retrieve the location of a user's home directory. But it would let me condense the entire extension down into one single SSH_FXP_HOMEDIR("fred") command, which would be much nicer than the huge great proposal I've currently got...) > What is the point of making the client ever deal with the server's > internal uid's? As I understand NT, its security identifiers are quite complex, come in several parts, and might not map exactly to a simple user name. But then, if it came to that then the server could just produce a textual representation of a SID and be done with it, so I think even that isn't a good argument against your suggestion. Cheers, Simon -- Simon Tatham "The distinction between the enlightened and the terminally confused is only apparent to the latter." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 14 12:54:25 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07269 for ; Wed, 14 Nov 2001 12:54:24 -0500 (EST) Received: (qmail 6026 invoked by uid 605); 14 Nov 2001 17:51:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6011 invoked from network); 14 Nov 2001 17:51:20 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 14 Nov 2001 17:51:20 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA28598 for ; Wed, 14 Nov 2001 09:51:17 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id JAA28315 for ; Wed, 14 Nov 2001 09:51:19 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with SMTP id fAEHpHCn920610 for ; Wed, 14 Nov 2001 09:51:17 -0800 (PST) Message-Id: <200111141751.fAEHpHCn920610@jurassic.eng.sun.com> Date: Wed, 14 Nov 2001 09:51:17 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Core Drafts To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: lN3fm1vZ4KaZKM+Q2EWutw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_47 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list I haven't had any comments yet on the latest revisions of the 4 core drafts I sent out last week. If there are no comments by Friday 16th at 1200 PST I will be sumbitting these as the working groups latest drafts. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 14 13:05:01 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08122 for ; Wed, 14 Nov 2001 13:05:00 -0500 (EST) Received: (qmail 8432 invoked by uid 605); 14 Nov 2001 18:04:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8348 invoked from network); 14 Nov 2001 18:04:44 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 14 Nov 2001 18:04:44 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18677 for ; Wed, 14 Nov 2001 11:04:25 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28485; Wed, 14 Nov 2001 13:04:37 -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 fAEI4bVO019920; Wed, 14 Nov 2001 13:04:37 -0500 (EST) Message-Id: <200111141804.fAEI4bVO019920@thunk.east.sun.com> From: Bill Sommerfeld To: Darren Moffat Cc: ietf-ssh@netbsd.org Subject: Re: Core Drafts In-Reply-To: Your message of "Wed, 14 Nov 2001 09:51:17 PST." <200111141751.fAEHpHCn920610@jurassic.eng.sun.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 14 Nov 2001 13:04:37 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > I haven't had any comments yet on the latest revisions of the 4 core > drafts I sent out last week. If there are no comments by Friday 16th > at 1200 PST I will be sumbitting these as the working groups latest > drafts. Actually, send them in now. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 14 14:03:48 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11527 for ; Wed, 14 Nov 2001 14:03:47 -0500 (EST) Received: (qmail 866 invoked by uid 605); 14 Nov 2001 19:03:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 859 invoked from network); 14 Nov 2001 19:03:43 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 14 Nov 2001 19:03:43 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id UAA12824; Wed, 14 Nov 2001 20:03:33 +0100 (MET) Date: Wed, 14 Nov 2001 20:03:33 +0100 From: Markus Friedl To: Bill Sommerfeld Cc: Darren Moffat , ietf-ssh@netbsd.org Subject: Re: Core Drafts Message-ID: <20011114200333.D11649@faui02.informatik.uni-erlangen.de> References: <200111141751.fAEHpHCn920610@jurassic.eng.sun.com> <200111141804.fAEI4bVO019920@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <200111141804.fAEI4bVO019920@thunk.east.sun.com>; from sommerfeld@east.sun.com on Wed, Nov 14, 2001 at 01:04:37PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Nov 14, 2001 at 01:04:37PM -0500, Bill Sommerfeld wrote: > > I haven't had any comments yet on the latest revisions of the 4 core > > drafts I sent out last week. If there are no comments by Friday 16th > > at 1200 PST I will be sumbitting these as the working groups latest > > drafts. > > Actually, send them in now. can you send them again with fixes? -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 14 14:04:28 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11604 for ; Wed, 14 Nov 2001 14:04:27 -0500 (EST) Received: (qmail 507 invoked by uid 605); 14 Nov 2001 19:03:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 500 invoked from network); 14 Nov 2001 19:03:12 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 14 Nov 2001 19:03:12 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id UAA12756; Wed, 14 Nov 2001 20:03:08 +0100 (MET) Date: Wed, 14 Nov 2001 20:03:08 +0100 From: Markus Friedl To: Darren Moffat Cc: ietf-ssh@netbsd.org Subject: Re: Core Drafts Message-ID: <20011114200308.C11649@faui02.informatik.uni-erlangen.de> References: <200111141751.fAEHpHCn920610@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <200111141751.fAEHpHCn920610@jurassic.eng.sun.com>; from Darren.Moffat@eng.sun.com on Wed, Nov 14, 2001 at 09:51:17AM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Nov 14, 2001 at 09:51:17AM -0800, Darren Moffat wrote: > I haven't had any comments yet on the latest revisions of the 4 core > drafts I sent out last week. If there are no comments by Friday 16th > at 1200 PST I will be sumbitting these as the working groups latest > drafts. draft-ietf-secsh-architecture-10.txt contains < instead of <= the 'connect' document contains: There are several kinds of requests that affect the state of the remote end "globally", independent of any channels. An example is a request to start TCP/IP forwarding for a specific port. All such requests use the following format. byte SSH_MSG_GLOBAL_REQUEST string request name (restricted to US-ASCII) boolean want reply ... request-specific data follows request names follow the DNS extensibility naming convention outlined in [SSH-ARCH] ^^^ shouldn't there be some CAPS or trailing DOTS. ? and: It is RECOMMENDED to request and check the reply for these messages. The client SHOULD ignore these messages. subsystem names follow the DNS extensibility naming convention outlined in [SSH-ARCH] ^^^^ same here is the message: The response to an SSH_MSG_GLOBAL_REQUEST is of the form: bytes SSH_MSG_GLOBAL_REQUEST_SUCCESS string "tcpip-forward" unint32 port that was bound on the server a MUST? because this would break the currently deployed protocol, i think. moreover, SSH_MSG_GLOBAL_REQUEST_SUCCESS is not defined. all you can do is send a byte SSH_MSG_REQUEST_SUCCESS or byte SSH_MSG_REQUEST_FAILURE i suggest you to remove the The client may send 0 as the port to bind to, in this case the server should interpret this as meaning it should allocate the next availble non privileged port and return the value in the response packet. and The response to an SSH_MSG_GLOBAL_REQUEST is of the form: bytes SSH_MSG_GLOBAL_REQUEST_SUCCESS string "tcpip-forward" unint32 port that was bound on the server since these things should be delayed after the drafts advance. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 15 16:17:58 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21133 for ; Thu, 15 Nov 2001 16:17:57 -0500 (EST) Received: (qmail 25872 invoked by uid 605); 15 Nov 2001 21:17:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25865 invoked from network); 15 Nov 2001 21:17:46 -0000 Received: from mx04.nexgo.de (151.189.8.80) by mail.netbsd.org with SMTP; 15 Nov 2001 21:17:46 -0000 Received: from localhost (dsl-213-023-060-162.arcor-ip.net [213.23.60.162]) by mx04.nexgo.de (Postfix) with ESMTP id 2F9CF37B6B; Thu, 15 Nov 2001 22:17:45 +0100 (CET) Received: by localhost (Postfix, from userid 31451) id 72AAF43CF; Thu, 15 Nov 2001 22:16:32 +0100 (CET) Date: Thu, 15 Nov 2001 22:16:31 +0100 From: Markus Friedl To: ietf-ssh@netbsd.org Cc: Darren Moffat , openssh@openbsd.org Subject: Re: Core Drafts Message-ID: <20011115221631.A16567@folly> References: <200111141751.fAEHpHCn920610@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200111141751.fAEHpHCn920610@jurassic.eng.sun.com>; from Darren.Moffat@eng.sun.com on Wed, Nov 14, 2001 at 09:51:17AM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Nov 14, 2001 at 09:51:17AM -0800, Darren Moffat wrote: > I haven't had any comments yet on the latest revisions of the 4 core > drafts I sent out last week. If there are no comments by Friday 16th > at 1200 PST I will be sumbitting these as the working groups latest > drafts. does anybody care about the drafts? draft-ietf-secsh-connect-12.txt is currently broken, because SSH_MSG_GLOBAL_REQUEST_SUCCESS is not defined. the 'connect' document says about SSH_MSG_GLOBAL_REQUEST: The recipient will respond to this message with SSH_MSG_REQUEST_SUCCESS, SSH_MSG_REQUEST_FAILURE, or some request- specific continuation messages if `want reply' is TRUE. i suggest to remove the "," after SSH_MSG_REQUEST_FAILURE. moreover, if SSH_MSG_GLOBAL_REQUEST_SUCCESS is a so-called 'request-specific continuation messages' then it should have a more 'request-specific' name. but at this point i prefer to drop the addition of the 'bind to 0' feature. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 19 08:33:07 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27575 for ; Mon, 19 Nov 2001 08:33:07 -0500 (EST) Received: (qmail 8121 invoked by uid 605); 19 Nov 2001 13:33:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8114 invoked from network); 19 Nov 2001 13:33:04 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 19 Nov 2001 13:33:04 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27556; Mon, 19 Nov 2001 08:33:01 -0500 (EST) Message-Id: <200111191333.IAA27556@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-connect-12.txt Date: Mon, 19 Nov 2001 08:33:00 -0500 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 : SSH Connection Protocol Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-connect-12.txt Pages : 21 Date : 16-Nov-01 SSH is a protocol for secure remote login and other secure network services over an insecure network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-12.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-connect-12.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-connect-12.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: <20011116142758.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-connect-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-connect-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011116142758.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 19 08:33:21 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27639 for ; Mon, 19 Nov 2001 08:33:20 -0500 (EST) Received: (qmail 8367 invoked by uid 605); 19 Nov 2001 13:33:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8354 invoked from network); 19 Nov 2001 13:33:10 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 19 Nov 2001 13:33:10 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27574; Mon, 19 Nov 2001 08:33:07 -0500 (EST) Message-Id: <200111191333.IAA27574@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-architecture-10.txt Date: Mon, 19 Nov 2001 08:33:07 -0500 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 : SSH Protocol Architecture Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-architecture-10.txt Pages : 15 Date : 16-Nov-01 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-10.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-architecture-10.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-architecture-10.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: <20011116142811.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-architecture-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-architecture-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011116142811.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 19 08:33:32 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27683 for ; Mon, 19 Nov 2001 08:33:32 -0500 (EST) Received: (qmail 8457 invoked by uid 605); 19 Nov 2001 13:33:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8429 invoked from network); 19 Nov 2001 13:33:14 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 19 Nov 2001 13:33:14 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27540; Mon, 19 Nov 2001 08:32:55 -0500 (EST) Message-Id: <200111191332.IAA27540@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-userauth-12.txt Date: Mon, 19 Nov 2001 08:32:55 -0500 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 : SSH Authentication Protocol Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-userauth-12.txt Pages : 15 Date : 16-Nov-01 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host- based client authentication methods. Additional authentication methods are described in separate documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-12.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-userauth-12.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-userauth-12.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: <20011116142745.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-userauth-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-userauth-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011116142745.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 19 08:33:48 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27726 for ; Mon, 19 Nov 2001 08:33:48 -0500 (EST) Received: (qmail 8523 invoked by uid 605); 19 Nov 2001 13:33:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8473 invoked from network); 19 Nov 2001 13:33:15 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 19 Nov 2001 13:33:15 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27611; Mon, 19 Nov 2001 08:33:12 -0500 (EST) Message-Id: <200111191333.IAA27611@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-transport-10.txt Date: Mon, 19 Nov 2001 08:33:12 -0500 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 : SSH Transport Layer Protocol Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-transport-10.txt Pages : 27 Date : 16-Nov-01 SSH is a protocol for secure remote login and other secure network services over an insecure network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-10.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-transport-10.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-transport-10.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: <20011116142825.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-transport-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-transport-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011116142825.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 19 11:05:35 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06545 for ; Mon, 19 Nov 2001 11:05:34 -0500 (EST) Received: (qmail 1846 invoked by uid 605); 19 Nov 2001 16:05:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1839 invoked from network); 19 Nov 2001 16:05:31 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 19 Nov 2001 16:05:31 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id RAA27766; Mon, 19 Nov 2001 17:05:18 +0100 (MET) Date: Mon, 19 Nov 2001 17:05:18 +0100 From: Markus Friedl To: Darren Moffat , Bill Sommerfeld Cc: ietf-ssh@netbsd.org, openssh@openbsd.org Subject: Re: I-D ACTION:draft-ietf-secsh-connect-12.txt Message-ID: <20011119170518.A27493@faui02.informatik.uni-erlangen.de> References: <200111191333.IAA27556@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <200111191333.IAA27556@ietf.org>; from Internet-Drafts@ietf.org on Mon, Nov 19, 2001 at 08:33:00AM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list hi, fyi: this is still the broken document. http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-12.txt From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 19 12:17:03 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10559 for ; Mon, 19 Nov 2001 12:17:03 -0500 (EST) Received: (qmail 18005 invoked by uid 605); 19 Nov 2001 17:16:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17998 invoked from network); 19 Nov 2001 17:16:49 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 19 Nov 2001 17:16:49 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10940; Mon, 19 Nov 2001 10:16:30 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id JAA11967; Mon, 19 Nov 2001 09:16:51 -0800 (PST) Received: from Sun.COM (dsl-192-32.Eng.Sun.COM [129.146.192.32]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJHGiCm800714; Mon, 19 Nov 2001 09:16:44 -0800 (PST) Message-ID: <3BF93FDC.9040104@Sun.COM> Date: Mon, 19 Nov 2001 09:22:36 -0800 From: Darren J Moffat User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Markus Friedl CC: ietf-ssh@netbsd.org, openssh@openbsd.org Subject: Re: I-D ACTION:draft-ietf-secsh-connect-12.txt References: <200111191333.IAA27556@ietf.org> <20011119170518.A27493@faui02.informatik.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Markus Friedl wrote: > hi, fyi: this is still the broken document. > > http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-12.txt I know this was the one submitted before I got your comments, it takes about a week from sending the email before they actually show up. The process seems to be very slow at this time of year ;-) I'm submitting the version with your comments today. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 19 12:27:58 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11252 for ; Mon, 19 Nov 2001 12:27:57 -0500 (EST) Received: (qmail 20357 invoked by uid 605); 19 Nov 2001 17:27:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20350 invoked from network); 19 Nov 2001 17:27:56 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 19 Nov 2001 17:27:56 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 382708 for ietf-ssh@netbsd.org; Mon, 19 Nov 2001 10:31:27 -0700 Message-ID: <051401c1711f$86f9b080$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: References: <200111191333.IAA27611@ietf.org> Subject: Draft comments... Date: Mon, 19 Nov 2001 10:27:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Transport draft: o In section 4.2, at the bottom there is an empty reference. (Right above the start of section 4.3) : "Additional methods may be defined as specified in ." Connection Draft: o As Markus has noted, the connection draft is broken in section 5.1; we can do one of several things: 1. Remove the new text; revert to SSH_MSG_REQUEST_SUCCESS 2. Define a message number for SSH_MSG_GLOBAL_REQUEST_SUCCESS, and give it a flexible format, i.e., byte SSH_MSG_GLOBAL_REQUEST_SUCCESS string "response-name" ... response specific data in addition, for "tcpip-forward", specify that this response should only be sent if the bind request is for port 0; otherwise SSH_MSG_REQUEST_SUCCESS should be sent. 3. Specify that SSH_MSG_REQUEST_SUCCESS has the format: byte SSH_MSG_REQUEST_SUCCESS ... response specific data where the response specific data is usually non-existent. And specify for "tcpip-forward" request, that if and only if the request port is 0, the response look like: byte SSH_MSG_REQUEST_SUCCESS uint32 port that was bound on the server I would prefer 3; Markus has expressed a strong preference for 1. If anyone else has an opinion on the matter, can you please speak up? I would like to have this included, but more than that, I would love to have a version of the draft that we can go to last call with. Is there any chance we can get these fixes in this week, and resubmitted, so we can have version of the draft that is a candidate for last call? All drafts: o I believe the references section needs to be updated to refer to the new versions of the companion drafts -- they are still referring to the previous version number. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 19 20:58:50 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05527 for ; Mon, 19 Nov 2001 20:58:49 -0500 (EST) Received: (qmail 19371 invoked by uid 605); 20 Nov 2001 00:56:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19364 invoked from network); 20 Nov 2001 00:56:48 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 20 Nov 2001 00:56:48 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA04181; Mon, 19 Nov 2001 17:56:30 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id QAA04172; Mon, 19 Nov 2001 16:56:55 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with SMTP id fAK0ukCn914738; Mon, 19 Nov 2001 16:56:47 -0800 (PST) Message-Id: <200111200056.fAK0ukCn914738@jurassic.eng.sun.com> Date: Mon, 19 Nov 2001 16:56:47 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: Draft comments... To: ietf-ssh@netbsd.org, galb-list@vandyke.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 5FLFrfu6NpLFJcHHTiUE2w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_50 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >Transport draft: > >o In section 4.2, at the bottom there is an empty reference. > (Right above the start of section 4.3) : > > "Additional methods may be defined as specified in ." fixed and resubmitted. >Connection Draft: > >o As Markus has noted, the connection draft is broken > in section 5.1; we can do one of several things: > I would prefer 3; Markus has expressed a strong > preference for 1. > > If anyone else has an opinion on the matter, > can you please speak up? Option 3 seems to be the one that best deals with adding the feature to the current drafts in a backwards compatible way until we can do something better. My vote is for Option 3. > Is there any chance we can get these fixes in > this week, and resubmitted, so we can have > version of the draft that is a candidate for > last call? Given that the cut off is 21st November we don't have time to discuss this and get a resubmittion before the meeting. I'll leave it as it stands just now, until we can discuss this at the meeting - I know it is what we want but given the time and the sever lack of response from a lot of people I don't have an better answer. >All drafts: > >o I believe the references section needs to be updated > to refer to the new versions of the companion drafts -- > they are still referring to the previous version number. Bugger, I'll resubmit them all today. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 19 21:01:21 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05792 for ; Mon, 19 Nov 2001 21:01:21 -0500 (EST) Received: (qmail 5951 invoked by uid 605); 20 Nov 2001 02:01:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5944 invoked from network); 20 Nov 2001 02:01:16 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 20 Nov 2001 02:01:16 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA15982; Mon, 19 Nov 2001 18:01:14 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.37]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id SAA19775; Mon, 19 Nov 2001 18:01:21 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with SMTP id fAK21DCn923849; Mon, 19 Nov 2001 18:01:13 -0800 (PST) Message-Id: <200111200201.fAK21DCn923849@jurassic.eng.sun.com> Date: Mon, 19 Nov 2001 18:01:13 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: Core Drafts To: ietf-ssh@netbsd.org, markus@openbsd.org Cc: openssh@openbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: QTNdXjZqkjxW9Jqz9HLdEA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_50 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >draft-ietf-secsh-connect-12.txt is currently broken, because >SSH_MSG_GLOBAL_REQUEST_SUCCESS is not defined. Okay dispite what I said in my last reply I'm going to fix this brokenness, and we can disucss the whole port forwarding area at the meeting and/or after it. >the 'connect' document says about SSH_MSG_GLOBAL_REQUEST: > > The recipient will respond to this message with > SSH_MSG_REQUEST_SUCCESS, SSH_MSG_REQUEST_FAILURE, or some request- > specific continuation messages if `want reply' is TRUE. > >i suggest to remove the "," after SSH_MSG_REQUEST_FAILURE. I assume you just mean the , not the text after it. >but at this point i prefer to drop the addition of >the 'bind to 0' feature. Removed, I suggest we have an adenda item and discussion to move this area forward since there seems to be interest in the functionality. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 19 21:08:54 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06644 for ; Mon, 19 Nov 2001 21:08:54 -0500 (EST) Received: (qmail 6934 invoked by uid 605); 20 Nov 2001 02:08:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6927 invoked from network); 20 Nov 2001 02:08:52 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 20 Nov 2001 02:08:52 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA17743 for ; Mon, 19 Nov 2001 18:08:51 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id SAA21383 for ; Mon, 19 Nov 2001 18:08:58 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with SMTP id fAK28oCn925339 for ; Mon, 19 Nov 2001 18:08:50 -0800 (PST) Message-Id: <200111200208.fAK28oCn925339@jurassic.eng.sun.com> Date: Mon, 19 Nov 2001 18:08:50 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Core Drafts rev'd again To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: blzlxxyehSFs4T2NCvEz7g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_50 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list I've just resubmitted the core drafts again and got an auto reply which contains the following: > AS you may surmise, this is an extremly busy week. Be advised > that it may take a number of days to process and announce your > document. Our goal is to process and announce all valid > Internet-Draft submissions by December 3, 2001 at the latest. Bill are we having a meeting ? If so which day is it going to be ? Here are the things I think the wg needs to talk about: * Reach consensus that the 4 core drafts are now complete. * What to do, if anything, about port forwarding to support bind to 0 requests. * SFTP - in particular the recent list discussion topic on user identifiers. * GSS drafts status update (assuming the authors are there). * Fingerprint draft status (assuming the authors are there). Will the draft be updated to allow SHA and/or MD5 as per the suggestion at a previous meeting ? * Creating a new draft for agent forwarding. * Review our WG goals and milestones. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 19 21:18:26 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07217 for ; Mon, 19 Nov 2001 21:18:25 -0500 (EST) Received: (qmail 8325 invoked by uid 605); 20 Nov 2001 02:18:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8318 invoked from network); 20 Nov 2001 02:18:24 -0000 Received: from sommerfeld.ne.mediaone.net (HELO stack.hamachi.org) (66.31.126.43) by mail.netbsd.org with SMTP; 20 Nov 2001 02:18:24 -0000 Received: from syn.hamachi.org (orchard.hamachi.org [18.101.2.2]) by stack.hamachi.org (Postfix) with ESMTP id 60A5926DE; Mon, 19 Nov 2001 21:18:05 -0500 (EST) Received: from syn.hamachi.org (localhost [[UNIX: localhost]]) by syn.hamachi.org (8.11.6/8.8.8) with ESMTP id fAK2GYX10214; Mon, 19 Nov 2001 21:16:34 -0500 (EST) Message-Id: <200111200216.fAK2GYX10214@syn.hamachi.org> From: Bill Sommerfeld To: Darren Moffat Cc: ietf-ssh@netbsd.org Subject: Re: Core Drafts rev'd again In-Reply-To: Message from Darren Moffat of "Mon, 19 Nov 2001 18:08:50 PST." <200111200208.fAK28oCn925339@jurassic.eng.sun.com> Reply-To: sommerfeld@orchard.arlington.ma.us Date: Mon, 19 Nov 2001 21:16:34 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > Bill are we having a meeting ? If so which day is it going to be ? See http://www.ietf.org/meetings/agenda_52.txt We're currently on the agenda for Tuesday afternoon. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 20 07:58:52 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06172 for ; Tue, 20 Nov 2001 07:58:52 -0500 (EST) Received: (qmail 17891 invoked by uid 605); 20 Nov 2001 12:58:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17884 invoked from network); 20 Nov 2001 12:58:50 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 20 Nov 2001 12:58:50 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 1D61B82FFDB; Tue, 20 Nov 2001 13:58:49 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.3/8.8.7) id NAA03065; Tue, 20 Nov 2001 13:58:48 +0100 (MET) To: "Joseph Galbraith" Cc: Subject: Re: Draft comments... References: <200111191333.IAA27611@ietf.org> <051401c1711f$86f9b080$2800a8c0@test.vandyke.com> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels Möller) Date: 20 Nov 2001 13:58:48 +0100 In-Reply-To: "Joseph Galbraith"'s message of "Mon, 19 Nov 2001 10:27:56 -0700" Message-ID: Lines: 29 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit "Joseph Galbraith" writes: > 3. Specify that SSH_MSG_REQUEST_SUCCESS has the format: > > byte SSH_MSG_REQUEST_SUCCESS > ... response specific data > > where the response specific data is usually non-existent. > > And specify for "tcpip-forward" request, that > if and only if the request port is 0, the > response look like: > > byte SSH_MSG_REQUEST_SUCCESS > uint32 port that was bound on the server > > I would prefer 3; Markus has expressed a strong > preference for 1. > > If anyone else has an opinion on the matter, > can you please speak up? The change you propose is small, clean, and backwards-compatible for all cases I care about. So it looks good to me. I think larger changes should wait until we want to bump the protocol version number. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 20 14:39:43 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01295 for ; Tue, 20 Nov 2001 14:39:42 -0500 (EST) Received: (qmail 9949 invoked by uid 605); 20 Nov 2001 19:39:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9942 invoked from network); 20 Nov 2001 19:39:36 -0000 Received: from mx04.nexgo.de (151.189.8.80) by mail.netbsd.org with SMTP; 20 Nov 2001 19:39:36 -0000 Received: from localhost (dsl-213-023-060-106.arcor-ip.net [213.23.60.106]) by mx04.nexgo.de (Postfix) with ESMTP id A0C0137F2B; Tue, 20 Nov 2001 20:39:31 +0100 (CET) Received: by localhost (Postfix, from userid 31451) id CB57043CF; Tue, 20 Nov 2001 20:38:09 +0100 (CET) Date: Tue, 20 Nov 2001 20:38:09 +0100 From: Markus Friedl To: Joseph Galbraith Cc: ietf-ssh@netbsd.org Subject: Re: Draft comments... Message-ID: <20011120203809.A18987@folly> References: <200111191333.IAA27611@ietf.org> <051401c1711f$86f9b080$2800a8c0@test.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <051401c1711f$86f9b080$2800a8c0@test.vandyke.com>; from galb-list@vandyke.com on Mon, Nov 19, 2001 at 10:27:56AM -0700 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Nov 19, 2001 at 10:27:56AM -0700, Joseph Galbraith wrote: > 3. Specify that SSH_MSG_REQUEST_SUCCESS has the format: > > byte SSH_MSG_REQUEST_SUCCESS > ... response specific data > > where the response specific data is usually non-existent. > > And specify for "tcpip-forward" request, that > if and only if the request port is 0, the > response look like: > > byte SSH_MSG_REQUEST_SUCCESS > uint32 port that was bound on the server > > I would prefer 3; Markus has expressed a strong > preference for 1. well, i agree with #3. then we can change: The recipient will respond to this message with SSH_MSG_REQUEST_SUCCESS, SSH_MSG_REQUEST_FAILURE, or some request- specific continuation messages if `want reply' is TRUE. to The recipient will respond to this message with SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE if `want reply' is TRUE. > I would like to have this included, but more than > that, I would love to have a version of the > draft that we can go to last call with. so do i. we really should move on. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 20 14:47:08 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01652 for ; Tue, 20 Nov 2001 14:47:06 -0500 (EST) Received: (qmail 11271 invoked by uid 605); 20 Nov 2001 19:47:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11251 invoked from network); 20 Nov 2001 19:47:04 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 20 Nov 2001 19:47:04 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18817; Tue, 20 Nov 2001 12:46:43 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.130]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id LAA01283; Tue, 20 Nov 2001 11:47:09 -0800 (PST) Received: from quirm (dsl-192-32.Eng.Sun.COM [129.146.192.32]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with SMTP id fAKJkuCn160988; Tue, 20 Nov 2001 11:46:59 -0800 (PST) Message-Id: <200111201946.fAKJkuCn160988@jurassic.eng.sun.com> Date: Tue, 20 Nov 2001 11:46:44 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: Draft comments... To: galb-list@vandyke.com, markus@openbsd.org Cc: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: WqvWEEKDyhOMXwmT/nRl0w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >On Mon, Nov 19, 2001 at 10:27:56AM -0700, Joseph Galbraith wrote: >> 3. Specify that SSH_MSG_REQUEST_SUCCESS has the format: >> >> byte SSH_MSG_REQUEST_SUCCESS >> ... response specific data >> >> where the response specific data is usually non-existent. >> >> And specify for "tcpip-forward" request, that >> if and only if the request port is 0, the >> response look like: >> >> byte SSH_MSG_REQUEST_SUCCESS >> uint32 port that was bound on the server >> >> I would prefer 3; Markus has expressed a strong >> preference for 1. > >well, i agree with #3. So do we have consensus that requesting port 0 with the symantics defined above is acceptable for now rather that some later revision ? >then we can change: > The recipient will respond to this message with > SSH_MSG_REQUEST_SUCCESS, SSH_MSG_REQUEST_FAILURE, or some request- > specific continuation messages if `want reply' is TRUE. >to > The recipient will respond to this message with > SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE > if `want reply' is TRUE. agreed. >> I would like to have this included, but more than >> that, I would love to have a version of the >> draft that we can go to last call with. > >so do i. we really should move on. So am I to put it in and resubmit again ? Wednesday 21st at 1200 EST is the cut of for changes before the meeting, so I must know today if I need to change the docs again. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 20 17:06:56 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08464 for ; Tue, 20 Nov 2001 17:06:55 -0500 (EST) Received: (qmail 29827 invoked by uid 605); 20 Nov 2001 22:06:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29561 invoked from network); 20 Nov 2001 22:06:23 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 20 Nov 2001 22:06:23 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 384495 for ietf-ssh@netbsd.org; Tue, 20 Nov 2001 15:09:56 -0700 Message-ID: <010f01c1720f$96eb6650$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: References: <200111201946.fAKJkuCn160988@jurassic.eng.sun.com> Subject: Re: Draft comments... Date: Tue, 20 Nov 2001 15:06:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > So am I to put it in and resubmit again ? Wednesday 21st at 1200 EST > is the cut of for changes before the meeting, so I must know today if > I need to change the docs again. I'm all for it -- - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 21 04:48:40 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08117 for ; Wed, 21 Nov 2001 04:48:40 -0500 (EST) Received: (qmail 1928 invoked by uid 605); 21 Nov 2001 09:48:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1921 invoked from network); 21 Nov 2001 09:48:35 -0000 Received: from chiark.greenend.org.uk (195.224.76.132) by mail.netbsd.org with SMTP; 21 Nov 2001 09:48:35 -0000 Received: from sgtatham by chiark.greenend.org.uk with local (Exim 3.12 #2) id 166Tze-0002XM-00 (Debian); Wed, 21 Nov 2001 09:48:34 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <200111191333.IAA27556@ietf.org> Subject: Re: I-D ACTION:draft-ietf-secsh-connect-12.txt Message-Id: Date: Wed, 21 Nov 2001 09:48:34 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list wrote: > Title : SSH Connection Protocol [...] > Filename : draft-ietf-secsh-connect-12.txt Markus has just drawn my attention to section 4.4, which I hadn't noticed before. I've got one small comment on it: | Typically, each machine will have a preconfigured set of variables | that it will allow. Since uncontrolled setting of environment | variables can be very dangerous, it is recommended that | implementations allow setting only variables whose names have been | explicitly configured to be allowed. Surely uncontrolled setting of environment variables is only dangerous if you do it while you're still running as root? I was under the impression that all the problems in Telnet's environment passing mechanism have come up because telnetd invokes login to authenticate the user, so login runs as root with all the user's environment variables available. Whereas the typical SSH server will do the uid change itself, so it can set the environment variables _after_ it changes uid and then the only person who can be hurt by malicious or incompetent setting of (e.g.) LD_PRELOAD is the user themself. I'm sure there are some SSH servers, or some situations, in which this won't be the case, but it seems far from obvious to me that the above text is appropriate for every implementation or even for the typical ones. Have I misunderstood? If I haven't misunderstood anything, then perhaps an alternative wording might be: | Uncontrolled setting of environment variables in a privileged | process can be a security hazard, so it is recommended that | implementations either maintain a list of allowable variable names, | or do not actually set the variables until after the server process | has dropped its privileges. Cheers, Simon -- Simon Tatham "_shin_, n. An ingenious device for finding tables and chairs in the dark." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 21 11:43:51 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24195 for ; Wed, 21 Nov 2001 11:43:50 -0500 (EST) Received: (qmail 11876 invoked by uid 605); 21 Nov 2001 16:43:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11869 invoked from network); 21 Nov 2001 16:43:48 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 21 Nov 2001 16:43:48 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24105; Wed, 21 Nov 2001 08:43:42 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.36]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id IAA24644; Wed, 21 Nov 2001 08:43:46 -0800 (PST) Received: from Sun.COM (dsl-192-32.Eng.Sun.COM [129.146.192.32]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fALGhbLs156625; Wed, 21 Nov 2001 08:43:37 -0800 (PST) Message-ID: <3BFBD9AF.1030700@Sun.COM> Date: Wed, 21 Nov 2001 08:43:27 -0800 From: Darren J Moffat User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Simon Tatham CC: ietf-ssh@netbsd.org Subject: Re: I-D ACTION:draft-ietf-secsh-connect-12.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Simon Tatham wrote: > If I haven't misunderstood anything, then perhaps an alternative > wording might be: > > | Uncontrolled setting of environment variables in a privileged > | process can be a security hazard, so it is recommended that > | implementations either maintain a list of allowable variable names, > | or do not actually set the variables until after the server process > | has dropped its privileges. I think that wording is much more appropriate, since it actually describes the problem as well as giving solutions. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 21 12:00:46 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25075 for ; Wed, 21 Nov 2001 12:00:46 -0500 (EST) Received: (qmail 15271 invoked by uid 605); 21 Nov 2001 17:00:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15262 invoked from network); 21 Nov 2001 17:00:36 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 21 Nov 2001 17:00:36 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 385124; Wed, 21 Nov 2001 10:04:11 -0700 Message-ID: <01f801c172ae$0a0af210$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: "Darren J Moffat" , "Simon Tatham" Cc: References: <3BFBD9AF.1030700@Sun.COM> Subject: Re: I-D ACTION:draft-ietf-secsh-connect-12.txt Date: Wed, 21 Nov 2001 10:00:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Darren Moffat wrote: > Simon Tatham wrote: > > > If I haven't misunderstood anything, then perhaps an alternative > > wording might be: > > > > | Uncontrolled setting of environment variables in a privileged > > | process can be a security hazard, so it is recommended that > > | implementations either maintain a list of allowable variable names, > > | or do not actually set the variables until after the server process > > | has dropped its privileges. > > > I think that wording is much more appropriate, since it actually > describes the problem as well as giving solutions. I prefer this wording as well -- unless people feel we can remove it completely. It seems acceptable to have a implementation note to me. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 21 15:55:29 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05347 for ; Wed, 21 Nov 2001 15:55:29 -0500 (EST) Received: (qmail 12161 invoked by uid 605); 21 Nov 2001 20:55:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12154 invoked from network); 21 Nov 2001 20:55:26 -0000 Received: from chiark.greenend.org.uk (195.224.76.132) by mail.netbsd.org with SMTP; 21 Nov 2001 20:55:26 -0000 Received: from sgtatham by chiark.greenend.org.uk with local (Exim 3.12 #2) id 166eOz-0006x3-00 (Debian); Wed, 21 Nov 2001 20:55:25 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org Subject: des-cbc cipher Message-Id: Date: Wed, 21 Nov 2001 20:55:25 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Looking at ssh.com's SSH-3.0.1, it appears that it supports single-DES encryption under the identifier "des-cbc". I don't see this listed as an approved name in the latest transport draft. Is it an approved name, or has ssh.com unilaterally added it and failed to put a domain on the end? Cheers, Simon -- Simon Tatham "My heart bleeds. (That's how it works.)" -- Gareth Taylor From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 21 18:18:12 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12966 for ; Wed, 21 Nov 2001 18:18:12 -0500 (EST) Received: (qmail 25697 invoked by uid 605); 21 Nov 2001 23:16:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25684 invoked from network); 21 Nov 2001 23:16:23 -0000 Received: from fw.hel.fi.ssh.com (193.64.193.124) by mail.netbsd.org with SMTP; 21 Nov 2001 23:16:23 -0000 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id fALNGMf22370 for ; Thu, 22 Nov 2001 01:16:22 +0200 (EET) Received: (qmail 27945 invoked from network); 21 Nov 2001 23:16:21 -0000 Received: from unknown (HELO johto.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 21 Nov 2001 23:16:21 -0000 Received: (from sjl@localhost) by johto.hel.fi.ssh.com (8.9.3/8.9.3) id BAA04495; Thu, 22 Nov 2001 01:16:43 +0200 To: ietf-ssh@netbsd.org Subject: Re: des-cbc cipher References: From: sjl@ssh.com (Sami J. Lehtinen) Date: 22 Nov 2001 01:16:43 +0200 In-Reply-To: anakin@pobox.com's message of "Wed, 21 Nov 2001 20:55:34 +0000 (UTC)" Message-ID: Lines: 26 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Canyonlands" Sender: ietf-ssh-owner@netbsd.org Precedence: list anakin@pobox.com (Simon Tatham) writes: > Looking at ssh.com's SSH-3.0.1, it appears that it supports > single-DES encryption under the identifier "des-cbc". > > I don't see this listed as an approved name in the latest transport > draft. Is it an approved name, or has ssh.com unilaterally added it > and failed to put a domain on the end? Shall we say, a misfeature. It is not in the transport draft (nor should it). DES is supported for marketroid reasons (some people actually really want to use it, even with advice for the contrary), and it not having a "@ssh.com" ending is a bug. Which will also be present in 3.1.0, unfortunately. This shouldn't have any adverse affect on interoperability, as other implementations will just ignore it as not supported (or do you specifically look for algorithms that are not in the spec, and disconnect in disgust?). -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 20 5007425][gsm:+358 40 864 3001][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 22 03:56:01 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10805 for ; Thu, 22 Nov 2001 03:56:01 -0500 (EST) Received: (qmail 11144 invoked by uid 605); 22 Nov 2001 08:55:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11128 invoked from network); 22 Nov 2001 08:55:55 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 22 Nov 2001 08:55:55 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 37159834D83; Thu, 22 Nov 2001 09:55:54 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.3/8.8.7) id JAA00753; Thu, 22 Nov 2001 09:55:53 +0100 (MET) X-Authentication-Warning: sture.lysator.liu.se: nisse set sender to nisse@sture.lysator.liu.se using -f To: sjl@ssh.com (Sami J. Lehtinen) Cc: ietf-ssh@netbsd.org Subject: Re: des-cbc cipher References: Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 22 Nov 2001 09:55:53 +0100 In-Reply-To: Message-ID: Lines: 16 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit sjl@ssh.com (Sami J. Lehtinen) writes: > This shouldn't have any adverse affect on interoperability, as other > implementations will just ignore it as not supported (or do you > specifically look for algorithms that are not in the spec, and > disconnect in disgust?). At least I simply ignore it. I only check that the _length_ of the name is allowed. Next I look it up in my list of known names. Unknown names are ignored, with no further syntax checks of any kind. I think this is the right way to behave. New algorithms could be added to the spec (like aes was not long ago), even if I hope noone will ever propose adding plain single-des. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 22 04:34:55 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11359 for ; Thu, 22 Nov 2001 04:34:55 -0500 (EST) Received: (qmail 18032 invoked by uid 605); 22 Nov 2001 09:34:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18025 invoked from network); 22 Nov 2001 09:34:53 -0000 Received: from chiark.greenend.org.uk (195.224.76.132) by mail.netbsd.org with SMTP; 22 Nov 2001 09:34:53 -0000 Received: from sgtatham by chiark.greenend.org.uk with local (Exim 3.12 #2) id 166qFw-0000P9-00 (Debian); Thu, 22 Nov 2001 09:34:52 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: Subject: Re: des-cbc cipher Message-Id: Date: Thu, 22 Nov 2001 09:34:52 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Sami J. Lehtinen wrote: > This shouldn't have any adverse affect on interoperability, as other > implementations will just ignore it as not supported (or do you > specifically look for algorithms that are not in the spec, and > disconnect in disgust?). *grin* no, I'm not _that_ pedantic. In fact I've just added support for it to PuTTY, because a user claimed to have some weird kind of router with an SSH server that supported no other ciphers at all. By default PuTTY will give a warning about the low security level. I agree it's not a major namespace problem - I can't easily imagine anyone inventing another cipher called DES which needs the same name! And I can't imagine single-DES being standardised, if it's ever standardised at all, in a way that's different from the way you've done it. Just checking, really. If I'm in violation of a spec I like to at least know about it. Cheers, Simon -- Simon Tatham These are my opinions. There are many like them but these ones are mine. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 22 08:53:08 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14819 for ; Thu, 22 Nov 2001 08:53:07 -0500 (EST) Received: (qmail 23264 invoked by uid 605); 22 Nov 2001 13:53:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23252 invoked from network); 22 Nov 2001 13:53:02 -0000 Received: from fw.hel.fi.ssh.com (193.64.193.124) by mail.netbsd.org with SMTP; 22 Nov 2001 13:53:02 -0000 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id fAMDr1f04010 for ; Thu, 22 Nov 2001 15:53:01 +0200 (EET) Received: (qmail 18306 invoked from network); 22 Nov 2001 13:53:00 -0000 Received: from unknown (HELO johto.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 22 Nov 2001 13:53:00 -0000 Received: (from sjl@localhost) by johto.hel.fi.ssh.com (8.9.3/8.9.3) id PAA05095; Thu, 22 Nov 2001 15:53:23 +0200 To: ietf-ssh@netbsd.org Subject: Re: des-cbc cipher References: From: sjl@ssh.com (Sami J. Lehtinen) Date: 22 Nov 2001 15:53:22 +0200 In-Reply-To: anakin@pobox.com's message of "Thu, 22 Nov 2001 09:35:01 +0000 (UTC)" Message-ID: Lines: 11 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Canyonlands" Sender: ietf-ssh-owner@netbsd.org Precedence: list anakin@pobox.com (Simon Tatham) writes: > Just checking, really. If I'm in violation of a spec I like to at > least know about it. And I thank you for that. Cheers, -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 20 5007425][gsm:+358 40 864 3001][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 26 06:19:16 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19786 for ; Mon, 26 Nov 2001 06:19:15 -0500 (EST) Received: (qmail 24175 invoked by uid 605); 26 Nov 2001 11:19:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24161 invoked from network); 26 Nov 2001 11:19:12 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 26 Nov 2001 11:19:12 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19704; Mon, 26 Nov 2001 06:18:54 -0500 (EST) Message-Id: <200111261118.GAA19704@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-filexfer-02.txt Date: Mon, 26 Nov 2001 06:18:54 -0500 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 : SSH File Transfer Protocol Author(s) : T. Ylonen, S. Lehtinen Filename : draft-ietf-secsh-filexfer-02.txt Pages : 29 Date : 21-Nov-01 The SSH File Transfer Protocol provides secure file transfer functionality over any reliable data stream. It is the standard file transfer protocol for use with the SSH2 protocol. This document describes the file transfer protocol and its interface to the SSH2 protocol suite. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-02.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-filexfer-02.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-filexfer-02.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: <20011121142103.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-filexfer-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-filexfer-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011121142103.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 26 10:52:29 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05551 for ; Mon, 26 Nov 2001 10:52:28 -0500 (EST) Received: (qmail 12267 invoked by uid 605); 26 Nov 2001 15:52:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12260 invoked from network); 26 Nov 2001 15:52:26 -0000 Received: from mail.fr.uu.net (HELO argyre.fr.uu.net) (194.98.0.9) by mail.netbsd.org with SMTP; 26 Nov 2001 15:52:26 -0000 Received: from [213.11.39.71] ([213.11.39.71]) by argyre.fr.uu.net (8.9.3/8.8.7) with SMTP id QAA18866 for ; Mon, 26 Nov 2001 16:59:01 +0100 (MET) From: annuaire@annuairefrancais.com Message-Id: <200111261559.QAA18866@argyre.fr.uu.net> Mime-Version: 1.0 Content-Type: text/plain;charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Mon, 26 Nov 2001 16:51:21 +0100 To: ietf-ssh@netbsd.org Subject: Info : L'Annuaire Francais par Departement facilite vos recherches Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Bonjour, L'annuaire Francais Par departement http://www.annuairefrancais.com integre desormais un moteur de recherche pour affiner vos recherches sur le web. L'inscription reste gratuite et la validation toujours manuelle. L'adresse d'inscription est desormais http://inscrip.annuairefrancais.com Pour toutes suggestions contactez par mail : direction : laurent@annuairefrancais.com validation : validation@annuairefrancais.com publicite : publicite@annuairefrancais.com partenariat : partenariat@annuairefrancais.com INFORMATIONS : retrait de notre liste d'info : http://supressinfo.annuairefrancais.com (L'annuaire francais envoi 2 infos par an) L'annuaire Francais 119 Rue des Pyrenees 75020 PARIS +33 (0)1 43 67 00 74 From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Nov 26 15:45:30 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29646 for ; Mon, 26 Nov 2001 15:45:29 -0500 (EST) Received: (qmail 16914 invoked by uid 605); 26 Nov 2001 20:45:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16906 invoked from network); 26 Nov 2001 20:45:27 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 26 Nov 2001 20:45:27 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA19034; Mon, 26 Nov 2001 12:45:26 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA18865; Mon, 26 Nov 2001 15:45:25 -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 fAQKjOU8003659; Mon, 26 Nov 2001 15:45:24 -0500 (EST) Message-Id: <200111262045.fAQKjOU8003659@thunk.east.sun.com> From: Bill Sommerfeld To: Simon Tatham cc: ietf-ssh@netbsd.org Subject: Re: I-D ACTION:draft-ietf-secsh-connect-12.txt In-Reply-To: Your message of "Wed, 21 Nov 2001 09:48:34 GMT." Reply-to: sommerfeld@east.sun.com Date: Mon, 26 Nov 2001 15:45:24 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > If I haven't misunderstood anything, then perhaps an alternative > wording might be: > > | Uncontrolled setting of environment variables in a privileged > | process can be a security hazard, so it is recommended that > | implementations either maintain a list of allowable variable names, > | or do not actually set the variables until after the server process > | has dropped its privileges. comments: (personal observation, wg chair hat off) Unrestricted setting of environment variables, even *after* the daemon process sets apparently-appropriate privileges, could conceivably also cause trouble when sshd is used to implement restricted environments rather than give full shell access -- I'm thinking of setups like the ones you can build with the `command="..."' option in the authorized_keys file)... i.e., it would be a Good Thing for server implementations to allow fine-grained control over what environment variables can be set). (wg chair hat on). The IETF is primarily about wire protocols, not implementations. environment variables are very much a local matter. In particular, while we can make vague recommendations, exactly when and where it's "safe" to allow environment variables to be set is inherently implementation specific. Any comments on this text? Uncontrolled setting of environment variables can be a security hazard. It is recommended that implementations exercise due care with requests to set environment variables, possibly including some form of fine-grained control over which variables may be set. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 27 06:02:05 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA18781 for ; Tue, 27 Nov 2001 06:02:05 -0500 (EST) Received: (qmail 20062 invoked by uid 605); 27 Nov 2001 11:02:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20055 invoked from network); 27 Nov 2001 11:01:57 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 27 Nov 2001 11:01:57 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18738; Tue, 27 Nov 2001 06:01:53 -0500 (EST) Message-Id: <200111271101.GAA18738@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-userauth-13.txt Date: Tue, 27 Nov 2001 06:01:52 -0500 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 : SSH Authentication Protocol Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-userauth-13.txt Pages : 15 Date : 26-Nov-01 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host- based client authentication methods. Additional authentication methods are described in separate documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-13.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-userauth-13.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-userauth-13.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: <20011126102059.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-userauth-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-userauth-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011126102059.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 27 06:02:36 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA18938 for ; Tue, 27 Nov 2001 06:02:35 -0500 (EST) Received: (qmail 20192 invoked by uid 605); 27 Nov 2001 11:02:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20110 invoked from network); 27 Nov 2001 11:02:01 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 27 Nov 2001 11:02:01 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18751; Tue, 27 Nov 2001 06:01:57 -0500 (EST) Message-Id: <200111271101.GAA18751@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-connect-13.txt Date: Tue, 27 Nov 2001 06:01:57 -0500 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 : SSH Connection Protocol Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-connect-13.txt Pages : 21 Date : 26-Nov-01 SSH is a protocol for secure remote login and other secure network services over an insecure network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-13.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-connect-13.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-connect-13.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: <20011126102113.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-connect-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-connect-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011126102113.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 27 06:03:21 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19017 for ; Tue, 27 Nov 2001 06:03:20 -0500 (EST) Received: (qmail 20342 invoked by uid 605); 27 Nov 2001 11:02:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20210 invoked from network); 27 Nov 2001 11:02:06 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 27 Nov 2001 11:02:06 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18773; Tue, 27 Nov 2001 06:02:02 -0500 (EST) Message-Id: <200111271102.GAA18773@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-architecture-11.txt Date: Tue, 27 Nov 2001 06:02:02 -0500 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 : SSH Protocol Architecture Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-architecture-11.txt Pages : 15 Date : 26-Nov-01 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-11.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-architecture-11.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-architecture-11.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: <20011126102129.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-architecture-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-architecture-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011126102129.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 27 06:03:34 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19039 for ; Tue, 27 Nov 2001 06:03:34 -0500 (EST) Received: (qmail 20592 invoked by uid 605); 27 Nov 2001 11:02:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20365 invoked from network); 27 Nov 2001 11:02:12 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 27 Nov 2001 11:02:12 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18797; Tue, 27 Nov 2001 06:02:08 -0500 (EST) Message-Id: <200111271102.GAA18797@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-transport-11.txt Date: Tue, 27 Nov 2001 06:02:08 -0500 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 : SSH Transport Layer Protocol Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-transport-11.txt Pages : 27 Date : 26-Nov-01 SSH is a protocol for secure remote login and other secure network services over an insecure network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-11.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-transport-11.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-transport-11.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: <20011126102141.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-transport-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-transport-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011126102141.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 27 11:03:08 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05802 for ; Tue, 27 Nov 2001 11:03:07 -0500 (EST) Received: (qmail 5562 invoked by uid 605); 27 Nov 2001 16:03:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5555 invoked from network); 27 Nov 2001 16:03:05 -0000 Received: from web14403.mail.yahoo.com (216.136.174.60) by mail.netbsd.org with SMTP; 27 Nov 2001 16:03:05 -0000 Message-ID: <20011127160304.93204.qmail@web14403.mail.yahoo.com> Received: from [194.176.223.193] by web14403.mail.yahoo.com via HTTP; Tue, 27 Nov 2001 16:03:04 GMT Date: Tue, 27 Nov 2001 16:03:04 +0000 (GMT) From: =?iso-8859-1?q?Peter=20M=20Boyd?= Subject: SecSH Server functionality on Windows - incomplete To: ietf-ssh@netbsd.org 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 As I understand it: The goal of the Secure Shell working group is to update and standardize the popular SSH protocol. The working group will attempt to assure that the SSH protocol o provides strong security against cryptanalysis and protocol attacks, o can work reasonably well without a global key management or certificate infrastructure, o can utilize existing certificate infrastructures (e.g., DNSSEC, SPKI, X.509) when available, o can be made easy to deploy and take into use, o requires minimum or no manual interaction from users, o is reasonably clean and simple to implement. The resulting protocol will operate over TCP/IP or other reliable but insecure transport. It is intended to be implemented at the application level. And yet as implemented in many, if not all, versions on Windows, SecSH cannot support the full Windows Shell capabilities. Examples: when using CMD.EXE as the Shell on Windows Servers, the simple text editor EDLIN cannot be used via SecSH to support its natural functionality that works in a local DOS Window browsing a file using 'pipe' into the 'more' function doesn't work via SecSH yet it does, of course, work locally CTRL&C does not interrupt a long running function via SecSH, which does work locally Have Windows implementors not understood what SecSH was intended to support? It seems to me that SecSH is good to *N*X Servers, is good as a tunnel between a Client program and a Server program, e.g. used with VNC but not good to a Shell in Windows ---- even if a *N*X Shell is used in Windows instead of CMD.EXE, the ablove deficiencies still apply Is this of any concern to the IETF? regards Peter M Boyd __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 27 11:07:45 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06038 for ; Tue, 27 Nov 2001 11:07:45 -0500 (EST) Received: (qmail 6585 invoked by uid 605); 27 Nov 2001 16:07:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6577 invoked from network); 27 Nov 2001 16:07:44 -0000 Received: from watsun.cc.columbia.edu (128.59.39.2) by mail.netbsd.org with SMTP; 27 Nov 2001 16:07:44 -0000 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id LAA11527; Tue, 27 Nov 2001 11:07:40 -0500 (EST) Date: Tue, 27 Nov 2001 11:07:32 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: =?iso-8859-1?q?Peter=20M=20Boyd?= Cc: ietf-ssh@netbsd.org Subject: Re: SecSH Server functionality on Windows - incomplete In-Reply-To: Your message of Tue, 27 Nov 2001 16:03:04 +0000 (GMT) Message-ID: Sender: ietf-ssh-owner@netbsd.org Precedence: list > Have Windows implementors not understood what SecSH > was intended to support? > > > It seems to me that SecSH is good to *N*X Servers, is > good as a tunnel between a Client program and a Server > program, e.g. used with VNC > > but not good to a Shell in Windows > > ---- even if a *N*X Shell is used in Windows instead > of CMD.EXE, the ablove deficiencies still apply > > > Is this of any concern to the IETF? This is no concern of the IETF. The Secure Shell working group is responsible for defining wire protocols. It is not responsible for platform specific implementation issues. The things you want done are much more difficult to implement on Windows than they are on Unix. However, they have been done to the limited extent possible for Telnet Servers and several of the companies that have sold decent (ok, acceptable) Telnet Servers are no selling SSH Servers with the same capabilities. I suggest you perform a web search. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 27 11:08:49 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06153 for ; Tue, 27 Nov 2001 11:08:48 -0500 (EST) Received: (qmail 7867 invoked by uid 605); 27 Nov 2001 16:08:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7846 invoked from network); 27 Nov 2001 16:08:24 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 27 Nov 2001 16:08:24 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id RAA09007; Tue, 27 Nov 2001 17:08:21 +0100 (MET) Date: Tue, 27 Nov 2001 17:08:20 +0100 From: Markus Friedl To: Peter M Boyd Cc: ietf-ssh@netbsd.org Subject: Re: SecSH Server functionality on Windows - incomplete Message-ID: <20011127170820.D8252@faui02> References: <20011127160304.93204.qmail@web14403.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011127160304.93204.qmail@web14403.mail.yahoo.com> User-Agent: Mutt/1.3.23i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Nov 27, 2001 at 04:03:04PM +0000, Peter M Boyd wrote: > ---- even if a *N*X Shell is used in Windows instead > of CMD.EXE, the ablove deficiencies still apply > [..] > Is this of any concern to the IETF? i don't see how this applies to the protocol. have you checked that the protocol disallows CTRL-C on Windows? have you checked your implementation for a bug? it seems this is an implementation issue and not a protocol issue. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 27 12:23:18 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11381 for ; Tue, 27 Nov 2001 12:23:17 -0500 (EST) Received: (qmail 2303 invoked by uid 605); 27 Nov 2001 17:23:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2296 invoked from network); 27 Nov 2001 17:23:12 -0000 Received: from ns2.pkiclue.com (HELO xena.pkiclue.com) (216.218.196.15) by mail.netbsd.org with SMTP; 27 Nov 2001 17:23:12 -0000 Received: from skylab3.tillerman.to (IDENT:root@localhost [127.0.0.1]) by xena.pkiclue.com (8.9.3/8.9.3) with ESMTP id JAA06847; Tue, 27 Nov 2001 09:25:01 -0800 Message-Id: <5.1.0.14.2.20011127091705.03577f60@127.0.0.1> X-Sender: rodney@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 27 Nov 2001 09:20:23 -0800 To: Peter M Boyd , ietf-ssh@netbsd.org From: Rodney Thayer Subject: Re: SecSH Server functionality on Windows - incomplete In-Reply-To: <20011127160304.93204.qmail@web14403.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ietf-ssh-owner@netbsd.org Precedence: list First, this is off topic for the IETF WG list. In another place, it'd be a fine and legitimate topic. The WG list is for the protocol, I believe. Check the charter if you disagree. a 'shell server' on a Windows box is a stretch, since that platform doesn't really support that paradigm. it's about the same as a shell server on a macintosh (e.g. no Redmond bashing required.) However, scp to a Windows box, or equivalent, to update a web site is tremendously more secure that something done insecurely (e.g. "PC Anywhere" style functionality with no security) I can't fire up a command shell on one win2k box from another, even if there's no security in the middle, so I don't think this is ssh's problem. At 04:03 PM 11/27/2001 +0000, Peter M Boyd wrote: >And yet as implemented in many, if not all, versions >on Windows, SecSH cannot support the full Windows >Shell capabilities. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 27 14:58:28 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22175 for ; Tue, 27 Nov 2001 14:58:27 -0500 (EST) Received: (qmail 12754 invoked by uid 605); 27 Nov 2001 19:58:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12745 invoked from network); 27 Nov 2001 19:58:24 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 27 Nov 2001 19:58:24 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21145; Tue, 27 Nov 2001 12:58:05 -0700 (MST) 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 OAA09913; Tue, 27 Nov 2001 14:58:22 -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 fARJwLU8014910; Tue, 27 Nov 2001 14:58:22 -0500 (EST) Message-Id: <200111271958.fARJwLU8014910@thunk.east.sun.com> From: Bill Sommerfeld To: =?iso-8859-1?q?Peter=20M=20Boyd?= cc: ietf-ssh@netbsd.org Subject: Re: SecSH Server functionality on Windows - incomplete In-Reply-To: Your message of "Tue, 27 Nov 2001 16:03:04 GMT." <20011127160304.93204.qmail@web14403.mail.yahoo.com> Reply-to: sommerfeld@east.sun.com Date: Tue, 27 Nov 2001 14:58:21 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > Is this of any concern to the IETF? Peter, It's a quality-of-implementation issue. As others have pointed out, this is (as best as I can tell) not a problem with the protocol specification, but a limitation of either certain implementations of the SSH service on Microsoft OS's or of the MS OS's themselves. As such, it's out of scope for this working group. It sounds like you've pointed out a few bugs or missing features, and I'd encourage any or all of the implementors for M$ OS's listening here to take these to heart. On the other hand, if the implementors-for-M$ can identify specific difficulties with the *wire protocol*, I'm all ears... - Bill Working Group chair, IETF SECSH WG From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Nov 27 21:15:28 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03005 for ; Tue, 27 Nov 2001 21:15:27 -0500 (EST) Received: (qmail 22555 invoked by uid 605); 28 Nov 2001 02:13:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22548 invoked from network); 28 Nov 2001 02:13:18 -0000 Received: from centaur.acm.jhu.edu (128.220.223.65) by mail.netbsd.org with SMTP; 28 Nov 2001 02:13:18 -0000 Received: from sol.galaxy.acm.jhu.edu (typhon.acm.jhu.edu [128.220.223.231]) by centaur.acm.jhu.edu (Postfix) with ESMTP id 45BD41435B; Tue, 27 Nov 2001 21:13:12 -0500 (EST) Received: by sol.galaxy.acm.jhu.edu (Postfix, from userid 528) id 4E25CD8C9; Tue, 27 Nov 2001 21:13:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by sol.galaxy.acm.jhu.edu (Postfix) with ESMTP id 3BE3878B0; Tue, 27 Nov 2001 21:13:11 -0500 (EST) Date: Tue, 27 Nov 2001 21:13:11 -0500 (EST) From: Jack Lloyd X-Sender: To: Rodney Thayer Cc: Peter M Boyd , Subject: Re: SecSH Server functionality on Windows - incomplete In-Reply-To: <5.1.0.14.2.20011127091705.03577f60@127.0.0.1> Message-ID: X-GPG-Key-ID: 4DCDF398 X-GPG-Key-Fingerprint: 2DD2 95F9 C7E3 A15E AF29 80E1 D6A9 A5B9 4DCD F398 X-Red-Robot-Approved: CRUSH ALL HU-MANS! Organization: JHU ACM/CS/CIRL MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 27 Nov 2001, Rodney Thayer wrote: > a 'shell server' on a Windows box is a stretch, > since that platform doesn't really support that paradigm. > it's about the same as a shell server on a macintosh > (e.g. no Redmond bashing required.) Unless, of course, you're running MacOS X. ;) Sorry, couldn't help myself... -J From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 28 17:51:05 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21403 for ; Wed, 28 Nov 2001 17:51:05 -0500 (EST) Received: (qmail 28499 invoked by uid 605); 28 Nov 2001 22:51:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28489 invoked from network); 28 Nov 2001 22:51:00 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 28 Nov 2001 22:51:00 -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 OAA20521; Wed, 28 Nov 2001 14:50:57 -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 RAA07481; Wed, 28 Nov 2001 17:50:49 -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 fASMomU8027789; Wed, 28 Nov 2001 17:50:49 -0500 (EST) Message-Id: <200111282250.fASMomU8027789@thunk.east.sun.com> From: Bill Sommerfeld To: Simon Tatham cc: ietf-ssh@netbsd.org Subject: Re: des-cbc cipher In-Reply-To: Your message of "Thu, 22 Nov 2001 09:34:52 GMT." Reply-to: sommerfeld@east.sun.com Date: Wed, 28 Nov 2001 17:50:48 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On this issue, it looks like we have consensus that: - there should be no mention of a des-cbc algorithm in the spec. - implementations should treat algorithms they don't know about the same as they treat algorithms they've been told not to use. - Bill [I'm somewhat bemused by this because I distinctly remember seeing a certain ssh implementor standing up in front of an IETF WG meeting a few years ago saying that ssh-the-program would never support weak crypto] From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 28 17:58:57 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21977 for ; Wed, 28 Nov 2001 17:58:56 -0500 (EST) Received: (qmail 29616 invoked by uid 605); 28 Nov 2001 22:58:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29609 invoked from network); 28 Nov 2001 22:58:56 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 28 Nov 2001 22:58:56 -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 OAA24065 for ; Wed, 28 Nov 2001 14:58:54 -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 RAA08727 for ; Wed, 28 Nov 2001 17:58:48 -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 fASMwmU8028190 for ; Wed, 28 Nov 2001 17:58:48 -0500 (EST) Message-Id: <200111282258.fASMwmU8028190@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: core draft last call coming Real Soon Now. Reply-to: sommerfeld@east.sun.com Date: Wed, 28 Nov 2001 17:58:48 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Just FYI, as soon as one more draft shows up, i'll be starting the formal working group Last Call on the core drafts. Let's see if we can converge this time... - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 28 19:56:13 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01397 for ; Wed, 28 Nov 2001 19:56:12 -0500 (EST) Received: (qmail 23323 invoked by uid 605); 29 Nov 2001 00:56:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23316 invoked from network); 29 Nov 2001 00:56:09 -0000 Received: from inet.org (HELO gnat.inet.org) (63.108.254.91) by mail.netbsd.org with SMTP; 29 Nov 2001 00:56:09 -0000 Received: from mosquito.inet.org (unknown [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 7BB4E67103; Wed, 28 Nov 2001 20:02:30 -0500 (EST) Message-Id: <5.1.0.14.2.20011128194352.00a05510@10.30.15.3> X-Sender: rja@10.30.15.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 28 Nov 2001 19:46:23 -0500 To: sommerfeld@east.sun.com From: RJ Atkinson Subject: Re: des-cbc cipher Cc: ietf-ssh@netbsd.org In-Reply-To: <200111282250.fASMomU8027789@thunk.east.sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 17:50 28/11/01, Bill Sommerfeld wrote: >On this issue, it looks like we have consensus that: > > - there should be no mention of a des-cbc algorithm in the spec. > > - implementations should treat algorithms they don't know about the >same as they treat algorithms they've been told not to use. Pardon ? I haven't seen this thread in some while. I really disagree with the first conclusion. DES-CBC is widely deployed with SSHv2 right now, so it ought to be mentioned. That way a new implementer has a good chance of interoperating with the installed base. Paranoid folks should kindly note well that I'm not saying ANYTHING about what should be the recommended or default algorithm used with SSHv2. Yours, Ran rja@inet.org From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 28 20:07:27 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02169 for ; Wed, 28 Nov 2001 20:07:26 -0500 (EST) Received: (qmail 25567 invoked by uid 605); 29 Nov 2001 01:07:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25560 invoked from network); 29 Nov 2001 01:07:25 -0000 Received: from intern12.lnk.telstra.net (HELO shitei.mindrot.org) (139.130.53.38) by mail.netbsd.org with SMTP; 29 Nov 2001 01:07:25 -0000 Received: from mothra.mindrot.org (mothra.mindrot.org [203.44.118.225]) by shitei.mindrot.org (Postfix) with ESMTP id 50DE72DF08; Thu, 29 Nov 2001 12:07:23 +1100 (EST) Received: from localhost (djm@localhost) by mothra.mindrot.org (8.11.6/8.11.6) with ESMTP id fAT17N928884; Thu, 29 Nov 2001 12:07:23 +1100 X-Authentication-Warning: mothra.mindrot.org: djm owned process doing -bs Date: Thu, 29 Nov 2001 12:07:23 +1100 (EST) From: Damien Miller To: RJ Atkinson Cc: , Subject: Re: des-cbc cipher In-Reply-To: <5.1.0.14.2.20011128194352.00a05510@10.30.15.3> 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 Wed, 28 Nov 2001, RJ Atkinson wrote: > At 17:50 28/11/01, Bill Sommerfeld wrote: > >On this issue, it looks like we have consensus that: > > > > - there should be no mention of a des-cbc algorithm in the spec. > > > > - implementations should treat algorithms they don't know about the > >same as they treat algorithms they've been told not to use. > > Pardon ? > > I haven't seen this thread in some while. I really disagree with the > first conclusion. DES-CBC is widely deployed with SSHv2 right now, > so it ought to be mentioned. That way a new implementer has a good > chance of interoperating with the installed base. They will interop just fine if they follow Bill's second point and ignore des-cbc. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 28 20:09:22 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02337 for ; Wed, 28 Nov 2001 20:09:22 -0500 (EST) Received: (qmail 25963 invoked by uid 605); 29 Nov 2001 01:09:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25956 invoked from network); 29 Nov 2001 01:09:21 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 29 Nov 2001 01:09:21 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA25402; Wed, 28 Nov 2001 18:09:02 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id RAA04871; Wed, 28 Nov 2001 17:09:36 -0800 (PST) Received: from quirm (dsl-192-32.Eng.Sun.COM [129.146.192.32]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with SMTP id fAT19Dba989626; Wed, 28 Nov 2001 17:09:17 -0800 (PST) Message-Id: <200111290109.fAT19Dba989626@jurassic.eng.sun.com> Date: Wed, 28 Nov 2001 17:08:54 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: des-cbc cipher To: sommerfeld@east.sun.com, rja@inet.org Cc: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4t0EE2CrLZSlXuU2fGSkfQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >At 17:50 28/11/01, Bill Sommerfeld wrote: >>On this issue, it looks like we have consensus that: >> >> - there should be no mention of a des-cbc algorithm in the spec. >> >> - implementations should treat algorithms they don't know about the >>same as they treat algorithms they've been told not to use. > >Pardon ? > >I haven't seen this thread in some while. I really disagree with the >first conclusion. DES-CBC is widely deployed with SSHv2 right now, >so it ought to be mentioned. That way a new implementer has a good Only the SSHv2 client and server software from SSH Inc supports DES-CBC all other support the mandatory 3DES-CBC algorithm. 3DES != DES. >chance of interoperating with the installed base. Paranoid folks should >kindly note well that I'm not saying ANYTHING about what should be the >recommended or default algorithm used with SSHv2. Since any compliant implementation MUST have 3DES-CBC they will always interoperate providing the admin doesn't turn off 3DES. I agree with the original statment there should be no mention of des-cbc in the spec and implementions that don't support will correctly ignore it if they are correctly implementing the spec. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 28 20:49:15 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05563 for ; Wed, 28 Nov 2001 20:49:15 -0500 (EST) Received: (qmail 7764 invoked by uid 605); 29 Nov 2001 01:49:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7575 invoked from network); 29 Nov 2001 01:48:57 -0000 Received: from inet.org (HELO gnat.inet.org) (63.108.254.91) by mail.netbsd.org with SMTP; 29 Nov 2001 01:48:57 -0000 Received: from mosquito.inet.org (unknown [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 9B99667103; Wed, 28 Nov 2001 20:55:42 -0500 (EST) Message-Id: <5.1.0.14.2.20011128203852.009f9700@10.30.15.3> X-Sender: rja@10.30.15.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 28 Nov 2001 20:39:35 -0500 To: Damien Miller From: RJ Atkinson Subject: Re: des-cbc cipher Cc: In-Reply-To: References: <5.1.0.14.2.20011128194352.00a05510@10.30.15.3> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 20:07 28/11/01, Damien Miller wrote: >They will interop just fine if they follow Bill's second point and >ignore des-cbc. Not accurate. They won't be able to talk with remote end systems that want to talk des-cbc, which is the definition of interoperability that matters here. Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 28 20:53:19 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05935 for ; Wed, 28 Nov 2001 20:53:18 -0500 (EST) Received: (qmail 8965 invoked by uid 605); 29 Nov 2001 01:53:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8958 invoked from network); 29 Nov 2001 01:53:18 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 29 Nov 2001 01:53:18 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19301; Wed, 28 Nov 2001 18:52:59 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.45]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id RAA14764; Wed, 28 Nov 2001 17:53:33 -0800 (PST) Received: from quirm (dsl-192-32.Eng.Sun.COM [129.146.192.32]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with SMTP id fAT1rCEu995870; Wed, 28 Nov 2001 17:53:15 -0800 (PST) Message-Id: <200111290153.fAT1rCEu995870@jurassic.eng.sun.com> Date: Wed, 28 Nov 2001 17:52:52 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: des-cbc cipher To: rja@inet.org Cc: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: sgRKkjQNSufdo99ObR3pkA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >At 20:07 28/11/01, Damien Miller wrote: >>They will interop just fine if they follow Bill's second point and >>ignore des-cbc. > >Not accurate. They won't be able to talk with remote end systems that >want to talk des-cbc, which is the definition of interoperability that >matters here. Since 3DES-CBC is the MANDATORY algorithm all implementations that comply with the spec will have it, therefore it is an admin choice to disable 3DES-CBC in favour of DES-CBC thus the admin should only do this if they know that all connecting clients will provide the weak DES-CBC method. To my knowlege only SSH Inc code supplies DES-CBC, and I don't believe all of their engineers agree with doing so. Why is DES-CBC so important to you ? -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 28 20:53:55 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05978 for ; Wed, 28 Nov 2001 20:53:55 -0500 (EST) Received: (qmail 9297 invoked by uid 605); 29 Nov 2001 01:53:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9288 invoked from network); 29 Nov 2001 01:53:54 -0000 Received: from inet.org (HELO gnat.inet.org) (63.108.254.91) by mail.netbsd.org with SMTP; 29 Nov 2001 01:53:54 -0000 Received: from mosquito.inet.org (unknown [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 3C1B367103; Wed, 28 Nov 2001 21:00:39 -0500 (EST) Message-Id: <5.1.0.14.2.20011128203942.009f95f0@10.30.15.3> X-Sender: rja@10.30.15.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 28 Nov 2001 20:44:33 -0500 To: Darren Moffat From: RJ Atkinson Subject: Re: des-cbc cipher Cc: ietf-ssh@netbsd.org In-Reply-To: <200111290109.fAT19Dba989626@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 20:08 28/11/01, Darren Moffat wrote: >Only the SSHv2 client and server software from SSH Inc supports >DES-CBC all other support the mandatory 3DES-CBC algorithm. Not relevant to my point in any event. And I think that's wrong anyway, since I know of at least one other that supports DES-CBC. >Since any compliant implementation MUST have 3DES-CBC they will always >interoperate providing the admin doesn't turn off 3DES. Nope. Interoperability here means able to talk DES-CBC when desired to with another implementation that supports DES-CBC. Note that it buys absolutely zero benefit to the user to leave DES-CBC undocumented. It won't make folks use 3DES, for example. It just means that the poor sod trying to implement a fully interoperable SSHv2 client/server will have to try to reverse engineer the details unique to DES-CBC. If folks are having religion about DES-CBC, put the few relevant details in an Appendix, mark it as purely informational or even not recommended, but don't omit documentation that's already known to the community... Oh, and yes, I have commit access to an SSHv2 implementation, so please count these as implementer comments. Ran rja@inet.org From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 28 21:08:55 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07052 for ; Wed, 28 Nov 2001 21:08:55 -0500 (EST) Received: (qmail 12663 invoked by uid 605); 29 Nov 2001 02:08:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12656 invoked from network); 29 Nov 2001 02:08:54 -0000 Received: from inet.org (HELO gnat.inet.org) (63.108.254.91) by mail.netbsd.org with SMTP; 29 Nov 2001 02:08:54 -0000 Received: from mosquito.inet.org (unknown [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 1BEF467103; Wed, 28 Nov 2001 21:15:37 -0500 (EST) Message-Id: <5.1.0.14.2.20011128205528.00ac19b0@10.30.15.3> X-Sender: rja@10.30.15.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 28 Nov 2001 20:59:29 -0500 To: Darren Moffat From: RJ Atkinson Subject: Re: des-cbc cipher Cc: ietf-ssh@netbsd.org In-Reply-To: <200111290153.fAT1rCEu995870@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 20:52 28/11/01, Darren Moffat wrote: >>At 20:07 28/11/01, Damien Miller wrote: >>>They will interop just fine if they follow Bill's second point and >>>ignore des-cbc. >> >>Not accurate. They won't be able to talk with remote end systems that >>want to talk des-cbc, which is the definition of interoperability that >>matters here. > >Since 3DES-CBC is the MANDATORY algorithm all implementations that >comply with the spec will have it, therefore it is an admin choice to >disable 3DES-CBC in favour of DES-CBC thus the admin should only do this >if they know that all connecting clients will provide the weak DES-CBC >method. You are trying to decide someone else's policy for them. Policy requirements on operators are outside the scope of the IETF. Not appropriate for this list or another IETF list. Recommendations to operators are fine and normal (e.g. "don't use DES because ...") but levying policy requirements on network operators aren't fine or normal in the IETF since we just define protocols here. >To my knowlege only SSH Inc code supplies DES-CBC, and I don't believe >all of their engineers agree with doing so. > >Why is DES-CBC so important to you ? DES isn't the issue per se, despite the attempts of you and some to cloud the interoperability issue. Broad interoperability of any IETF standards-track protocol is crucially important to me. That alone justifies documenting how DES-CBC works, even if it is marked as deprecated, optional-to-implement, or what have you. (And I don't care if those sorts of recommendations are made, provided it is clearly documented in the RFC). Ran rja@inet.org From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 28 21:15:14 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07513 for ; Wed, 28 Nov 2001 21:15:14 -0500 (EST) Received: (qmail 14247 invoked by uid 605); 29 Nov 2001 02:15:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14205 invoked from network); 29 Nov 2001 02:15:07 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 29 Nov 2001 02:15:07 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA00525; Wed, 28 Nov 2001 19:14:48 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.45]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id SAA20162; Wed, 28 Nov 2001 18:15:22 -0800 (PST) Received: from quirm (dsl-192-32.Eng.Sun.COM [129.146.192.32]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with SMTP id fAT2F1Eu998747; Wed, 28 Nov 2001 18:15:04 -0800 (PST) Message-Id: <200111290215.fAT2F1Eu998747@jurassic.eng.sun.com> Date: Wed, 28 Nov 2001 18:14:41 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: des-cbc cipher To: rja@inet.org Cc: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: B9fsHDTkQYT56tSEqHMDew== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >DES isn't the issue per se, despite the attempts of you and some >to cloud the interoperability issue. Broad interoperability of I'm certainly not trying to cloud the issue and I don't think others are either. Myself and others are only pointing out that the protocol already allows for additional algorithms and implementing des-cbc is certainly possible using that mechanism. Nothing addtional has to be added to the drafts to add the functionality. >any IETF standards-track protocol is crucially important to me. >That alone justifies documenting how DES-CBC works, even if it is >marked as deprecated, optional-to-implement, or what have you. >(And I don't care if those sorts of recommendations are made, >provided it is clearly documented in the RFC). Given the reaction to this on the list I doubt you are going to get consensus - but I maybe wrong. I suggest you log a personal submission that references the relevant sections from the core drafts, you could then ask if the secsh-wg is willing to take it on as a working group draft. Since we are trying to get last call on the core drafts it is unfortunate timing regardless of the issues of appropriateness, but not too late if you get agreement from the group. I suggest this be brought up at the SLC IETF meeting as an agenda item. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 28 21:28:55 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA08544 for ; Wed, 28 Nov 2001 21:28:55 -0500 (EST) Received: (qmail 17571 invoked by uid 605); 29 Nov 2001 02:28:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17560 invoked from network); 29 Nov 2001 02:28:54 -0000 Received: from edinburgh.cisco.com (HELO cisco.com) (144.254.112.76) by mail.netbsd.org with SMTP; 29 Nov 2001 02:28:54 -0000 Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id CAA09059 for ietf-ssh@netbsd.org; Thu, 29 Nov 2001 02:28:22 GMT Date: Thu, 29 Nov 2001 02:28:22 +0000 From: Derek Fawcus To: ietf-ssh@netbsd.org Subject: Re: des-cbc cipher Message-ID: <20011129022822.B8866@edinburgh.cisco.com> References: <200111290215.fAT2F1Eu998747@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200111290215.fAT2F1Eu998747@jurassic.eng.sun.com>; from Darren.Moffat@eng.sun.com on Wed, Nov 28, 2001 at 06:14:41PM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Nov 28, 2001 at 06:14:41PM -0800, Darren Moffat wrote: > > >any IETF standards-track protocol is crucially important to me. > >That alone justifies documenting how DES-CBC works, even if it is > >marked as deprecated, optional-to-implement, or what have you. > >(And I don't care if those sorts of recommendations are made, > >provided it is clearly documented in the RFC). > > Given the reaction to this on the list I doubt you are going to get > consensus - but I maybe wrong. I suggest you log a personal submission > that references the relevant sections from the core drafts, you could > then ask if the secsh-wg is willing to take it on as a working group draft. I'd be rather inclined to object to having des-cbc (or des-anything) in the core specs, if for no other reason than to reduce the size of the documents. I'd certainly have no objection to it being documented in an seperate informational RFC. DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 28 21:32:05 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA08832 for ; Wed, 28 Nov 2001 21:32:04 -0500 (EST) Received: (qmail 18294 invoked by uid 605); 29 Nov 2001 02:32:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18287 invoked from network); 29 Nov 2001 02:32:03 -0000 Received: from edinburgh.cisco.com (HELO cisco.com) (144.254.112.76) by mail.netbsd.org with SMTP; 29 Nov 2001 02:32:03 -0000 Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id CAA09116 for ietf-ssh@netbsd.org; Thu, 29 Nov 2001 02:31:32 GMT Date: Thu, 29 Nov 2001 02:31:32 +0000 From: Derek Fawcus To: ietf-ssh@netbsd.org Subject: Re: des-cbc cipher Message-ID: <20011129023132.C8866@edinburgh.cisco.com> References: <200111290153.fAT1rCEu995870@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200111290153.fAT1rCEu995870@jurassic.eng.sun.com>; from Darren.Moffat@eng.sun.com on Wed, Nov 28, 2001 at 05:52:52PM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Nov 28, 2001 at 05:52:52PM -0800, Darren Moffat wrote: > Since 3DES-CBC is the MANDATORY algorithm all implementations that > comply with the spec will have it, I've started knocking up an implementation (don't know yet if I'll finish it so no promises...), but I've currently got no intention of implementing any of the DES varients. So that'll mean this implementation will not be complient, but what the heck - I don't like DES! DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 28 21:45:32 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA10946 for ; Wed, 28 Nov 2001 21:45:32 -0500 (EST) Received: (qmail 19747 invoked by uid 605); 29 Nov 2001 02:45:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19740 invoked from network); 29 Nov 2001 02:45:32 -0000 Received: from inet.org (HELO gnat.inet.org) (63.108.254.91) by mail.netbsd.org with SMTP; 29 Nov 2001 02:45:32 -0000 Received: from mosquito.inet.org (unknown [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 18D1C67103; Wed, 28 Nov 2001 21:52:17 -0500 (EST) Message-Id: <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> X-Sender: rja@10.30.15.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 28 Nov 2001 21:36:09 -0500 To: Darren Moffat From: RJ Atkinson Subject: Re: des-cbc cipher Cc: ietf-ssh@netbsd.org In-Reply-To: <200111290215.fAT2F1Eu998747@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 21:14 28/11/01, Darren Moffat wrote: >I'm certainly not trying to cloud the issue >and I don't think others are either. Darren, Kindly put the shoe on the other foot for a moment. What problem is solved by omitting the DES-CBC information from the drafts ? Are we saving bytes on a disk or what ? Ran rja@inet.org From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 28 21:50:18 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11249 for ; Wed, 28 Nov 2001 21:50:17 -0500 (EST) Received: (qmail 22482 invoked by uid 605); 29 Nov 2001 02:50:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22475 invoked from network); 29 Nov 2001 02:50:16 -0000 Received: from intern12.lnk.telstra.net (HELO shitei.mindrot.org) (139.130.53.38) by mail.netbsd.org with SMTP; 29 Nov 2001 02:50:16 -0000 Received: from mothra.mindrot.org (mothra.mindrot.org [203.44.118.225]) by shitei.mindrot.org (Postfix) with ESMTP id 459B02DF0F; Thu, 29 Nov 2001 13:50:14 +1100 (EST) Received: from localhost (djm@localhost) by mothra.mindrot.org (8.11.6/8.11.6) with ESMTP id fAT2oE929245; Thu, 29 Nov 2001 13:50:14 +1100 X-Authentication-Warning: mothra.mindrot.org: djm owned process doing -bs Date: Thu, 29 Nov 2001 13:50:14 +1100 (EST) From: Damien Miller To: RJ Atkinson Cc: Darren Moffat , Subject: Re: des-cbc cipher In-Reply-To: <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> 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 Wed, 28 Nov 2001, RJ Atkinson wrote: > Kindly put the shoe on the other foot for a moment. > What problem is solved by omitting the DES-CBC information > from the drafts ? Are we saving bytes on a disk or what ? What benefit is obtained from enshrining a known insecure transform in the protocol? -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 28 22:35:34 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15113 for ; Wed, 28 Nov 2001 22:35:34 -0500 (EST) Received: (qmail 330 invoked by uid 605); 29 Nov 2001 03:35:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 322 invoked from network); 29 Nov 2001 03:35:33 -0000 Received: from inet.org (HELO gnat.inet.org) (63.108.254.91) by mail.netbsd.org with SMTP; 29 Nov 2001 03:35:33 -0000 Received: from mosquito.inet.org (unknown [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 2857D67103; Wed, 28 Nov 2001 22:42:19 -0500 (EST) Message-Id: <5.1.0.14.2.20011128222301.009f16e0@10.30.15.3> X-Sender: rja@10.30.15.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 28 Nov 2001 22:26:11 -0500 To: Damien Miller From: RJ Atkinson Subject: Re: des-cbc cipher Cc: In-Reply-To: References: <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 21:50 28/11/01, Damien Miller wrote: >On Wed, 28 Nov 2001, RJ Atkinson wrote: > >> Kindly put the shoe on the other foot for a moment. >> What problem is solved by omitting the DES-CBC information >> from the drafts ? Are we saving bytes on a disk or what ? Damian, Kindly answer the question posed. Are we saving bytes ? Or is your goal to make it impossible for folks to use DES-CBC because you think you know more than they do about their situation and threat environment ? And by the way, all algorithms are insecure. And the low-cost attacks on SSHv2 aren't brute force and don't vary with the algorithm in use (try reading Ross Anderson's paper on "Why Cryptosystems Fail" if any of this seems confusing). Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Nov 28 22:53:31 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16600 for ; Wed, 28 Nov 2001 22:53:31 -0500 (EST) Received: (qmail 3012 invoked by uid 605); 29 Nov 2001 03:53:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3005 invoked from network); 29 Nov 2001 03:53:29 -0000 Received: from intern12.lnk.telstra.net (HELO shitei.mindrot.org) (139.130.53.38) by mail.netbsd.org with SMTP; 29 Nov 2001 03:53:29 -0000 Received: from mothra.mindrot.org (mothra.mindrot.org [203.44.118.225]) by shitei.mindrot.org (Postfix) with ESMTP id BFA2D2DF0F; Thu, 29 Nov 2001 14:53:26 +1100 (EST) Received: from localhost (djm@localhost) by mothra.mindrot.org (8.11.6/8.11.6) with ESMTP id fAT3rQ729605; Thu, 29 Nov 2001 14:53:26 +1100 X-Authentication-Warning: mothra.mindrot.org: djm owned process doing -bs Date: Thu, 29 Nov 2001 14:53:26 +1100 (EST) From: Damien Miller To: RJ Atkinson Cc: Subject: Re: des-cbc cipher In-Reply-To: <5.1.0.14.2.20011128222301.009f16e0@10.30.15.3> 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 Wed, 28 Nov 2001, RJ Atkinson wrote: > Kindly answer the question posed. Are we saving bytes ? Your question was not posed to me, but since you asked: I would prefer that we do not make further unnecessary changes to the drafts at this late stage, especially when such changes are obviously controversial. > Or is your goal to make it impossible for folks to use DES-CBC > because you think you know more than they do about their situation > and threat environment ? The protocol includes an extension mechanism which allows you to implement des-cbc for those few cases where it may be appropriate. There is nothing stopping you, or another interested party from agreeing on an implementation and advancing that separately. > And by the way, all algorithms are insecure. Some are even more insecure than others. > attacks on SSHv2 aren't brute force and don't vary with the algorithm > in use (try reading Ross Anderson's paper on "Why Cryptosystems Fail" > if any of this seems confusing). If there are feasible attacks against the protocol which require a similar or lesser order of work than breaking DES, then I'd certainly like to know about them - please share. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 03:44:27 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA16144 for ; Thu, 29 Nov 2001 03:44:26 -0500 (EST) Received: (qmail 7035 invoked by uid 605); 29 Nov 2001 08:43:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7028 invoked from network); 29 Nov 2001 08:43:52 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 29 Nov 2001 08:43:52 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id JAA28026; Thu, 29 Nov 2001 09:43:41 +0100 (MET) Date: Thu, 29 Nov 2001 09:43:41 +0100 From: Markus Friedl To: RJ Atkinson Cc: Darren Moffat , ietf-ssh@netbsd.org Subject: Re: des-cbc cipher Message-ID: <20011129094341.B27343@faui02> References: <200111290215.fAT2F1Eu998747@jurassic.eng.sun.com> <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> User-Agent: Mutt/1.3.23i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Nov 28, 2001 at 09:36:09PM -0500, RJ Atkinson wrote: > Kindly put the shoe on the other foot for a moment. > What problem is solved by omitting the DES-CBC information > from the drafts ? Are we saving bytes on a disk or what ? Adding "des-cbc" to the draft encourages use of DES-CBC. However, if you need to have DES-CBC, write a document, use "des-cbc@inet.org" and everything will be fine. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 06:12:52 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21491 for ; Thu, 29 Nov 2001 06:12:52 -0500 (EST) Received: (qmail 1171 invoked by uid 605); 29 Nov 2001 11:12:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1164 invoked from network); 29 Nov 2001 11:12:51 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 29 Nov 2001 11:12:51 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21418; Thu, 29 Nov 2001 06:12:31 -0500 (EST) Message-Id: <200111291112.GAA21418@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-connect-14.txt Date: Thu, 29 Nov 2001 06:12:31 -0500 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 : SSH Connection Protocol Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-connect-14.txt Pages : 21 Date : 28-Nov-01 SSH is a protocol for secure remote login and other secure network services over an insecure network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-14.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-connect-14.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-connect-14.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: <20011128145429.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-connect-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-connect-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011128145429.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 10:23:57 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11770 for ; Thu, 29 Nov 2001 10:23:56 -0500 (EST) Received: (qmail 17700 invoked by uid 605); 29 Nov 2001 15:23:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17693 invoked from network); 29 Nov 2001 15:23:24 -0000 Received: from inet.org (HELO gnat.inet.org) (63.108.254.91) by mail.netbsd.org with SMTP; 29 Nov 2001 15:23:24 -0000 Received: from mosquito.inet.org (unknown [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id AA90367103; Thu, 29 Nov 2001 10:30:13 -0500 (EST) Message-Id: <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3> X-Sender: rja@10.30.15.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 29 Nov 2001 10:14:03 -0500 To: Markus Friedl From: RJ Atkinson Subject: Re: des-cbc cipher Cc: ietf-ssh@netbsd.org In-Reply-To: <20011129094341.B27343@faui02> References: <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <200111290215.fAT2F1Eu998747@jurassic.eng.sun.com> <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 03:43 29/11/01, Markus Friedl wrote: >However, if you need to have DES-CBC, write a document, >use "des-cbc@inet.org" and everything will be fine. Regrettably, that doesn't help at all -- because it doesn't document how to implement such that one can interoperate with the installed base of DES-CBC implementations of SSHv2. There are multiple such implementations and an installed base of users. I'd REALLY prefer to resolve this in the WG. I've tried to propose several forms of packaging that would both let the technical detail get documented and also let folks who have passion against DES-CBC document their issues/concerns/recommendations and also make it crystal clear that DES-CBC isn't something an implementation is expected to support. If we can't resolve this issue here, then an appeal is likely -- which will necessarily delay the documents substantially (delay being explicitly NOT my objective). Sigh. Yours, Ran rja@inet.org From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 10:29:45 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12720 for ; Thu, 29 Nov 2001 10:29:44 -0500 (EST) Received: (qmail 19174 invoked by uid 605); 29 Nov 2001 15:29:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19167 invoked from network); 29 Nov 2001 15:29:41 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 29 Nov 2001 15:29:41 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id QAA28756; Thu, 29 Nov 2001 16:29:38 +0100 (MET) Date: Thu, 29 Nov 2001 16:29:38 +0100 From: Markus Friedl To: RJ Atkinson Cc: ietf-ssh@netbsd.org Subject: Re: des-cbc cipher Message-ID: <20011129162938.D14394@faui02> References: <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <200111290215.fAT2F1Eu998747@jurassic.eng.sun.com> <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3> User-Agent: Mutt/1.3.23i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Nov 29, 2001 at 10:14:03AM -0500, RJ Atkinson wrote: > At 03:43 29/11/01, Markus Friedl wrote: > >However, if you need to have DES-CBC, write a document, > >use "des-cbc@inet.org" and everything will be fine. > > Regrettably, that doesn't help at all -- because it doesn't document > how to implement such that one can interoperate with the installed base > of DES-CBC implementations of SSHv2. There are multiple such > implementations and an installed base of users. but these implementations violate the drafts if they use "des-cbc". they must use "des-cbc@domain". if i add some cipher to openssh without a "@", will the working group add the cipher to the drafts? i don't think so. > I'd REALLY prefer to resolve this in the WG. I've tried to > propose several forms of packaging that would both let the technical > detail get documented and also let folks who have passion against > DES-CBC document their issues/concerns/recommendations and also make > it crystal clear that DES-CBC isn't something an implementation is > expected to support. If we can't resolve this issue here, then an appeal > is likely -- which will necessarily delay the documents substantially > (delay being explicitly NOT my objective). Sigh. i don't think it's the job of the WG to add a specification just because some broken implemenations violate the draft. the drafts should not try to describe all existing implemenations and their bugs. or am i missing something? -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 10:29:56 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12763 for ; Thu, 29 Nov 2001 10:29:56 -0500 (EST) Received: (qmail 19312 invoked by uid 605); 29 Nov 2001 15:29:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19265 invoked from network); 29 Nov 2001 15:29:44 -0000 Received: from edinburgh.cisco.com (HELO cisco.com) (144.254.112.76) by mail.netbsd.org with SMTP; 29 Nov 2001 15:29:44 -0000 Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id PAA21760; Thu, 29 Nov 2001 15:29:05 GMT Date: Thu, 29 Nov 2001 15:29:05 +0000 From: Derek Fawcus To: RJ Atkinson Cc: ietf-ssh@netbsd.org Subject: Re: des-cbc cipher Message-ID: <20011129152904.F16432@edinburgh.cisco.com> References: <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <200111290215.fAT2F1Eu998747@jurassic.eng.sun.com> <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <20011129094341.B27343@faui02> <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3>; from rja@inet.org on Thu, Nov 29, 2001 at 10:14:03AM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Nov 29, 2001 at 10:14:03AM -0500, RJ Atkinson wrote: > At 03:43 29/11/01, Markus Friedl wrote: > >However, if you need to have DES-CBC, write a document, > >use "des-cbc@inet.org" and everything will be fine. > > Regrettably, that doesn't help at all -- because it doesn't document > how to implement such that one can interoperate with the installed base > of DES-CBC implementations of SSHv2. Is it the name of the protocol that's the issue 'des-cbc' vs 'des-cbc@somthing', or that you want this in the base docs? I'd have thougth an Informational RFC (wg owned or not - I'm not bothered) would have been sufficient. > There are multiple such implementations and an installed base of users. Hmm - Is one of them by any chance Cisco routers when using a 'export' version of crypto code? i.e. DES instead of 3DES. DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 10:30:10 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12855 for ; Thu, 29 Nov 2001 10:30:10 -0500 (EST) Received: (qmail 19536 invoked by uid 605); 29 Nov 2001 15:29:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19506 invoked from network); 29 Nov 2001 15:29:51 -0000 Received: from mail.iamx.com (166.84.156.6) by mail.netbsd.org with SMTP; 29 Nov 2001 15:29:51 -0000 Received: from columbia.edu (dhcp-085.iamx.com [166.84.156.85]) by mail.iamx.com (8.12.1/8.12.1) with ESMTP id fATFRpIG024860 for ; Thu, 29 Nov 2001 10:27:55 -0500 Message-ID: <3C065441.6000207@columbia.edu> Date: Thu, 29 Nov 2001 10:29:05 -0500 From: Jeffrey Altman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-ssh@netbsd.org Subject: Re: des-cbc cipher References: <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <200111290215.fAT2F1Eu998747@jurassic.eng.sun.com> <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit The way this should be handled in the IETF is to publish the deprecated functionality as a separate Historical RFC. This documents the required functionality to provide backward compatibility and indicates in no uncertain terms that the functionality should no longer be used. Isn't this what we agreed should be done for the SSHv1 protocol? - Jeff RJ Atkinson wrote: > At 03:43 29/11/01, Markus Friedl wrote: > >>However, if you need to have DES-CBC, write a document, >>use "des-cbc@inet.org" and everything will be fine. >> > > Regrettably, that doesn't help at all -- because it doesn't document > how to implement such that one can interoperate with the installed base > of DES-CBC implementations of SSHv2. There are multiple such > implementations and an installed base of users. > > I'd REALLY prefer to resolve this in the WG. I've tried to > propose several forms of packaging that would both let the technical > detail get documented and also let folks who have passion against > DES-CBC document their issues/concerns/recommendations and also make > it crystal clear that DES-CBC isn't something an implementation is > expected to support. If we can't resolve this issue here, then an appeal > is likely -- which will necessarily delay the documents substantially > (delay being explicitly NOT my objective). Sigh. > > Yours, > > Ran > rja@inet.org > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 10:45:11 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14808 for ; Thu, 29 Nov 2001 10:45:11 -0500 (EST) Received: (qmail 22820 invoked by uid 605); 29 Nov 2001 15:45:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22809 invoked from network); 29 Nov 2001 15:45:05 -0000 Received: from inet.org (HELO gnat.inet.org) (63.108.254.91) by mail.netbsd.org with SMTP; 29 Nov 2001 15:45:05 -0000 Received: from mosquito.inet.org (unknown [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id C9A4A67103; Thu, 29 Nov 2001 10:51:55 -0500 (EST) Message-Id: <5.1.0.14.2.20011129103349.01ea5710@10.30.15.3> X-Sender: rja@10.30.15.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 29 Nov 2001 10:35:45 -0500 To: Derek Fawcus From: RJ Atkinson Subject: Re: des-cbc cipher Cc: ietf-ssh@netbsd.org In-Reply-To: <20011129152904.F16432@edinburgh.cisco.com> References: <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3> <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <200111290215.fAT2F1Eu998747@jurassic.eng.sun.com> <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <20011129094341.B27343@faui02> <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 10:29 29/11/01, Derek Fawcus wrote: >Is it the name of the protocol that's the issue 'des-cbc' vs >'des-cbc@somthing', or that you want this in the base docs? I think there are multiple issues. One is that folks appear to want to outlaw the currently deployed protocol token for DES-CBC. A second is that folks want to prohibit documentation of how DES-CBC is currently used (in a widely deployed context) with SSHv2. There might be other issues that I personally have not yet puzzled out... Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 10:49:30 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15121 for ; Thu, 29 Nov 2001 10:49:30 -0500 (EST) Received: (qmail 23290 invoked by uid 605); 29 Nov 2001 15:49:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23283 invoked from network); 29 Nov 2001 15:49:28 -0000 Received: from inet.org (HELO gnat.inet.org) (63.108.254.91) by mail.netbsd.org with SMTP; 29 Nov 2001 15:49:28 -0000 Received: from mosquito.inet.org (unknown [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 7E79967103; Thu, 29 Nov 2001 10:56:17 -0500 (EST) Message-Id: <5.1.0.14.2.20011129103604.01eb02f0@10.30.15.3> X-Sender: rja@10.30.15.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 29 Nov 2001 10:40:05 -0500 To: Jeffrey Altman From: RJ Atkinson Subject: Re: des-cbc cipher Cc: ietf-ssh@netbsd.org In-Reply-To: <3C065441.6000207@columbia.edu> References: <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <200111290215.fAT2F1Eu998747@jurassic.eng.sun.com> <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 10:29 29/11/01, Jeffrey Altman wrote: >The way this should be handled in the IETF is to publish the >deprecated functionality as a separate Historical RFC. The IETF has not traditionally required that. It would be one approach. It would not appear to solve all issues (more below) in any event. Instead, a common IETF approach is to document the deprecated capability in an Appendix of the regular documents, clearly marked as deprecated or informational (I don't object to the labelling either way), so that an implementer trying can easily locate it and then make an informed decision about what to do in her/his implementation. In any event, it appears (I hope I'm confused and this can be clarified) that some folks want to make sure the protocol element changes -- so that the existing deployed implementations won't be interoperable or compliant with the SSHv2 standard (regardless of how DES-CBC were documented or even not documented). Sigh. Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 10:51:22 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15293 for ; Thu, 29 Nov 2001 10:51:21 -0500 (EST) Received: (qmail 23944 invoked by uid 605); 29 Nov 2001 15:51:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23937 invoked from network); 29 Nov 2001 15:51:20 -0000 Received: from inet.org (HELO gnat.inet.org) (63.108.254.91) by mail.netbsd.org with SMTP; 29 Nov 2001 15:51:20 -0000 Received: from mosquito.inet.org (unknown [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 92DFE67103; Thu, 29 Nov 2001 10:58:10 -0500 (EST) Message-Id: <5.1.0.14.2.20011129104023.01eb4ec0@10.30.15.3> X-Sender: rja@10.30.15.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 29 Nov 2001 10:41:59 -0500 To: Markus Friedl From: RJ Atkinson Subject: Re: des-cbc cipher Cc: ietf-ssh@netbsd.org In-Reply-To: <20011129162938.D14394@faui02> References: <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3> <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <200111290215.fAT2F1Eu998747@jurassic.eng.sun.com> <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 10:29 29/11/01, Markus Friedl wrote: >but these implementations violate the drafts if they >use "des-cbc". they must use "des-cbc@domain". The IETF traditionally does not change a spec after it is deployed such that existing implementations are gratuitously made non-compliant. Am I confused ? Is this WG trying to make existing deployed SSHv2 implementations non-compliant with its current drafts ? Ran rja@inet.org From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 11:13:48 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17362 for ; Thu, 29 Nov 2001 11:13:47 -0500 (EST) Received: (qmail 29127 invoked by uid 605); 29 Nov 2001 16:13:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28733 invoked from network); 29 Nov 2001 16:12:42 -0000 Received: from mail1.cisco.com (171.68.225.60) by mail.netbsd.org with SMTP; 29 Nov 2001 16:12:42 -0000 Received: from CLONVICK-W2K.cisco.com (dhcp-64-101-182-136.cisco.com [64.101.182.136]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA09073; Thu, 29 Nov 2001 08:12:21 -0800 (PST) Message-Id: <4.3.2.7.2.20011129095832.022d1230@sj-email.cisco.com> X-Sender: clonvick@sj-email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Nov 2001 10:12:07 -0600 To: Derek Fawcus , RJ Atkinson From: "Chris M. Lonvick" Subject: Re: des-cbc cipher Cc: ietf-ssh@netbsd.org In-Reply-To: <20011129152904.F16432@edinburgh.cisco.com> References: <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3> <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <200111290215.fAT2F1Eu998747@jurassic.eng.sun.com> <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <20011129094341.B27343@faui02> <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 03:29 PM 11/29/2001 +0000, Derek Fawcus wrote: >On Thu, Nov 29, 2001 at 10:14:03AM -0500, RJ Atkinson wrote: > >> There are multiple such implementations and an installed base of users. > >Hmm - Is one of them by any chance Cisco routers when using a 'export' >version of crypto code? i.e. DES instead of 3DES. No. Cisco's IOS does not support SSHv2 which is what is being discussed. Beyond that, from what I've seen, the IETF doesn't respect any political boundaries with regards to crypto strengths permitted or denied by any governing body, nor by any vendor. Let's not revisit that argument here. Regards, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 11:25:58 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18650 for ; Thu, 29 Nov 2001 11:25:57 -0500 (EST) Received: (qmail 6675 invoked by uid 605); 29 Nov 2001 16:25:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6667 invoked from network); 29 Nov 2001 16:25:54 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 29 Nov 2001 16:25:54 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id RAA02023; Thu, 29 Nov 2001 17:25:47 +0100 (MET) Date: Thu, 29 Nov 2001 17:25:47 +0100 From: Markus Friedl To: RJ Atkinson Cc: ietf-ssh@netbsd.org, openssh@openbsd.org Subject: Re: des-cbc cipher Message-ID: <20011129172547.A29231@faui02> References: <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3> <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <200111290215.fAT2F1Eu998747@jurassic.eng.sun.com> <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3> <5.1.0.14.2.20011129104023.01eb4ec0@10.30.15.3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20011129104023.01eb4ec0@10.30.15.3> User-Agent: Mutt/1.3.23i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Nov 29, 2001 at 10:41:59AM -0500, RJ Atkinson wrote: > At 10:29 29/11/01, Markus Friedl wrote: > >but these implementations violate the drafts if they > >use "des-cbc". they must use "des-cbc@domain". > > The IETF traditionally does not change a spec after it is deployed > such that existing implementations are gratuitously made non-compliant. > Am I confused ? Is this WG trying to make existing deployed SSHv2 > implementations non-compliant with its current drafts ? do you have an old WG draft that has specified "des-cbc" before? i cannot find one in my archives. so implementations using "des-cbc" -- i only know of ssh.com's software and their author says it was accidentially assigned the name "des-cbc" -- will not interoperate, since there was never any specification. adding "des-cbc" to the spec does not unbreak these implementations, it does not make them "compliant". not adding "des-cbc" does not change them to "non-compliant", since they have not been "compliant" before. if some old implementations use "des-cbc", well, good luck, they might interoperate. adding "des-cbc" will not change their implemenation. i really don't understand what all this is about. if we modify the drafts every now and then we will never have a _single_ compliant implemenation since there never will be a SSHv2 standard. thanks. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 12:00:12 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21670 for ; Thu, 29 Nov 2001 12:00:11 -0500 (EST) Received: (qmail 13446 invoked by uid 605); 29 Nov 2001 17:00:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13437 invoked from network); 29 Nov 2001 17:00:07 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 29 Nov 2001 17:00:07 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id B7FCF834E16; Thu, 29 Nov 2001 18:00:05 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.3/8.8.7) id SAA08582; Thu, 29 Nov 2001 18:00:05 +0100 (MET) X-Authentication-Warning: sture.lysator.liu.se: nisse set sender to nisse@sture.lysator.liu.se using -f To: RJ Atkinson Cc: sommerfeld@east.sun.com, ietf-ssh@netbsd.org Subject: Re: des-cbc cipher References: <5.1.0.14.2.20011128194352.00a05510@10.30.15.3> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 29 Nov 2001 18:00:02 +0100 In-Reply-To: <5.1.0.14.2.20011128194352.00a05510@10.30.15.3> Message-ID: Lines: 38 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit RJ Atkinson writes: > At 17:50 28/11/01, Bill Sommerfeld wrote: > > - there should be no mention of a des-cbc algorithm in the spec. > > I haven't seen this thread in some while. I really disagree with the > first conclusion. DES-CBC is widely deployed with SSHv2 right now, > so it ought to be mentioned. As far as I understand, the fact that SSH Inc's implementation use the name "des-cbc", rather than "des-cbc@ssh.com", is an accidental bug that'll be fixed in the their next release. Even if I don't think it's totally outrageous to document "des-cbc" to the spec, as long as its use is discouraged, there are a lot of other bugs in various versions of ssh implementations, including SSH Inc's, that does a lot more damage to interoperation than this one. I don't see why it is necessary or desirable to change the spec to match this particular bug. If you (or anybody else) really needs des-cbc, write up a document that defines "des-cbc@ssh.com" or "des-cbc@inet.org", and if you like, add a paragraph on bug compatibility that mentions that some existing implementations use the name "des-cbc" for the same thing. Would that solve the problem? To me, des-cbc seems like a specialized algorithm, useful only under very specialized circumstances (like if you're trying to export boxes from certain countries, or have customers that for some peculiar reason *insists* on using plain des), and therefore it makes sense to specify it independently from the core drafts. [ Furthermore, I'd expect that in any real SSH communication where des-cbc is used, at least one of the end-points doesn't support 3des-cbc, and is thus not complying with the spec. That makes the issue look even more like a question of bug-compatibility. ] /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 13:08:25 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27587 for ; Thu, 29 Nov 2001 13:08:24 -0500 (EST) Received: (qmail 10928 invoked by uid 605); 29 Nov 2001 18:08:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10918 invoked from network); 29 Nov 2001 18:08:20 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 29 Nov 2001 18:08:20 -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 KAA07419; Thu, 29 Nov 2001 10:08:11 -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 NAA02725; Thu, 29 Nov 2001 13:08:11 -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 fATI8AU8005659; Thu, 29 Nov 2001 13:08:10 -0500 (EST) Message-Id: <200111291808.fATI8AU8005659@thunk.east.sun.com> From: Bill Sommerfeld To: RJ Atkinson cc: Markus Friedl , ietf-ssh@netbsd.org Subject: Re: des-cbc cipher In-Reply-To: Your message of "Thu, 29 Nov 2001 10:41:59 EST." <5.1.0.14.2.20011129104023.01eb4ec0@10.30.15.3> Reply-to: sommerfeld@east.sun.com Date: Thu, 29 Nov 2001 13:08:10 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Ran, > Is this WG trying to make existing deployed SSHv2 implementations > non-compliant with its current drafts ? No. To the best of my knowledge: 1) before this discussion started, there was smooth working group consensus to avoid weak algorithms in the spec, single-DES included. 2) i've seen zero interest in actually including des-cbc before this point was raised. 3) The spec has never mentioned des-cbc. This thread started when someone noticed that one implementation chose to use the (never officially allocated and thus out-of-spec) des-cbc algorithm name for single-DES. We're behind schedule; building consensus to add des-cbc to the spec (since I see substantial opposition) will make the documents even later. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 14:46:02 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06163 for ; Thu, 29 Nov 2001 14:46:01 -0500 (EST) Received: (qmail 6017 invoked by uid 605); 29 Nov 2001 19:45:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5992 invoked from network); 29 Nov 2001 19:45:40 -0000 Received: from inet.org (HELO gnat.inet.org) (63.108.254.91) by mail.netbsd.org with SMTP; 29 Nov 2001 19:45:40 -0000 Received: from mosquito.inet.org (unknown [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 1CD4567103; Thu, 29 Nov 2001 14:52:27 -0500 (EST) Message-Id: <5.1.0.14.2.20011129143402.00a1dbb0@10.30.15.3> X-Sender: rja@10.30.15.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 29 Nov 2001 14:36:14 -0500 To: Markus Friedl From: RJ Atkinson Subject: Re: des-cbc cipher Cc: ietf-ssh@netbsd.org In-Reply-To: <20011129172547.A29231@faui02> References: <5.1.0.14.2.20011129104023.01eb4ec0@10.30.15.3> <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3> <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <200111290215.fAT2F1Eu998747@jurassic.eng.sun.com> <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3> <5.1.0.14.2.20011129104023.01eb4ec0@10.30.15.3> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 11:25 29/11/01, Markus Friedl wrote: >so implementations using "des-cbc" -- i only know of ssh.com's software >and their author says it was accidentially assigned the name "des-cbc" >-- will not interoperate, since there was never any specification. There are several actually. They interoperate using the token "des-cbc" just fine today. >not adding "des-cbc" does not change them to "non-compliant", since >they have not been "compliant" before. Not so. The spec didn't strictly prohibit the use of "des-cbc" (as different from "des-cbc@domain" all along. That's the part that makes the deployed implementations non-compliant. >i really don't understand what all this is about. Interoperability of deployed SSHv2 clients is the topic; or at least its my topic... Ran rja@inet.org From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 14:49:14 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06351 for ; Thu, 29 Nov 2001 14:49:13 -0500 (EST) Received: (qmail 6834 invoked by uid 605); 29 Nov 2001 19:49:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6827 invoked from network); 29 Nov 2001 19:49:08 -0000 Received: from inet.org (HELO gnat.inet.org) (63.108.254.91) by mail.netbsd.org with SMTP; 29 Nov 2001 19:49:08 -0000 Received: from mosquito.inet.org (unknown [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 9B10C67103; Thu, 29 Nov 2001 14:55:54 -0500 (EST) Message-Id: <5.1.0.14.2.20011129143638.00a1c060@10.30.15.3> X-Sender: rja@10.30.15.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 29 Nov 2001 14:39:42 -0500 To: nisse@lysator.liu.se (Niels Möller) From: RJ Atkinson Subject: Re: des-cbc cipher Cc: ietf-ssh@netbsd.org In-Reply-To: References: <5.1.0.14.2.20011128194352.00a05510@10.30.15.3> <5.1.0.14.2.20011128194352.00a05510@10.30.15.3> 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 At 12:00 29/11/01, Niels Möller wrote: >If you (or anybody else) really needs des-cbc, write up a document >that defines "des-cbc@ssh.com" or "des-cbc@inet.org", and if you like, >add a paragraph on bug compatibility that mentions that some existing >implementations use the name "des-cbc" for the same thing. What's needed is to document that using "des-cbc" (not "des-cbc@domain") is permitted, but not required of anyone, and that using that token (not the "des-cbc@domain" token) for that purpose does not make an existing implementation non-compliant with the standards. >[ Furthermore, I'd expect that in any real SSH communication where > des-cbc is used, at least one of the end-points doesn't support > 3des-cbc, and is thus not complying with the spec. That makes the > issue look even more like a question of bug-compatibility. ] No. One might choose not to use 3DES even if it were available, for example because the time to break DES-CBC is longer than the information being protected is valuable (e.g. real-time stock quotes) or because one's client/server is a tiny device with small CPU where the computational expense is not justified for the value of the data being protected. Ran rja@inet.org From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 15:01:03 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07261 for ; Thu, 29 Nov 2001 15:01:02 -0500 (EST) Received: (qmail 11566 invoked by uid 605); 29 Nov 2001 20:00:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11558 invoked from network); 29 Nov 2001 20:00:51 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 29 Nov 2001 20:00:51 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id VAA19359; Thu, 29 Nov 2001 21:00:43 +0100 (MET) Date: Thu, 29 Nov 2001 21:00:43 +0100 From: Markus Friedl To: RJ Atkinson Cc: ietf-ssh@netbsd.org Subject: Re: des-cbc cipher Message-ID: <20011129210043.A11679@faui02> References: <5.1.0.14.2.20011129104023.01eb4ec0@10.30.15.3> <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3> <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <200111290215.fAT2F1Eu998747@jurassic.eng.sun.com> <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3> <5.1.0.14.2.20011129104023.01eb4ec0@10.30.15.3> <5.1.0.14.2.20011129143402.00a1dbb0@10.30.15.3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20011129143402.00a1dbb0@10.30.15.3> User-Agent: Mutt/1.3.23i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Nov 29, 2001 at 02:36:14PM -0500, RJ Atkinson wrote: > At 11:25 29/11/01, Markus Friedl wrote: > >so implementations using "des-cbc" -- i only know of ssh.com's software > >and their author says it was accidentially assigned the name "des-cbc" > >-- will not interoperate, since there was never any specification. > > There are several actually. They interoperate using the token "des-cbc" > just fine today. what implementations? > >not adding "des-cbc" does not change them to "non-compliant", since > >they have not been "compliant" before. > > Not so. The spec didn't strictly prohibit the use of "des-cbc" > (as different from "des-cbc@domain" all along. That's the part > that makes the deployed implementations non-compliant. it's obvious from draft-ietf-secsh-transport-00.txt that the "alg@domain" notation must be used for "additional algorithms" that are not "defined in the base protocol": [...] There are two formats for algorithm identifiers: o Algorithms defined in the base protocol are simple strings, such as "3des-cbc", "sha-1", "hmac-sha", or "zip" (the quotes are not part of the name). Defined algorithms may be mandatory or optional. All interoperable implementations should implement mandatory algorithms and offer them as a possibility in key exchanges. Optional algorithms are not crucial for interoperability, but may provide better performance or other advantages. It is up to an implementation to decide which of these are supported and which are offered in key exchanges by default. o Anyone can define additional algorithms by using names in the format name@domainname, e.g. "ourcipher-cbc@ssh.fi". The format of the part preceding the at sign is not specified; it may contain any non- control characters except at signs and commas. The part following the at sign should be a valid internet domain name for the organization defining the name. It is up to the each organization how they manage its locally defined names. [...] The following ciphers are currently defined: none optional no encryption 3des-cbc mandatory three-key 3DES in CBC mode idea-cbc optional IDEA in CBC mode arcfour optional ARCFOUR stream cipher blowfish-cbc optional Blowfish in CBC mode [...] From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 15:02:34 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07373 for ; Thu, 29 Nov 2001 15:02:34 -0500 (EST) Received: (qmail 11937 invoked by uid 605); 29 Nov 2001 20:02:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11930 invoked from network); 29 Nov 2001 20:02:30 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 29 Nov 2001 20:02:30 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id VAA19423; Thu, 29 Nov 2001 21:02:24 +0100 (MET) Date: Thu, 29 Nov 2001 21:02:24 +0100 From: Markus Friedl To: RJ Atkinson Cc: Niels =?iso-8859-1?Q?M=F6ller?= , ietf-ssh@netbsd.org Subject: Re: des-cbc cipher Message-ID: <20011129210224.B11679@faui02> References: <5.1.0.14.2.20011128194352.00a05510@10.30.15.3> <5.1.0.14.2.20011128194352.00a05510@10.30.15.3> <5.1.0.14.2.20011129143638.00a1c060@10.30.15.3> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5.1.0.14.2.20011129143638.00a1c060@10.30.15.3> User-Agent: Mutt/1.3.23i Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit On Thu, Nov 29, 2001 at 02:39:42PM -0500, RJ Atkinson wrote: > At 12:00 29/11/01, Niels Möller wrote: > >If you (or anybody else) really needs des-cbc, write up a document > >that defines "des-cbc@ssh.com" or "des-cbc@inet.org", and if you like, > >add a paragraph on bug compatibility that mentions that some existing > >implementations use the name "des-cbc" for the same thing. > > What's needed is to document that using "des-cbc" (not "des-cbc@domain") > is permitted, but not required of anyone, and that using that token > (not the "des-cbc@domain" token) for that purpose does not make an > existing implementation non-compliant with the standards. no, "des-cbc" was never permitted, i checked: draft-ietf-secsh-transport-00.txt draft-ietf-secsh-transport-01.txt draft-ietf-secsh-transport-02.txt draft-ietf-secsh-transport-03.txt draft-ietf-secsh-transport-04.txt draft-ietf-secsh-transport-05.txt draft-ietf-secsh-transport-06.txt draft-ietf-secsh-transport-07.txt draft-ietf-secsh-transport-08.txt draft-ietf-secsh-transport-09.txt draft-ietf-secsh-transport-10.txt draft-ietf-secsh-transport-11.txt -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 15:10:48 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07885 for ; Thu, 29 Nov 2001 15:10:47 -0500 (EST) Received: (qmail 14577 invoked by uid 605); 29 Nov 2001 20:10:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14570 invoked from network); 29 Nov 2001 20:10:44 -0000 Received: from fw.hel.fi.ssh.com (193.64.193.124) by mail.netbsd.org with SMTP; 29 Nov 2001 20:10:44 -0000 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id fATKAgf02236 for ; Thu, 29 Nov 2001 22:10:42 +0200 (EET) Received: (qmail 3875 invoked from network); 29 Nov 2001 20:10:42 -0000 Received: from unknown (HELO johto.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 29 Nov 2001 20:10:42 -0000 Received: (from sjl@localhost) by johto.hel.fi.ssh.com (8.9.3/8.9.3) id WAA12455; Thu, 29 Nov 2001 22:11:03 +0200 To: ietf-ssh@netbsd.org Subject: Re: des-cbc cipher References: <20011129172547.A29231@faui02> From: sjl@ssh.com (Sami J. Lehtinen) Date: 29 Nov 2001 22:11:03 +0200 In-Reply-To: markus@openbsd.org's message of "Thu, 29 Nov 2001 16:26:04 +0000 (UTC)" Message-ID: Lines: 28 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Canyonlands" Sender: ietf-ssh-owner@netbsd.org Precedence: list markus@openbsd.org (Markus Friedl) writes: > adding "des-cbc" to the spec does not unbreak these implementations, > it does not make them "compliant". > > not adding "des-cbc" does not change them to "non-compliant", since > they have not been "compliant" before. if some old implementations use > "des-cbc", well, good luck, they might interoperate. adding "des-cbc" > will not change their implemenation. How would the implementations be non-compliant, if des-cbc was added? The text would probably be something like: The "des-cbc" cipher is DES (Data Encryption Standard) in CBC mode, with 56 bit keys. The key is represented as 64 bits, with the least significant bit of every byte used as parity [SCHNEIER]. This is a block cipher with 8 byte blocks. Note: this algorithm is considered INSECURE because of small key size. I really don't have a strong opinion about this; if it were only up to me, the cipher would be removed from our implementation. But if it gets added to the spec, our implementation would be conformant in this respect without me adding compatibility code :) -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 20 5007425][gsm:+358 40 864 3001][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 15:12:10 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07967 for ; Thu, 29 Nov 2001 15:12:10 -0500 (EST) Received: (qmail 14968 invoked by uid 605); 29 Nov 2001 20:12:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14961 invoked from network); 29 Nov 2001 20:12:07 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 29 Nov 2001 20:12:07 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id AC906834DBE; Thu, 29 Nov 2001 21:12:06 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.3/8.8.7) id VAA13784; Thu, 29 Nov 2001 21:12:06 +0100 (MET) X-Authentication-Warning: sture.lysator.liu.se: nisse set sender to nisse@sture.lysator.liu.se using -f To: RJ Atkinson Cc: Markus Friedl , ietf-ssh@netbsd.org Subject: Re: des-cbc cipher References: <5.1.0.14.2.20011129104023.01eb4ec0@10.30.15.3> <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3> <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <200111290215.fAT2F1Eu998747@jurassic.eng.sun.com> <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3> <5.1.0.14.2.20011129104023.01eb4ec0@10.30.15.3> <5.1.0.14.2.20011129143402.00a1dbb0@10.30.15.3> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 29 Nov 2001 21:12:06 +0100 In-Reply-To: <5.1.0.14.2.20011129143402.00a1dbb0@10.30.15.3> Message-ID: Lines: 22 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit RJ Atkinson writes: > At 11:25 29/11/01, Markus Friedl wrote: > >not adding "des-cbc" does not change them to "non-compliant", since > >they have not been "compliant" before. > > Not so. The spec didn't strictly prohibit the use of "des-cbc" > (as different from "des-cbc@domain" all along. That's the part > that makes the deployed implementations non-compliant. People seem to disagree on this point. As far back as I can remember, all wg drafts have clearly given a list of Official Algorithm Names (not including des-cbc), and clearly stated that for any algorithm not on that list, one MUST use a name of the form @. Could you please quote the spec that said differently? Finally, I agree with Bill that the timing of your proposal is highly sub-optimal. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 15:19:24 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08424 for ; Thu, 29 Nov 2001 15:19:23 -0500 (EST) Received: (qmail 15605 invoked by uid 605); 29 Nov 2001 20:19:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15593 invoked from network); 29 Nov 2001 20:19:19 -0000 Received: from inet.org (HELO gnat.inet.org) (63.108.254.91) by mail.netbsd.org with SMTP; 29 Nov 2001 20:19:19 -0000 Received: from mosquito.inet.org (unknown [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 99D1067103; Thu, 29 Nov 2001 15:26:10 -0500 (EST) Message-Id: <5.1.0.14.2.20011129150815.009fa7a0@10.30.15.3> X-Sender: rja@10.30.15.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 29 Nov 2001 15:09:56 -0500 To: Markus Friedl From: RJ Atkinson Subject: Re: des-cbc cipher Cc: ietf-ssh@netbsd.org In-Reply-To: <20011129210224.B11679@faui02> References: <5.1.0.14.2.20011129143638.00a1c060@10.30.15.3> <5.1.0.14.2.20011128194352.00a05510@10.30.15.3> <5.1.0.14.2.20011128194352.00a05510@10.30.15.3> <5.1.0.14.2.20011129143638.00a1c060@10.30.15.3> 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 At 15:02 29/11/01, Markus Friedl wrote: >On Thu, Nov 29, 2001 at 02:39:42PM -0500, RJ Atkinson wrote: >> At 12:00 29/11/01, Niels Möller wrote: >> >If you (or anybody else) really needs des-cbc, write up a document >> >that defines "des-cbc@ssh.com" or "des-cbc@inet.org", and if you like, >> >add a paragraph on bug compatibility that mentions that some existing >> >implementations use the name "des-cbc" for the same thing. >> >> What's needed is to document that using "des-cbc" (not "des-cbc@domain") >> is permitted, but not required of anyone, and that using that token >> (not the "des-cbc@domain" token) for that purpose does not make an >> existing implementation non-compliant with the standards. > >no, "des-cbc" was never permitted, i checked: SSHv2 was deployed before the time of the first IETF WG I-D, so that isn't really sufficient here. The WG is supposedly standardising the deployed protocol, though perhaps not in fact. The need remains and is technically founded in interoperability and in not making otherwise conforming implementations non-conforming. Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 15:40:19 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10129 for ; Thu, 29 Nov 2001 15:40:18 -0500 (EST) Received: (qmail 19398 invoked by uid 605); 29 Nov 2001 20:40:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19390 invoked from network); 29 Nov 2001 20:40:16 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 29 Nov 2001 20:40:16 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id VAA21654; Thu, 29 Nov 2001 21:40:13 +0100 (MET) Date: Thu, 29 Nov 2001 21:40:13 +0100 From: Markus Friedl To: RJ Atkinson Cc: ietf-ssh@netbsd.org Subject: Re: des-cbc cipher Message-ID: <20011129214012.A19559@faui02> References: <5.1.0.14.2.20011129143638.00a1c060@10.30.15.3> <5.1.0.14.2.20011128194352.00a05510@10.30.15.3> <5.1.0.14.2.20011128194352.00a05510@10.30.15.3> <5.1.0.14.2.20011129143638.00a1c060@10.30.15.3> <5.1.0.14.2.20011129150815.009fa7a0@10.30.15.3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20011129150815.009fa7a0@10.30.15.3> User-Agent: Mutt/1.3.23i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Nov 29, 2001 at 03:09:56PM -0500, RJ Atkinson wrote: > >no, "des-cbc" was never permitted, i checked: > > SSHv2 was deployed before the time of the first IETF WG I-D, > so that isn't really sufficient here. hm, draft-ietf-secsh-transport-00.txt is from March 22, 1997 and does not even define the current key-exchange. the protocol described in the draft-ietf-secsh-transport-00.txt is very very different from the current SSHv2 spec. so i doubt that a 1997 implemenation, that only speaks "double-encrypting-sha" should be considered in this WG. "Currently, the following key exchange methods have been defined: double-encrypting-sha mandatory The implementation of these methods is described later in this section." > The WG is supposedly > standardising the deployed protocol, though perhaps not in fact. the WG cannot, see below. > The need remains and is technically founded in interoperability > and in not making otherwise conforming implementations non-conforming. have you ever realized that many deployed implementations of SSHv2 are violating the current specs? this because the specs have changed. * there are several implementations that use a different encoding of the session id during authentication. these implementations are non-conforming to the current drafts. * there are several implementations that use a different encoding of the data that will be signed during authentication. these implementations are non-conforming to the current drafts. * the encoding for SSH_MSG_CHANNEL_OPEN_FAILURE has changed. so there are yet more implentations that are not conforming to the current drafts. delaying the last call will only leed to more non-conforming implementations. should the WG add all these 'bugs' to the specs, just to make existing implementations conforming? -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 15:55:46 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11244 for ; Thu, 29 Nov 2001 15:55:45 -0500 (EST) Received: (qmail 21106 invoked by uid 605); 29 Nov 2001 20:55:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21016 invoked from network); 29 Nov 2001 20:55:38 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 29 Nov 2001 20:55:38 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09786; Thu, 29 Nov 2001 13:55:19 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id MAA02516; Thu, 29 Nov 2001 12:55:54 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with SMTP id fATKtZEu526352; Thu, 29 Nov 2001 12:55:35 -0800 (PST) Message-Id: <200111292055.fATKtZEu526352@jurassic.eng.sun.com> Date: Thu, 29 Nov 2001 12:55:35 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: des-cbc cipher To: rja@inet.org Cc: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: DMCadwNmiBslVWJBU4YaLw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_50 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list There are already two I-Ds for an alternate KEX methods. What is your objection to defining the des-cbc cipher in a separate I-D ? In a previous email you said you would escalate this, can you share with the list the justification exactly as you would present it in the escalation. Since you claim there are implementations other than from SSH Inc which have des-cbc can you give us a list of them - this would be useful for people doing interop testing, I'd also like to invite those people to Connectathon 2002. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 16:24:40 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13430 for ; Thu, 29 Nov 2001 16:24:40 -0500 (EST) Received: (qmail 5457 invoked by uid 605); 29 Nov 2001 21:24:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5391 invoked from network); 29 Nov 2001 21:24:10 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 29 Nov 2001 21:24:10 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 7039D834D0E; Thu, 29 Nov 2001 22:24:09 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.3/8.8.7) id WAA15835; Thu, 29 Nov 2001 22:24:08 +0100 (MET) X-Authentication-Warning: sture.lysator.liu.se: nisse set sender to nisse@sture.lysator.liu.se using -f To: RJ Atkinson Cc: Markus Friedl , ietf-ssh@netbsd.org Subject: Re: des-cbc cipher References: <5.1.0.14.2.20011129143638.00a1c060@10.30.15.3> <5.1.0.14.2.20011128194352.00a05510@10.30.15.3> <5.1.0.14.2.20011128194352.00a05510@10.30.15.3> <5.1.0.14.2.20011129143638.00a1c060@10.30.15.3> <5.1.0.14.2.20011129150815.009fa7a0@10.30.15.3> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 29 Nov 2001 22:24:08 +0100 In-Reply-To: <5.1.0.14.2.20011129150815.009fa7a0@10.30.15.3> Message-ID: Lines: 50 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit RJ Atkinson writes: > SSHv2 was deployed before the time of the first IETF WG I-D, > so that isn't really sufficient here. The WG is supposedly > standardising the deployed protocol, though perhaps not in fact. > > The need remains and is technically founded in interoperability > and in not making otherwise conforming implementations non-conforming. I'm not getting this. I've been involved with an secsh implementations, and in this wg, since a week or two after draft-ietf-secsh-transport-04.txt was published 6 August 1998, more than three years ago. The use of "des-cbc" by SSH Inc. was pointed out to me in December 1998 (in private mail, or on the psst mailing list, I don't quite remember how or by whome). I regarded it as yet another deviation from the protocol, and I didn't think much about it. All other similar "implementing-before-the-spec" bugs in SSH Inc's implementation that I can remember have been fixed sooner or later, I don't think this one is any special. [1] And in all that time, "des-cbc" has never ever been allowed by any draft spec, and noone have ever proposed it on this mailing list. I don't understand why its suddenly so important *today*. After more than three years?! From a pragmatic point of view, I don't see a problem either. Implementations that currently uses "des-cbc" will continue to do so for a few years, for backwards compatibility. The proper name "des-cbc@ssh.com" will be added in the next release of each of the involved implementations. Breaking the spec in this regard won't cause any practical problems. That said, I think des-cbc should be abandoned (cpu-constrained devices are better off with arcfour or blowfish (which have both been in the spec for a long time) or aes or something. I would consider its introduction in the spec as a wart. But it would be a benign wart that I could ignore with no trouble. I don't want to fight against it to the extent that the standardization process is delayed even more. /Niels [1] Actually, at one time the specified format used for dss signatures *was* changed to match SSH Inc's implementation. That's the only time the spec has adapted to that particular implementation, and I didn't quite like that either. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 17:11:22 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16560 for ; Thu, 29 Nov 2001 17:11:21 -0500 (EST) Received: (qmail 16192 invoked by uid 605); 29 Nov 2001 22:11:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16043 invoked from network); 29 Nov 2001 22:11:09 -0000 Received: from sommerfeld.ne.mediaone.net (HELO stack.hamachi.org) (66.31.126.43) by mail.netbsd.org with SMTP; 29 Nov 2001 22:11:09 -0000 Received: from orchard.arlington.ma.us (orchard.hamachi.org [18.101.2.2]) by stack.hamachi.org (Postfix) with ESMTP id 2C46126CF for ; Thu, 29 Nov 2001 17:10:45 -0500 (EST) Received: by orchard.arlington.ma.us (Postfix, from userid 587) id 568CB2A51; Thu, 29 Nov 2001 17:08:48 -0500 (EST) Received: from orchard.arlington.ma.us (localhost [127.0.0.1]) by orchard.arlington.ma.us (Postfix) with ESMTP id 408091FDA for ; Thu, 29 Nov 2001 17:08:48 -0500 (EST) From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: forwarded from peter_m_boyd@yahoo.co.uk: SecSH server functionality on windows Reply-To: peter_m_boyd@yahoo.co.uk Date: Thu, 29 Nov 2001 17:08:42 -0500 Message-Id: <20011129220848.568CB2A51@orchard.arlington.ma.us> Sender: ietf-ssh-owner@netbsd.org Precedence: list [anti-spam filters on netbsd.org suffered a false positive on this message; I've edited it down to remove redundancies -- Bill] ------- Forwarded Message Date: Thu, 29 Nov 2001 15:10:27 +0000 (GMT) From: =?iso-8859-1?q?Peter=20M=20Boyd?= Subject: Re: SecSH Server functionality on Windows - incomplete To: ietf-ssh@netbsd.org MIME-Version: 1.0 From advice given in a reply to the original post and subsequent testing I have found one implementation that does not have these limitations: vshell 1.2 from www.vandyke.com --- Peter M Boyd ------- End of Forwarded Message From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Nov 29 18:04:02 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19926 for ; Thu, 29 Nov 2001 18:04:01 -0500 (EST) Received: (qmail 29383 invoked by uid 605); 29 Nov 2001 23:04:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29370 invoked from network); 29 Nov 2001 23:04:00 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 29 Nov 2001 23:04:00 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 392352 for ietf-ssh@netbsd.org; Thu, 29 Nov 2001 16:07:53 -0700 Message-ID: <042701c1792a$2216ee40$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: Subject: Multiple simultaneous userauth requests Date: Thu, 29 Nov 2001 16:04:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit The userauth draft contains this text in section 2.2: > The client MAY send several authentication > requests without waiting for responses from > previous requests. The server MUST acknowledge > any failed requests with a SSH_MSG_USERAUTH_FAILURE > message. However, SSH_MSG_USERAUTH_SUCCESS MUST > be sent only once, and once SSH_MSG_USERAUTH_SUCCESS > has been sent, any further authentication requests > received after that SHOULD be silently ignored. This seems overly complicated? Do any clients actually do this? Can't we make things easier on implementers and just say the multiple simultaneous userauth requests are illegal? - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Nov 30 06:45:59 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04861 for ; Fri, 30 Nov 2001 06:45:58 -0500 (EST) Received: (qmail 26795 invoked by uid 605); 30 Nov 2001 11:45:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26788 invoked from network); 30 Nov 2001 11:45:56 -0000 Received: from guinness.cs.stevens-tech.edu (155.246.89.8) by mail.netbsd.org with SMTP; 30 Nov 2001 11:45:56 -0000 Received: by guinness.cs.stevens-tech.edu (Postfix, from userid 3330) id B886014186A; Fri, 30 Nov 2001 06:45:53 -0500 (EST) Date: Fri, 30 Nov 2001 06:45:53 -0500 From: Thor Simon To: ietf-ssh@netbsd.org Subject: Re: des-cbc cipher Message-ID: <20011130064553.B823471@cs.stevens-tech.edu> References: <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <200111290215.fAT2F1Eu998747@jurassic.eng.sun.com> <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <20011129094341.B27343@faui02> <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3>; from rja@inet.org on Thu, Nov 29, 2001 at 10:14:03AM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Nov 29, 2001 at 10:14:03AM -0500, RJ Atkinson wrote: > At 03:43 29/11/01, Markus Friedl wrote: > >However, if you need to have DES-CBC, write a document, > >use "des-cbc@inet.org" and everything will be fine. > > Regrettably, that doesn't help at all -- because it doesn't document > how to implement such that one can interoperate with the installed base > of DES-CBC implementations of SSHv2. There are multiple such > implementations and an installed base of users. It's the plain fault of the folks who chose to name their DES-CBC implementation "des-cbc" instead of "des-cbc@ssh.com" that this situation exists. Why should we break the standard just for them? Should we do so in the future any time an implementation that's widely used violates any detail of any standard? Thor From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Nov 30 11:29:04 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19470 for ; Fri, 30 Nov 2001 11:29:04 -0500 (EST) Received: (qmail 22628 invoked by uid 605); 30 Nov 2001 16:29:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22621 invoked from network); 30 Nov 2001 16:29:02 -0000 Received: from relay.hq.tis.com (HELO sentry.gw.tislabs.com) (192.94.214.100) by mail.netbsd.org with SMTP; 30 Nov 2001 16:29:02 -0000 Received: by sentry.gw.tislabs.com; id LAA19717; Fri, 30 Nov 2001 11:34:01 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma019680; Fri, 30 Nov 01 11:33:49 -0500 Received: (from balenson@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id fAUGSmW24203 for ietf-ssh@netbsd.org; Fri, 30 Nov 2001 11:28:48 -0500 (EST) Date: Fri, 30 Nov 2001 11:28:48 -0500 (EST) Message-Id: <200111301628.fAUGSmW24203@raven.gw.tislabs.com> From: balenson@tislabs.com To: ietf-ssh@netbsd.org Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS'02) Sender: ietf-ssh-owner@netbsd.org Precedence: list R E G I S T E R N O W ! ! THE INTERNET SOCIETY'S 2002 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'02) February 7-8, 2002 Catamaran Resort Hotel, San Diego, California General Chair: Cliff Neuman, USC Information Sciences Institute Program Chairs: Paul Van Oorschot, Entrust Virgil Gligor, University of Maryland ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss02 EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2002 The 9th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. THIS YEAR'S TOPICS INCLUDE: * Wireless Security * Analyzing the Anonymity of Anonymous Networking Protocols * Intrusion Detection and Defending Against Network Attacks * Detecting Steganographic Content on the Web * Server-Aided Digital Signatures * PKI, Certificates and Privilege Management * Various Aspects of Transport Layer Security/TLS PRE-CONFERENCE TECHNICAL TUTORIALS: * Major IETF Security Standards: PKIX, IPsec, SSL/TLS, Dr. Stephen Kent * Crash Course in SSL and TLS, Mr. Eric Rescorla * Building Secure Software, Dr. Gary McGraw * Wirelss LAN Security: Problems & Solutions, Dr. William Arbaugh * Group Security, Dr. Thomas Harjono and Mr. Hugh Harney For further information about NDSS'02 REGISTRATION contact Michele Estadt at the Internet Society at +1-703-326-9880 ext 104 or send e-mail to infondss@isoc.org SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Martin Kupres at the Internet Society EMEA office at +41 22 807 1444 or send e-mail to sponsorndss@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Nov 30 12:16:30 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22320 for ; Fri, 30 Nov 2001 12:16:29 -0500 (EST) Received: (qmail 651 invoked by uid 605); 30 Nov 2001 17:16:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 644 invoked from network); 30 Nov 2001 17:16:28 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 30 Nov 2001 17:16:28 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id B094A8352B8; Fri, 30 Nov 2001 18:16:27 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.3/8.8.7) id SAA17906; Fri, 30 Nov 2001 18:16:27 +0100 (MET) X-Authentication-Warning: sture.lysator.liu.se: nisse set sender to nisse@sture.lysator.liu.se using -f To: "Joseph Galbraith" Cc: Subject: Re: Multiple simultaneous userauth requests References: <042701c1792a$2216ee40$2800a8c0@test.vandyke.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 30 Nov 2001 18:16:25 +0100 In-Reply-To: <042701c1792a$2216ee40$2800a8c0@test.vandyke.com> Message-ID: Lines: 54 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit "Joseph Galbraith" writes: > The userauth draft contains this text in section 2.2: > > > The client MAY send several authentication > > requests without waiting for responses from > > previous requests. The server MUST acknowledge > > any failed requests with a SSH_MSG_USERAUTH_FAILURE > > message. However, SSH_MSG_USERAUTH_SUCCESS MUST > > be sent only once, and once SSH_MSG_USERAUTH_SUCCESS > > has been sent, any further authentication requests > > received after that SHOULD be silently ignored. > > This seems overly complicated? Do any clients > actually do this? lsh does. This way, the client can send a none request, immediately followed by a publickey requests (without any actual signature) for each available public key. Next the client processes the replies in order, if it gets any USERAUTH_SUCCESS response (could happen with anonymous services, or with kerberos or srp key exchange) it goes on doing whatever it wanted to do after login. If it receives any SSH_MSG_USERAUTH_PK_OK response it computes a signature for the correspondign key and sends that. If it receives USERAUTH_FAILURE for all of the requests, and the server indicates that password authentication might work, it asks the user for a password and sends a password request. I think it is nice to be able to do this without having to wait a full roundtrip for a reply between each request. It did add a little complexity to my server, but the simplest way to deal with it is to let the server work with one userauth request at a time. When you receive a userauth request, simply don't read anything more from the client until the userauth request is completely processed and replied to. At that time, you *know* whether or not the userauth phase is over, and if it is, you redirect all future userauth requests to /dev/null. The reason my implementation got a little complex is that I haven't yet forked when processing userauth requests, and I want to support password authentication methods that require communication with remote host, and thus need to return the main select loop before any reply can be sent. I also believe it is bad protocol design in general to require clients to wait unnecessarily. If a server wants to process a single request at a time or do some other serialization, it can just do that, it should not push that responsibity to that clients (and even if it does, it can't rely on clients behaving properly). Regards, /Niels