From owner-ietf-ssh@clinet.fi Thu Jan 4 00:42:01 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16493 for ; Thu, 4 Jan 2001 00:42:00 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id FAA03313 for ietf-ssh-outgoing; Thu, 4 Jan 2001 05:48:30 +0200 Received: from devonshire.cnchost.com (devonshire.concentric.net [207.155.248.12]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id FAA03306 for ; Thu, 4 Jan 2001 05:48:28 +0200 Received: from mannsberger.com (w164.z064220047.nyc-ny.dsl.cnc.net [64.220.47.164]) by devonshire.cnchost.com id WAA07821; Wed, 3 Jan 2001 22:48:26 -0500 (EST) [ConcentricHost SMTP Relay 1.10] Message-ID: <3A53F289.AF229810@mannsberger.com> Date: Wed, 03 Jan 2001 22:48:25 -0500 From: Michael Mannsberger X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ssh@clinet.fi Subject: how does the encryption work? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit when i ssh to a host i basically send my public key and some check bytes -> the remote server forks a child which generates a RSA key which will be stored in memory -> i receive a encrypted packet including remote public key and check bytes -> verify the check bytes -> extract remote public key -> session encypted from now on, is this correct? my questions: a) the RSA key generated by the child - how and when is it used? b) the servers exchange the supported cipher information after the key exchange right? thanx, -mike From owner-ietf-ssh@clinet.fi Thu Jan 4 03:24:19 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00216 for ; Thu, 4 Jan 2001 03:24:18 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id IAA15320 for ietf-ssh-outgoing; Thu, 4 Jan 2001 08:32:54 +0200 Received: from syrinx.oankali.net (syrinx.oankali.net [206.243.169.50]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id IAA15298 for ; Thu, 4 Jan 2001 08:32:51 +0200 Received: (from res@localhost) by syrinx.oankali.net (8.9.3/8.9.3) id BAA12568; Thu, 4 Jan 2001 01:32:31 -0500 Date: Thu, 4 Jan 2001 01:32:30 -0500 (EST) From: "Richard E. Silverman" X-Sender: res@syrinx.oankali.net Reply-To: "Richard E. Silverman" To: Michael Mannsberger cc: SECSH Discussion List Subject: Re: how does the encryption work? In-Reply-To: <3A53F289.AF229810@mannsberger.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Wed, 3 Jan 2001, Michael Mannsberger wrote: > when i ssh to a host i basically send my public key and some check bytes > -> the remote server forks a child which generates a RSA key which will > be stored in memory -> i receive a encrypted packet including remote > public key and check bytes -> verify the check bytes -> extract remote > public key -> session encypted from now on, is this correct? First: you didn't say which version of the protocol you're asking about. Second: no, this is not right. Your description is very confused; you're mixing up several different elements of the protocol. Third: this mailing list is for discussions regarding the standardization process for SSH-2. General questions like yours would be better directed to comp.security.ssh. Fourth: The entire process is spelled out in detail in the protocol documents. I suggest you consult them, and then ask any specific questions you have. SSH-1: http://www.snailbook.com/docs/protocol-1.5.txt SSH-2: SSH Protocol Architecture http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-06.txt SSH Transport Layer Protocol http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-08.txt SSH Authentication Protocol http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-08.txt SSH Connection Protocol http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-08.txt -- Richard Silverman slade@shore.net From owner-ietf-ssh@clinet.fi Wed Jan 10 09:23:25 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17552 for ; Wed, 10 Jan 2001 09:23:24 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id NAA28025 for ietf-ssh-outgoing; Wed, 10 Jan 2001 13:46:23 +0200 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id NAA27983 for ; Wed, 10 Jan 2001 13:46:19 +0200 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13351; Wed, 10 Jan 2001 06:46:16 -0500 (EST) Message-Id: <200101101146.GAA13351@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@clinet.fi From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-filexfer-00.txt Date: Wed, 10 Jan 2001 06:46:16 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk --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-00.txt Pages : 18 Date : 09-Jan-01 The SSH File Transfer Protocol provides secure file transfer functional- ity 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-00.txt 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-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-filexfer-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <20010109131015.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-filexfer-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-filexfer-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010109131015.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ssh@clinet.fi Wed Jan 10 15:12:36 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25962 for ; Wed, 10 Jan 2001 15:12:33 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA23278 for ietf-ssh-outgoing; Wed, 10 Jan 2001 19:32:59 +0200 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA23270 for ; Wed, 10 Jan 2001 19:32:58 +0200 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id TAA10470; Wed, 10 Jan 2001 19:32:40 +0200 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14940.40120.396573.482246@asgard.tky.hut.fi> Date: Wed, 10 Jan 2001 19:32:40 +0200 To: IETF-SecSH List Subject: filexfer version packet X-Mailer: VM 6.87 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit In this proposal, SSH_FXP_INIT packet has the following format uint32 version This will, however, make version 3 and higher versions incompatible with version 2 or lower (they won't understand the extension field). I will be happy to remove that field, unless someone can think of a solid reason to leave it (we already have the SSH_FXP_EXTENDED packet in this proposal). It is possible, of course, to work around this incompatibility, but it would be cleaner implementationwise not to use different packet format for the version packet as in the previous versions. -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Wed Jan 10 20:47:14 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08628 for ; Wed, 10 Jan 2001 20:47:13 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA15204 for ietf-ssh-outgoing; Thu, 11 Jan 2001 01:46:31 +0200 Received: from folly.informatik.uni-erlangen.de (muedi6-212-144-216-067.arcor-ip.net [212.144.216.67]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id BAA15197 for ; Thu, 11 Jan 2001 01:46:29 +0200 Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id CA3DD10C8; Thu, 11 Jan 2001 00:46:00 +0100 (CET) Date: Thu, 11 Jan 2001 00:46:00 +0100 From: Markus Friedl To: Sami Lehtinen Cc: IETF-SecSH List Subject: Re: filexfer version packet Message-ID: <20010111004600.A12276@folly> References: <14940.40120.396573.482246@asgard.tky.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <14940.40120.396573.482246@asgard.tky.hut.fi>; from sjl@iki.fi on Wed, Jan 10, 2001 at 07:32:40PM +0200 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk oh yes, please remove the extension fields from the version messages... -markus On Wed, Jan 10, 2001 at 07:32:40PM +0200, Sami Lehtinen wrote: > In this proposal, SSH_FXP_INIT packet has the following format > > uint32 version > > > This will, however, make version 3 and higher versions incompatible > with version 2 or lower (they won't understand the extension field). > > I will be happy to remove that field, unless someone can think of a > solid reason to leave it (we already have the SSH_FXP_EXTENDED > packet in this proposal). > > It is possible, of course, to work around this incompatibility, but it > would be cleaner implementationwise not to use different packet format > for the version packet as in the previous versions. > > -- > [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] > [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] > [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Wed Jan 10 21:59:02 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA10926 for ; Wed, 10 Jan 2001 21:59:01 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA18894 for ietf-ssh-outgoing; Thu, 11 Jan 2001 02:59:41 +0200 Message-Id: <200101110059.CAA18894@mail.clinet.fi> Received: from city-dialup.ttknet.ru ([213.59.165.241]) by mail.clinet.fi (8.9.3/8.9.3) with SMTP id CAA18890 for ; Thu, 11 Jan 2001 02:59:40 +0200 X-Server: Advanced Direct Remailer (www.elcomsoft.com) From: Александр X-Priority: 3 X-MSMail-Priority: Normal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 11 Jan 2001 03:11:58 +0300 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk NEVER SEND SPAM. IT IS BAD. From owner-ietf-ssh@clinet.fi Thu Jan 11 10:51:27 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05007 for ; Thu, 11 Jan 2001 10:51:26 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA09587 for ietf-ssh-outgoing; Thu, 11 Jan 2001 15:47:15 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA09575 for ; Thu, 11 Jan 2001 15:47:13 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 66471240822F; Thu, 11 Jan 2001 13:47:13 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id OAA01594; Thu, 11 Jan 2001 14:47:12 +0100 (MET) To: Sami Lehtinen Cc: IETF-SecSH List Subject: Re: filexfer version packet References: <14940.40120.396573.482246@asgard.tky.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 11 Jan 2001 14:47:12 +0100 In-Reply-To: Sami Lehtinen's message of "Wed, 10 Jan 2001 19:32:40 +0200" Message-ID: Lines: 38 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Sami Lehtinen writes: > In this proposal, SSH_FXP_INIT packet has the following format > > uint32 version > > > This will, however, make version 3 and higher versions incompatible > with version 2 or lower (they won't understand the extension field). What was the reason for including this field from the start? > It is possible, of course, to work around this incompatibility, but it > would be cleaner implementationwise not to use different packet format > for the version packet as in the previous versions. A clean way to keep the field would be to say as follows: 1. Both servers and clients MUST accept extensions data, and ignore any extensions they don't know about. In particular, if no extensions are known, all data after the version field is ignored completely. 2. Servers MAY send extension data, if the client is version 3 or higher. Note that the spec already requires the server not to send its SSH_FXP_INIT message until the client's message is received and processed, so that the client's version is always known by the time the servers message is sent. 3. Clients SHOULD not send any extension data, at this time. Doing so breaks interoperability with earlier protocol versions. As far as I can see, that shouldn't case any problems, it makes it easy to start using server extensions now, and it makes it possible to start using client extensions as soon as one believes pre-version-3 servers are no longer in use. /Niels From owner-ietf-ssh@clinet.fi Thu Jan 11 10:54:00 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05135 for ; Thu, 11 Jan 2001 10:53:59 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA07348 for ietf-ssh-outgoing; Thu, 11 Jan 2001 15:37:11 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA07342 for ; Thu, 11 Jan 2001 15:37:10 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 010E4240822F for ; Thu, 11 Jan 2001 13:37:10 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id OAA22701; Thu, 11 Jan 2001 14:37:09 +0100 (MET) To: ietf-ssh@clinet.fi Subject: draft-ietf-secsh-filexfer-00.txt, presentation References: <200101101146.GAA13351@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 11 Jan 2001 14:37:09 +0100 In-Reply-To: Internet-Drafts@ietf.org's message of "Wed, 10 Jan 2001 06:46:16 -0500" Message-ID: Lines: 50 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk I've read the draft, and I have a few comments. First, the presentation: * In section 3, the packet format is describes as follows: : 3. General Packet Format : : All packets transmitted over the secure connection are of the following : format: : : uint32 length : byte type : byte[length - 1] data payload Then particular messages are described as for example : Files are opened and created using the SSH_FXP_OPEN message, whose data : part is as follows: : : uint32 id : string filename : uint32 pflags : ATTRS attrs I think it would be clearer, and more consistent with the other secsh documents, to include the type byte in the payload. The descriptions would be changed to : uint32 length : byte[length] data payload (first byte is a type identifier) ... : Files are opened and created using the SSH_FXP_OPEN message, whose data : part is as follows: : : byte SSH_FXP_OPEN : uint32 id : string filename : uint32 pflags : ATTRS attrs * The document would be easier to read if the response (server to client) messages were described first. There are a large number of forward references to SSH_FXP_STATUS. I also have some comments on the protocol itself, which I'll write in a separate message. /Niels From owner-ietf-ssh@clinet.fi Thu Jan 11 10:56:26 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05251 for ; Thu, 11 Jan 2001 10:56:25 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA11802 for ietf-ssh-outgoing; Thu, 11 Jan 2001 15:56:44 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA11776 for ; Thu, 11 Jan 2001 15:56:40 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 914A7240822F for ; Thu, 11 Jan 2001 13:56:39 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id OAA09949; Thu, 11 Jan 2001 14:56:39 +0100 (MET) To: ietf-ssh@clinet.fi Subject: filexfer time stamps Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 11 Jan 2001 14:56:38 +0100 Message-ID: Lines: 16 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk In the filexfer protocol, time stamps (in file attributes) are represented as uint32. The consequences are 1. We get a year 2106-something problem. This doesn't matter much, as the protocol version can be increased and the timestamp field expanded in good time before that. 2. The protocol can't deal at all with files older than 1970. Perhaps the spec should note that the special value 0 means any time before 1970? Or should we use a _signed_ number instead (giving us a "2038 problem")? For the next 30 years, files older than 1970 will be more common than files dated after 2038. Not that I have any such old files (I was born 1971 ;-), but I would expect for instance any ITS mirror to have some. /Niels From owner-ietf-ssh@clinet.fi Thu Jan 11 11:00:31 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05453 for ; Thu, 11 Jan 2001 11:00:31 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id QAA13792 for ietf-ssh-outgoing; Thu, 11 Jan 2001 16:04:52 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id QAA13788 for ; Thu, 11 Jan 2001 16:04:51 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id E291E240822F for ; Thu, 11 Jan 2001 14:04:50 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id PAA17152; Thu, 11 Jan 2001 15:04:50 +0100 (MET) To: ietf-ssh@clinet.fi Subject: filexfer, create umask Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 11 Jan 2001 15:04:50 +0100 Message-ID: Lines: 13 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk When creating a file (using SSH_FXP_OPEN, with SSH_FXF_CREAT), I understand that the umask (however that is configured, probably in the /etc/profile if the ftp service is started by exec:ing /bin/sh -c sftp-subsystem) would be applied if the user doesn't specify any permission bits; this is a reasonable interpretation of "Default values will be used for those attributes that are not specified." But what if the permission bits *are* specified by the client? Should they be filtered through the user's umask, or should the server make sure they are really used as is (by clearing its umask)? /Niels From owner-ietf-ssh@clinet.fi Thu Jan 11 11:07:52 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05756 for ; Thu, 11 Jan 2001 11:07:51 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id QAA17758 for ietf-ssh-outgoing; Thu, 11 Jan 2001 16:25:06 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id QAA17726 for ; Thu, 11 Jan 2001 16:24:56 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id D78EC2402D5B for ; Thu, 11 Jan 2001 14:24:54 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id PAA04843; Thu, 11 Jan 2001 15:24:54 +0100 (MET) To: ietf-ssh@clinet.fi Subject: filexfer, SSH_FXP_STATUS Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 11 Jan 2001 15:24:54 +0100 Message-ID: Lines: 8 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk There's no place to put a human readable error message (like in the transport and connection protocols). Perhaps that should be added? It seems a little strange that the spec defines error codes SSH_FX_NO_CONNECTION SSH_FX_CONNECTION_LOST that never occur on the wire. /Niels From owner-ietf-ssh@clinet.fi Thu Jan 11 11:09:57 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05850 for ; Thu, 11 Jan 2001 11:09:56 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id QAA16360 for ietf-ssh-outgoing; Thu, 11 Jan 2001 16:17:24 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id QAA16349 for ; Thu, 11 Jan 2001 16:17:21 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 977262409FE6 for ; Thu, 11 Jan 2001 14:17:21 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id PAA28196; Thu, 11 Jan 2001 15:17:21 +0100 (MET) To: ietf-ssh@clinet.fi Subject: filexfer, SSH_FXP_READ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 11 Jan 2001 15:17:20 +0100 Message-ID: Lines: 26 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk The spec says "For normal disk files, it is guaranteed that this will read the specified number of bytes, or up to end of file. For e.g. device files this may return fewer bytes than requested." I'm interested in the case of reading from something that resembles a character special file like a serial port or tty. The above text seems to allow the server to reply with a SSH_FXP_DATA containing *zero* bytes. I'd think it would make a lot of sense to disallow this case. I think a server should be required to keep a SSH_FXP_READ request in the pending state until it can send a SSH_FXP_DATA reply containing at least one byte. Or send a SSH_FXP_STATUS of SSH_FX_EOF. Some other cases also need to be clarified: A SSH_FXP_READ with length = 0, can that return immediately, or should it stay pending until some data is available? The latter behaviour makes it possible to implement poll/select over the filexfer protocol. What happens if a client sends a SSH_FXP_CLOSE on a handle that have pending read or write requests? The spec requires the server to send replies for the read and write requests, in order, before sending a reply to the close request. What should the replies be? Some kind of status=interrupted, or an SSH_FXP_DATA with zero bytes data? /Niels From owner-ietf-ssh@clinet.fi Thu Jan 11 12:51:21 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10638 for ; Thu, 11 Jan 2001 12:51:20 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA30370 for ietf-ssh-outgoing; Thu, 11 Jan 2001 17:49:03 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA30363 for ; Thu, 11 Jan 2001 17:49:01 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 96F2D24086B7 for ; Thu, 11 Jan 2001 15:49:00 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id QAA19373; Thu, 11 Jan 2001 16:49:00 +0100 (MET) To: ietf-ssh@clinet.fi Subject: Re: draft-ietf-secsh-filexfer-00.txt, presentation References: <200101101146.GAA13351@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 From: nisse@lysator.liu.se (Niels Mцller) Date: 11 Jan 2001 16:48:59 +0100 In-Reply-To: nisse@lysator.liu.se's message of "11 Jan 2001 14:37:09 +0100" Message-ID: Lines: 15 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id RAA30370 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA10638 nisse@lysator.liu.se (Niels Mцller) writes: > I've read the draft, and I have a few comments. First, the > presentation: One more comment: I can't understand the final sentence in the description of SSH_FXP_NAME: "Each file is specified to be a minimum of certain number of character positions (indicated by the second line above), but may also be longer if the data does not fit in the specified length." /Niels From owner-ietf-ssh@clinet.fi Thu Jan 11 12:56:11 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10866 for ; Thu, 11 Jan 2001 12:56:10 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA31929 for ietf-ssh-outgoing; Thu, 11 Jan 2001 18:02:23 +0200 Received: from faui02.informatik.uni-erlangen.de (msfriedl@faui02.informatik.uni-erlangen.de [131.188.30.102]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA31926 for ; Thu, 11 Jan 2001 18:02:22 +0200 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id RAA06441; Thu, 11 Jan 2001 17:02:08 +0100 (MET) Date: Thu, 11 Jan 2001 17:02:08 +0100 From: Markus Friedl To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: ietf-ssh@clinet.fi Subject: Re: filexfer, SSH_FXP_STATUS Message-ID: <20010111170208.E22357@faui02.informatik.uni-erlangen.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 In-Reply-To: ; from nisse@lysator.liu.se on Thu, Jan 11, 2001 at 03:24:54PM +0100 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id SAA31929 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA10866 the drafts say about SSH_FX_NO_CONNECTION, SSH_FX_CONNECTION_LOST: it can only be generated locally by the client, and MUST NOT be returned by servers this is probably an implementation defail of the sftp client and should not be in the spec. perhaps a range of message types should be reserved for imlementation use? -m On Thu, Jan 11, 2001 at 03:24:54PM +0100, Niels Mцller wrote: > There's no place to put a human readable error message (like in the > transport and connection protocols). Perhaps that should be added? > > It seems a little strange that the spec defines error codes > SSH_FX_NO_CONNECTION SSH_FX_CONNECTION_LOST that never occur on the > wire. > > /Niels From owner-ietf-ssh@clinet.fi Thu Jan 11 18:25:01 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16319 for ; Thu, 11 Jan 2001 18:25:00 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA25816 for ietf-ssh-outgoing; Thu, 11 Jan 2001 23:18:19 +0200 Received: from mystery.acr.fi (ip212-226-160-97.adsl.kpnqwest.fi [212.226.160.97]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA25813 for ; Thu, 11 Jan 2001 23:18:18 +0200 Received: from localhost (ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) with ESMTP id XAA31541; Thu, 11 Jan 2001 23:16:04 +0200 X-Authentication-Warning: mystery.acr.fi: ylo owned process doing -bs Date: Thu, 11 Jan 2001 23:16:04 +0200 (EET) From: Tatu Ylonen X-Sender: ylo@mystery.acr.fi To: Niels Mvller cc: ietf-ssh@clinet.fi Subject: Re: filexfer, SSH_FXP_STATUS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > It seems a little strange that the spec defines error codes > SSH_FX_NO_CONNECTION SSH_FX_CONNECTION_LOST that never occur on the > wire. The motivation for including these is that an implementation will probably want to have some codes for these internally, and this way we guarantee that any implementation-specific codes don't conflict with the ones defined by the protocol. However, I don't strongly object if there is desire to remove them. But if we do that, we might reserve a range of error numbers for use by implementations (so that they will not be allocated in future protocol versions). If a human-readable code is added, I would do that as an extension in order to remain compatible with the installed base. Tatu From owner-ietf-ssh@clinet.fi Thu Jan 11 18:27:33 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16353 for ; Thu, 11 Jan 2001 18:27:32 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA24644 for ietf-ssh-outgoing; Thu, 11 Jan 2001 23:00:30 +0200 Received: from mystery.acr.fi (ip212-226-160-97.adsl.kpnqwest.fi [212.226.160.97]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA24632 for ; Thu, 11 Jan 2001 23:00:29 +0200 Received: from localhost (ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) with ESMTP id WAA31479; Thu, 11 Jan 2001 22:58:14 +0200 X-Authentication-Warning: mystery.acr.fi: ylo owned process doing -bs Date: Thu, 11 Jan 2001 22:58:14 +0200 (EET) From: Tatu Ylonen X-Sender: ylo@mystery.acr.fi To: Niels Mvller cc: Sami Lehtinen , IETF-SecSH List Subject: Re: filexfer version packet In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > > In this proposal, SSH_FXP_INIT packet has the following format > > > > uint32 version > > > > > > This will, however, make version 3 and higher versions incompatible > > with version 2 or lower (they won't understand the extension field). > > What was the reason for including this field from the start? I didn't think about it enough when I wrote the spec. I fully agree with Sami and others that we should keep the version exchange compatible. Generally the idea of the extension data was to allow smooth negotiation of support for various features that might be added in the future. Examples might include: - chroot support - rename support (I think that was in the base spec now but was only added less than a year ago) - file name syntax conventions - additional compression support - support for more advanced access control mechanisms - etc. > > It is possible, of course, to work around this incompatibility, but it > > would be cleaner implementationwise not to use different packet format > > for the version packet as in the previous versions. > > A clean way to keep the field would be to say as follows: > > 1. Both servers and clients MUST accept extensions data, and ignore > any extensions they don't know about. In particular, if no > extensions are known, all data after the version field is ignored > completely. > > 2. Servers MAY send extension data, if the client is version 3 or > higher. Note that the spec already requires the server not to send > its SSH_FXP_INIT message until the client's message is received and > processed, so that the client's version is always known by the time > the servers message is sent. > > 3. Clients SHOULD not send any extension data, at this time. Doing so > breaks interoperability with earlier protocol versions. > > As far as I can see, that shouldn't case any problems, it makes it > easy to start using server extensions now, and it makes it possible to > start using client extensions as soon as one believes pre-version-3 > servers are no longer in use. Or: client must not send extension data in their first version message, but if they have received a version 3 or higher reply fron the server they may send another SSH_FXP_INIT that contains extension data. Tatu From owner-ietf-ssh@clinet.fi Thu Jan 11 18:42:35 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16493 for ; Thu, 11 Jan 2001 18:42:34 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA25622 for ietf-ssh-outgoing; Thu, 11 Jan 2001 23:14:53 +0200 Received: from mystery.acr.fi (ip212-226-160-97.adsl.kpnqwest.fi [212.226.160.97]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA25619 for ; Thu, 11 Jan 2001 23:14:52 +0200 Received: from localhost (ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) with ESMTP id XAA31492; Thu, 11 Jan 2001 23:12:37 +0200 X-Authentication-Warning: mystery.acr.fi: ylo owned process doing -bs Date: Thu, 11 Jan 2001 23:12:37 +0200 (EET) From: Tatu Ylonen X-Sender: ylo@mystery.acr.fi To: Niels Mvller cc: ietf-ssh@clinet.fi Subject: Re: filexfer, SSH_FXP_READ In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > The spec says "For normal disk files, it is guaranteed that this will > read the specified number of bytes, or up to end of file. For e.g. > device files this may return fewer bytes than requested." > > I'm interested in the case of reading from something that resembles a > character special file like a serial port or tty. The above text seems > to allow the server to reply with a SSH_FXP_DATA containing *zero* > bytes. > > I'd think it would make a lot of sense to disallow this case. I think > a server should be required to keep a SSH_FXP_READ request in the > pending state until it can send a SSH_FXP_DATA reply containing at > least one byte. Or send a SSH_FXP_STATUS of SSH_FX_EOF. I would tend to agree with you. However, no-one has ever tried to use the protocol for anything useful with anything other than disk files, so there may be special issues that we haven't seen yet. Thus, I would consider the use of the protocol with devices as "experimental" (regardless of what we write in the spec). > Some other cases also need to be clarified: A SSH_FXP_READ with length > = 0, can that return immediately, or should it stay pending until some > data is available? The latter behaviour makes it possible to implement > poll/select over the filexfer protocol. Again, I didn't think about this when writing the spec. My first reaction would be to disallow length=0 rather than giving it poll semantics. My reason for this that the protocol has been designed so that it would (at least in theory) be possible to use it for implementing a remote file system. If it is ever used for that, and if select() is to be supported in a reasonable manner, we might want to implement it as a new feature (negotiated using the extensions in the initial version exchange) so that it allows polling multiple handles simultaneously. On the other hand, select() does not make much sense unless one support devices and/or sockets in some reasonable manner. For this reason, I would leave the use with devices/sockets/etc and the implementation of select open until someone comes up with real experience and a working implementation in a practical application. If that ever happens, I would then make it a separate RFC that amends this one. > What happens if a client sends a SSH_FXP_CLOSE on a handle that have > pending read or write requests? The spec requires the server to send > replies for the read and write requests, in order, before sending a > reply to the close request. What should the replies be? Some kind of > status=interrupted, or an SSH_FXP_DATA with zero bytes data? Again good question. My opinion is that the server MUST complete any earlier read/write requests before processing the close. Reason: provide an illusion of the operations being performed sequentially. If I recall correctly, the protocol placed a similar constraint on the order in which read/write operations are processed. I don't like the area of later operations affecting earlier ones unpredictably. Also, if close can be sent after write without waiting for wait completion first, we save one roundtrip per each file copied to the remote server. While not a big saving, other things being equal it is probably worth doing. Tatu From owner-ietf-ssh@clinet.fi Thu Jan 11 18:54:50 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16622 for ; Thu, 11 Jan 2001 18:54:49 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA26070 for ietf-ssh-outgoing; Thu, 11 Jan 2001 23:22:40 +0200 Received: from mystery.acr.fi (ip212-226-160-97.adsl.kpnqwest.fi [212.226.160.97]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA26065 for ; Thu, 11 Jan 2001 23:22:39 +0200 Received: from localhost (ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) with ESMTP id XAA31551; Thu, 11 Jan 2001 23:20:25 +0200 X-Authentication-Warning: mystery.acr.fi: ylo owned process doing -bs Date: Thu, 11 Jan 2001 23:20:25 +0200 (EET) From: Tatu Ylonen X-Sender: ylo@mystery.acr.fi To: =?X-UNKNOWN?Q?Niels_M=F6ller?= cc: ietf-ssh@clinet.fi Subject: Re: draft-ietf-secsh-filexfer-00.txt, presentation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > I can't understand the final sentence in the description of > SSH_FXP_NAME: "Each file is specified to be a minimum of certain > number of character positions (indicated by the second line above), > but may also be longer if the data does not fit in the specified > length." First, the "Each file" should probably be "Each field". The idea is that they are fixed-length fields, but if the value exceeds the length of the field, the field will be longer than the standard length. For example, assume 9 characters was allocated for file length (I don't remember how many the draft actually allocated), and the server used 64 bit file lengths and the file happened to be 1.5 terabytes (requiring 13 character positions). In this case, the length field would be expanded to 13 positions for that file, and the following fields would be shifted right by the extra 3 positions (as opposed to e.g. truncating the field). Tatu From owner-ietf-ssh@clinet.fi Thu Jan 11 20:15:34 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17174 for ; Thu, 11 Jan 2001 20:15:33 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA00762 for ietf-ssh-outgoing; Fri, 12 Jan 2001 01:09:06 +0200 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id BAA00759 for ; Fri, 12 Jan 2001 01:09:05 +0200 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id BAA11567; Fri, 12 Jan 2001 01:08:44 +0200 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Message-ID: <14942.15611.930044.407428@asgard.tky.hut.fi> Date: Fri, 12 Jan 2001 01:08:43 +0200 To: nisse@lysator.liu.se (Niels Mцller) Cc: ietf-ssh@clinet.fi Subject: draft-ietf-secsh-filexfer-00.txt, presentation In-Reply-To: References: <200101101146.GAA13351@ietf.org> X-Mailer: VM 6.87 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id BAA00762 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA17174 Niels Mцller, on January 11. 2001, wrote: : I've read the draft, and I have a few comments. First, the : presentation: : : * In section 3, the packet format is describes as follows: : I think it would be clearer, and more consistent with the other secsh : documents, to include the type byte in the payload. I agree with you, now that I think about this. : * The document would be easier to read if the response (server to : client) messages were described first. There are a large number of : forward references to SSH_FXP_STATUS. I have no strong opinions about this. -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Thu Jan 11 20:32:03 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17272 for ; Thu, 11 Jan 2001 20:32:03 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA01975 for ietf-ssh-outgoing; Fri, 12 Jan 2001 01:30:37 +0200 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id BAA01972 for ; Fri, 12 Jan 2001 01:30:37 +0200 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id BAA11591; Fri, 12 Jan 2001 01:30:11 +0200 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Message-ID: <14942.16899.543521.883389@asgard.tky.hut.fi> Date: Fri, 12 Jan 2001 01:30:11 +0200 To: nisse@lysator.liu.se (Niels Mцller) Cc: ietf-ssh@clinet.fi Subject: filexfer, SSH_FXP_STATUS In-Reply-To: References: X-Mailer: VM 6.87 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id BAA01975 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA17272 Niels Mцller, on January 11. 2001, wrote: : There's no place to put a human readable error message (like in the : transport and connection protocols). Perhaps that should be added? How about this: byte SSH_FXP_STATUS uint32 id uint32 error/status code string error message (ISO-10646 UTF-8) string language tag (as defined in [RFC-1766]) : It seems a little strange that the spec defines error codes : SSH_FX_NO_CONNECTION SSH_FX_CONNECTION_LOST that never occur on the : wire. I thought about this myself, and I agree. Those can be changed to reserved. -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Thu Jan 11 20:35:36 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17292 for ; Thu, 11 Jan 2001 20:35:35 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA00641 for ietf-ssh-outgoing; Fri, 12 Jan 2001 01:06:56 +0200 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id BAA00637 for ; Fri, 12 Jan 2001 01:06:55 +0200 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id BAA11564; Fri, 12 Jan 2001 01:06:33 +0200 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Message-ID: <14942.15481.723715.625247@asgard.tky.hut.fi> Date: Fri, 12 Jan 2001 01:06:33 +0200 To: nisse@lysator.liu.se (Niels Mцller) Cc: ietf-ssh@clinet.fi Subject: filexfer time stamps In-Reply-To: References: X-Mailer: VM 6.87 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id BAA00641 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA17292 Niels Mцller, on January 11. 2001, wrote: : In the filexfer protocol, time stamps (in file attributes) are : represented as uint32. The consequences are : : 1. We get a year 2106-something problem. This doesn't matter much, as : the protocol version can be increased and the timestamp field : expanded in good time before that. : : 2. The protocol can't deal at all with files older than 1970. Perhaps : the spec should note that the special value 0 means any time before : 1970? Or should we use a _signed_ number instead (giving us a "2038 : problem")? For the next 30 years, files older than 1970 will be : more common than files dated after 2038. Not that I have any such : old files (I was born 1971 ;-), but I would expect for instance any : ITS mirror to have some. Should this use a 64 bit signed integer? This would put the date range to something like -292471206707 to 292471210647 (in years). Of course, modern operating systems don't handle that (yet), but are we so far from that? 2038 is approaching us like a train... Of course, this could be a "little" overkill. 292 billion years to the past or the future could be considered excessive. OTOH, time_t usually is a 32 bit signed integer. This would leave us 37 years to handle the problem, but we couldn't have files dated before the universe existed... :) Cheers, -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Thu Jan 11 20:54:44 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17420 for ; Thu, 11 Jan 2001 20:54:43 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA01580 for ietf-ssh-outgoing; Fri, 12 Jan 2001 01:24:26 +0200 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id BAA01577 for ; Fri, 12 Jan 2001 01:24:25 +0200 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id BAA11580; Fri, 12 Jan 2001 01:24:03 +0200 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Message-ID: <14942.16531.605702.332859@asgard.tky.hut.fi> Date: Fri, 12 Jan 2001 01:24:03 +0200 To: nisse@lysator.liu.se (Niels Mцller) Cc: ietf-ssh@clinet.fi Subject: filexfer, create umask In-Reply-To: References: X-Mailer: VM 6.87 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id BAA01580 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA17420 Niels Mцller, on January 11. 2001, wrote: : When creating a file (using SSH_FXP_OPEN, with SSH_FXF_CREAT), I : understand that the umask (however that is configured, probably in the : /etc/profile if the ftp service is started by exec:ing /bin/sh -c : sftp-subsystem) would be applied if the user doesn't specify any : permission bits; this is a reasonable interpretation of "Default : values will be used for those attributes that are not specified." : : But what if the permission bits *are* specified by the client? Should : they be filtered through the user's umask, or should the server make : sure they are really used as is (by clearing its umask)? I think we want to use the *nix philosophy here, and use it filtered with umask. -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Thu Jan 11 21:25:42 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17629 for ; Thu, 11 Jan 2001 21:25:40 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA03720 for ietf-ssh-outgoing; Fri, 12 Jan 2001 01:59:11 +0200 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id BAA03717 for ; Fri, 12 Jan 2001 01:59:10 +0200 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id BAA11620; Fri, 12 Jan 2001 01:58:49 +0200 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14942.18617.492890.14891@asgard.tky.hut.fi> Date: Fri, 12 Jan 2001 01:58:49 +0200 To: Tatu Ylonen Cc: =?X-UNKNOWN?Q?Niels_M=F6ller?= , ietf-ssh@clinet.fi Subject: Re: draft-ietf-secsh-filexfer-00.txt, presentation In-Reply-To: References: X-Mailer: VM 6.87 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Tatu Ylonen, on January 11. 2001, wrote: : > I can't understand the final sentence in the description of : > SSH_FXP_NAME: "Each file is specified to be a minimum of certain : > number of character positions (indicated by the second line above), : > but may also be longer if the data does not fit in the specified : > length." : : First, the "Each file" should probably be "Each field". Ok, changed that. -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Fri Jan 12 11:15:47 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11532 for ; Fri, 12 Jan 2001 11:15:46 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id QAA09941 for ietf-ssh-outgoing; Fri, 12 Jan 2001 16:36:11 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id QAA09937 for ; Fri, 12 Jan 2001 16:36:09 +0200 Received: from merlin ([127.0.0.1]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 187 for ; Fri, 12 Jan 2001 07:40:31 -0700 Message-ID: <028401c07ca4$e1203900$2800a8c0@merlin> From: "Joseph Galbraith" To: Subject: Two comments on the filexfer draft Date: Fri, 12 Jan 2001 07:35:15 -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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit I have two comments on the file transfer draft. 1. We need to be careful of international language issues. I would recommend all file / path names should be specified as UTF-8. 2. Currently, there is no way to correctly interpret time information because we have no way of determining the timezone of the server. I would prefer that all times should be specified as UTC. Alternatively, adding a mechanism to discover server time zone information would be acceptable. Thanks, - Joseph From owner-ietf-ssh@clinet.fi Fri Jan 12 13:39:05 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14803 for ; Fri, 12 Jan 2001 13:39:05 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA21442 for ietf-ssh-outgoing; Fri, 12 Jan 2001 18:26:16 +0200 Received: from mystery.acr.fi (ip212-226-160-97.adsl.kpnqwest.fi [212.226.160.97]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA21436 for ; Fri, 12 Jan 2001 18:26:15 +0200 Received: from localhost (ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) with ESMTP id SAA23052; Fri, 12 Jan 2001 18:23:58 +0200 X-Authentication-Warning: mystery.acr.fi: ylo owned process doing -bs Date: Fri, 12 Jan 2001 18:23:58 +0200 (EET) From: Tatu Ylonen X-Sender: ylo@mystery.acr.fi To: Joseph Galbraith cc: ietf-ssh@clinet.fi Subject: Re: Two comments on the filexfer draft In-Reply-To: <028401c07ca4$e1203900$2800a8c0@merlin> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > 1. We need to be careful of international language issues. > I would recommend all file / path names should be specified > as UTF-8. I would tend to agree with you, even though this differs from the current implementation(s). > 2. Currently, there is no way to correctly interpret time > information because we have no way of determining the > timezone of the server. > > I would prefer that all times should be specified as UTC. > Alternatively, adding a mechanism to discover server time > zone information would be acceptable. I agree. (I was intending them to be UTC, and they are UTC in the existing implementation(s).) Tatu From owner-ietf-ssh@clinet.fi Fri Jan 12 13:39:31 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14814 for ; Fri, 12 Jan 2001 13:39:30 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA22562 for ietf-ssh-outgoing; Fri, 12 Jan 2001 18:40:56 +0200 Received: from mystery.acr.fi (ip212-226-160-97.adsl.kpnqwest.fi [212.226.160.97]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA22556 for ; Fri, 12 Jan 2001 18:40:55 +0200 Received: from localhost (ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) with ESMTP id SAA23058; Fri, 12 Jan 2001 18:38:37 +0200 X-Authentication-Warning: mystery.acr.fi: ylo owned process doing -bs Date: Fri, 12 Jan 2001 18:38:37 +0200 (EET) From: Tatu Ylonen X-Sender: ylo@mystery.acr.fi To: Sami Lehtinen cc: =?X-UNKNOWN?Q?Niels_M=F6ller?= , ietf-ssh@clinet.fi Subject: Re: filexfer, create umask In-Reply-To: <14942.16531.605702.332859@asgard.tky.hut.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > : But what if the permission bits *are* specified by the client? Should > : they be filtered through the user's umask, or should the server make > : sure they are really used as is (by clearing its umask)? > > I think we want to use the *nix philosophy here, and use it filtered > with umask. There may be practical implementation problems with this. The umask is typically set by the user's .cshrc files (or equivalent). The only way to get umask set is to run the user's login shell, have it evaluate all config files, and then run the file transfer code as a separate module. There are several reasons why I think this may be a bad idea: - some implementations may want to include sftp server in the same process that implements the SSH protocol - one could very reasonably want to create accounts that allow sftp transfers to/from certain subdirectories but nothing else (e.g., allowing product managers to information related to their own products on a web site). Enforcing such policies becomes tricky if the daemon reads config files. - umask makes it more difficult to implement e.g. "scp -p" (preserve modes) option. - I remember at least one account that I've had where the initial .cshrc did not set umask but .login did. .login is not executed when you just execute an external program through the login shell. - suppose the protocol was ever used as a file sharing protocol. What would happen if umask was implemented both by the client and by the server? None of these is a critical issue, but overall I think it would be better to not have the server do umask processing. Instead, I would add a note that if the client does not support unix-like file modes, it should not send any, and if the server does not receive modes for open/create, it should default to 644. Thus, my vote would be that server should clear umask, have a reasonable default, and client should send the modes if it wishes a particular mode. I don't have a very strong opinion though. Tatu From owner-ietf-ssh@clinet.fi Fri Jan 12 16:56:29 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25546 for ; Fri, 12 Jan 2001 16:56:26 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA05490 for ietf-ssh-outgoing; Fri, 12 Jan 2001 22:04:45 +0200 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id WAA05486 for ; Fri, 12 Jan 2001 22:04:44 +0200 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA19299; Fri, 12 Jan 2001 12:04:41 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.166]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id MAA09923; Fri, 12 Jan 2001 12:04:41 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f0CK4er392796; Fri, 12 Jan 2001 12:04:40 -0800 (PST) Message-Id: <200101122004.f0CK4er392796@jurassic.eng.sun.com> Date: Fri, 12 Jan 2001 12:04:40 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: Two comments on the filexfer draft To: ietf-ssh@clinet.fi, galb-list@vandyke.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: FWb0+TLQyVxj++PTbt8JSQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_26 SunOS 5.9 sun4u sparc Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > I would prefer that all times should be specified as UTC. This is what I assumed, but the text to make it explicit should be added. > Alternatively, adding a mechanism to discover server time > zone information would be acceptable. Timezones are complex enough as it is with out trying to discover what timezone a remote machine is running in. If it is a UNIX(like) system then it is runing in UTC and only displaying time in different timezones. I know this is not the case for other systems and it is differences like this that make such a discovery protocol very difficult to implement in a workable way for all systems. There are also platforms that could have SSH clients (and servers) for which there is no concept of a timezone (PalmOS has no timezone everything is localtime). I think the safest and easiest thing to do is say that the protocol uses UTC it is then upto each client and server implementations to make the appropriate translations if they need to. -- Darren J Moffat From owner-ietf-ssh@clinet.fi Fri Jan 12 17:12:06 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25876 for ; Fri, 12 Jan 2001 17:12:05 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id VAA04261 for ietf-ssh-outgoing; Fri, 12 Jan 2001 21:47:03 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id VAA04255 for ; Fri, 12 Jan 2001 21:47:01 +0200 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23152 for ; Fri, 12 Jan 2001 11:47:00 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id LAA04883 for ; Fri, 12 Jan 2001 11:46:59 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f0CJkxr389846 for ; Fri, 12 Jan 2001 11:46:59 -0800 (PST) Message-Id: <200101121946.f0CJkxr389846@jurassic.eng.sun.com> Date: Fri, 12 Jan 2001 11:46:59 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: filexfer time stamps To: ietf-ssh@clinet.fi MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: IvNbhO9dw3nRS8DT7aQdXg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_26 SunOS 5.9 sun4u sparc Sender: owner-ietf-ssh@clinet.fi Precedence: bulk ------------- Begin Forwarded Message ------------- > I'm interested in the rational for including nseconds in the definition of > nfstime4 (struct nfstime4 { int64_t seconds, uint32_t nseconds} ). The > reason behind this is that the SSH (secsh) IETF working group has just > published a draft for the filexfer subsystem of SSH. The draft currently > uses uint32_t for storing "file times". > > I suggested that the SSH filexfer draft should use the same representation > of time as NFSv4 but that raised the issue of why the need for nsecond > granularity for file systems. NFS version 2 used a regular BSD-style timeval with 32-bit seconds and 32-bit milliseconds. The milliseconds was changed to nanoseconds in NFS version 3. I think as a result of SVr4 switching to nanoseconds in one of its time values. NFS version 4 is just following in the NFS v3 tradition. I think the only discussion we had (you can check the mailing list archives) was over negative values for this quantity, or whether the time field should be used to represent dates prior to 1970. To my knowledge, there wasn't any real analysis of whether nanoseconds was more appropriate than milliseconds for file times. You can represent both in a 32-bit field, and it seemed to make sense to go for the more fine-grain one, even if there weren't any OS's that could support file times with this resolution - at some point in the future it could have become a big deal. A field with too much resolution isn't usually too much of a problem. I presume the SSH proposal is just a 1 second resolution. For most uses that's OK, but it could be a problem if you're comparing file times to see which file was created first, e.g. it's a big deal if you're doing a "make" :-) ------------- End Forwarded Message ------------- -- Darren J Moffat From owner-ietf-ssh@clinet.fi Fri Jan 12 17:12:46 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25898 for ; Fri, 12 Jan 2001 17:12:45 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA06387 for ietf-ssh-outgoing; Fri, 12 Jan 2001 22:18:55 +0200 Received: from gnat.inet.org (209-9-249-62.sdsl.cais.net [209.9.249.62]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id WAA06381 for ; Fri, 12 Jan 2001 22:18:53 +0200 Received: from mosquito.inet.org (mosquito.inet.org [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id B5AB18266C; Fri, 12 Jan 2001 15:17:35 -0500 (EST) Message-Id: <5.0.0.25.2.20010112150811.01ae6c00@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 12 Jan 2001 15:09:47 -0500 To: "Joseph Galbraith" From: RJ Atkinson Subject: Re: Two comments on the filexfer draft Cc: In-Reply-To: <028401c07ca4$e1203900$2800a8c0@merlin> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ssh@clinet.fi Precedence: bulk At 09:35 12/01/01, Joseph Galbraith wrote: >I have two comments on the file transfer draft. > >1. We need to be careful of international language issues. > I would recommend all file / path names should be specified > as UTF-8. It would be worthwhile, IMHO, to study how the IETF NFS WG dealt with file/pathname internationalisation in hopes that the IETF could handle this matter in a consistent way. >2. Currently, there is no way to correctly interpret time > information because we have no way of determining the > timezone of the server. > > I would prefer that all times should be specified as UTC. > Alternatively, adding a mechanism to discover server time > zone information would be acceptable. Either there ought to be a way of communicating timezone information xor the specification should state in crystal clear manner that all times are in UTC. IMHO, Ran rja@inet.org From owner-ietf-ssh@clinet.fi Fri Jan 12 17:18:12 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25986 for ; Fri, 12 Jan 2001 17:18:11 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id VAA05034 for ietf-ssh-outgoing; Fri, 12 Jan 2001 21:58:45 +0200 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id VAA05031 for ; Fri, 12 Jan 2001 21:58:43 +0200 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA16769 for ; Fri, 12 Jan 2001 11:58:41 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id LAA08033 for ; Fri, 12 Jan 2001 11:58:40 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f0CJwar391555 for ; Fri, 12 Jan 2001 11:58:37 -0800 (PST) Message-Id: <200101121958.f0CJwar391555@jurassic.eng.sun.com> Date: Fri, 12 Jan 2001 11:58:36 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: filexfer, create umask To: ietf-ssh@clinet.fi MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: SLE8kYKZxC6bIvHV+2eB3g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_26 SunOS 5.9 sun4u sparc Sender: owner-ietf-ssh@clinet.fi Precedence: bulk >None of these is a critical issue, but overall I think it would be better >to not have the server do umask processing. Instead, I would add a note >that if the client does not support unix-like file modes, it should not >send any, and if the server does not receive modes for open/create, it >should default to 644. All okay except I don't think the draft should mention permissions the server should use if no permissions are received. I think it should be upto the implmentations what they do and I would imagine either the umask of the process providing the service is used or it would be a config file type options to have it specify what to do. I don't think 644 is an acceptable thing to say we should do. The only think I think should be presumed is that there be sufficient permissions for the user who created the file to read it again assuming it hasn't been changed by some process outside of the protocol. -- Darren J Moffat From owner-ietf-ssh@clinet.fi Sat Jan 13 08:54:24 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17259 for ; Sat, 13 Jan 2001 08:54:24 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id OAA24616 for ietf-ssh-outgoing; Sat, 13 Jan 2001 14:07:34 +0200 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id OAA24613 for ; Sat, 13 Jan 2001 14:07:33 +0200 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id OAA13198; Sat, 13 Jan 2001 14:07:06 +0200 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14944.17642.65692.727298@asgard.tky.hut.fi> Date: Sat, 13 Jan 2001 14:07:06 +0200 To: "Joseph Galbraith" Cc: Subject: Two comments on the filexfer draft In-Reply-To: <028401c07ca4$e1203900$2800a8c0@merlin> References: <028401c07ca4$e1203900$2800a8c0@merlin> X-Mailer: VM 6.87 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Joseph Galbraith, on January 12. 2001, wrote: : I have two comments on the file transfer draft. : : 1. We need to be careful of international language issues. : I would recommend all file / path names should be specified : as UTF-8. I don't have a strong opinion about this. : 2. Currently, there is no way to correctly interpret time : information because we have no way of determining the : timezone of the server. I changed the draft to specify UTC in atime/ctime in ATTRS. I didn't add this to the `longname' description, as that field is filled in by the server, and it has no knowledge about the client. Clarification: IMO, if you type `ls -l' in the remote server, and print out longnames on a remote system from the same server, these should look about the same. -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Sun Jan 14 12:12:07 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09364 for ; Sun, 14 Jan 2001 12:12:07 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA08303 for ietf-ssh-outgoing; Sun, 14 Jan 2001 17:26:22 +0200 Received: from commserv.gea.ru ([212.44.145.130]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA08299 for ; Sun, 14 Jan 2001 17:26:21 +0200 Received: from eK3429Bqf (max1-69.losangeles.corecomm.net [216.214.106.197]) by commserv.gea.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id CZX7CZN6; Sun, 14 Jan 2001 16:23:50 +0300 DATE: 14 Jan 01 5:15:28 AM FROM: sandywho1212@yahoo.com Message-ID: <02DM63sEPDB> SUBJECT: Would you like to keep more of what you and your company earns? Sender: owner-ietf-ssh@clinet.fi Precedence: bulk With over 70% of our clients in the construction industry, we are experts in preparing financial statements to achieve the highest bonding and banking credit levels and-most importantly-minimizing your tax burden creatively. According to the Orange County Business Journal, of the 21 largest CPA firms in Orange County, Glenn M. Gelman & Associates is the only CPA firm specializing in the Construction Industry. And, we are so competent in serving the construction industry that Construction Link rated us the best accounting firm in Southern California. We are also proud to have been included in Inc. magazines list of America's 500 fastest growing privately held companies, the only CPA firm ever listed. You wouldn't use a screwdriver to hammer a nail. Why use a CPA firm that's not skilled in your industry? Glenn M. Gelman & Associates has the right tools for your accounting, tax and consulting needs, all built to what you do. To request further information please send an e-mail to Kara Kruger at Kkruger@gmgcpa.com. Thank you and we look forward to hearing from you. This mailing list is opt-in/subscriber ONLY. This is NOT SPAM and is never sent unsolicited. You are receiving this email because you or someone you know has subscribed for you at one of our associate web sites that offers free subscriptions and newsletters. If you no longer wish to receive any of our mailings please send an email to : sandywho1212@yahoo.com you will be removed permanently. Thanks From owner-ietf-ssh@clinet.fi Sun Jan 14 20:33:18 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11818 for ; Sun, 14 Jan 2001 20:33:18 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA04445 for ietf-ssh-outgoing; Mon, 15 Jan 2001 01:50:08 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id BAA04442 for ; Mon, 15 Jan 2001 01:50:07 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 677B8240C640; Sun, 14 Jan 2001 23:50:07 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id AAA08573; Mon, 15 Jan 2001 00:50:06 +0100 (MET) To: Sami Lehtinen Cc: ietf-ssh@clinet.fi Subject: Re: filexfer, SSH_FXP_STATUS References: <14942.16899.543521.883389@asgard.tky.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 From: nisse@lysator.liu.se (Niels Mцller) Date: 15 Jan 2001 00:50:06 +0100 In-Reply-To: Sami Lehtinen's message of "Fri, 12 Jan 2001 01:30:11 +0200" Message-ID: Lines: 21 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id BAA04445 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA11818 Sami Lehtinen writes: > Niels Mцller, on January 11. 2001, wrote: > : There's no place to put a human readable error message (like in the > : transport and connection protocols). Perhaps that should be added? > > How about this: > > byte SSH_FXP_STATUS > uint32 id > uint32 error/status code > string error message (ISO-10646 UTF-8) > string language tag (as defined in [RFC-1766]) Looks good to me. Specifying a preferred language can be done by some internal communication between the ssh server and the sftp subsystem, or by an extension to the filexfer protocol. So we don't need to say much about where languages come from in the filexfer document, just as we don't say much about it in the connection document. /Niels From owner-ietf-ssh@clinet.fi Sun Jan 14 20:40:18 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11891 for ; Sun, 14 Jan 2001 20:40:18 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA05177 for ietf-ssh-outgoing; Mon, 15 Jan 2001 02:01:27 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id CAA05174 for ; Mon, 15 Jan 2001 02:01:26 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 8ED84240C27B; Mon, 15 Jan 2001 00:01:25 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id BAA18627; Mon, 15 Jan 2001 01:01:25 +0100 (MET) To: Tatu Ylonen Cc: Sami Lehtinen , ietf-ssh@clinet.fi Subject: Re: filexfer, create umask References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 15 Jan 2001 01:01:24 +0100 In-Reply-To: Tatu Ylonen's message of "Fri, 12 Jan 2001 18:38:37 +0200 (EET)" Message-ID: Lines: 10 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Tatu Ylonen writes: > Thus, my vote would be that server should clear umask, have a reasonable > default, and client should send the modes if it wishes a particular mode. I agree. If the client goes to the trouble of providing the permission bits, it seems right to use them as they are, without filtering. (One might want the *client* to do umask filtering, though). /Niels From owner-ietf-ssh@clinet.fi Sun Jan 14 20:58:30 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12033 for ; Sun, 14 Jan 2001 20:58:29 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA05881 for ietf-ssh-outgoing; Mon, 15 Jan 2001 02:15:14 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id CAA05877 for ; Mon, 15 Jan 2001 02:15:14 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id C9B9A240C27B; Mon, 15 Jan 2001 00:15:13 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id BAA00938; Mon, 15 Jan 2001 01:15:13 +0100 (MET) To: Tatu Ylonen Cc: ietf-ssh@clinet.fi Subject: Re: filexfer, SSH_FXP_READ References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 15 Jan 2001 01:15:12 +0100 In-Reply-To: Tatu Ylonen's message of "Thu, 11 Jan 2001 23:12:37 +0200 (EET)" Message-ID: Lines: 34 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Tatu Ylonen writes: > > What happens if a client sends a SSH_FXP_CLOSE on a handle that have > > pending read or write requests? The spec requires the server to send > > replies for the read and write requests, in order, before sending a > > reply to the close request. What should the replies be? Some kind of > > status=interrupted, or an SSH_FXP_DATA with zero bytes data? > > Again good question. My opinion is that the server MUST complete > any earlier read/write requests before processing the close. Reason: > provide an illusion of the operations being performed sequentially. If I > recall correctly, the protocol placed a similar constraint on the order in > which read/write operations are processed. I don't like the area of later > operations affecting earlier ones unpredictably. Also, if close can be > sent after write without waiting for wait completion first, we save one > roundtrip per each file copied to the remote server. While not a big > saving, other things being equal it is probably worth doing. You have a point about pending writes. But I'm not sure about reads. It makes sense to me to close a handle when you don't want to complete pending read requests. The client can't really know if a file is special like /dev/tty, or has long or infinite response times for some other reason, and it still needs to be able to kill the handle. Perhaps we need two messages, one for friendly closing, and one for abrupt closing (somewhat like the SSH_CHANNEL_EOF and SSH_CHANNEL_CLOSE in the connection protocol)? If so, the behavior you describe should be assigned to the "friendly close" operation, and the abrupt close operation can perhaps wait until we have some experience with special files. What do other file sharing protocols do? /Niels From owner-ietf-ssh@clinet.fi Mon Jan 15 15:59:58 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15671 for ; Mon, 15 Jan 2001 15:59:57 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA03942 for ietf-ssh-outgoing; Mon, 15 Jan 2001 20:58:32 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA03939 for ; Mon, 15 Jan 2001 20:58:32 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 5A9E42402808; Mon, 15 Jan 2001 18:58:31 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id TAA22550; Mon, 15 Jan 2001 19:58:31 +0100 (MET) To: "Joseph Galbraith" Cc: Subject: Re: Two comments on the filexfer draft References: <028401c07ca4$e1203900$2800a8c0@merlin> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 15 Jan 2001 19:58:30 +0100 In-Reply-To: "Joseph Galbraith"'s message of "Fri, 12 Jan 2001 07:35:15 -0700" Message-ID: Lines: 20 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk "Joseph Galbraith" writes: > 1. We need to be careful of international language issues. > I would recommend all file / path names should be specified > as UTF-8. This could get messy, but perhaps it's necessary. If we do it, the document must also specify that either A. the server is responsible for respecting unicode canonical equivalence, or B. the client should normalize all filenames (according to some reasonable rules for normalization). When we were discussion usernames and passwords previously, I think the wg tended towards the former option. Again, it would be interesting to know what other file sharing protocols do. /Niels From owner-ietf-ssh@clinet.fi Mon Jan 15 17:54:42 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17174 for ; Mon, 15 Jan 2001 17:54:41 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA12022 for ietf-ssh-outgoing; Mon, 15 Jan 2001 22:45:40 +0200 Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id WAA12018 for ; Mon, 15 Jan 2001 22:45:39 +0200 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id PAA24752; Mon, 15 Jan 2001 15:45:34 -0500 (EST) Date: Mon, 15 Jan 2001 15:45:32 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: nisse@lysator.liu.se (Niels Mller) Cc: "Joseph Galbraith" , Subject: Re: Two comments on the filexfer draft In-Reply-To: Your message of 15 Jan 2001 19:58:30 +0100 Message-ID: Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > "Joseph Galbraith" writes: > > > 1. We need to be careful of international language issues. > > I would recommend all file / path names should be specified > > as UTF-8. > > This could get messy, but perhaps it's necessary. > If we do it, the document must also specify that either > > A. the server is responsible for respecting unicode canonical > equivalence, or > > B. the client should normalize all filenames (according to some > reasonable rules for normalization). > > When we were discussion usernames and passwords previously, I think > the wg tended towards the former option. Again, it would be > interesting to know what other file sharing protocols do. For the most part most file transfer protocols ignore the issue of path names since directory naming conventions and character set usage is not portable among operating systems. FTP uses the Unix conventions and recently adopted the notion that all names should use UTF-8. The IETF's requirement for the use of Unicode require the use of canonical representation in order to avoid security issues. This is true of all external representations. As for Usernames and Passwords, FTP punts. I believe the assumption is that all filenames and passwords are 7-bit US-ASCII or that the client and server are using common character-sets. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. From owner-ietf-ssh@clinet.fi Tue Jan 16 04:17:00 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07445 for ; Tue, 16 Jan 2001 04:16:59 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id JAA28197 for ietf-ssh-outgoing; Tue, 16 Jan 2001 09:27:56 +0200 Received: from mystery.acr.fi (ip212-226-160-97.adsl.kpnqwest.fi [212.226.160.97]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id JAA28110 for ; Tue, 16 Jan 2001 09:27:29 +0200 Received: from localhost (ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) with ESMTP id JAA03313; Tue, 16 Jan 2001 09:25:14 +0200 X-Authentication-Warning: mystery.acr.fi: ylo owned process doing -bs Date: Tue, 16 Jan 2001 09:25:13 +0200 (EET) From: Tatu Ylonen X-Sender: ylo@mystery.acr.fi To: Niels Mvller cc: ietf-ssh@clinet.fi Subject: Re: filexfer, SSH_FXP_READ In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > It makes sense to me to close a handle when you don't want to complete > pending read requests. The client can't really know if a file is > special like /dev/tty, or has long or infinite response times for some > other reason, and it still needs to be able to kill the handle. This is also a good point... > Perhaps we need two messages, one for friendly closing, and one for > abrupt closing (somewhat like the SSH_CHANNEL_EOF and > SSH_CHANNEL_CLOSE in the connection protocol)? If so, the behavior you > describe should be assigned to the "friendly close" operation, and the > abrupt close operation can perhaps wait until we have some experience > with special files. > > What do other file sharing protocols do? I think at least Unix systems interpret Unix devices at the client (i.e., if you have a device i-node on an NFS file system, it refers to that device on the client system). This means that operations never block on the server. In my opinion we shouldn't worry too much about file sharing. It is just a wild future possibility, which might never become real with this protocol. I wouldn't want to complicate the protocol because of that; if someone needs extensions later, they can be negotiated. Perhaps we should say that the file transfer server SHOULD NOT open files that are actually devices or sockets? There is also a denial of service risk here if server implementations are not careful. If someone actually tries to do something useful with devices, we could write a new draft/RFC at that point to describe the extensions that were made. Tatu From owner-ietf-ssh@clinet.fi Tue Jan 16 14:16:26 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19858 for ; Tue, 16 Jan 2001 14:16:25 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA23951 for ietf-ssh-outgoing; Tue, 16 Jan 2001 19:03:14 +0200 Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA23947 for ; Tue, 16 Jan 2001 19:03:13 +0200 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id MAA03727; Tue, 16 Jan 2001 12:03:06 -0500 (EST) Date: Tue, 16 Jan 2001 12:03:04 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Tero Kivinen Cc: nisse@lysator.liu.se (Niels Mller), "Joseph Galbraith" , Subject: Re: Two comments on the filexfer draft In-Reply-To: Your message of Tue, 16 Jan 2001 18:32:14 +0200 (EET) Message-ID: Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > I think we should say: > > C. The sender of the filename MUST send it in UTF-8 without any > normalization. The receiver of the filename SHOULD convert the > filename to follow the rules of the local file system, if the direct > UTF-8 filename is not acceptable for the local file system. The > receiver SHOULD NOT normalize the filename unless it is required by > the local file system. This allows original sender to get the original > filename back when it later tries to retrieve the file. The rules for generation and interpretation of UTF-8 are specified in Unicode 3.0.1: http://www.unicode.org/unicode/uni2errata/UTF-8_Corrigendum.html Normalization to shortest-form is required before interpretation. Clearly, its not possible to enforce a restriction on generation of non-shortest-form representations. non-shortest-form representations are very likely to be generated by attackers. > Also if we do normalization in both ends then we might end up having > two different files that have identical names after the normalization > process, thus one of them is inaccesable if we do normalization. Filesystems if they are using UTF-8 must use the shortest-form representation. Otherwise, they are non-compliant. > > FTP uses the Unix conventions and recently adopted the notion that all > > names should use UTF-8. The IETF's requirement for the use of Unicode > > require the use of canonical representation in order to avoid security > > issues. This is true of all external representations. > > Which security issues? Can you give me example what kind of security > issues we avoid if we do normalization? Anytime you have two representations of the same string you have a security issue. If I am building an exclude list I certainly should not have to be intelligent enough to specify all of the different ways that Unicode can represent the same string. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. From owner-ietf-ssh@clinet.fi Wed Jan 17 15:03:55 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25173 for ; Wed, 17 Jan 2001 15:03:54 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA15950 for ietf-ssh-outgoing; Wed, 17 Jan 2001 20:14:09 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA15944 for ; Wed, 17 Jan 2001 20:14:08 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id E14002407DFF; Wed, 17 Jan 2001 18:14:06 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id TAA01009; Wed, 17 Jan 2001 19:14:06 +0100 (MET) To: Tero Kivinen Cc: jaltman@columbia.edu, "Joseph Galbraith" , Subject: Re: Two comments on the filexfer draft References: <14948.16772.107201.132709@hutcs.cs.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 17 Jan 2001 19:14:06 +0100 In-Reply-To: Tero Kivinen's message of "Tue, 16 Jan 2001 18:32:14 +0200 (EET)" Message-ID: Lines: 56 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Tero Kivinen writes: > When the recipient receives that it should convert the filename to > format that is suitable for the file system. If the filesystem names > are already in unicode (or the file system does not have defined > character set for the filenames) it can directly store the filename in > the format the other end sent it. I'm not sure. If the OS/filesystem claims to be unicode compliant, it must treat names that are unicode canonical equivalents as the same name, but I'd prefer not doing any normalization inside a kernel filesystem driver. I don't know what existing unicode filesystems do. Or do they use some kind of retain-and-ignore-differences, just like some systems ignores case in filenames? > Also if we do normalization in both ends then we might end up having > two different files that have identical names after the normalization > process, thus one of them is inaccesable if we do normalization. You should never have two separate files whose names are unicode canonical equivalent. Either applications or the OS should stop you from doing that. Anyway, doing normalization at both ends seems unnecessary; it should be good enough to specify which end is responsible. I'd like the spec (preferably the architecture spec) to say that 1. Implementations MUST NEVER use overlong utf-8 representations. Then we only have to care about names that are equivalent in unicode. Does anybody disagree with that? 2. Either a) say that the server SHOULD respect unicode canonical equivalents, or b) say that the client is responsible for normalization. For 2b), perhaps we can get some guidance from Title : Character Normalization in ITEF Protocols Author(s) : M. Duerst, M. Davis Filename : draft-duerst-i18n-norm-04.txt Pages : 12 Date : 13-Sep-00 I believe those normalization rules should be friendly to applications that only want to translate common 8-bit character sets (like latin-x) to and from unicode. If we can't get utf-8 done right, it would be better not to do it at all. Problems caused by incompatible character sets should be a lot easier to understand and work around (programmers and users know how to recognize and deal with those problems) than problems caused by incompatible normalization and equivalence rules. /Niels From owner-ietf-ssh@clinet.fi Wed Jan 17 15:16:27 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25491 for ; Wed, 17 Jan 2001 15:16:26 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA17792 for ietf-ssh-outgoing; Wed, 17 Jan 2001 20:39:40 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA17787 for ; Wed, 17 Jan 2001 20:39:39 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 40308240822E; Wed, 17 Jan 2001 18:39:38 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id TAA24558; Wed, 17 Jan 2001 19:39:37 +0100 (MET) To: Tatu Ylonen Cc: ietf-ssh@clinet.fi Subject: Re: filexfer, SSH_FXP_READ References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 17 Jan 2001 19:39:37 +0100 In-Reply-To: Tatu Ylonen's message of "Tue, 16 Jan 2001 09:25:13 +0200 (EET)" Message-ID: Lines: 11 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Tatu Ylonen writes: > Perhaps we should say that the file transfer server SHOULD NOT open files > that are actually devices or sockets? There is also a denial of service > risk here if server implementations are not careful. I think it would be inappropriate to make a strong recommendation either way (SHOULD/SHOULD NOT). Just say that servers MAY refuse to open devices and special files. Or say nothing about it. /Niels From owner-ietf-ssh@clinet.fi Wed Jan 17 17:04:26 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26783 for ; Wed, 17 Jan 2001 17:04:25 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA25365 for ietf-ssh-outgoing; Wed, 17 Jan 2001 22:24:13 +0200 Received: from gnat.inet.org (209-9-249-62.sdsl.cais.net [209.9.249.62]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id WAA25360 for ; Wed, 17 Jan 2001 22:24:11 +0200 Received: from mosquito.inet.org (mosquito.inet.org [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id B88DB8264F; Wed, 17 Jan 2001 15:22:40 -0500 (EST) Message-Id: <5.0.0.25.2.20010117151310.01c3aeb0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 17 Jan 2001 15:14:37 -0500 To: nisse@lysator.liu.se (Niels Mцller) From: RJ Atkinson Subject: Re: filexfer, SSH_FXP_READ Cc: Tatu Ylonen , ietf-ssh@clinet.fi In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id WAA25365 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA26783 At 13:39 17/01/01, Niels Mцller wrote: >Tatu Ylonen writes: > >> Perhaps we should say that the file transfer server SHOULD NOT open files >> that are actually devices or sockets? There is also a denial of service >> risk here if server implementations are not careful. > >I think it would be inappropriate to make a strong recommendation >either way (SHOULD/SHOULD NOT). Just say that servers MAY refuse to >open devices and special files. Or say nothing about it. Disagree. While you and Tatu will be able to apply common sense and come up with something reasonable, in the modern IETF lots of folks who read the RFCs later on will do so slavishly without applying common sense. So it is sensible for the RFC to make some sensible recommendations SHOULD/SHOULD NOT, for the benefit of naive implementers (and their user base). Regards, Ran rja@inet.org From owner-ietf-ssh@clinet.fi Wed Jan 17 18:52:49 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29058 for ; Wed, 17 Jan 2001 18:52:48 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id AAA00726 for ietf-ssh-outgoing; Thu, 18 Jan 2001 00:16:50 +0200 Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id AAA00721 for ; Thu, 18 Jan 2001 00:16:49 +0200 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id RAA07611; Wed, 17 Jan 2001 17:16:42 -0500 (EST) Date: Wed, 17 Jan 2001 17:16:41 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Tero Kivinen Cc: "Joseph Galbraith" , Subject: Re: Two comments on the filexfer draft In-Reply-To: Your message of Wed, 17 Jan 2001 22:49:53 +0200 (EET) Message-ID: Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Using UTF-8 (or UCS2) for filenames raises all sorts of issues. . normalization is required to prevent files with duplicate names from being created on the receiving system; or the sending system transmitting two files with equivalent names but different representations to the receiver . normalization is required because it is very likely that given two files with equivalent names it is only possible to access one and not the other. This could be a security hole in that I can cause a file to be uploaded which will be accessed instead of the file that is really desired. . normalization as defined by the Unicode committee must be done by the sender and the receiver must reject any string that is not normalized . normalization is a nightmare. Performing normalization requires the every character in the string be looked up in a database to determine its shortest form. There are also compatiblity issues. When determining equivalence do you expand every character to base character and sorted list of modifiers and then perform the comparison (extensible) OR do you reduce every multi-byte representation to a single character (when possible) and then perform the comparison (not backward compatible). But before we even make this decision to use UTF-8, we need to decide if we want to preserve character set information in file names. At the moment most file systems do not have a well defined character set. NTFS uses Unicode as does Plan 9 and BFS (BeOS); but most other file systems are ignorant of character sets. The file names are just a series of 8-bit bytes. It is up to the applications to determine what the bytes mean. If we do not think that we can determine the character-set associated with a file name what should we do? We can't perform a translation from a random series of bytes to Unicode; nor can we translate from Unicode to an unknown character set. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. From owner-ietf-ssh@clinet.fi Thu Jan 18 10:23:32 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26356 for ; Thu, 18 Jan 2001 10:23:30 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id OAA21962 for ietf-ssh-outgoing; Thu, 18 Jan 2001 14:57:12 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id OAA21949 for ; Thu, 18 Jan 2001 14:57:11 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 4BC232408233; Thu, 18 Jan 2001 12:57:10 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id NAA20214; Thu, 18 Jan 2001 13:57:09 +0100 (MET) To: jaltman@columbia.edu Cc: Tero Kivinen , "Joseph Galbraith" , Subject: Re: Two comments on the filexfer draft References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 18 Jan 2001 13:57:09 +0100 In-Reply-To: Jeffrey Altman's message of "Wed, 17 Jan 2001 17:16:41 EST" Message-ID: Lines: 102 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Jeffrey Altman writes: > Using UTF-8 (or UCS2) for filenames raises all sorts of issues. > > . normalization is a nightmare. Performing normalization requires From draft-duerst-i18n-norm-04.txt, at least checking that a string is in normalized form seems simpler than normalizing it. I've written code to normalize unicode strings (into expanded form), and it's not terribly difficult, but I'd still prefer not having to do it in ssh implementation, in particular not in the server. I'd also like to quote the main principles from that draft: : For protocol elements used as identifiers, this document recommends : Internet protocols to specify the following: : : - Comparison SHOULD be carried out purely binary (after it has been : made sure, where necessary, that the texts to be compared are in : the same character encoding). : - Any kind of text, and in particular identifier-like protocol : elements, SHOULD be sent normalized to Normalization Form C. : - In case comparison fails due to a difference in text normalization, : the originator of the non-normalized text is responsible for the : failure. : - In case implementors are aware of the fact, or suspect, that their : underlying infrastructure produces non-normalized text, they SHOULD : take care to do the necessary tests, and if necessary the actual : normalization, by themselves. : - In the case of creation of identifiers, and in particular if this : creation is comparatively infrequent (e.g. newsgroup names, domain : names), and happens in a rather centralized manner, explicit checks : for normalization SHOULD be required by the protocol specification. > But before we even make this decision to use UTF-8, we need to decide > if we want to preserve character set information in file names. At > the moment most file systems do not have a well defined character > set. There are a few different cases to consider: 1. Communication between a unicode-aware system and a system that uses a smaller character set like iso-8859-1. 2. Communication between two systems using small character sets. 3. Communication between two unicode aware systems. To get (1) to work, using utf8 for all names seems like a good idea. For (2), if we ignore character sets issues completely, it will always "work", but with confusing results unless the character sets on both sides are the same. The problems should be familiar to anyone using characters beyong usascii. For (3) names on the wire will be utf-8. It doesn't really matter if they are in utf-8 because we require utf-8, or because it happens to be the natural octet-string representation of the system's native character set. Either way, differences in canonicalization will cause subtle problems. The most interesting cases are (1) and (2). If we want to facilitate communication between unicode and non-unicode systems, we should use utf-8 (this seems to be the ietf recommended choice). But then communication in case (2) will fail completely (not just produce confusing names) if the systems use distinct character sets. We either have to accept that, or not mandate utf-8, which in turn leads to mechanisms for explicitly declare what character set is being used. > We can't perform a translation from a random series of bytes to > Unicode; nor can we translate from Unicode to an unknown character > set. We could say that if an implementation have no idea of what character set is being used, it should interpret each byte as a latin1 character, and then convert the string to utf-8. This conversion at least doesn't not destroy any information, and it's very simple, if normalization form C is applied (draft-duerst-i18n-norm-04.txt). I think the first question we have to ask is if it is important to be able to use filenames that are random byte strings, with no sensible character set? If I understand Tatu right, at least he thinks so (I haven't made up my mind yet). If so, I think it is a mistake to mandate utf-8, it's better to leave the interpretation of filenames mostly undefined like the current (-00) draft, and add a separate message like uint8 SSH_FXP_UOPEN string filename [ in utf-8, normalization form C ] uint32 id uint32 pflags ATTRS attrs and similarly for SSH_FXP_UOPENDIR. The rest of the requests can be used as they are, with the understanding SSH_FXP_NAME uses the same conventions as the request it is a response to. > NTFS uses Unicode as does Plan 9 and BFS (BeOS) How do these filesystems deal with normalization? /Niels From owner-ietf-ssh@clinet.fi Thu Jan 18 12:50:46 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29565 for ; Thu, 18 Jan 2001 12:50:45 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id QAA14376 for ietf-ssh-outgoing; Thu, 18 Jan 2001 16:54:56 +0200 Received: from watsun.cc.columbia.edu (IDENT:cu41754@watsun.cc.columbia.edu [128.59.39.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id QAA14366 for ; Thu, 18 Jan 2001 16:54:46 +0200 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id JAA11134; Thu, 18 Jan 2001 09:31:49 -0500 (EST) Date: Thu, 18 Jan 2001 9:31:48 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu Cc: Tero Kivinen , "Joseph Galbraith" , Subject: Re: Two comments on the filexfer draft In-Reply-To: Your message of 18 Jan 2001 13:57:09 +0100 Message-ID: Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > > if we want to preserve character set information in file names. At > > the moment most file systems do not have a well defined character > > set. > > There are a few different cases to consider: > > 1. Communication between a unicode-aware system and a system that uses > a smaller character set like iso-8859-1. > > 2. Communication between two systems using small character sets. > > 3. Communication between two unicode aware systems. > > To get (1) to work, using utf8 for all names seems like a good idea. > > For (2), if we ignore character sets issues completely, it will always > "work", but with confusing results unless the character sets on both > sides are the same. The problems should be familiar to anyone using > characters beyong usascii. How can you say that "it will always work"? It never works unless you have to be lucky enough to be using the same character set on both systems. Kermit has dealt with this issue of character set issues for almost 20 years. Kermit explicitly requires the user to specify the character sets used on the local and remote systems. And then the sender translates from the local set to a standard ISO-8869-X (or now Unicode) character set and the receiver translates back to the character set on its system. If you don't do this you are playing a game of chance. > For (3) names on the wire will be utf-8. It doesn't really matter if > they are in utf-8 because we require utf-8, or because it happens to > be the natural octet-string representation of the system's native > character set. Either way, differences in canonicalization will cause > subtle problems. > > The most interesting cases are (1) and (2). If we want to facilitate > communication between unicode and non-unicode systems, we should use > utf-8 (this seems to be the ietf recommended choice). But then > communication in case (2) will fail completely (not just produce > confusing names) if the systems use distinct character sets. We either > have to accept that, or not mandate utf-8, which in turn leads to > mechanisms for explicitly declare what character set is being used. > > > We can't perform a translation from a random series of bytes to > > Unicode; nor can we translate from Unicode to an unknown character > > set. > > We could say that if an implementation have no idea of what character > set is being used, it should interpret each byte as a latin1 > character, and then convert the string to utf-8. This conversion at > least doesn't not destroy any information, and it's very simple, if > normalization form C is applied (draft-duerst-i18n-norm-04.txt). This will fail on Windows because the Microsoft Code Pages used for storing file names violate the rules of ISO-8859 character sets since they contain printable characters in the C1 control range. > I think the first question we have to ask is if it is important to be > able to use filenames that are random byte strings, with no sensible > character set? If I understand Tatu right, at least he thinks so (I > haven't made up my mind yet). If so, I think it is a mistake to > mandate utf-8, it's better to leave the interpretation of filenames > mostly undefined like the current (-00) draft, and add a separate > message like > > uint8 SSH_FXP_UOPEN > string filename [ in utf-8, normalization form C ] > uint32 id > uint32 pflags > ATTRS attrs > > and similarly for SSH_FXP_UOPENDIR. The rest of the requests can be > used as they are, with the understanding SSH_FXP_NAME uses the same > conventions as the request it is a response to. Character sets must be translated from the local into some agreed upon intermediary form. Otherwise, you run the risk of taking a file name from Windows (CP1252) and placing it on Unix where all the applications use ISO-8859-1 and now suddenly you have file names that can't be displayed to the user and worse (when using ECMA-48 compatible terminals: VT...) the use of the C1 space for printable characters can cause the terminal to be shifted into an undesireable state. > > NTFS uses Unicode as does Plan 9 and BFS (BeOS) > > How do these filesystems deal with normalization? Both of these filesystems are Unicode 1.x based. Unicode 1.x precedes most canonicalization rules and certainly all of the discussions regarding security problems with Unicode. I doubt there is any normalization performed in these file systems. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. From owner-ietf-ssh@clinet.fi Thu Jan 18 17:46:43 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06505 for ; Thu, 18 Jan 2001 17:46:42 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA10445 for ietf-ssh-outgoing; Thu, 18 Jan 2001 22:34:22 +0200 Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id WAA10441 for ; Thu, 18 Jan 2001 22:34:21 +0200 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id PAA26821; Thu, 18 Jan 2001 15:34:16 -0500 (EST) Date: Thu, 18 Jan 2001 15:34:15 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Tero Kivinen Cc: "Joseph Galbraith" , Subject: Re: Two comments on the filexfer draft In-Reply-To: Your message of Thu, 18 Jan 2001 22:28:39 +0200 (EET) Message-ID: Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > > Character sets must be translated from the local into some agreed upon > > intermediary form. Otherwise, you run the risk of taking a file name > > from Windows (CP1252) and placing it on Unix where all the > > applications use ISO-8859-1 and now suddenly you have file names that > > can't be displayed to the user and worse (when using ECMA-48 > > compatible terminals: VT...) the use of the C1 space for printable > > characters can cause the terminal to be shifted into an undesireable > > state. > > Of course they will see the filenames, they just might be funny, like > "h?h?" or h\366h\344 or h:f6:h:e4: etc. If the application does not > know how to show that kind of filenames then the application is > broken. Also if the local filesystem completely forbids some > characters (for example somebody transfers file named "foo:bar" to > macintosh system), then it is up to the local end (i.e the macintosh) > to convert the offending characters something it can cope with. > Hopefully it will use a method that it can reverse when seeing that > filename again later... Please read the ISO standards for character-sets. An application is not broken if it cannot display a file name because the file name is illegal. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. From owner-ietf-ssh@clinet.fi Sat Jan 20 18:02:09 2001 Received: from mail.clinet.fi ([194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29884 for ; Sat, 20 Jan 2001 18:02:08 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA26872 for ietf-ssh-outgoing; Sat, 20 Jan 2001 23:09:17 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA26867 for ; Sat, 20 Jan 2001 23:09:15 +0200 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18585 for ; Sat, 20 Jan 2001 13:09:14 -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,v1.7) with ESMTP id QAA29620 for ; Sat, 20 Jan 2001 16:09:14 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id f0KL8T5118602 for ; Sat, 20 Jan 2001 16:08:30 -0500 (EST) Message-Id: <200101202108.f0KL8T5118602@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@clinet.fi Subject: San Diego secsh meeting minutes (draft) Reply-to: sommerfeld@east.sun.com Date: Sat, 20 Jan 2001 16:08:29 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Send corrections to me.. Minutes of the secsh working group Monday December 11, 2000 Notes taken by "RL 'Bob' Morgan" revised by Bill Sommerfeld We first discussed the core protocol drafts, with a quick review of the open issues and changes from last time. A. Core SECSH protocol drafts. 1. Authentication User certificates: we don't have any implementation experience yet. 2. Transport - optimistic algorithm negotiation Sami will reverse-engineer from ssh implementation and write it down - public key algorithms vs certificates Need to be able to specify PK algorithms and cert formats independently. Joseph Galbraith[?] made a proposal: extend names to multi-part eg x509v3-sign-rsa, x509v3-sign-dss; is that enough? Tero says yes. Requirement for client to ask for cert from specific CA? No. Negotiate cert exchange after key exchange? this adds more round trips ... - AES key sizes 256 is required, 128 optional, is this overkill? only 80 bits of key material from DH anyway ... Lisa Yin: 256 is more secure due to larger number of rounds - Twofish also needs variable key size Key size should be in all new alg names; this helps with interoperability. We're not going to bother renaming existing fixed size ciphers, even though we can have aliases: twofish and twofish256 as same. 3. Connection - signals: Is current draft language OK? yes - forwarding to multiple X11 displays An attendee brought up an issue with X11 forwarding to multiple displays through a single ssh connection; the demultiplexing info gets lost. Maybe some language is needed on how to fix this in the client, maybe a and new draft is needed to specify an extension to really fix it. 4. Architecture Comment from Jeff Hutzelman : the architecture draft requires "every host must have a host key"; this is unnecessary, and is not needed for kerberos. Change to SHOULD? Comment from Jeff Hutzelman : Documents are unclear on why the DH exchange involves the host key.. is it to detect a man-in-the-middle attack? What should go there for a key exchange which doesn't use the host key? IANA considerations: Jeff Schiller (Security AD): We have to do pass over all docs for IANA considerations. The IANA considerations section still needs review and work [This was discusssed offline and on the list after the meeting] B. Extensions 1. Use of GSSAPI/Kerberos for SECSH authentication and key exchange. we had impromptu presentations from the authors of several different individual submissions on tying together SECSH with kerberos and/or GSSAPI. a. Kerberos/GSS, Joe Salowey, now jsalowey@cisco.com Protocol: Two variants: o Ties Kerberos into key exchange, by using kerberos to authenticate the DH exchange (uses kerberos session key to encrypt the DH hash) o pure Kerberos: just use the Kerberos session key, which is faster than doing DH, but loses PFS. Possible change to GSS? adds more round trips. is GSS delegation too limited? it's what people use Is this a secsh WG thing or a krbwg thing? it's a ssh change, not a Kerb or GSS change, hence secsh. b. GSS key exchange, Jeff Hutzelman Draft not yet sent to list. Propose a "null host key" algorithm to deal with host that has no host key but can do GSSAPI authentication. Kerberos key type? no, not for GSS case; there's no need to distinguish various types of secret keys add "external" user authentication via key exchange so a separate user authentication step is not needed. Consensus at the meeting to make this a WG draft. c. Joseph Galbraith, vandyke.com Using GSS for user authentication. Disallows use of GSSAPI algorithm negotiation (ie SPNEGO), since ssh already protects negotiation. Need to express GSS mechs as OIDs, in capability list; some clarification needed on userauth failure. Tying them together: Why two proposals? Are they complementary? yes - If a client knows host's DSS key, might want to use that and not do GSS key exchange - a GSS mechanism might not support integrity, and therefore not be useful for key exchange. - Might want to do GSS key exchange to avoid the usual MITM problem, but authenticate user via public key or some other means. Text explaining all this will be added to the documents. Kerberos/GSS issues Kerberos vs GSS? Consensus seems to be for using GSS now. However: we should prohibit use of SPNEGO (GSSAPI's algorithm negotiation mechanism) as secsh negotiation already covers that; collapsing two levels of negotiation to one prevents certain kinds of negotiation failures. What happened to the prior proposal from Tatu? had too many problems. The use of Kerberos for password checking on the server is not a protocol issue and is out of scope for this WG. 2. Keyboard-interactive It's "back from the dead"; Martin has resurrected it and released a new rev. keyboard-interactive, Martin Forssen For authentication methods that don't need/want specific support just "interact with user" via prompts/responses? All this happens (as userauth always does) after transport encryption for Securid, challenge-response tokens, forced password changing OTP Client request includes language tag, device name(s) service name, etc server sends text to be displayed client responds, etc this idea tried and rejected before in ssh, but this had larger scope, to cover biometric, binary, etc so learn from past excesses Maybe "device" is confusing since could just be "method"? Need multiple questions in a single round trip? PAM could use that, but doesn't require it Can there be multiple roundtrips? Yes, like any userauth method Does this work with WAP phones? (SIM cards?) no. Biometrics should be done as a separate authentication method PAM is easy to add ... ? 3. Public-key channel, Joseph Galbraith ssh public key channel replaces public-key file format? Intent is to solve problem of users getting PKs to servers. Current draft has problems, will be rewritten New one should use "subsystem" rather than "channel"? yes, subsystem, because adding subsystem is easier (in some implementations?) Some subsystems give "shell" output where it isn't wanted, which causes whole thing to fail; is this a broken subsystem implementation?) Bill: proposed keyfile format to establish access to new machines; PK channel proposal only handles managing keys after you authenticate. The keyfile thing still needs to be done, as standards track. (many non-protocol things are stds) Jeff Vandyke will write that draft. Possibly a separate doc for handling Kerberos/GSS config. From owner-ietf-ssh@clinet.fi Sat Jan 20 18:26:50 2001 Received: from mail.clinet.fi ([194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00026 for ; Sat, 20 Jan 2001 18:26:50 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA28515 for ietf-ssh-outgoing; Sat, 20 Jan 2001 23:46:56 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA28512 for ; Sat, 20 Jan 2001 23:46:55 +0200 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25657 for ; Sat, 20 Jan 2001 13:46:54 -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,v1.7) with ESMTP id QAA01023 for ; Sat, 20 Jan 2001 16:46:53 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id f0KLk95118641 for ; Sat, 20 Jan 2001 16:46:09 -0500 (EST) Message-Id: <200101202146.f0KLk95118641@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@clinet.fi Subject: WG Last Call for secsh core drafts. Reply-to: sommerfeld@east.sun.com Date: Sat, 20 Jan 2001 16:46:09 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk A Working Group Last Call begins today and will end in two weeks for the following four drafts: draft-ietf-secsh-architecture-07.txt draft-ietf-secsh-transport-09.txt draft-ietf-secsh-userauth-09.txt draft-ietf-secsh-connect-09.txt I believe that these documents likely represent the current consensus of the working group and should be submitted to the IESG for consideration for publication as a Proposed Standard. Comments regarding the content of these documents should be sent to the working group mailing list, . If you believe a change to a document is necessary, it would be very helpful if you include revised wording along with your comment. This Last Call period extends until February 3rd, 2001. - Bill From owner-ietf-ssh@clinet.fi Sun Jan 21 21:13:58 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12678 for ; Sun, 21 Jan 2001 21:13:57 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA06007 for ietf-ssh-outgoing; Mon, 22 Jan 2001 02:29:10 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id CAA06001 for ; Mon, 22 Jan 2001 02:29:09 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id D2B972402D56; Mon, 22 Jan 2001 00:29:03 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id BAA21043; Mon, 22 Jan 2001 01:29:03 +0100 (MET) To: jaltman@columbia.edu Cc: Tero Kivinen , "Joseph Galbraith" , Subject: Re: Two comments on the filexfer draft References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 22 Jan 2001 01:29:03 +0100 In-Reply-To: Jeffrey Altman's message of "Thu, 18 Jan 2001 9:31:48 EST" Message-ID: Lines: 96 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Jeffrey Altman writes: > > For (2), if we ignore character sets issues completely, it will always > > "work", but with confusing results unless the character sets on both > > sides are the same. The problems should be familiar to anyone using > > characters beyong usascii. > > How can you say that "it will always work"? It never works unless you > have to be lucky enough to be using the same character set on both > systems. What I meant with "work" was that you will get the file across, although perhaps with a file name that is improperly translated. This is different (and possibly better) than the fatal "File could not be transferred because of incompatibel file name character sets" error which you would get if you *do* convert filenames to and from utf-8 (or use some other means to negotiate character sets), and the two systems don't support the same characters locally. I'm not saying this is a good idea, I just want to point out that the problems it causes are well known and people have been able to live with them before. To avoiding problems, one either avoids using "strange" characters (which one would *have* to do anyway if character set translation were done more strictly), or rename the files later. > > > We can't perform a translation from a random series of bytes to > > > Unicode; nor can we translate from Unicode to an unknown character > > > set. > > > > We could say that if an implementation have no idea of what character > > set is being used, it should interpret each byte as a latin1 > > character, and then convert the string to utf-8. This conversion at > > least doesn't not destroy any information, and it's very simple, if > > normalization form C is applied (draft-duerst-i18n-norm-04.txt). > > This will fail on Windows because the Microsoft Code Pages used for > storing file names violate the rules of ISO-8859 character sets since > they contain printable characters in the C1 control range. Huh? Either the character set is considered known, and it is mapped properly to utf-8, or it is assumed to be bogus, and the characters are interpreted as latin-1 (with the control characters mapped to corresponding unicode reserved area in the latin-1 range) for purposes of mapping it to and from utf-8. This idea may be stupid, but I don't see how your example breaks it. I would expect a well-behaved ssh implementation on windows to know the character set that is used, and that an ssh implementation on unix will either know what character set is to be used for file names on the system, or be happy to use a microsoft codepage for some filenames. > Character sets must be translated from the local into some agreed upon > intermediary form. Otherwise, you run the risk of taking a file name > from Windows (CP1252) and placing it on Unix where all the > applications use ISO-8859-1 and now suddenly you have file names that > can't be displayed to the user and worse (when using ECMA-48 > compatible terminals: VT...) the use of the C1 space for printable > characters can cause the terminal to be shifted into an undesireable > state. To me, that would be annoying, but not a terrible problem. And the alternative to getting files with garbled names is failure to transfer those files at all. In another mail you wrote: > Please read the ISO standards for character-sets. An application is > not broken if it cannot display a file name because the file name is > illegal. I'm not sure what "illegal" means here. From my point of view, each conceivable file name is either legal or illegal (on a given operating system or file system). 1. If a filename is legal, than applications should be prepared to handle it some reasonable way. Applications that don't do that are broken. 2. And if a name is illegal, then the system must not allow any application to create a file with that name. If the system allows that, the system is broken. An example is the NFS deamon in some unix kernel that that allowed clients (in particular Macs) to create directory entries containing the '/' character. We're drifting a little off-topic here. One important questions for the working group ought to be * Do we need to support file names that are random byte strings? The only objection to normalization I've noticed so far (from Tatu) seems to be based on a desire to support file names that are random byte strings. Regards, /Niels From owner-ietf-ssh@clinet.fi Tue Jan 23 08:12:41 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10430 for ; Tue, 23 Jan 2001 08:12:40 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id NAA07819 for ietf-ssh-outgoing; Tue, 23 Jan 2001 13:21:25 +0200 Received: from ixion.tartarus.org (ixion.tartarus.org [195.153.205.133]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id NAA07816 for ; Tue, 23 Jan 2001 13:21:24 +0200 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 14L1Vs-00085L-00; Tue, 23 Jan 2001 11:21:24 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@clinet.fi Subject: X forwarding: suggestions Message-Id: Date: Tue, 23 Jan 2001 11:21:24 +0000 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Hi, I maintain PuTTY, a Windows SSH1/SSH2 client. I've recently implemented X forwarding, and I have a couple of suggestions about authentication of the X client connections. (I'm currently considering the usual case of forwarding X connections from the SSH server to the SSH client, so I'll use the terms `client' and `server' that way round. I'm aware SSH2 is more symmetric than that really.) Suggestion 1: allow the client to do better ------------------------------------------- Currently, the auth data PuTTY invents to send to the server uses the MIT-MAGIC-COOKIE-1 protocol: the client demonstrates that it possesses the same shared secret as the server by simply quoting the whole secret. This is of course vulnerable to a passive network listener. (An active man-in-the-middle can _always_ subvert an X connection, because after the auth phase there is no integrity protection. So I'll consider passive attacks only.) A slightly better protocol is XDM-AUTHORIZATION-1, in which the client uses half the shared secret as a DES key with which it encrypts: - the other half of the shared secret - the source IP address and port of the X connection (or other equivalent data for connections over media other than IP) - a timestamp. The server decrypts this claim and verifies the components. The XDM specification states that the timestamp should be verified to within a 20 minute tolerance either way. I would like PuTTY to be able to provide this auth protocol as an alternative to MIT-MAGIC-COOKIE-1. In order to do so, PuTTY would need to know the source IP and port of the forwarded connection. SSH2, in the protocol spec, claims to provide this: string originator address (e.g. "192.168.7.38") uint32 originator port but in practice, OpenSSH provided a hostname instead of an address. This is useless for verifying an IP, because one hostname may map to more than one IP, and/or the DNS at the other end may be different (for example, consider a private network with internal DNS). If the SSH2 protocol were to mandate the provision of an actual IP address rather than a hostname, X forwarding would become significantly more secure against passive network listeners. (IPv6 and other network protocols would also be a consideration; I don't know what support the X protocol has for IPv6 as yet.) Suggestion 2: make the server do it! ------------------------------------ Better still, it seems to me, why not make the SSH _server_ invent the remote auth data and verify it? This doesn't allow any new attacks by somebody subverting the SSH server and causing it to accept unauthenticated connections, because the SSH server already has access to the fake auth data, so anyone who subverts it can _already_ pull off this attack. So it places no additional trust in the SSH server to let it authenticate incoming X connections. The advantage would be that the server can perform XDM-AUTHORIZATION-1 or other complex authentications very easily, because it obviously does have access to the source IP/port of the incoming connection - or to the equivalent if the connection should come in on a Unix domain socket. It seems silly to forward all the details back to the client and make the client do it, when there's no reason for the server not to just do it itself. The server would them strip out the auth strings from the X connection before forwarding it back to the client; and the client could insert the real auth strings to allow the connection to be accepted by the real X server. So each end deals only with what's important at that end. Cheers, Simon -- Simon Tatham "loop, infinite _see_ infinite loop" - Index, Borland Pascal Language Guide From owner-ietf-ssh@clinet.fi Tue Jan 23 10:09:07 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14162 for ; Tue, 23 Jan 2001 10:09:05 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA03472 for ietf-ssh-outgoing; Tue, 23 Jan 2001 15:15:23 +0200 Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA03450 for ; Tue, 23 Jan 2001 15:15:17 +0200 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id IAA23815; Tue, 23 Jan 2001 08:15:14 -0500 (EST) Date: Tue, 23 Jan 2001 8:15:11 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Simon Tatham Cc: ietf-ssh@clinet.fi Subject: Re: X forwarding: suggestions In-Reply-To: Your message of Tue, 23 Jan 2001 11:21:24 +0000 Message-ID: Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > Suggestion 2: make the server do it! > ------------------------------------ > > Better still, it seems to me, why not make the SSH _server_ invent > the remote auth data and verify it? > > This doesn't allow any new attacks by somebody subverting the SSH > server and causing it to accept unauthenticated connections, because > the SSH server already has access to the fake auth data, so anyone > who subverts it can _already_ pull off this attack. So it places no > additional trust in the SSH server to let it authenticate incoming > X connections. > > The advantage would be that the server can perform > XDM-AUTHORIZATION-1 or other complex authentications very easily, > because it obviously does have access to the source IP/port of the > incoming connection - or to the equivalent if the connection should > come in on a Unix domain socket. It seems silly to forward all the > details back to the client and make the client do it, when there's > no reason for the server not to just do it itself. > > The server would them strip out the auth strings from the X > connection before forwarding it back to the client; and the client > could insert the real auth strings to allow the connection to be > accepted by the real X server. So each end deals only with what's > important at that end. This is almost what Telnet Forward-X does. The only difference is that the Telnet Client replaces the stripped Xauth data with the data necessary to authenticate to the local X server. This allows daisy chained connections to be protected. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. From owner-ietf-ssh@clinet.fi Tue Jan 23 12:41:11 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18912 for ; Tue, 23 Jan 2001 12:41:10 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA29951 for ietf-ssh-outgoing; Tue, 23 Jan 2001 17:23:32 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA29943 for ; Tue, 23 Jan 2001 17:23:29 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 4AA89240319B; Tue, 23 Jan 2001 15:23:28 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id QAA25559; Tue, 23 Jan 2001 16:23:27 +0100 (MET) To: Simon Tatham Cc: ietf-ssh@clinet.fi Subject: Re: X forwarding: suggestions References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 23 Jan 2001 16:23:26 +0100 In-Reply-To: Simon Tatham's message of "Tue, 23 Jan 2001 11:21:24 +0000" Message-ID: Lines: 40 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Simon Tatham writes: > I would like PuTTY to be able to provide this auth protocol as an > alternative to MIT-MAGIC-COOKIE-1. In order to do so, PuTTY would > need to know the source IP and port of the forwarded connection. > SSH2, in the protocol spec, claims to provide this: > > string originator address (e.g. "192.168.7.38") > uint32 originator port > > but in practice, OpenSSH provided a hostname instead of an address. If so, that seems to be a bug in OpenSSH, the "originator address" ought to be either an ipv4 address (in dotted decimal notation), or an IPv6 address literal. But fixing that would not quite solve your problem, I'm afraid. For instance, "127.0.0.1" is a reasonable address but probably not very useful for authentication purposes. And the originator may also be using an AF_LOCAL socket, in which case an empty string may be a reasonable thing to put in the "originator address" field. > Suggestion 2: make the server do it! > ------------------------------------ > > Better still, it seems to me, why not make the SSH _server_ invent > the remote auth data and verify it? [...] > The server would them strip out the auth strings from the X > connection before forwarding it back to the client; and the client > could insert the real auth strings to allow the connection to be > accepted by the real X server. So each end deals only with what's > important at that end. Sounds very reasonable to me. Regards, /Niels From owner-ietf-ssh@clinet.fi Tue Jan 23 17:53:32 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25844 for ; Tue, 23 Jan 2001 17:53:31 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA31044 for ietf-ssh-outgoing; Tue, 23 Jan 2001 23:06:51 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA31040 for ; Tue, 23 Jan 2001 23:06:50 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id CA3C22402D4A; Tue, 23 Jan 2001 21:06:49 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id WAA19031; Tue, 23 Jan 2001 22:06:49 +0100 (MET) To: ietf-ssh@clinet.fi Cc: sommerfeld@east.sun.com Subject: RSA signature encoding (Re: WG Last Call for secsh core drafts) References: <200101202146.f0KLk95118641@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 23 Jan 2001 22:06:49 +0100 In-Reply-To: Bill Sommerfeld's message of "Sat, 20 Jan 2001 16:46:09 -0500" Message-ID: Lines: 31 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk The encoding rules for ssh-rsa signatures (in the transport draft) : The resulting signature is encoded as follows: : : string "ssh-rsa" : string rsa_signature_blob : : rsa_signature_blob is encoded as a string containing s (which is an : integer, without lengths or padding, unsigned and in network byte : order). is not consistent with the architecture draft, : mpint : [...] : : By convention, a number that is used in modular computations in : Z_n SHOULD be represented in the range 0 <= x < n. The value s is definitely such a number. Why is it not encoded as an mpint? The differences in the actual encoding rules are small (the differences is when leading zero digits are allowed or required). Using two almost equivalent encodings for numbers only adds to confusion and complexity. I also believe that any argument for not using mpint in the RSA case would apply equally well to most other the places in the protocol where mpints are used. Regards, /Niels From owner-ietf-ssh@clinet.fi Wed Jan 24 04:40:57 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA17296 for ; Wed, 24 Jan 2001 04:40:56 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id JAA17910 for ietf-ssh-outgoing; Wed, 24 Jan 2001 09:54:25 +0200 Received: from tolstoi.ru.hilti.com ([195.239.59.130]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id JAA17903 for ; Wed, 24 Jan 2001 09:54:23 +0200 Received: by tolstoi.ru.hilti.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jan 2001 10:45:09 +0300 Message-ID: From: "Shesterikov Maxim (sm)" To: ietf-ssh@clinet.fi Subject: Comments for draft-ietf-secsh-auth-kbdinteract-01.txt Date: Wed, 24 Jan 2001 10:45:08 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="koi8-r" Sender: owner-ietf-ssh@clinet.fi Precedence: bulk For a server that uses a separate authentication layer it is desirable to state in the draft that the order of responses should match with the order of prompts. Maxim From owner-ietf-ssh@clinet.fi Wed Jan 24 09:08:31 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20928 for ; Wed, 24 Jan 2001 09:08:31 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id OAA18472 for ietf-ssh-outgoing; Wed, 24 Jan 2001 14:21:12 +0200 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id OAA18446 for ; Wed, 24 Jan 2001 14:21:09 +0200 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18617; Wed, 24 Jan 2001 07:21:08 -0500 (EST) Message-Id: <200101241221.HAA18617@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@clinet.fi From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-publickeyfile-00.txt Date: Wed, 24 Jan 2001 07:21:07 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk --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 : SECSH Public Key File Format Author(s) : J. Galbraith, R. Thayer Filename : draft-ietf-secsh-publickeyfile-00.txt Pages : 4 Date : 23-Jan-01 This document formally documents the existing public key file format in use for exchanging public keys between different SECSH implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickeyfile-00.txt 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-publickeyfile-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-publickeyfile-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <20010123115438.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-publickeyfile-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-publickeyfile-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010123115438.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ssh@clinet.fi Wed Jan 24 13:22:32 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27114 for ; Wed, 24 Jan 2001 13:22:31 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA01874 for ietf-ssh-outgoing; Wed, 24 Jan 2001 18:39:29 +0200 Received: from fries.net (ns0.fries.net [206.30.141.10]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA01861 for ; Wed, 24 Jan 2001 18:39:19 +0200 Received: (from todd@localhost) by fries.net (8.10.1/8.10.1) id f0OGcvJ14727; Wed, 24 Jan 2001 10:38:57 -0600 (CST) Date: Wed, 24 Jan 2001 10:38:57 -0600 From: "Todd T. Fries" To: ietf-ssh@clinet.fi Subject: draft-ietf-secsh-publickeyfile-00.txt Message-ID: <20010124103857.F9152@eclipse.fries.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-PGP-Fingerprint: B6 3B 70 46 BC 0F 8C DD 14 D4 C7 D1 47 F6 23 FA Sender: owner-ietf-ssh@clinet.fi Precedence: bulk It's been brought to my attention that this draft is still open for comment. I come from a UNIX background (OpenBSD specifically) and it seems rather strange for a standard to state: `MUST be terminated with a ' then later Because current practice is to terminate lines with only, implementations SHOULD be able to read files with lines terminated only by a for backwards compatibility reasons. Ok, so we are suggesting that we have a file that is readable with eol, and the clients should always, for backwards compatibility, be able to read that file, but new files should be generated with `'? I fail to see the necessity or logic this follows. If the client should read either format, then it would be my two cents worth that the draft should allow either format, given the obvious benifit of allowing files to be exchanged between different os types that prefer different `native' textfile formats. Why should you mandate one over the other? And if you were to mandate one, why pick the one that carries extra size with it? Besides my not liking on unix, there exists a behavior of many unix people that might cause problems if the mandated format ends in . That is to remove the every time a text file is encountered that contains one, since it wastes space and looks rather ugly in editors. So not only does it not make sense with respect to filesize increase, it also will cause problems for users of unix everywhere if they don't know that the really belongs in a text file. Please reconsider the manditory and allow either, suggested new wording: 3. Key File Format SECSH implementations must share public key files between the client and the server in order interoperate. A key file consists of a sequence of lines, each of which MUST be terminated with a or a and MUST NOT exceed 72 bytes in length (excluding the or line terminator.) Implementations MUST be able to read files with lines terminated by a or a for compatibility reasons. There are other locations where exists in the document, I am certain that if the above is accepted that they will be changed similarly. The other alternative is to not deviate from the current practice referred in the original wording: Because current practice is to terminate lines with only Either way makes sense to me, but if people desire , I hardly think it should be a mandate; rather an option. Thanks, -- Todd Fries .. todd@fries.net From owner-ietf-ssh@clinet.fi Wed Jan 24 18:50:53 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02355 for ; Wed, 24 Jan 2001 18:50:53 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA27524 for ietf-ssh-outgoing; Wed, 24 Jan 2001 23:53:34 +0200 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA27520 for ; Wed, 24 Jan 2001 23:53:31 +0200 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA19698 for ; Wed, 24 Jan 2001 13:53:29 -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,v1.7) with ESMTP id QAA22463 for ; Wed, 24 Jan 2001 16:53:29 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id f0OLrS5124804 for ; Wed, 24 Jan 2001 16:53:28 -0500 (EST) Message-Id: <200101242153.f0OLrS5124804@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@clinet.fi Subject: Re: draft-ietf-secsh-publickeyfile-00.txt In-reply-to: Your message of "Wed, 24 Jan 2001 10:38:57 CST." <20010124103857.F9152@eclipse.fries.net> Reply-to: sommerfeld@east.sun.com Date: Wed, 24 Jan 2001 16:53:28 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk I think a better way out of the line-terminator morass is for the draft to say as little as possible about line termination and just specify that this is a text file format. Files in this format should therefore be transferred as text files (sequences of lines, which are sequences of printable characters), not binary files. Since people commonly forget to do this, implementations SHOULD be robust in the face of unexpected line terminators (CR only, LF only, or CR LF). - Bill From owner-ietf-ssh@clinet.fi Wed Jan 24 22:35:54 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA06294 for ; Wed, 24 Jan 2001 22:35:53 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id DAA09140 for ietf-ssh-outgoing; Thu, 25 Jan 2001 03:49:19 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id DAA09137 for ; Thu, 25 Jan 2001 03:49:17 +0200 Received: from viper2 ([127.0.0.1]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 647 for ; Wed, 24 Jan 2001 18:54:10 -0700 Message-ID: <003901c08670$dde73470$0201a8c0@vandyke.com> From: "Jeff P. Van Dyke" To: References: <200101242153.f0OLrS5124804@thunk.east.sun.com> Subject: Re: draft-ietf-secsh-publickeyfile-00.txt Date: Wed, 24 Jan 2001 18:47:48 -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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Bill Sommerfeld writes: > I think a better way out of the line-terminator morass is for the > draft to say as little as possible about line termination and just > specify that this is a text file format. I think just saying it is a text file is a mistake. > Files in this format should therefore be transferred as text files > (sequences of lines, which are sequences of printable characters), not > binary files. Unlike FTP, sftp doesn't distinguish between ASCII and BINARY. If you're going to upload your public key with sftp or scp2 from a Windows box to a UNIX box (or visa versa), where does the line terminator get fixed? > Since people commonly forget to do this, implementations SHOULD be > robust in the face of unexpected line terminators (CR only, LF only, > or CR LF). Protocols like SMTP, IMAP and SSH2 (at least for the ident string) require both . If the current draft requiring as the line terminator isn't acceptable to majority of the WG, I think we should require implementors to support both and . Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Wed Jan 24 23:09:43 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06705 for ; Wed, 24 Jan 2001 23:09:37 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id EAA11615 for ietf-ssh-outgoing; Thu, 25 Jan 2001 04:32:36 +0200 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id EAA11612 for ; Thu, 25 Jan 2001 04:32:34 +0200 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA14658; Wed, 24 Jan 2001 18:32:30 -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,v1.7) with ESMTP id VAA25954; Wed, 24 Jan 2001 21:32:29 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id f0P2WS5128857; Wed, 24 Jan 2001 21:32:28 -0500 (EST) Message-Id: <200101250232.f0P2WS5128857@thunk.east.sun.com> From: Bill Sommerfeld To: nisse@lysator.liu.se (Niels M ller) cc: ietf-ssh@clinet.fi, sommerfeld@east.sun.com Subject: Re: RSA signature encoding (Re: WG Last Call for secsh core drafts) In-reply-to: Your message of "23 Jan 2001 22:06:49 +0100." Reply-to: sommerfeld@east.sun.com Date: Wed, 24 Jan 2001 21:32:28 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > The encoding rules for ssh-rsa signatures (in the transport draft) > > : The resulting signature is encoded as follows: > : > : string "ssh-rsa" > : string rsa_signature_blob > : > : rsa_signature_blob is encoded as a string containing s (which is an > : integer, without lengths or padding, unsigned and in network byte > : order). > > is not consistent with the architecture draft, > > : mpint > : [...] > : > : By convention, a number that is used in modular computations in > : Z_n SHOULD be represented in the range 0 <= x < n. > > The value s is definitely such a number. Why is it not encoded as an > mpint? The differences in the actual encoding rules are small (the > differences is when leading zero digits are allowed or required). My evaluation of this is that this isn't an editorial change, since "mpint" is a signed integer. For modulus sizes which are a multiple of 8 bits, a sender using the "string" encoding will send a value with the most significant bit set about half the time, which an "mpint" decoder will interpret as a negative value. So, do we want to leave the draft alone, or should we include include an implementation note that says that mpints received as an rsa_signature_blob should always be treated as positive numbers? Any views from the implementors? Is consistency important enough to warrant breaking interoperability? How big of an installed base does this signature type have? Do we need to pick a new name? > Using two almost equivalent encodings for numbers only adds to > confusion and complexity. Understood, though one can argue consistency with the dss signature blob (which is also sent as a string). - Bill From owner-ietf-ssh@clinet.fi Wed Jan 24 23:11:33 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06741 for ; Wed, 24 Jan 2001 23:11:32 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id EAA11810 for ietf-ssh-outgoing; Thu, 25 Jan 2001 04:36:33 +0200 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id EAA11807 for ; Thu, 25 Jan 2001 04:36:31 +0200 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA15503; Wed, 24 Jan 2001 18:36:27 -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,v1.7) with ESMTP id VAA26450; Wed, 24 Jan 2001 21:36:27 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id f0P2aQ5128871; Wed, 24 Jan 2001 21:36:26 -0500 (EST) Message-Id: <200101250236.f0P2aQ5128871@thunk.east.sun.com> From: Bill Sommerfeld To: "Jeff P. Van Dyke" cc: ietf-ssh@clinet.fi Subject: Re: draft-ietf-secsh-publickeyfile-00.txt In-reply-to: Your message of "Wed, 24 Jan 2001 18:47:48 MST." <003901c08670$dde73470$0201a8c0@vandyke.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 24 Jan 2001 21:36:26 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > Unlike FTP, sftp doesn't distinguish between ASCII > and BINARY. maybe we should fix this rather than overspecifying things in the key file format.. - Bill From owner-ietf-ssh@clinet.fi Wed Jan 24 23:49:29 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA07415 for ; Wed, 24 Jan 2001 23:49:28 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id FAA13295 for ietf-ssh-outgoing; Thu, 25 Jan 2001 05:02:55 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id FAA13292 for ; Thu, 25 Jan 2001 05:02:53 +0200 Received: from viper2 ([127.0.0.1]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 297 for ; Wed, 24 Jan 2001 20:07:46 -0700 Message-ID: <000901c0867b$26959310$0201a8c0@vandyke.com> From: "Jeff P. Van Dyke" To: References: <200101250236.f0P2aQ5128871@thunk.east.sun.com> Subject: Re: draft-ietf-secsh-publickeyfile-00.txt Date: Wed, 24 Jan 2001 20:01:27 -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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit > > Unlike FTP, sftp doesn't distinguish between ASCII > > and BINARY. > > maybe we should fix this rather than overspecifying things in the key > file format.. I consider mentioning this. I'm not sure which is a bigger can of worms. Maybe one of the authors of the sftp draft could comment... Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Thu Jan 25 00:34:15 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07854 for ; Thu, 25 Jan 2001 00:34:14 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id FAA15669 for ietf-ssh-outgoing; Thu, 25 Jan 2001 05:48:26 +0200 Received: from pianosa.catch22.org (postfix@pianosa.catch22.org [64.81.70.4]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id FAA15664 for ; Thu, 25 Jan 2001 05:48:25 +0200 Received: by pianosa.catch22.org (Postfix, from userid 1000) id 89B61177A; Wed, 24 Jan 2001 19:48:22 -0800 (PST) Date: Wed, 24 Jan 2001 19:48:22 -0800 From: David Terrell To: ietf-ssh@clinet.fi Subject: Re: draft-ietf-secsh-publickeyfile-00.txt Message-ID: <20010124194821.A2062@pianosa.catch22.org> Reply-To: David Terrell References: <200101242153.f0OLrS5124804@thunk.east.sun.com> <003901c08670$dde73470$0201a8c0@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <003901c08670$dde73470$0201a8c0@vandyke.com>; from jpv@vandyke.com on Wed, Jan 24, 2001 at 06:47:48PM -0700 X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 7:46PM up 65 days, 7:39, 30 users, load averages: 0.54, 0.26, 0.20 X-Baby-Due-In: 47 days, 4 hours, 13 minutes, 51 seconds Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Wed, Jan 24, 2001 at 06:47:48PM -0700, Jeff P. Van Dyke wrote: > Bill Sommerfeld writes: > > Since people commonly forget to do this, implementations SHOULD be > > robust in the face of unexpected line terminators (CR only, LF only, > > or CR LF). > > Protocols like SMTP, IMAP and SSH2 (at least for the ident > string) require both . This is on the wire, not a local file. And yes, is the common EOL for wire protocols. > If the current draft requiring as the line terminator > isn't acceptable to majority of the WG, I think we should require > implementors to support both and . And for Macintosh-origin files, so we're right back to what Bill suggested. Dave, not a mac bigot, just amused at EOL madness. -- David Terrell | "The reasons for my decision to quit were myriad, but Nebcorp PM | central to the decision was the realization that there are dbt@meat.net | two kinds of companies: Good ones ask you to think for wwn.nebcorp.com | them. The others tell you to think like them." -Benjy Feen From owner-ietf-ssh@clinet.fi Thu Jan 25 00:43:11 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07880 for ; Thu, 25 Jan 2001 00:43:11 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id FAA14525 for ietf-ssh-outgoing; Thu, 25 Jan 2001 05:26:31 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id FAA14521 for ; Thu, 25 Jan 2001 05:26:30 +0200 Received: from viper2 ([127.0.0.1]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 582 for ; Wed, 24 Jan 2001 20:31:23 -0700 Message-ID: <001f01c0867e$72dfe150$0201a8c0@vandyke.com> From: "Jeff P. Van Dyke" To: References: <200101202146.f0KLk95118641@thunk.east.sun.com> Subject: Are we going to add a magic cookie to sftp? Date: Wed, 24 Jan 2001 20:25:18 -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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit In section 4.6 of the connection draft, http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-09.txt I was pleased to see the following new text: As the user's shell is usually used to execute the subsystem, it is advisable for the subsystem protocol to have a "magic cookie" at the beginning of the protocol transaction to distinguish from arbitrary output from shell initialization scripts etc. This spurious output from the shell may be filtered out either at the server or at the client. Are there plans to update the sftp draft http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-00.txt to include such a magic cookie? Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Thu Jan 25 05:20:46 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22870 for ; Thu, 25 Jan 2001 05:20:45 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id KAA16297 for ietf-ssh-outgoing; Thu, 25 Jan 2001 10:15:40 +0200 Received: from faui02.informatik.uni-erlangen.de (msfriedl@faui02.informatik.uni-erlangen.de [131.188.30.102]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id KAA16289 for ; Thu, 25 Jan 2001 10:15:38 +0200 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id JAA24883; Thu, 25 Jan 2001 09:15:36 +0100 (MET) Date: Thu, 25 Jan 2001 09:15:36 +0100 From: Markus Friedl To: ietf-ssh@clinet.fi Cc: openssh@openbsd.org Subject: Re: Are we going to add a magic cookie to sftp? Message-ID: <20010125091536.B24046@faui02.informatik.uni-erlangen.de> References: <200101202146.f0KLk95118641@thunk.east.sun.com> <001f01c0867e$72dfe150$0201a8c0@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <001f01c0867e$72dfe150$0201a8c0@vandyke.com>; from jpv@vandyke.com on Wed, Jan 24, 2001 at 08:25:18PM -0700 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Wed, Jan 24, 2001 at 08:25:18PM -0700, Jeff P. Van Dyke wrote: > http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-09.txt > > I was pleased to see the following new text: > > As the user's shell is usually used to execute the > subsystem, it is advisable for the subsystem protocol > to have a "magic cookie" at the beginning of the protocol > transaction to distinguish from arbitrary output from > shell initialization scripts etc. This spurious output > from the shell may be filtered out either at the server > or at the client. i really think that this paragraph should be deleted from the drafts, since the subsystem protocols (e.g. secsh-filexfer) are not the place where misconfigurations and broken shell accounts should be fixed. > Are there plans to update the sftp draft > > http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-00.txt > > to include such a magic cookie? oh please, do not. the filetransfer protocol is not a place where you can fix every possible system configuration error. i don't like to see the secsh protocol suite move towards a drop-in box for features that might be useful for this and that obscure situation. we should try to avoid any kind of bloat. -markus From owner-ietf-ssh@clinet.fi Thu Jan 25 06:06:29 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23220 for ; Thu, 25 Jan 2001 06:06:27 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id LAA28351 for ietf-ssh-outgoing; Thu, 25 Jan 2001 11:04:48 +0200 Received: from kado.mindrot.org (foobar@CPE-203-45-24-18.vic.bigpond.net.au [203.45.24.18]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id LAA28334 for ; Thu, 25 Jan 2001 11:04:45 +0200 Received: from toad.mindrot.org (toad.mindrot.org [203.44.118.252]) by kado.mindrot.org (Postfix) with ESMTP id F07009004; Thu, 25 Jan 2001 20:01:39 +1100 (EST) Received: from mothra.mindrot.org (mothra.mindrot.org [203.44.118.225]) by toad.mindrot.org (Postfix) with ESMTP id 2AAEE1A4B0; Thu, 25 Jan 2001 20:04:39 +1100 (EST) Received: by mothra.mindrot.org (Postfix, from userid 500) id A7FA93C08B; Thu, 25 Jan 2001 20:04:37 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by mothra.mindrot.org (Postfix) with ESMTP id A40283C08A; Thu, 25 Jan 2001 20:04:37 +1100 (EST) Date: Thu, 25 Jan 2001 20:04:37 +1100 (EST) From: Damien Miller To: Markus Friedl Cc: ietf-ssh@clinet.fi, openssh@openbsd.org Subject: Re: Are we going to add a magic cookie to sftp? In-Reply-To: <20010125091536.B24046@faui02.informatik.uni-erlangen.de> 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: owner-ietf-ssh@clinet.fi Precedence: bulk On Thu, 25 Jan 2001, Markus Friedl wrote: > oh please, do not. the filetransfer protocol is not a place where you > can fix every possible system configuration error. i don't like to see > the secsh protocol suite move towards a drop-in box for features that > might be useful for this and that obscure situation. we should try > to avoid any kind of bloat. Agreed. Why not skip the shell initialisation altogether for subsystems? -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From owner-ietf-ssh@clinet.fi Thu Jan 25 07:42:03 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24484 for ; Thu, 25 Jan 2001 07:42:02 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA14410 for ietf-ssh-outgoing; Thu, 25 Jan 2001 12:21:16 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id MAA14277 for ; Thu, 25 Jan 2001 12:20:35 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 85DF0240319F; Thu, 25 Jan 2001 10:20:34 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id LAA01453; Thu, 25 Jan 2001 11:20:34 +0100 (MET) To: sommerfeld@east.sun.com Cc: ietf-ssh@clinet.fi Subject: Re: RSA signature encoding (Re: WG Last Call for secsh core drafts) References: <200101250232.f0P2WS5128857@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 25 Jan 2001 11:20:24 +0100 In-Reply-To: Bill Sommerfeld's message of "Wed, 24 Jan 2001 21:32:28 -0500" Message-ID: Lines: 49 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Bill Sommerfeld writes: > > The encoding rules for ssh-rsa signatures (in the transport draft) ... > > is not consistent with the architecture draft, > My evaluation of this is that this isn't an editorial change, since > "mpint" is a signed integer. Exactly, it is a change to the protocol although a small one. > So, do we want to leave the draft alone, or should we include include > an implementation note that says that mpints received as an > rsa_signature_blob should always be treated as positive numbers? I think it would be good to make it very vlear that the encoding used is not compatible with mpint. > > Using two almost equivalent encodings for numbers only adds to > > confusion and complexity. > > Understood, though one can argue consistency with the dss signature > blob (which is also sent as a string). I used to argue that the dss encoding was wrong as well (iirc, an earlier draft, specified it as mpint r mpint s and that was later changed to string dss-signature-blob with no motivation provided for the change. My guess is that it was done to match the ssh2 implementation). Actually, using unsigned numbers rather than mpint turned out to make the dss code in implementation slightly simpler. I belive we should either stick to using mpint, for consistency. Or conclude that signed mpints are unneeded and too complicated, add an mpuint type, use mpuint for the rsa signature values, and recommend that mpuint rather than mpint be used for representing values in Z_n. The latter alternative is an editorial change (I could write it up if desired), and it makes the inconsistency more visible. /Niels From owner-ietf-ssh@clinet.fi Thu Jan 25 08:11:57 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25085 for ; Thu, 25 Jan 2001 08:11:55 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id NAA27568 for ietf-ssh-outgoing; Thu, 25 Jan 2001 13:16:00 +0200 Received: from mail.mindbright.se (IDENT:postfix@mindterm.appgate.com [193.12.107.237]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id NAA27463 for ; Thu, 25 Jan 2001 13:15:31 +0200 Received: by mail.mindbright.se (Postfix, from userid 1001) id 296101FF01; Thu, 25 Jan 2001 12:25:08 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by mail.mindbright.se (Postfix) with ESMTP id 22AA21F101; Thu, 25 Jan 2001 12:25:08 +0100 (MET) Date: Thu, 25 Jan 2001 12:25:08 +0100 (MET) From: Mats Andersson X-Sender: mats@mindterm.appgate.com To: Damien Miller Cc: Markus Friedl , ietf-ssh@clinet.fi, openssh@openbsd.org Subject: Re: Are we going to add a magic cookie to sftp? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Thu, 25 Jan 2001, Damien Miller wrote: > Why not skip the shell initialisation altogether for subsystems? Agreed^2 We alreday have "exec" for having a command in a shell... Subsystem seems to implicate something cleaner IMHO. Cheers, /Mats From owner-ietf-ssh@clinet.fi Thu Jan 25 08:12:41 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25129 for ; Thu, 25 Jan 2001 08:12:40 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id NAA29275 for ietf-ssh-outgoing; Thu, 25 Jan 2001 13:22:57 +0200 Received: from faui02.informatik.uni-erlangen.de (msfriedl@faui02.informatik.uni-erlangen.de [131.188.30.102]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id NAA29266 for ; Thu, 25 Jan 2001 13:22:55 +0200 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id MAA10195; Thu, 25 Jan 2001 12:22:46 +0100 (MET) Date: Thu, 25 Jan 2001 12:22:46 +0100 From: Markus Friedl To: Mats Andersson Cc: Damien Miller , ietf-ssh@clinet.fi, openssh@openbsd.org Subject: Re: Are we going to add a magic cookie to sftp? Message-ID: <20010125122246.A3879@faui02.informatik.uni-erlangen.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from mats@mindbright.se on Thu, Jan 25, 2001 at 12:25:08PM +0100 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk i think this is a implementation or even a site policy. perhaps the site does accounting by login shells (e.g. /bin/false). but, after all, i think all this does not belong to the protocol. -markus On Thu, Jan 25, 2001 at 12:25:08PM +0100, Mats Andersson wrote: > > On Thu, 25 Jan 2001, Damien Miller wrote: > > Why not skip the shell initialisation altogether for subsystems? > > Agreed^2 > > We alreday have "exec" for having a command in a shell... Subsystem seems > to implicate something cleaner IMHO. > > Cheers, > > /Mats > > From owner-ietf-ssh@clinet.fi Thu Jan 25 08:47:11 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25738 for ; Thu, 25 Jan 2001 08:47:10 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id OAA06257 for ietf-ssh-outgoing; Thu, 25 Jan 2001 14:01:30 +0200 Received: from mystery.acr.fi (ip212-226-160-97.adsl.kpnqwest.fi [212.226.160.97]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id OAA06249 for ; Thu, 25 Jan 2001 14:01:28 +0200 Received: from localhost (ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) with ESMTP id NAA28575; Thu, 25 Jan 2001 13:58:09 +0200 X-Authentication-Warning: mystery.acr.fi: ylo owned process doing -bs Date: Thu, 25 Jan 2001 13:58:09 +0200 (EET) From: Tatu Ylonen X-Sender: ylo@mystery.acr.fi To: Simon Tatham cc: ietf-ssh@clinet.fi Subject: Re: X forwarding: suggestions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > string originator address (e.g. "192.168.7.38") > uint32 originator port > > but in practice, OpenSSH provided a hostname instead of an address. > This is useless for verifying an IP, because one hostname may map to > more than one IP, and/or the DNS at the other end may be different > (for example, consider a private network with internal DNS). The intention was for it to always be an actual IP address (IPv4 or IPv6). It looks like most of the other channel opens already say "originator IP address" and explain "Originator IP address is the numeric IP address of the machine where the connection request comes from". In the case of "x11" channels, it says "originator address" and gives a numeric example. Perhaps the draft shoud be clarified to have the same text for X11 channels as for the other channels, but I certainly don't think any delay in the process should be caused by this. > Better still, it seems to me, why not make the SSH _server_ invent > the remote auth data and verify it? You basically mean double-faking the cookies? One reason not to do it is that the server would need to know about authentication methods to do something useful there. (Of course, the client would too, but the client is usually on the same machine as the X11 server, and can more easily be controlled by the same administrator, whereas the server may be in a different administrative domain.) > The advantage would be that the server can perform > XDM-AUTHORIZATION-1 or other complex authentications very easily, > because it obviously does have access to the source IP/port of the > incoming connection - or to the equivalent if the connection should > come in on a Unix domain socket. It seems silly to forward all the > details back to the client and make the client do it, when there's > no reason for the server not to just do it itself. The client should already be getting the IP address, not a host name. I don't think we should do X11 auth cookie faking in the server for the following reasons: - it adds no security, but adds complexity - the client should already have the required info (IP address) in correct implementations - the server should not need to know about new X11 auth methods, because it is often in a different administrative domain and cannot be upgraded at the same time as X11 servers. Furthermore, I would hate to change the protocol at this point unless there is some very critical issue. In this case, I don't think the benefit justifies the delay that would be caused by the change (I personally don't think it should be done in the server at all). Also, whether server does cookie faking is not really a protocol issue. A conforming server could do it regardless of whether the client does it. Tatu From owner-ietf-ssh@clinet.fi Thu Jan 25 09:01:27 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25937 for ; Thu, 25 Jan 2001 09:01:25 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id OAA09158 for ietf-ssh-outgoing; Thu, 25 Jan 2001 14:13:31 +0200 Received: from ixion.tartarus.org (ixion.tartarus.org [195.153.205.133]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id OAA09148 for ; Thu, 25 Jan 2001 14:13:29 +0200 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 14LlHG-0000Xh-00; Thu, 25 Jan 2001 12:13:22 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham In-Reply-To: To: Tatu Ylonen Cc: ietf-ssh@clinet.fi Subject: Re: X forwarding: suggestions Message-Id: Date: Thu, 25 Jan 2001 12:13:22 +0000 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Tatu Ylonen wrote: > Perhaps the draft shoud be clarified to have the same text for X11 > channels as for the other channels, but I certainly don't think any > delay in the process should be caused by this. Fair enough. That's good enough for me. >> Better still, it seems to me, why not make the SSH _server_ invent >> the remote auth data and verify it? > > You basically mean double-faking the cookies? No, just single-faking them in a different place. Provided the server is faking some auth data and thus controlling what connections get forwarded, the client has no _need_ to fake any auth data. The reason being, the server knows the cookie the client has made up, so a malicious server could get a hostile connection through to the client's X server _anyway_, so there's no security loss involved in just having the client trust anything the server forwards to it. > - it adds no security, but adds complexity Well, it adds complexity in the server, but that's the price of removing complexity in the protocol. *shrug* > One reason not to do it is that the server would need to know about > authentication methods to do something useful there. (Of course, > the client would too, but the client is usually on the same machine > as the X11 server, and can more easily be controlled by the same > administrator, whereas the server may be in a different > administrative domain.) This seems like a reasonable point though. Fair enough. As long as there are good grounds for getting OpenSSH to fix their originator addresses, I've got everything I need to do a proper job in any case. Many thanks, Simon -- Simon Tatham "loop, infinite _see_ infinite loop" - Index, Borland Pascal Language Guide From owner-ietf-ssh@clinet.fi Thu Jan 25 10:14:13 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29048 for ; Thu, 25 Jan 2001 10:14:11 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA29096 for ietf-ssh-outgoing; Thu, 25 Jan 2001 15:37:49 +0200 Received: from mystery.acr.fi (ip212-226-160-97.adsl.kpnqwest.fi [212.226.160.97]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA29073 for ; Thu, 25 Jan 2001 15:37:43 +0200 Received: from localhost (ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) with ESMTP id PAA28746; Thu, 25 Jan 2001 15:35:19 +0200 X-Authentication-Warning: mystery.acr.fi: ylo owned process doing -bs Date: Thu, 25 Jan 2001 15:35:19 +0200 (EET) From: Tatu Ylonen X-Sender: ylo@mystery.acr.fi To: Bill Sommerfeld cc: "Jeff P. Van Dyke" , ietf-ssh@clinet.fi Subject: Re: draft-ietf-secsh-publickeyfile-00.txt In-Reply-To: <200101250236.f0P2aQ5128871@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > > Unlike FTP, sftp doesn't distinguish between ASCII > > and BINARY. > > maybe we should fix this rather than overspecifying things in the key > file format.. The file transfer protocol was designed to handle all files as binary data. In my opinion this was one of the best things in the original Unix file system design. The client is free to implement any conversions locally, but such conversions will not affect the protocol or the server. This was a conscious design choice in the protocol. Doing e.g. newline conversions at the server would e.g. - make it very hard to restart large transfers which may have been aborted - break the file offset addressing model used in the protocol (note that it is essentially the same model used in POSIX file I/O) - increase cpu consumption on the server (probably not significant) Most MSDOS programmers I know of automatically add the "b" (binary) flag to every fopen call they write... Anyway, I think the client is the right place to do the conversions. Tatu From owner-ietf-ssh@clinet.fi Thu Jan 25 10:18:31 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29356 for ; Thu, 25 Jan 2001 10:18:29 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA26658 for ietf-ssh-outgoing; Thu, 25 Jan 2001 15:27:18 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA26514 for ; Thu, 25 Jan 2001 15:26:40 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 03B59240ACD6; Thu, 25 Jan 2001 13:26:40 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id OAA28218; Thu, 25 Jan 2001 14:26:39 +0100 (MET) To: Markus Friedl Cc: ietf-ssh@clinet.fi, openssh@openbsd.org Subject: Re: Are we going to add a magic cookie to sftp? References: <200101202146.f0KLk95118641@thunk.east.sun.com> <001f01c0867e$72dfe150$0201a8c0@vandyke.com> <20010125091536.B24046@faui02.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 25 Jan 2001 14:26:39 +0100 In-Reply-To: Markus Friedl's message of "Thu, 25 Jan 2001 09:15:36 +0100" Message-ID: Lines: 34 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Markus Friedl writes: > i really think that this paragraph should be deleted from the drafts, > since the subsystem protocols (e.g. secsh-filexfer) are not the place > where misconfigurations and broken shell accounts should be fixed. I agree completey. On Wed, Jan 24, 2001 at 08:25:18PM -0700, Jeff P. Van Dyke wrote: > > Are there plans to update the sftp draft > > > > http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-00.txt > > > > to include such a magic cookie? BTW, if one *really* wants to kludge around this particular system configuration error, one doesn't need any changes to the protocols. The server can exec the sftp-subsystem, look for the first server->client message 00 00 00 05 length 02 SSH_FXP_VERSION 00 00 00 03 version number and throw away any garbage sent by the subsystem before that. I haven't yet seen any broken shell initialization scripts that send NUL bytes to stdout, so I think that's all magic you could possibly need. And I'm even more against requiring the *client* to to kludge around configuration errors on the server than requiring the server to do the same. /Niels From owner-ietf-ssh@clinet.fi Thu Jan 25 10:26:33 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29931 for ; Thu, 25 Jan 2001 10:26:32 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA30812 for ietf-ssh-outgoing; Thu, 25 Jan 2001 15:44:42 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA30803 for ; Thu, 25 Jan 2001 15:44:41 +0200 Received: from viper2 ([127.0.0.1]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 317 for ; Thu, 25 Jan 2001 06:49:35 -0700 Message-ID: <002001c086d4$cf7c4330$0201a8c0@vandyke.com> From: "Jeff P. Van Dyke" To: References: Subject: Re: draft-ietf-secsh-publickeyfile-00.txt Date: Thu, 25 Jan 2001 06:43:27 -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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit > > > Unlike FTP, sftp doesn't distinguish between ASCII > > > and BINARY. > > > > maybe we should fix this rather than overspecifying things in the key > > file format.. > > The file transfer protocol was designed to handle all files as binary > data. In my opinion this was one of the best things in the original > Unix file system design. The client is free to implement any > conversions locally, but such conversions will not affect the protocol > or the server. This was a conscious design choice in the protocol. > > Doing e.g. newline conversions at the server would e.g. > > - make it very hard to restart large transfers which may have been > aborted > > - break the file offset addressing model used in the protocol (note that > it is essentially the same model used in POSIX file I/O) > > - increase cpu consumption on the server (probably not significant) > > Most MSDOS programmers I know of automatically add the "b" (binary) flag > to every fopen call they write... > > Anyway, I think the client is the right place to do the conversions. How does the client know if the text file is being transferred to a server running Windows NT, UNIX or ...? Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Thu Jan 25 10:51:50 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01767 for ; Thu, 25 Jan 2001 10:51:47 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA01605 for ietf-ssh-outgoing; Thu, 25 Jan 2001 15:58:45 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA01595 for ; Thu, 25 Jan 2001 15:58:43 +0200 Received: from viper2 ([127.0.0.1]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 470 for ; Thu, 25 Jan 2001 07:03:37 -0700 Message-ID: <002f01c086d6$c56e5700$0201a8c0@vandyke.com> From: "Jeff P. Van Dyke" To: References: <200101202146.f0KLk95118641@thunk.east.sun.com> <001f01c0867e$72dfe150$0201a8c0@vandyke.com> <20010125091536.B24046@faui02.informatik.uni-erlangen.de> Subject: Making subsystems robust (was: Are we going to add a magic cookie to sftp?) Date: Thu, 25 Jan 2001 06:56:06 -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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit > On Wed, Jan 24, 2001 at 08:25:18PM -0700, Jeff P. Van Dyke wrote: > > http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-09.txt > > > > I was pleased to see the following new text: > > > > As the user's shell is usually used to execute the > > subsystem, it is advisable for the subsystem protocol > > to have a "magic cookie" at the beginning of the protocol > > transaction to distinguish from arbitrary output from > > shell initialization scripts etc. This spurious output > > from the shell may be filtered out either at the server > > or at the client. > > i really think that this paragraph should be deleted from the drafts, > since the subsystem protocols (e.g. secsh-filexfer) are not the place > where misconfigurations and broken shell accounts should be fixed. I believe the new paragraph was added after the discussion regarding subsystems during the Working Group meeting in San Diego. First, some background for those who weren't in San Diego. Joseph Galbraith and I wrote a draft for a new channel for managing public keys. http://www.ietf.org/internet-drafts/draft-galb-secsh-publickey-channel-00.txt The consesus on the list and at the working group meeting was the draft needs to be rewritten as a subsystem. One of the reasons we had chosen to use a channel rather than a subsystem was because we discovered with some current server implementations, a user can have something in their .cshrc that will break the use of a subsystem. Most recently, one of our customers had an echo statement that sent an XTerm escape sequence. Because nothing visible was being echoed when the customer logged into the his account, this problem was a bit difficult to track down. I would like to see extensions for transferring files, managing public keys, etc. that can't be broken by a user making a simple mistake with his .cshrc. I believe the extensions must be more robust than that. I think skipping shell initialization is a good alternative. In my opinion, it is probably a better alternative than the magic cookie. However, the consesus at the meeting seemed to be that this was not acceptable. As I recall, Bill Sommerfeld indicated that some subsystems require the shell initialization. Bill? A third alternative would be to require shell initialiation, but require the server to discard all output from the shell initialization prior to starting the subsystem. This was discussed during the meeting, but I'm not sure how practical this solution is. I believe the draft requires some language to address this problem. I would find it very unfortunate if we simply deleted the paragraph and didn't address this issue in the draft. Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Thu Jan 25 11:34:24 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03397 for ; Thu, 25 Jan 2001 11:34:23 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id QAA06825 for ietf-ssh-outgoing; Thu, 25 Jan 2001 16:23:40 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id QAA06819 for ; Thu, 25 Jan 2001 16:23:39 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id E85F92403186; Thu, 25 Jan 2001 14:23:38 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id PAA22224; Thu, 25 Jan 2001 15:23:35 +0100 (MET) To: Tatu Ylonen Cc: Simon Tatham , ietf-ssh@clinet.fi Subject: Re: X forwarding: suggestions References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 25 Jan 2001 15:23:34 +0100 In-Reply-To: Tatu Ylonen's message of "Thu, 25 Jan 2001 13:58:09 +0200 (EET)" Message-ID: Lines: 67 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Tatu Ylonen writes: > > Better still, it seems to me, why not make the SSH _server_ invent > > the remote auth data and verify it? > > You basically mean double-faking the cookies? One reason not to do it is > that the server would need to know about authentication methods to do > something useful there. I don't see any need for passing any cookies across the ssh protocol. The ssh client and server are already talking to eachother over a mutually authenticated channel. > I don't think we should do X11 auth cookie faking in the server for the > following reasons: > > - it adds no security, but adds complexity I'm not so sure about the complexity in doing that, but I haven't yet implemented X11 forwarding. > - the client should already have the required info (IP address) in > correct implementations Except that if the ipaddress is 127.0.0.1 (or some other address that isn't globally unique, like an IPv6 site local or IPv4 private use address), it isn't terribly useful on the client side. And then we have the case of non-tcp connections, which have been discussed earlier. > - the server should not need to know about new X11 auth methods, > because it is often in a different administrative domain and cannot > be upgraded at the same time as X11 servers. To me, different administrative domains are an argument *against* having the client know about authentication of X clients at the server. What if the X infrastructure at the server (including the ssh server) only knows about the authentication method FOO, while the X system at the client, including the ssh client, only knows the authentication method BAR? Then forwarding fails, while it would have worked fine if the server had handled authentication at its end. In practice, I expect that both ends would fall back to the magic-cookie authentication instead of failing, but it would still be better if the X authentication at the client and at the server were independent. > Furthermore, I would hate to change the protocol at this point unless > there is some very critical issue. I understand that. > Also, whether server does cookie faking is not really a protocol > issue. A conforming server could do it regardless of whether the > client does it. You're right, the situation could be improved by just adding proper X authentication and cookie-generation to the server. Then clients could send an empty string as it's cookie in the x11-request (and a null x11 authentication protocol, if there is such a thing), or some more or less random string if they want to forward several displays. This doesn't change the wire formats, but it's still a slight protocol change. A client would want to know if the server will do proper authentication or not (because at least one of the client and server has to do it). /Niels From owner-ietf-ssh@clinet.fi Thu Jan 25 12:27:43 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04665 for ; Thu, 25 Jan 2001 12:27:42 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA18636 for ietf-ssh-outgoing; Thu, 25 Jan 2001 17:41:32 +0200 Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA18627 for ; Thu, 25 Jan 2001 17:41:27 +0200 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id KAA17653; Thu, 25 Jan 2001 10:40:02 -0500 (EST) Date: Thu, 25 Jan 2001 10:40:01 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Tatu Ylonen Cc: Bill Sommerfeld , "Jeff P. Van Dyke" , ietf-ssh@clinet.fi Subject: Re: draft-ietf-secsh-publickeyfile-00.txt In-Reply-To: Your message of Thu, 25 Jan 2001 15:35:19 +0200 (EET) Message-ID: Sender: owner-ietf-ssh@clinet.fi Precedence: bulk 30 years of experience transfering files between heterogeneous systems are being ignored in this protocol. Transfering everything as binary data is fine when using homogeneous systems. But it is not acceptable when transfering text files among heterogeneous systems. Just look at what happens when you attempt to transfer a makefile produced on Windows to a Unix host. Or worse, to a Macintosh. > - make it very hard to restart large transfers which may have been > aborted It is very hard to restart text transfers regardless of who is performing the conversion because the size of the file changes when the end of line indicator is manipulated. > - break the file offset addressing model used in the protocol (note that > it is essentially the same model used in POSIX file I/O) > > - increase cpu consumption on the server (probably not significant) not significant. Kermit and FTP have been performing these conversions for years. > Most MSDOS programmers I know of automatically add the "b" (binary) flag > to every fopen call they write... Microsoft Development tools do not. Neither do most editors. > Anyway, I think the client is the right place to do the conversions. It is appropriate for both the client and the server to perform conversions as necessary. When transfering text files you must have a well defined wire format. CR-LF is the usual standard. The client converts (if necessary) to CR-LF and the server converts if necessary to the local representation. You can provide optimizations by negotiating the system type and always use binary mode if the system types match. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. From owner-ietf-ssh@clinet.fi Thu Jan 25 13:00:25 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05150 for ; Thu, 25 Jan 2001 13:00:23 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA20787 for ietf-ssh-outgoing; Thu, 25 Jan 2001 17:58:46 +0200 Received: from faui02.informatik.uni-erlangen.de (msfriedl@faui02.informatik.uni-erlangen.de [131.188.30.102]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA20782 for ; Thu, 25 Jan 2001 17:58:45 +0200 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id QAA11970 for ietf-ssh@clinet.fi; Thu, 25 Jan 2001 16:58:44 +0100 (MET) Date: Thu, 25 Jan 2001 16:58:44 +0100 From: Markus Friedl To: ietf-ssh@clinet.fi Subject: Re: Making subsystems robust (was: Are we going to add a magic cookie to sftp?) Message-ID: <20010125165844.A11688@faui02.informatik.uni-erlangen.de> References: <200101202146.f0KLk95118641@thunk.east.sun.com> <001f01c0867e$72dfe150$0201a8c0@vandyke.com> <20010125091536.B24046@faui02.informatik.uni-erlangen.de> <002f01c086d6$c56e5700$0201a8c0@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <002f01c086d6$c56e5700$0201a8c0@vandyke.com>; from jpv@vandyke.com on Thu, Jan 25, 2001 at 06:56:06AM -0700 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Thu, Jan 25, 2001 at 06:56:06AM -0700, Jeff P. Van Dyke wrote: > I believe the draft requires some language to address this > problem. I would find it very unfortunate if we simply > deleted the paragraph and didn't address this issue in the draft. i think the best (and only) thing the draft could do is to have an advise for imlementors that says: be aware of broken .cshrc or other profile scripts can confuse subsystems if the login shell is involved. broken .cshrc scripts confuse rsh or rsync, too. it's not a secsh specific problem. -markus From owner-ietf-ssh@clinet.fi Thu Jan 25 13:02:28 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05196 for ; Thu, 25 Jan 2001 13:02:27 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA21850 for ietf-ssh-outgoing; Thu, 25 Jan 2001 18:07:50 +0200 Received: from mystery.acr.fi (ip212-226-160-97.adsl.kpnqwest.fi [212.226.160.97]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA21846 for ; Thu, 25 Jan 2001 18:07:49 +0200 Received: from localhost (ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) with ESMTP id SAA28956; Thu, 25 Jan 2001 18:05:25 +0200 X-Authentication-Warning: mystery.acr.fi: ylo owned process doing -bs Date: Thu, 25 Jan 2001 18:05:25 +0200 (EET) From: Tatu Ylonen X-Sender: ylo@mystery.acr.fi To: Mats Andersson cc: Damien Miller , Markus Friedl , ietf-ssh@clinet.fi, openssh@openbsd.org Subject: Re: Are we going to add a magic cookie to sftp? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > On Thu, 25 Jan 2001, Damien Miller wrote: > > Why not skip the shell initialisation altogether for subsystems? The reason for shell initialization for subsystems was related to the sftp umask issue. I have a slight preference for executing subsystems directly (not reading users .cshrc, and not setting user's default umask), whereas at least Sami Lehtinen preferred to have subsystems run through the user's shell (which means umask can default to user's umask). So we must basically decide on the subsystem execution method and the user's default umask at the same time. Tatu From owner-ietf-ssh@clinet.fi Thu Jan 25 14:25:35 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06539 for ; Thu, 25 Jan 2001 14:25:34 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA29204 for ietf-ssh-outgoing; Thu, 25 Jan 2001 19:21:54 +0200 Received: from mystery.acr.fi (ip212-226-160-97.adsl.kpnqwest.fi [212.226.160.97]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA29200 for ; Thu, 25 Jan 2001 19:21:51 +0200 Received: from localhost (ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) with ESMTP id TAA29103; Thu, 25 Jan 2001 19:19:35 +0200 X-Authentication-Warning: mystery.acr.fi: ylo owned process doing -bs Date: Thu, 25 Jan 2001 19:19:35 +0200 (EET) From: Tatu Ylonen X-Sender: ylo@mystery.acr.fi To: Simon Tatham cc: ietf-ssh@clinet.fi Subject: Re: X forwarding: suggestions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > No, just single-faking them in a different place. Provided the > server is faking some auth data and thus controlling what > connections get forwarded, the client has no _need_ to fake any auth > data. The reason being, the server knows the cookie the client has > made up, so a malicious server could get a hostile connection > through to the client's X server _anyway_, so there's no security > loss involved in just having the client trust anything the server > forwards to it. For MIT-MAGIC-COOKIE-1 the client has to do the faking, unless it wants to tell the server what the real cookie is. The reason for doing the faking in the client was that many people keep their X logins open for days/weeks/months. We don't want the X11 cookies on every machine we have ever logged into during a period of weeks/months, because a break-in to any of those could be used to break into the X server. As the faking is done in the client, the cookies left on the server (anything told to the server) will be useless as soon as the connection has been closed. > Well, it adds complexity in the server, but that's the price of > removing complexity in the protocol. *shrug* I don't think it is adding/removing any complexity in the protocol. The originator address is there for e.g. debugging/logging purposes anyway, so I don't think any change would simplify the protocol. Tatu From owner-ietf-ssh@clinet.fi Thu Jan 25 14:30:49 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06694 for ; Thu, 25 Jan 2001 14:30:48 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA30021 for ietf-ssh-outgoing; Thu, 25 Jan 2001 19:31:00 +0200 Received: from ixion.tartarus.org (ixion.tartarus.org [195.153.205.133]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA30018 for ; Thu, 25 Jan 2001 19:30:59 +0200 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 14LqEX-0001HD-00; Thu, 25 Jan 2001 17:30:53 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham In-Reply-To: To: Tatu Ylonen Cc: ietf-ssh@clinet.fi Subject: Re: X forwarding: suggestions Message-Id: Date: Thu, 25 Jan 2001 17:30:53 +0000 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Tatu Ylonen wrote: > For MIT-MAGIC-COOKIE-1 the client has to do the faking, unless it wants to > tell the server what the real cookie is. If the server does the faking, the client doesn't have to transmit any auth data _at all_. The X connections forwarded over the protocol are unauthenticated - this is why I said it makes the protocol simpler. The server validates and removes the auth data it receives from the remote X client. The client inserts valid auth data for the local X server. The client need not invent anything faked at all. > The reason for doing the faking in the client was that many people > keep their X logins open for days/weeks/months. This is an excellent argument against transmitting the real cookie to the server. But it doesn't follow that a fake cookie must be transmitted in its place. My scheme suggests that the client transmits _no_ cookie. > I don't think it is adding/removing any complexity in the protocol. > The originator address is there for e.g. debugging/logging purposes > anyway, so I don't think any change would simplify the protocol. ... see above. The complexity removed is the auth component of the original request for X forwarding. (I'm not actually arguing very hard for this any more; I'm just trying to correct misunderstandings.) Cheers, Simon -- Simon Tatham "The distinction between the enlightened and the terminally confused is only apparent to the latter." From owner-ietf-ssh@clinet.fi Thu Jan 25 14:41:29 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07019 for ; Thu, 25 Jan 2001 14:41:28 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA31638 for ietf-ssh-outgoing; Thu, 25 Jan 2001 19:51:13 +0200 Received: from mystery.acr.fi (ip212-226-160-97.adsl.kpnqwest.fi [212.226.160.97]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA31633 for ; Thu, 25 Jan 2001 19:51:12 +0200 Received: from localhost (ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) with ESMTP id TAA29131; Thu, 25 Jan 2001 19:48:55 +0200 X-Authentication-Warning: mystery.acr.fi: ylo owned process doing -bs Date: Thu, 25 Jan 2001 19:48:55 +0200 (EET) From: Tatu Ylonen X-Sender: ylo@mystery.acr.fi To: Niels Mvller cc: Simon Tatham , ietf-ssh@clinet.fi Subject: Re: X forwarding: suggestions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > > - the server should not need to know about new X11 auth methods, > > because it is often in a different administrative domain and cannot > > be upgraded at the same time as X11 servers. > > To me, different administrative domains are an argument *against* > having the client know about authentication of X clients at the > server. What if the X infrastructure at the server (including the ssh > server) only knows about the authentication method FOO, while the X > system at the client, including the ssh client, only knows the > authentication method BAR? Then forwarding fails, while it would have > worked fine if the server had handled authentication at its end. I've always throught that authentication is a policy of the X server (which typically runs on the same machine as the SSH client). If one uses an unusual (non-MIT-MAGIC-COOKIE-1) authentication, one has an unusual X server (i.e., on the same machine as the SSH client). In my opinion we are entering an area of complexity with the X11 forwarding issues that is not a really a problem for practical deployment but that we could spend weeks discussing, and might still not get the right solution. I would vote to not change the documents related to this at this time. I don't think we should delay the standard because of this, and I don't think we should make any hasty modifications here. Note also that since the cookies are encrypted by secure shell, and the real cookie is never sent over the X11 forwarding tunnel, the more advanced (e.g. DES-based) authentication methods don't actually provide very much additional security. > You're right, the situation could be improved by just adding proper X > authentication and cookie-generation to the server. Then clients could > send an empty string as it's cookie in the x11-request (and a null x11 > authentication protocol, if there is such a thing), or some more or > less random string if they want to forward several displays. > > This doesn't change the wire formats, but it's still a slight protocol > change. A client would want to know if the server will do proper > authentication or not (because at least one of the client and server > has to do it). If someone wants to experiment with this, support for it can be easily negotiated by first trying to connect with a new channel type that implies support for server-side faking (e.g., "x11-ssf@lysator.liu.se"), and if the server rejects the channel open request, then fall back to the ordinary "x11" channel type and protocol. If it turns out to be very useful, it could later become either an informational RFC or be added to the standard at a later stage. Tatu From owner-ietf-ssh@clinet.fi Thu Jan 25 16:53:50 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09713 for ; Thu, 25 Jan 2001 16:53:49 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA09506 for ietf-ssh-outgoing; Thu, 25 Jan 2001 22:04:29 +0200 Received: from mystery.acr.fi (ip212-226-160-97.adsl.kpnqwest.fi [212.226.160.97]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id WAA09503 for ; Thu, 25 Jan 2001 22:04:27 +0200 Received: from localhost (ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) with ESMTP id WAA29346; Thu, 25 Jan 2001 22:02:00 +0200 X-Authentication-Warning: mystery.acr.fi: ylo owned process doing -bs Date: Thu, 25 Jan 2001 22:02:00 +0200 (EET) From: Tatu Ylonen X-Sender: ylo@mystery.acr.fi To: Jeffrey Altman cc: Bill Sommerfeld , "Jeff P. Van Dyke" , ietf-ssh@clinet.fi Subject: Re: draft-ietf-secsh-publickeyfile-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > 30 years of experience transfering files between heterogeneous systems > are being ignored in this protocol. Transfering everything as binary > data is fine when using homogeneous systems. But it is not acceptable > when transfering text files among heterogeneous systems. Just look at > what happens when you attempt to transfer a makefile produced on > Windows to a Unix host. Or worse, to a Macintosh. Most people hardly ever transfer a Makefile between Unix, Windows, or Macintosh. They transfer a tgz, a zip, or an hqx. Transferring plain ASCII files is becoming extremely rare. Even the simplest memos now most often go with the mime type application/msword. Postscript has been replaced by pdf. Images are gifs, jpgs, tiffs, or some other binary format. HTML pages frequently have national characters from iso8859-x or some Japanese character set. Spreadsheets are usually made with Excel and presentations with Powerpoint. All these formats are binary. I don't see a big move back to non-binary formats in the future. I may be an exception, but I have never, ever, in my 20 years of intensely using computers (including some years of VAX, UNIVAC, Burroughs mainframe use, and several years of CP/M, MSDOS and Windows use, and having worked with full-text databases and newspaper editorial systems several years, including many ten-hour kermit transfers over serial lines) intentionally transferred a file using ASCII mode. I have many times accidentially transferred one in ASCII, and have sometimes spent considerable amount of time debugging before figuring out what was wrong. I have also had several customer complaints when the files they got had been accidentially corrupted by ASCII transfer. I will make the claim that automatically defaulting to ASCII mode is HARMFUL, and is becoming MORE HARMFUL as time goes by. If the user explicitly wants to convert, he/she can then specify conversion type to the client (e.g., convert for VAX/VMS). (I have received some (1-3) requests for ASCII mode in SSH/SCP/SFTP during the last five years; however, I have not been reading the support mailing lists myself for several years now. Some people are used to using ASCII mode in legacy applications, which may warrant supporting it when explicitly requested.) > It is appropriate for both the client and the server to perform > conversions as necessary. When transfering text files you must have a > well defined wire format. CR-LF is the usual standard. The client > converts (if necessary) to CR-LF and the server converts if necessary > to the local representation. I vote against adding the complexity of ASCII conversions into the protocol. My reason for this opinion is that I think it can be implemented in the client with the same complexity without modifying the protocol (also thinking of what the user has to do to enable it), and keeping it as a client implementation issue avoids bloating the complexity of the protocol and of server implementations. I will never release an implementation that would have ASCII mode turned on by default, because I think doing so would be seriously harmful for ease of use. If it has to be included in the protocol, I would recommend adding a "Text mode" attribute as an extension attribute that can be passed in the file open/create packet as part of the file attributes. This would request the server to manipulate the file in "text mode" according to its local conventions, converting whatever newline to server local newline in writes, and for reads the client side would always handle the conversion to the client's local conventions. Offsets would be defined to refer to the wire format that has been used for that file handle. However, I repeat that I am personally opposed to the adding the feature. Tatu From owner-ietf-ssh@clinet.fi Thu Jan 25 17:27:41 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10089 for ; Thu, 25 Jan 2001 17:27:40 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA12692 for ietf-ssh-outgoing; Thu, 25 Jan 2001 22:51:53 +0200 Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id WAA12686 for ; Thu, 25 Jan 2001 22:51:51 +0200 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id PAA03566 for ietf-ssh@clinet.fi; Thu, 25 Jan 2001 15:51:50 -0500 (EST) Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2]) by fozimane.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA19489; Thu, 25 Jan 2001 15:49:28 -0500 (EST) Received: (from fdc@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id PAA03155; Thu, 25 Jan 2001 15:49:19 -0500 (EST) Date: Thu, 25 Jan 2001 15:49:18 EST From: Frank da Cruz To: Tatu Ylonen cc: Jeffrey Altman Subject: Re: draft-ietf-secsh-publickeyfile-00.txt In-Reply-To: Your message of Thu, 25 Jan 2001 15:16:11 EST Message-ID: Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > Transferring plain ASCII files is becoming extremely rare. > ... > I may be an exception, but I have never, ever, in my 20 years of intensely > using computers (including some years of VAX, UNIVAC, Burroughs mainframe > use, and several years of CP/M, MSDOS and Windows use, and having worked > with full-text databases and newspaper editorial systems several years, > including many ten-hour kermit transfers over serial lines) intentionally > transferred a file using ASCII mode. > Then I would guess that you probably never transferred text (e.g. email, program source code, batch jobs) between an IBM mainframe (EBCDIC) and an ASCII-based system. In this case, binary mode is completely useless and an inappropriate default. I would also guess that you don't bother with Finnish or other languages where letters have diacritics or are not Roman letters; here too, binary mode is not particularly helpful. > I will make the claim that automatically defaulting to ASCII mode is > HARMFUL, and is becoming MORE HARMFUL as time goes by. If the user > explicitly wants to convert, he/she can then specify conversion type to > the client (e.g., convert for VAX/VMS). > We used to default to text mode. But in recognition of the trends you have cited, we switched the default to binary some years ago. But those trends don't eliminate the need for text mode becuase it's not just a mere question of record format conversion, but also of character-sets: ASCII/EBCDIC, UTF8/ISO8859-1, ISO Latin-Cyrillic/KOI8, etc etc. Sending around ZIP files and tarballs in binary mode doesn't help a bit. The ideal situation occurs when the file tranfer agent can switch between text and binary mode automatically, without the user having to know anything about it, so even an inappropriate default will have little or no impact. - Frank From owner-ietf-ssh@clinet.fi Thu Jan 25 17:50:30 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10494 for ; Thu, 25 Jan 2001 17:50:29 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA14609 for ietf-ssh-outgoing; Thu, 25 Jan 2001 23:16:53 +0200 Received: from mystery.acr.fi (ip212-226-160-97.adsl.kpnqwest.fi [212.226.160.97]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA14605 for ; Thu, 25 Jan 2001 23:16:52 +0200 Received: from localhost (ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) with ESMTP id XAA29445; Thu, 25 Jan 2001 23:14:24 +0200 X-Authentication-Warning: mystery.acr.fi: ylo owned process doing -bs Date: Thu, 25 Jan 2001 23:14:24 +0200 (EET) From: Tatu Ylonen X-Sender: ylo@mystery.acr.fi To: Simon Tatham cc: ietf-ssh@clinet.fi Subject: Re: X forwarding: suggestions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > If the server does the faking, the client doesn't have to transmit > any auth data _at all_. The X connections forwarded over the > protocol are unauthenticated - this is why I said it makes the > protocol simpler. It is also very different from the way the current installed base (which is rather large) uses... > This is an excellent argument against transmitting the real cookie > to the server. But it doesn't follow that a fake cookie must be > transmitted in its place. My scheme suggests that the client > transmits _no_ cookie. Ok, sorry, I didn't understand that. I now think the two methods are roughly equivalent in advantages/disadvantages (each some advantages and disadvantages). I would prefer not to introduce an unnecessary incompatibility and change at this stage unless there is some very pressing reason to do so. Tatu From owner-ietf-ssh@clinet.fi Thu Jan 25 18:35:33 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11293 for ; Thu, 25 Jan 2001 18:35:32 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA16772 for ietf-ssh-outgoing; Thu, 25 Jan 2001 23:52:54 +0200 Received: from mailgate.ias.edu (mailgate.ias.edu [192.16.204.20]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA16768 for ; Thu, 25 Jan 2001 23:52:52 +0200 Received: from mhost.math.ias.edu (mhost.math.ias.edu [192.108.106.49]) by mailgate.ias.edu (8.9.3/Pro-8.9.3) with ESMTP id QAA17729 for ; Thu, 25 Jan 2001 16:52:50 -0500 (EST) Received: from ias.edu (xmonaco.math.ias.edu [192.108.106.37]) by mhost.math.ias.edu (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA27723 for ; Thu, 25 Jan 2001 16:52:50 -0500 (EST) Message-ID: <3A70A031.AC554010@ias.edu> Date: Thu, 25 Jan 2001 16:52:49 -0500 From: Irena N Tuzla-Johnson X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ssh@clinet.fi Subject: ssh2 public key problems Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Hello all, I am running SSH on our SPARC Solaris servers -- everything works perfect (ssh-1.2.26 and ssh-2.4.0). I just installed ssh-2.1.0 and ssh-1.2.31 on a LINUX (Mandrake) box. From the linux box I can connect to any server. The problem is that I am not able to connect from the other systems to this LINUX box (with both ssh versions). Here is the error: ## trying with ssh1 $ ssh1 -v seoul SSH Version 1.2.31 [i686-unknown-linux], protocol version 1.5. Standard version. Does not use RSAREF. deva: Reading configuration data /etc/ssh_config deva: ssh_connect: getuid 501 geteuid 0 anon 0 deva: Connecting to seoul [192.108.106.28] port 22. deva: Allocated local port 1018. deva: Connection established. deva: Remote protocol version 1.99, remote software version 2.1.0 SSH Secure Shell (non-commercial) deva: Waiting for server public key. Sorry, you are not allowed to connect. # trying with ssh2 $ ssh2 -v haifa debug: hostname is 'haifa'. debug: Unable to open /home/irena/.ssh2/ssh2_config debug: connecting to haifa... debug: entering event loop debug: ssh_client_wrap: creating transport protocol debug: SshAuthMethodClient/sshauthmethodc.c:117/ssh_client_authentication_initialize: Added "publickey" to usable methods. debug: SshAuthMethodClient/sshauthmethodc.c:117/ssh_client_authentication_initialize: Added "password" to usable methods. debug: Ssh2Client/sshclient.c:1142/ssh_client_wrap: creating userauth protocol debug: Ssh2Common/sshcommon.c:502/ssh_common_wrap: local ip = 192.108.106.235, local port = 3378 debug: Ssh2Common/sshcommon.c:504/ssh_common_wrap: remote ip = 192.108.106.34, remote port = 22 debug: SshConnection/sshconn.c:1866/ssh_conn_wrap: Wrapping... debug: Ssh2Transport/trcommon.c:599/ssh_tr_input_version: Remote version: SSH-1. 99-2.1.0 SSH Secure Shell (non-commercial) debug: Ssh2Transport/trcommon.c:734/ssh_tr_input_version: Remote version has hostbased service name draft incompatibility bug. debug: Ssh2Transport/trcommon.c:738/ssh_tr_input_version: Remote version has publickey session_id encoding draft incompatibility bug. debug: Ssh2Transport/trcommon.c:742/ssh_tr_input_version: Remote version has malformed signatures draft incompatibility bug. debug: Ssh2Transport/trcommon.c:746/ssh_tr_input_version: Remote version uses deprecated disconnect codes. debug: Ssh2Transport/trcommon.c:782/ssh_tr_input_version: Remote version uses 16 byte key with SHA-1. debug: Ssh2Transport/trcommon.c:1120/ssh_tr_negotiate: c_to_s: cipher 3des-cbc, mac hmac-md5, compression none debug: Ssh2Transport/trcommon.c:1123/ssh_tr_negotiate: s_to_c: cipher 3des-cbc, mac hmac-md5, compression none debug: Ssh2Client/sshclient.c:406/keycheck_key_match: Host key found from database. debug: Ssh2Common/sshcommon.c:306/ssh_common_special: Received SSH_CROSS_STARTUP packet from connection protocol. debug: Ssh2Common/sshcommon.c:356/ssh_common_special: Received SSH_CROSS_ALGORITHMS packet from connection protocol. debug: Unable to open /home/irena/.ssh2/identification debug: Ssh2AuthClient/sshauthc.c:309/ssh_authc_completion_proc: Method 'publick Thay' disabled. debug: Ssh2AuthPasswdClient/authc-passwd.c:92/ssh_client_auth_passwd: Starting password query... irena's password: debug: Ssh2AuthPasswdClient/authc-passwd.c:92/ssh_client_auth_passwd: Starting password query... irena's password: debug: Ssh2AuthPasswdClient/authc-passwd.c:92/ssh_client_auth_passwd: Starting password query... irena's password: debug: Ssh2Common/sshcommon.c:137/ssh_common_disconnect: DISCONNECT received: No further authentication methods available. warning: Authentication failed. debug: Ssh2/ssh2.c:85/client_disconnect: locally_generated = TRUE Disconnected; no more authentication methods available (No further authentication methods available.). debug: uninitializing event loop Could someone help me to fix this? Thanks in advance! Irena -- Unix Systems Administrator School of Mathematics Institute for Advanced Study From owner-ietf-ssh@clinet.fi Fri Jan 26 05:33:07 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03591 for ; Fri, 26 Jan 2001 05:33:07 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id KAA09799 for ietf-ssh-outgoing; Fri, 26 Jan 2001 10:39:03 +0200 Received: from mail.mindbright.se (IDENT:postfix@mindterm.appgate.com [193.12.107.237]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id KAA09790 for ; Fri, 26 Jan 2001 10:39:01 +0200 Received: by mail.mindbright.se (Postfix, from userid 1001) id 7A1F51FF01; Fri, 26 Jan 2001 09:48:39 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by mail.mindbright.se (Postfix) with ESMTP id 6169D1F101; Fri, 26 Jan 2001 09:48:39 +0100 (MET) Date: Fri, 26 Jan 2001 09:48:39 +0100 (MET) From: Mats Andersson X-Sender: mats@mindterm.appgate.com To: Tatu Ylonen Cc: Jeffrey Altman , Bill Sommerfeld , "Jeff P. Van Dyke" , ietf-ssh@clinet.fi Subject: Re: draft-ietf-secsh-publickeyfile-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Hi, On Thu, 25 Jan 2001, Tatu Ylonen wrote: > > 30 years of experience transfering files between heterogeneous systems > > are being ignored in this protocol. Transfering everything as binary > > Most people hardly ever transfer a Makefile between Unix, Windows, or > Macintosh. They transfer a tgz, a zip, or an hqx. Please, we are discussing a communications protocol here, not an application!! The protocol is clear and simple, it doesn't need to include information on what kind of files we are transfering! On top of this protocol one can easily implement all sorts of filtering/transformation. The protocol even supports these kinds of extensions through explicitly defining how extensions can be done. from draft-ietf-secsh-filexfer-00.txt: ... 8. Vendor-Specific Extensions The SSH_FXP_EXTENDED request provides a generic extension mechanism for adding vendor-specific commands. ... Also, when transfering ASCII that should be translated in one way or the other, doesn't it often feel more intuitive that one have to do the translation by "external" means after the file have been transfered? So please let's not complicate any of these specs more than necessary. Cheers, /Mats From owner-ietf-ssh@clinet.fi Fri Jan 26 07:24:30 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05104 for ; Fri, 26 Jan 2001 07:24:30 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA07677 for ietf-ssh-outgoing; Fri, 26 Jan 2001 12:49:50 +0200 Received: from faui02.informatik.uni-erlangen.de (msfriedl@faui02.informatik.uni-erlangen.de [131.188.30.102]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id MAA07669 for ; Fri, 26 Jan 2001 12:49:47 +0200 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id LAA15812; Fri, 26 Jan 2001 11:49:43 +0100 (MET) Date: Fri, 26 Jan 2001 11:49:43 +0100 From: Markus Friedl To: "Jeff P. Van Dyke" Cc: ietf-ssh@clinet.fi Subject: Re: draft-ietf-secsh-publickeyfile-00.txt Message-ID: <20010126114943.A15630@faui02.informatik.uni-erlangen.de> References: <002001c086d4$cf7c4330$0201a8c0@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <002001c086d4$cf7c4330$0201a8c0@vandyke.com>; from jpv@vandyke.com on Thu, Jan 25, 2001 at 06:43:27AM -0700 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Thu, Jan 25, 2001 at 06:43:27AM -0700, Jeff P. Van Dyke wrote: > How does the client know if the text file is being transferred > to a server running Windows NT, UNIX or ...? i think this is what SSH_FILEXFER_ATTR_EXTENDED is for. -m From owner-ietf-ssh@clinet.fi Fri Jan 26 09:02:57 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07489 for ; Fri, 26 Jan 2001 09:02:56 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id NAA24008 for ietf-ssh-outgoing; Fri, 26 Jan 2001 13:59:31 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id NAA23992 for ; Fri, 26 Jan 2001 13:59:27 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 66118240ACDC; Fri, 26 Jan 2001 11:59:23 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id MAA29931; Fri, 26 Jan 2001 12:59:22 +0100 (MET) To: Tatu Ylonen Cc: Simon Tatham , ietf-ssh@clinet.fi Subject: Re: X forwarding: suggestions References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 26 Jan 2001 12:59:22 +0100 In-Reply-To: Tatu Ylonen's message of "Thu, 25 Jan 2001 19:48:55 +0200 (EET)" Message-ID: Lines: 10 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Tatu Ylonen writes: > I would vote to not change the documents related to this at this time. I > don't think we should delay the standard because of this, and I don't > think we should make any hasty modifications here. Although I think the scheme described by Simon Tatham is better, I agree that we should not delay the standard because of this. /Niels From owner-ietf-ssh@clinet.fi Fri Jan 26 11:23:54 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13372 for ; Fri, 26 Jan 2001 11:23:53 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id QAA22581 for ietf-ssh-outgoing; Fri, 26 Jan 2001 16:12:41 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id QAA22576 for ; Fri, 26 Jan 2001 16:12:39 +0200 Received: from oldviper ([192.168.0.16]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 619 for ; Fri, 26 Jan 2001 07:17:30 -0700 Message-ID: <000f01c087a1$e801a440$1000a8c0@oldviper> From: "Jeff P. Van Dyke" To: References: Subject: Re: X forwarding: suggestions Date: Fri, 26 Jan 2001 07:11:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id QAA22581 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA13372 Niels Mцller writes: > Tatu Ylonen writes: > > > I would vote to not change the documents related to this at this time. I > > don't think we should delay the standard because of this, and I don't > > think we should make any hasty modifications here. > > Although I think the scheme described by Simon Tatham is better, I > agree that we should not delay the standard because of this. > > /Niels I agree. We should not delay moving the drafts forward because of this issue. Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Fri Jan 26 13:16:36 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16778 for ; Fri, 26 Jan 2001 13:16:33 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA01744 for ietf-ssh-outgoing; Fri, 26 Jan 2001 17:42:11 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA01739 for ; Fri, 26 Jan 2001 17:42:09 +0200 Received: from merlin ([127.0.0.1]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 274 for ; Fri, 26 Jan 2001 08:47:04 -0700 Message-ID: <00bd01c087ae$6a4b4170$2800a8c0@merlin> From: "Joseph Galbraith" To: References: <200101202146.f0KLk95118641@thunk.east.sun.com> <001f01c0867e$72dfe150$0201a8c0@vandyke.com> <20010125091536.B24046@faui02.informatik.uni-erlangen.de> <002f01c086d6$c56e5700$0201a8c0@vandyke.com> <20010125165844.A11688@faui02.informatik.uni-erlangen.de> Subject: Re: Making subsystems robust (was: Are we going to add a magic cookie to sftp?) Date: Fri, 26 Jan 2001 08:41:13 -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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit > On Thu, Jan 25, 2001 at 06:56:06AM -0700, Jeff P. Van Dyke wrote: > > I believe the draft requires some language to address this > > problem. I would find it very unfortunate if we simply > > deleted the paragraph and didn't address this issue in the draft. > > i think the best (and only) thing the draft could do is to have an > advise for imlementors that says: be aware of broken .cshrc or other > profile scripts can confuse subsystems if the login shell is involved. > > broken .cshrc scripts confuse rsh or rsync, too. it's not a secsh > specific problem. I'm not fond of this behavior in rsh or rsync either. My not so humble opinion is that they are broken in this regard. I would hope that in the years since rsh was done, we've learned enough not to make the same mistake again. This isn't a completely obscure problem. We've been shipping SFTP for less than three months, and we have seen numerous reports from customers regarding this problem. Joseph From owner-ietf-ssh@clinet.fi Fri Jan 26 13:32:25 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17180 for ; Fri, 26 Jan 2001 13:32:24 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA01410 for ietf-ssh-outgoing; Fri, 26 Jan 2001 17:38:49 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA01405 for ; Fri, 26 Jan 2001 17:38:47 +0200 Received: from merlin ([127.0.0.1]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 650 for ; Fri, 26 Jan 2001 08:43:44 -0700 Message-ID: <00b701c087ad$f2e12ff0$2800a8c0@merlin> From: "Joseph Galbraith" To: References: Subject: Re: Making subsystems robust (was: Are we going to add a magic cookie to sftp?) Date: Fri, 26 Jan 2001 08:37:53 -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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit > > On Thu, 25 Jan 2001, Damien Miller wrote: > > > Why not skip the shell initialisation altogether for subsystems? > > The reason for shell initialization for subsystems was related to the sftp > umask issue. I have a slight preference for executing > subsystems directly (not reading users .cshrc, and not setting > user's default umask), whereas at least Sami Lehtinen preferred to have > subsystems run through the user's shell (which means umask can default to > user's umask). I think we should change the draft to specify that subsystems are executed directly (not reading users .cshrc, and not setting user's default umask). > So we must basically decide on the subsystem execution method and the > user's default umask at the same time. To address the SFTP UMASK problem, I would suggest adding a mechanism for setting UMASK to the SFTP draft. - Joseph From owner-ietf-ssh@clinet.fi Fri Jan 26 15:22:18 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20468 for ; Fri, 26 Jan 2001 15:22:17 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA14266 for ietf-ssh-outgoing; Fri, 26 Jan 2001 20:14:32 +0200 Received: from faui02.informatik.uni-erlangen.de (msfriedl@faui02.informatik.uni-erlangen.de [131.188.30.102]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA14259 for ; Fri, 26 Jan 2001 20:14:31 +0200 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id TAA16721; Fri, 26 Jan 2001 19:14:27 +0100 (MET) Date: Fri, 26 Jan 2001 19:14:27 +0100 From: Markus Friedl To: Joseph Galbraith Cc: ietf-ssh@clinet.fi Subject: Re: Making subsystems robust (was: Are we going to add a magic cookie to sftp?) Message-ID: <20010126191427.A16620@faui02.informatik.uni-erlangen.de> References: <00b701c087ad$f2e12ff0$2800a8c0@merlin> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <00b701c087ad$f2e12ff0$2800a8c0@merlin>; from galb-list@vandyke.com on Fri, Jan 26, 2001 at 08:37:53AM -0700 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Fri, Jan 26, 2001 at 08:37:53AM -0700, Joseph Galbraith wrote: > > > On Thu, 25 Jan 2001, Damien Miller wrote: > > > > Why not skip the shell initialisation altogether for subsystems? > > > > The reason for shell initialization for subsystems was related to the sftp > > umask issue. I have a slight preference for executing > > subsystems directly (not reading users .cshrc, and not setting > > user's default umask), whereas at least Sami Lehtinen preferred to have > > subsystems run through the user's shell (which means umask can default to > > user's umask). > > I think we should change the draft to specify that subsystems are > executed directly (not reading users .cshrc, and not setting > user's default umask). no, the protocol should not specify this. an implementation advice could be added, but shell vs. no-shell is a site or implementaion policy. the protocol should not care at all. -m From owner-ietf-ssh@clinet.fi Fri Jan 26 15:51:20 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21343 for ; Fri, 26 Jan 2001 15:51:20 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA14941 for ietf-ssh-outgoing; Fri, 26 Jan 2001 20:24:31 +0200 Received: from faui02.informatik.uni-erlangen.de (msfriedl@faui02.informatik.uni-erlangen.de [131.188.30.102]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA14938 for ; Fri, 26 Jan 2001 20:24:30 +0200 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id TAA17174; Fri, 26 Jan 2001 19:24:25 +0100 (MET) Date: Fri, 26 Jan 2001 19:24:25 +0100 From: Markus Friedl To: Joseph Galbraith Cc: ietf-ssh@clinet.fi Subject: Re: Making subsystems robust (was: Are we going to add a magic cookie to sftp?) Message-ID: <20010126192425.B16620@faui02.informatik.uni-erlangen.de> References: <200101202146.f0KLk95118641@thunk.east.sun.com> <001f01c0867e$72dfe150$0201a8c0@vandyke.com> <20010125091536.B24046@faui02.informatik.uni-erlangen.de> <002f01c086d6$c56e5700$0201a8c0@vandyke.com> <20010125165844.A11688@faui02.informatik.uni-erlangen.de> <00bd01c087ae$6a4b4170$2800a8c0@merlin> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <00bd01c087ae$6a4b4170$2800a8c0@merlin>; from galb-list@vandyke.com on Fri, Jan 26, 2001 at 08:41:13AM -0700 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Fri, Jan 26, 2001 at 08:41:13AM -0700, Joseph Galbraith wrote: > > i think the best (and only) thing the draft could do is to have an > > advise for imlementors that says: be aware of broken .cshrc or other > > profile scripts can confuse subsystems if the login shell is involved. > > > > broken .cshrc scripts confuse rsh or rsync, too. it's not a secsh > > specific problem. > > > I'm not fond of this behavior in rsh or rsync either. My > not so humble opinion is that they are broken in this regard. > I would hope that in the years since rsh was done, we've learned > enough not to make the same mistake again. no, it's not a mistake of rcp or rsync or cvs or whatever runs over rsh and ssh. if you want to have .cshrc print messages for every login, then i can use stderr for these kind of things. > This isn't a completely obscure problem. We've been shipping SFTP > for less than three months, and we have seen numerous reports from > customers regarding this problem. -markus From owner-ietf-ssh@clinet.fi Fri Jan 26 17:24:42 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23394 for ; Fri, 26 Jan 2001 17:24:42 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id VAA20095 for ietf-ssh-outgoing; Fri, 26 Jan 2001 21:42:10 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id VAA20087 for ; Fri, 26 Jan 2001 21:42:09 +0200 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17972; Fri, 26 Jan 2001 11:42:04 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id LAA07264; Fri, 26 Jan 2001 11:42:03 -0800 (PST) Received: from jurassic (jurassic [129.146.81.144]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0QJg29156028; Fri, 26 Jan 2001 11:42:02 -0800 (PST) Date: Fri, 26 Jan 2001 11:42:02 -0800 (PST) From: Darren J Moffat To: Markus Friedl cc: Joseph Galbraith , ietf-ssh@clinet.fi Subject: Re: Making subsystems robust (was: Are we going to add a magic cookie to sftp?) In-Reply-To: <20010126191427.A16620@faui02.informatik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk -- -- Darren J Moffat From owner-ietf-ssh@clinet.fi Fri Jan 26 18:12:48 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24363 for ; Fri, 26 Jan 2001 18:12:48 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA26145 for ietf-ssh-outgoing; Fri, 26 Jan 2001 23:05:19 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA26141 for ; Fri, 26 Jan 2001 23:05:17 +0200 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22214; Fri, 26 Jan 2001 11:48:23 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.89.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id LAA08633; Fri, 26 Jan 2001 11:48:22 -0800 (PST) Received: from jurassic (jurassic [129.146.81.144]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0QJmL9157608; Fri, 26 Jan 2001 11:48:22 -0800 (PST) Date: Fri, 26 Jan 2001 11:48:21 -0800 (PST) From: Darren J Moffat To: Markus Friedl cc: Joseph Galbraith , ietf-ssh@clinet.fi Subject: Re: Making subsystems robust (was: Are we going to add a magic cookie to sftp?) In-Reply-To: <20010126191427.A16620@faui02.informatik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Fri, 26 Jan 2001, Markus Friedl wrote: > On Fri, Jan 26, 2001 at 08:37:53AM -0700, Joseph Galbraith wrote: > > > > On Thu, 25 Jan 2001, Damien Miller wrote: > > > > > Why not skip the shell initialisation altogether for subsystems? > > > > > > The reason for shell initialization for subsystems was related to the sftp > > > umask issue. I have a slight preference for executing > > > subsystems directly (not reading users .cshrc, and not setting > > > user's default umask), whereas at least Sami Lehtinen preferred to have > > > subsystems run through the user's shell (which means umask can default to > > > user's umask). > > > > I think we should change the draft to specify that subsystems are > > executed directly (not reading users .cshrc, and not setting > > user's default umask). > > no, the protocol should not specify this. an implementation > advice could be added, but shell vs. no-shell is a site > or implementaion policy. I support this view point as well. umask is a UNIX concept (which has its own problems on some systems, eg default ACLs on Solaris) and is no justification for requiring the users shell be run before subsystems. Running the users shell could potentaill introduce security problems on some systems, unless you clean the environment before running the subsystem, but if you are going to do that why run the users shell at all. > the protocol should not care at all. I would go stronger than that and say that the protocol MUST not care. Many systems have alternate mechanisms of setting up the users umask without requiring the users login shell to be run. Implementations are should be advised, but not required, to do the appropriate thing using what ever is appropriate for the host platform. -- Darren J Moffat From owner-ietf-ssh@clinet.fi Fri Jan 26 20:49:26 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26803 for ; Fri, 26 Jan 2001 20:49:25 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA03243 for ietf-ssh-outgoing; Sat, 27 Jan 2001 01:43:24 +0200 Received: from kado.mindrot.org (foobar@CPE-203-45-24-18.vic.bigpond.net.au [203.45.24.18]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id BAA03238 for ; Sat, 27 Jan 2001 01:43:21 +0200 Received: from toad.mindrot.org (toad.mindrot.org [203.44.118.252]) by kado.mindrot.org (Postfix) with ESMTP id AAE609004; Sat, 27 Jan 2001 10:11:48 +1100 (EST) Received: from mothra.mindrot.org (mothra.mindrot.org [203.44.118.225]) by toad.mindrot.org (Postfix) with ESMTP id 85A081A4B3; Sat, 27 Jan 2001 10:43:10 +1100 (EST) Received: by mothra.mindrot.org (Postfix, from userid 500) id E4A823C08A; Sat, 27 Jan 2001 10:42:33 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by mothra.mindrot.org (Postfix) with ESMTP id E2D363C088; Sat, 27 Jan 2001 10:42:33 +1100 (EST) Date: Sat, 27 Jan 2001 10:42:33 +1100 (EST) From: Damien Miller To: Jeffrey Altman Cc: Tatu Ylonen , Bill Sommerfeld , "Jeff P. Van Dyke" , ietf-ssh@clinet.fi Subject: Re: draft-ietf-secsh-publickeyfile-00.txt In-Reply-To: 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: owner-ietf-ssh@clinet.fi Precedence: bulk On Thu, 25 Jan 2001, Jeffrey Altman wrote: > 30 years of experience transfering files between heterogeneous > systems are being ignored in this protocol. Transfering everything > as binary data is fine when using homogeneous systems. But it is > not acceptable when transfering text files among heterogeneous > systems. Just look at what happens when you attempt to transfer > a makefile produced on Windows to a Unix host. Or worse, to a > Macintosh. IMO ASCII conversion is more pain than gain - Its lack can be worked around with simple tools (most applications support multiple CRLF conventions), but I have never had anything but grief and corrupted files from its presence. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From owner-ietf-ssh@clinet.fi Fri Jan 26 22:42:35 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29275 for ; Fri, 26 Jan 2001 22:42:34 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id DAA09094 for ietf-ssh-outgoing; Sat, 27 Jan 2001 03:35:09 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id DAA09090 for ; Sat, 27 Jan 2001 03:35:07 +0200 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA09185; Fri, 26 Jan 2001 17:35:04 -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 UAA06001; Fri, 26 Jan 2001 20:35:03 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id f0R1Z35147066; Fri, 26 Jan 2001 20:35:03 -0500 (EST) Message-Id: <200101270135.f0R1Z35147066@thunk.east.sun.com> From: Bill Sommerfeld To: nisse@lysator.liu.se (Niels M ller) cc: sommerfeld@east.sun.com, ietf-ssh@clinet.fi Subject: Re: RSA signature encoding (Re: WG Last Call for secsh core drafts) In-reply-to: Your message of "25 Jan 2001 11:20:24 +0100." Reply-to: sommerfeld@east.sun.com Date: Fri, 26 Jan 2001 20:35:02 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > > My evaluation of this is that this isn't an editorial change, since > > "mpint" is a signed integer. > > Exactly, it is a change to the protocol although a small one. My viewpoint here (admittedly biased towards the the pragmatic) is that this is at worst merely an aesthetic flaw. in the presence of folks with running code and in the absence of wg consensus that a wire protocol change makes sense, we should attempt to keep the wire protocol compatible even at the expense of some aesthetic inconsistency. > > So, do we want to leave the draft alone, or should we include include > > an implementation note that says that mpints received as an > > rsa_signature_blob should always be treated as positive numbers? > > I think it would be good to make it very vlear that the encoding used > is not compatible with mpint. Yes, this makes sense. > Actually, using unsigned numbers rather than mpint turned out to make > the dss code in implementation slightly simpler. Interesting. > I belive we should either stick to using mpint, for consistency. Or > conclude that signed mpints are unneeded and too complicated, add an > mpuint type, use mpuint for the rsa signature values, and recommend > that mpuint rather than mpint be used for representing values in Z_n. > > The latter alternative is an editorial change (I could write it up if > desired), and it makes the inconsistency more visible. Yes, please, so we have a concrete proposal to review.. Any comments from the rest of the WG? On an issue which may involve a wire protocol change, I'm unwilling to assume that silence equals agreement.. - Bill From owner-ietf-ssh@clinet.fi Sat Jan 27 00:35:31 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00607 for ; Sat, 27 Jan 2001 00:35:30 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id FAA14745 for ietf-ssh-outgoing; Sat, 27 Jan 2001 05:31:46 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id FAA14734 for ; Sat, 27 Jan 2001 05:31:44 +0200 Received: from viper2 ([127.0.0.1]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 274 for ; Fri, 26 Jan 2001 20:36:41 -0700 Message-ID: <003401c08811$8614de30$0201a8c0@vandyke.com> From: "Jeff P. Van Dyke" To: References: <00b701c087ad$f2e12ff0$2800a8c0@merlin> <20010126191427.A16620@faui02.informatik.uni-erlangen.de> Subject: Re: Making subsystems robust (was: Are we going to add a magic cookie to sftp?) Date: Fri, 26 Jan 2001 20:28: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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Markus Friedl" writes: > On Fri, Jan 26, 2001 at 08:37:53AM -0700, Joseph Galbraith wrote: > > > > On Thu, 25 Jan 2001, Damien Miller wrote: > > > > > Why not skip the shell initialisation altogether for subsystems? > > > > > > The reason for shell initialization for subsystems was related to the sftp > > > umask issue. I have a slight preference for executing > > > subsystems directly (not reading users .cshrc, and not setting > > > user's default umask), whereas at least Sami Lehtinen preferred to have > > > subsystems run through the user's shell (which means umask can default to > > > user's umask). > > > > I think we should change the draft to specify that subsystems are > > executed directly (not reading users .cshrc, and not setting > > user's default umask). > > no, the protocol should not specify this. an implementation > advice could be added, but shell vs. no-shell is a site > or implementaion policy. > > the protocol should not care at all. I think a shell vs. no-shell for subsystems is more than just a site or implementation policy. If subsystem is going to be *the* main way toextend SECSH, I believe this mechanism must be robust. Allowing the server to start the subsystem in a way where the channel isn't clean and where stdout or stderr coming from a source other than a client is a mistake. I would find the following acceptable: 1) remove the text about magic cookies 2) add text indicating there must be a way to configure the starting of a subsystem where the stream is clean 3) add implementation advice that servers may wish to provide a mechanism for starting subsystems with a shell or user's enviroment With this change, it would be possible to configure a UNIX SSH server to invoke a public key subsystem so the .cshrc would not be used. And, it would allow the same system to configure sftp such that the .cshrc would be used and the default umask would be set. By making this change, when the .cshrc is used is a server configuration issue. But more importantly, it guarantees a robust mechanism for extending SECSH. For those who still think we should simply delete the new language about magic cookies, would they be opposed to extending SECSH by adding new channels as a more robust way of extending SECSH? Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Sat Jan 27 00:45:25 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00671 for ; Sat, 27 Jan 2001 00:45:25 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id FAA14746 for ietf-ssh-outgoing; Sat, 27 Jan 2001 05:31:47 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id FAA14739 for ; Sat, 27 Jan 2001 05:31:45 +0200 Received: from viper2 ([127.0.0.1]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 274 for ; Fri, 26 Jan 2001 20:36:43 -0700 Message-ID: <003501c08811$8718e0b0$0201a8c0@vandyke.com> From: "Jeff P. Van Dyke" To: References: <200101270135.f0R1Z35147066@thunk.east.sun.com> Subject: Re: RSA signature encoding (Re: WG Last Call for secsh core drafts) Date: Fri, 26 Jan 2001 20:30:28 -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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit > > I belive we should either stick to using mpint, for consistency. Or > > conclude that signed mpints are unneeded and too complicated, add an > > mpuint type, use mpuint for the rsa signature values, and recommend > > that mpuint rather than mpint be used for representing values in Z_n. > > > > The latter alternative is an editorial change (I could write it up if > > desired), and it makes the inconsistency more visible. > > Yes, please, so we have a concrete proposal to review.. > > Any comments from the rest of the WG? On an issue which may involve a > wire protocol change, I'm unwilling to assume that silence equals > agreement.. I would agree this is mostly an aesthetic issue. I would prefer to see no more than an editorial change for this issue. I would find it equally acceptable to leave it as is. Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Sat Jan 27 01:21:38 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02857 for ; Sat, 27 Jan 2001 01:21:37 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id GAA16600 for ietf-ssh-outgoing; Sat, 27 Jan 2001 06:12:06 +0200 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id GAA16596 for ; Sat, 27 Jan 2001 06:12:04 +0200 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA22087 for ; Fri, 26 Jan 2001 20:12:02 -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 XAA13048 for ; Fri, 26 Jan 2001 23:12:01 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id f0R4C15149791 for ; Fri, 26 Jan 2001 23:12:01 -0500 (EST) Message-Id: <200101270412.f0R4C15149791@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@clinet.fi Subject: Re: WG Last Call for secsh core drafts (halfway point). Reply-to: sommerfeld@east.sun.com Date: Fri, 26 Jan 2001 23:12:01 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk We're roughly halfway through the last-call period for the core drafts: draft-ietf-secsh-architecture-07.txt draft-ietf-secsh-transport-09.txt draft-ietf-secsh-userauth-09.txt draft-ietf-secsh-connect-09.txt I'd like to encourage additional review of the documents, especially by implementors. Based on the number of comments on the WG list during the Last Call, either we're really close to "done" with these, or nobody is paying attention. (It's also conceivable that I may have missed some comments in the flurry of discussion of newline conventions) I'd like to hope that we're almost done.. CURRENT ISSUES: Discussion concerning the core drafts on the WG list since the start of the last call has concerned two issues. - inconsistancy in architecture draft vs. RSA signature encoding Niels Mo"ller pointed out that the architecture draft recommends using mpint (a signed integer) for such values; the transport draft uses a "string" containing an (unsigned) representation. Because of a lack of other voices on this issue I can't judge where the WG consensus lies. [personal opinion] if a change to the drafts is warranted, we should fix this with an editorial change rather than a change to the wire protocol. - possible improvements to X11 forwarding Simon Tatham suggested some improvements to X11 forwarding. Rough consensus appears to be that we shouldn't hold the core drafts for improvements in the area. WHAT HAPPENS NEXT: Assuming nothing else is raised, we appear to be in good shape to actually submit the drafts to the IESG. If we decide to make an editorial change for Niels's issue, we can republish new versions of the two drafts (architecture and transport), and do an additional one week WG last call to review just that change. Once the last call period expires, I then then submit the documents to the security area directors for review; assuming it passes their review, it then goes into a 2-week-long IETF-wide last call, and then to the IESG for balloting. - Bill From owner-ietf-ssh@clinet.fi Sat Jan 27 04:00:30 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14475 for ; Sat, 27 Jan 2001 04:00:29 -0500 (EST) From: owner-ietf-ssh@clinet.fi Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id IAA23998 for ietf-ssh-outgoing; Sat, 27 Jan 2001 08:58:06 +0200 Received: from www.psvti.or.kr ([210.100.144.1]) by mail.clinet.fi (8.9.3/8.9.3) with SMTP id IAA23992 for ; Sat, 27 Jan 2001 08:58:03 +0200 Received: from j4LcwrJij (unverified [208.187.142.76]) by www.psvti.or.kr (EMWAC SMTPRS 0.83) with SMTP id ; Sat, 27 Jan 2001 15:57:59 +0900 DATE: 27 Jan 01 1:00:36 AM Message-ID: SUBJECT: make the choice, Lose it Sender: owner-ietf-ssh@clinet.fi Precedence: bulk It's a scientific fact: High-carbohydrate diets simply don't work. When you consume extra carbohydrates and sugars, they simply turn into fat. But now, a scientific breakthrough has shown that the real secret to losing fat is to cut your intake of carbohydrates and sugars. It's no wonder that low-carbohydrate diet plans have become so incredibly popular these days. Our product is the first scientifically designed, all-natural, stimulant-free dietary supplement that helps you cut the carbs and lose the fat. It's As Easy As 1, 2, 3! This supplement helps to: 1. Turn carbohydrates into energy instead of fat. 2. Burn stored fat while promoting lean muscle. 3. Reduce cravings for carbohydrates and sugars. For a link to our website with full details and online ordering mailto:nocarb1@uol.com.ar?subject=moreinfo AOL users click here ask for more info! Our product also presents an excellent opportunity for marketers and people in the MLM line of business.Please ask for marketing info if you are interseted Get healthy and get PAID! to be removed from the list mailto:stop24@uol.com.ar?subject=remove From owner-ietf-ssh@clinet.fi Sat Jan 27 04:23:53 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14646 for ; Sat, 27 Jan 2001 04:23:52 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id JAA24456 for ietf-ssh-outgoing; Sat, 27 Jan 2001 09:07:43 +0200 Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id JAA24448 for ; Sat, 27 Jan 2001 09:07:40 +0200 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id XAA03478 for ; Fri, 26 Jan 2001 23:07:38 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id XAA08324 for ietf-ssh@clinet.fi; Fri, 26 Jan 2001 23:07:38 -0800 (PST) Date: Fri, 26 Jan 2001 23:07:37 -0800 From: Wei Dai To: ietf-ssh@clinet.fi Subject: zlib partial flush Message-ID: <20010126230737.H17465@eskimo.com> References: <200101270412.f0R4C15149791@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200101270412.f0R4C15149791@thunk.east.sun.com>; from sommerfeld@east.sun.com on Fri, Jan 26, 2001 at 11:12:01PM -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk I raised an issue several months ago that I don't think ever got resolved. The issue is how to define "partial flush" of the zlib compressed data stream. I think the current definition is ambiguous, but I'm not sure how to fix it. The problem is that there is a bug in the current zlib library which requires more bits (consisting of empty blocks) to be outputed in a flush than is necessary. If we were to define "partial flush" in the most natural way (i.e. not taking into account this bug), someone may create an secsh implementation that's not compatible with any secsh implementation based on the current zlib. I've reported this bug to the zlib maintainers, and they've promised to fix it in a future release. Do we want to maintain backwards compatibility and define "partial flush" in a way that satisfies the current buggy zlib? From owner-ietf-ssh@clinet.fi Sat Jan 27 05:04:21 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14747 for ; Sat, 27 Jan 2001 05:04:21 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id JAA26565 for ietf-ssh-outgoing; Sat, 27 Jan 2001 09:52:46 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id JAA26560 for ; Sat, 27 Jan 2001 09:52:44 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id D05572402D4A; Sat, 27 Jan 2001 07:52:43 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id IAA08591; Sat, 27 Jan 2001 08:52:43 +0100 (MET) To: "Joseph Galbraith" Cc: Subject: Re: Making subsystems robust (was: Are we going to add a magic cookie to sftp?) References: <00b701c087ad$f2e12ff0$2800a8c0@merlin> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 27 Jan 2001 08:52:42 +0100 In-Reply-To: "Joseph Galbraith"'s message of "Fri, 26 Jan 2001 08:37:53 -0700" Message-ID: Lines: 33 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk "Joseph Galbraith" writes: > I think we should change the draft to specify that subsystems are > executed directly (not reading users .cshrc, and not setting > user's default umask). To me, that seems very much like an implementation detail. It's Unix tradition that daemons never start any user processes except by invoking the user's login shell, and many systems have restricted accounts where the restrictions are implemented by a special login shell in the passwd-database. (I'm not sure about how user CGI scripts are usually started, though). But a secsh implementation is still free to start subsystems in any way it likes. If you want to start some or all subsystems by plain exec(), not involving the user's login shell, please do (and I would like to hear about any problems that causes). > To address the SFTP UMASK problem, I would suggest adding a mechanism > for setting UMASK to the SFTP draft. I don't see any need for setting the umask in the protocol. If a client requests a file to be created, without specifying attributes, then the user's umask (if available) can be used for the defaults. OR the server provides some default permissions in some other way. As long as the default is reasonable (i.e. files are not created world writable, that's fine. When a client wants more control than that, the right way is for the client to specify the exact permission flags it wants, not to add the very unix-specific notion of umask to the protocol. /Niels From owner-ietf-ssh@clinet.fi Sat Jan 27 07:04:25 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15134 for ; Sat, 27 Jan 2001 07:04:25 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA02774 for ietf-ssh-outgoing; Sat, 27 Jan 2001 12:36:36 +0200 Received: from mystery.acr.fi (ip212-226-160-97.adsl.kpnqwest.fi [212.226.160.97]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id MAA02771 for ; Sat, 27 Jan 2001 12:36:34 +0200 Received: from localhost (ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) with ESMTP id MAA23317; Sat, 27 Jan 2001 12:34:17 +0200 X-Authentication-Warning: mystery.acr.fi: ylo owned process doing -bs Date: Sat, 27 Jan 2001 12:34:16 +0200 (EET) From: Tatu Ylonen X-Sender: ylo@mystery.acr.fi To: Bill Sommerfeld cc: Niels M ller , ietf-ssh@clinet.fi Subject: Re: RSA signature encoding (Re: WG Last Call for secsh core drafts) In-Reply-To: <200101270135.f0R1Z35147066@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk I would prefer not to change the wire protocol. Tatu On Fri, 26 Jan 2001, Bill Sommerfeld wrote: > > > My evaluation of this is that this isn't an editorial change, since > > > "mpint" is a signed integer. > > > > Exactly, it is a change to the protocol although a small one. > > My viewpoint here (admittedly biased towards the the pragmatic) is > that this is at worst merely an aesthetic flaw. in the presence of > folks with running code and in the absence of wg consensus that a wire > protocol change makes sense, we should attempt to keep the wire > protocol compatible even at the expense of some aesthetic > inconsistency. > > > > So, do we want to leave the draft alone, or should we include include > > > an implementation note that says that mpints received as an > > > rsa_signature_blob should always be treated as positive numbers? > > > > I think it would be good to make it very vlear that the encoding used > > is not compatible with mpint. > > Yes, this makes sense. > > > Actually, using unsigned numbers rather than mpint turned out to make > > the dss code in implementation slightly simpler. > > Interesting. > > > I belive we should either stick to using mpint, for consistency. Or > > conclude that signed mpints are unneeded and too complicated, add an > > mpuint type, use mpuint for the rsa signature values, and recommend > > that mpuint rather than mpint be used for representing values in Z_n. > > > > The latter alternative is an editorial change (I could write it up if > > desired), and it makes the inconsistency more visible. > > Yes, please, so we have a concrete proposal to review.. > > Any comments from the rest of the WG? On an issue which may involve a > wire protocol change, I'm unwilling to assume that silence equals > agreement.. > > - Bill > From owner-ietf-ssh@clinet.fi Sat Jan 27 08:00:57 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15450 for ; Sat, 27 Jan 2001 08:00:56 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA03519 for ietf-ssh-outgoing; Sat, 27 Jan 2001 12:49:32 +0200 Received: from mystery.acr.fi (ip212-226-160-97.adsl.kpnqwest.fi [212.226.160.97]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id MAA03515 for ; Sat, 27 Jan 2001 12:49:31 +0200 Received: from localhost (ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) with ESMTP id MAA23325; Sat, 27 Jan 2001 12:47:13 +0200 X-Authentication-Warning: mystery.acr.fi: ylo owned process doing -bs Date: Sat, 27 Jan 2001 12:47:13 +0200 (EET) From: Tatu Ylonen X-Sender: ylo@mystery.acr.fi To: Wei Dai cc: ietf-ssh@clinet.fi Subject: Re: zlib partial flush In-Reply-To: <20010126230737.H17465@eskimo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk I think we need to maintain backwards compatibility, or every Secure Shell (both SSH1 and SSH2) client and server is going to break. I wrote the original code that used the partial flush; unfortunately I am not sufficiently familiar with ZLIB and the compression mechanism in general. I never thoroughly analyzed the exact bits it generated on the wire. When writing the spec I just took the easy way out and referenced the ZLIB RFCs (1950 and 1951). Could you (or someone else familiar with the internals of ZLIB) please write a specification of what the partial flush really means in the context of SECSH? Something that could be put into the transport protocol draft. There is also the possibility of defining a new compression method (e.g., "zlib-2") which does not suffer from the bug. The downside would be that for a long transition period, compression would often be disabled because no common algorithm was found (unless new implementations supported both). I don't know zlib well enough to really know what would be the best answer, but I would be happy if we could avoid having a second zlib compression method. Tatu On Fri, 26 Jan 2001, Wei Dai wrote: > I raised an issue several months ago that I don't think ever got resolved. > The issue is how to define "partial flush" of the zlib compressed data > stream. I think the current definition is ambiguous, but I'm not sure how > to fix it. The problem is that there is a bug in the current zlib library > which requires more bits (consisting of empty blocks) to be outputed in a > flush than is necessary. If we were to define "partial flush" in the most > natural way (i.e. not taking into account this bug), someone may create an > secsh implementation that's not compatible with any secsh implementation > based on the current zlib. > > I've reported this bug to the zlib maintainers, and they've promised to > fix it in a future release. Do we want to maintain backwards compatibility > and define "partial flush" in a way that satisfies the current buggy zlib? > From owner-ietf-ssh@clinet.fi Sat Jan 27 11:04:22 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16663 for ; Sat, 27 Jan 2001 11:04:21 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA13733 for ietf-ssh-outgoing; Sat, 27 Jan 2001 15:58:36 +0200 Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA13729 for ; Sat, 27 Jan 2001 15:58:34 +0200 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id FAA04373; Sat, 27 Jan 2001 05:58:32 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id FAA09294; Sat, 27 Jan 2001 05:58:32 -0800 (PST) Date: Sat, 27 Jan 2001 05:58:32 -0800 From: Wei Dai To: Tatu Ylonen Cc: ietf-ssh@clinet.fi Subject: Re: zlib partial flush Message-ID: <20010127055832.J17465@eskimo.com> References: <20010126230737.H17465@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from ylo@ssh.com on Sat, Jan 27, 2001 at 12:47:13PM +0200 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Here are my suggested definitions. First the non-compatible version, which you may consider for "zlib-2". (An implementation that supports "zlib-2" can also easily support "zlib" so it may be a good idea to have both.) This definition has the advantage of being simpler and saving a few bytes per packet: A partial flush means that the current compressed block is ended and all data will be output. If the current block does not end on a byte boundary, an empty block is added to fill up the last byte. Here's the compatible version: A partial flush means that the current compressed block is ended and all data will be output. One or more empty blocks are added after the compressed block to ensure that there are at least 9 bits counting from the start of the last Huffman code not coding for end-of-block to the end of the packet payload. On Sat, Jan 27, 2001 at 12:47:13PM +0200, Tatu Ylonen wrote: > I think we need to maintain backwards compatibility, or every Secure Shell > (both SSH1 and SSH2) client and server is going to break. > > I wrote the original code that used the partial flush; unfortunately I am > not sufficiently familiar with ZLIB and the compression mechanism in > general. I never thoroughly analyzed the exact bits it generated on the > wire. When writing the spec I just took the easy way out and referenced > the ZLIB RFCs (1950 and 1951). > > Could you (or someone else familiar with the internals of ZLIB) > please write a specification of what the partial flush really means in the > context of SECSH? Something that could be put into the transport protocol > draft. > > There is also the possibility of defining a new compression method (e.g., > "zlib-2") which does not suffer from the bug. The downside would be that > for a long transition period, compression would often be disabled because no > common algorithm was found (unless new implementations supported both). I > don't know zlib well enough to really know what would be the best answer, > but I would be happy if we could avoid having a second zlib compression > method. > > Tatu > > On Fri, 26 Jan 2001, Wei Dai wrote: > > > I raised an issue several months ago that I don't think ever got resolved. > > The issue is how to define "partial flush" of the zlib compressed data > > stream. I think the current definition is ambiguous, but I'm not sure how > > to fix it. The problem is that there is a bug in the current zlib library > > which requires more bits (consisting of empty blocks) to be outputed in a > > flush than is necessary. If we were to define "partial flush" in the most > > natural way (i.e. not taking into account this bug), someone may create an > > secsh implementation that's not compatible with any secsh implementation > > based on the current zlib. > > > > I've reported this bug to the zlib maintainers, and they've promised to > > fix it in a future release. Do we want to maintain backwards compatibility > > and define "partial flush" in a way that satisfies the current buggy zlib? > > From owner-ietf-ssh@clinet.fi Sat Jan 27 11:56:44 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16885 for ; Sat, 27 Jan 2001 11:56:44 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA17394 for ietf-ssh-outgoing; Sat, 27 Jan 2001 17:04:45 +0200 Received: from orchard.arlington.ma.us (orchard.hamachi.org [4.255.0.98]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA17390 for ; Sat, 27 Jan 2001 17:04:44 +0200 Received: by orchard.arlington.ma.us (Postfix, from userid 587) id 8B5642A4B; Sat, 27 Jan 2001 10:04:38 -0500 (EST) Received: from orchard.arlington.ma.us (localhost [127.0.0.1]) by orchard.arlington.ma.us (Postfix) with ESMTP id 5189F1FC0; Sat, 27 Jan 2001 10:04:38 -0500 (EST) To: Wei Dai Cc: Tatu Ylonen , ietf-ssh@clinet.fi Subject: Re: zlib partial flush In-Reply-To: Message from Wei Dai of "Sat, 27 Jan 2001 05:58:32 PST." <20010127055832.J17465@eskimo.com> Reply-To: sommerfeld@orchard.arlington.ma.us Date: Sat, 27 Jan 2001 10:04:32 -0500 From: Bill Sommerfeld Message-Id: <20010127150438.8B5642A4B@orchard.arlington.ma.us> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Ok. [WG chair hat on] I'd like to treat this as two separate issues: 1) we don't accurately describe what's on the wire (due to the zlib bug). This is serious and (IMHO) warrants a fix to the current drafts. (noting the zlib bug). 2) we could do better on the compression. One of my alter egos is a performance tweaker, so fixing this (by creating an alternate zlib-2 compression method) has a definite appeal. At this stage in the game (for Proposed Standard), it's OK to toss in new features without implementation experience, but I don't think we want to delay the drafts until we get consensus on zlib-2; it might also be wise to wait until someone plugs the new zlib release into a secsh implementation before defining "zlib-2". So, what we can do is create a separate zlib-2 draft, and when that gets suitably mature fold that into the transport draft.. Comments? - Bill From owner-ietf-ssh@clinet.fi Sat Jan 27 12:53:40 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17148 for ; Sat, 27 Jan 2001 12:53:39 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA19907 for ietf-ssh-outgoing; Sat, 27 Jan 2001 17:48:05 +0200 Received: from folly.informatik.uni-erlangen.de (muedi6-212-144-217-103.arcor-ip.net [212.144.217.103]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA19897 for ; Sat, 27 Jan 2001 17:48:02 +0200 Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 3AB7FF2D; Sat, 27 Jan 2001 16:05:06 +0100 (CET) Date: Sat, 27 Jan 2001 16:05:05 +0100 From: Markus Friedl To: ietf-ssh@clinet.fi Subject: Re: Making subsystems robust (was: Are we going to add a magic cookie to sftp?) Message-ID: <20010127160505.A12905@folly> References: <00b701c087ad$f2e12ff0$2800a8c0@merlin> <20010126191427.A16620@faui02.informatik.uni-erlangen.de> <003401c08811$8614de30$0201a8c0@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: <003401c08811$8614de30$0201a8c0@vandyke.com>; from jpv@vandyke.com on Fri, Jan 26, 2001 at 08:28:11PM -0700 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Fri, Jan 26, 2001 at 08:28:11PM -0700, Jeff P. Van Dyke wrote: > Markus Friedl" writes: > > > > no, the protocol should not specify this. an implementation > > advice could be added, but shell vs. no-shell is a site > > or implementaion policy. > > > > the protocol should not care at all. > > I think a shell vs. no-shell for subsystems is more than > just a site or implementation policy. for example, many sites use /bin/false as a login shell for disabled accounts (propaply much more than users with /bin/csh and a broken .cshrc). if you decide that the SECSH protocol says that all subsystems _must_ be executed directly, without the login-shell, then these users are allowed to use SFTP. > If subsystem is going to be *the* main way toextend SECSH, I > believe this mechanism must be robust. Allowing the server > to start the subsystem in a way where the channel isn't > clean and where stdout or stderr coming from a source > other than a client is a mistake. you probably mean 'subsystem process' instead of client. but even the .cshrc problems can be fixed without changing the protocols. when a ssh-server executes a subsystem, it can wait for some magic cookie. but this is an implementation detail and there is no need to add these cookies to the protocols themselve. > I would find the following acceptable: > > 1) remove the text about magic cookies i agree. > 2) add text indicating there must be a way to configure > the starting of a subsystem where the stream is clean s/must/should/ > 3) add implementation advice that servers may wish to > provide a mechanism for starting subsystems with > a shell or user's enviroment this sounds reasonable. > With this change, it would be possible to configure a > UNIX SSH server to invoke a public key subsystem so > the .cshrc would not be used. And, it would allow the > same system to configure sftp such that the .cshrc > would be used and the default umask would be set. so after all, it's a site policy. i completely agree with this. > By making this change, when the .cshrc is used is a > server configuration issue. But more importantly, > it guarantees a robust mechanism for extending SECSH. > > For those who still think we should simply delete the > new language about magic cookies, would they be opposed > to extending SECSH by adding new channels as a more > robust way of extending SECSH? i strongly support the deletion of the paragraph about 'magic cookies, an implementation advices is more than enough. -markus From owner-ietf-ssh@clinet.fi Sat Jan 27 12:56:12 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17170 for ; Sat, 27 Jan 2001 12:56:12 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA19906 for ietf-ssh-outgoing; Sat, 27 Jan 2001 17:48:06 +0200 Received: from folly.informatik.uni-erlangen.de (muedi6-212-144-217-103.arcor-ip.net [212.144.217.103]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA19898 for ; Sat, 27 Jan 2001 17:48:02 +0200 Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 7A1F8114F; Sat, 27 Jan 2001 16:19:20 +0100 (CET) Date: Sat, 27 Jan 2001 16:19:20 +0100 From: Markus Friedl To: Bill Sommerfeld Cc: ietf-ssh@clinet.fi Subject: Re: WG Last Call for secsh core drafts (halfway point). Message-ID: <20010127161920.B12905@folly> References: <200101270412.f0R4C15149791@thunk.east.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: <200101270412.f0R4C15149791@thunk.east.sun.com>; from sommerfeld@east.sun.com on Fri, Jan 26, 2001 at 11:12:01PM -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Fri, Jan 26, 2001 at 11:12:01PM -0500, Bill Sommerfeld wrote: > We're roughly halfway through the last-call period for the core > drafts: > > draft-ietf-secsh-architecture-07.txt > draft-ietf-secsh-transport-09.txt > draft-ietf-secsh-userauth-09.txt > draft-ietf-secsh-connect-09.txt > > I'd like to encourage additional review of the documents, especially > by implementors. Based on the number of comments on the WG list > during the Last Call, either we're really close to "done" with these, > or nobody is paying attention. (It's also conceivable that I may have > missed some comments in the flurry of discussion of newline > conventions) > > I'd like to hope that we're almost done.. > > CURRENT ISSUES: > > - inconsistancy in architecture draft vs. RSA signature encoding this is not really a inconsistancy, since it's at least consistent with the "ssh-dss" encoding. there is one more issue: i think that the text about 'magic cookies' added in draft-ietf-secsh-connect-09.txt should be removed again. As the user's shell is usually used to execute the subsystem, it is advisable for the subsystem protocol to have a "magic cookie" at the beginning of the protocol transaction to distinguish from arbitrary output from shell initialization scripts etc. This spurious output from the shell may be filtered out either at the server or at the client. an implementation advise, as proposed by Jeff P. Van Dyke, is more than enough. if you don't want to remove this section, than at least the last sentence should be changed to : This spurious output from the shell must be filtered out at the server. because old and future clients should not be affected by server implementation details! -markus From owner-ietf-ssh@clinet.fi Sat Jan 27 20:40:23 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19258 for ; Sat, 27 Jan 2001 20:40:22 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA13300 for ietf-ssh-outgoing; Sun, 28 Jan 2001 01:42:44 +0200 Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id BAA13280 for ; Sun, 28 Jan 2001 01:42:29 +0200 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id PAA23373; Sat, 27 Jan 2001 15:42:22 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id PAA00606; Sat, 27 Jan 2001 15:42:21 -0800 (PST) Date: Sat, 27 Jan 2001 15:42:21 -0800 From: Wei Dai To: Bill Sommerfeld Cc: Tatu Ylonen , ietf-ssh@clinet.fi Subject: Re: zlib partial flush Message-ID: <20010127154221.M17465@eskimo.com> References: <20010127150438.8B5642A4B@orchard.arlington.ma.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010127150438.8B5642A4B@orchard.arlington.ma.us>; from sommerfeld@orchard.arlington.ma.us on Sat, Jan 27, 2001 at 10:04:32AM -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Sat, Jan 27, 2001 at 10:04:32AM -0500, Bill Sommerfeld wrote: > At this stage in the game (for Proposed Standard), it's OK to toss in > new features without implementation experience, but I don't think we > want to delay the drafts until we get consensus on zlib-2; it might > also be wise to wait until someone plugs the new zlib release into a > secsh implementation before defining "zlib-2". I don't think there's really any need to wait. The risk seems very low that if we define zlib-2 today it will turn out to be unimplementable or ill-defined. In fact there is already an implementation of the zlib compression format that doesn't suffer from the zlib bug, namely the one in Crypto++ (http://cryptopp.com). From owner-ietf-ssh@clinet.fi Sat Jan 27 21:36:46 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20345 for ; Sat, 27 Jan 2001 21:36:45 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA15586 for ietf-ssh-outgoing; Sun, 28 Jan 2001 02:23:50 +0200 Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id CAA15576 for ; Sun, 28 Jan 2001 02:23:47 +0200 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id QAA02164; Sat, 27 Jan 2001 16:23:37 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id QAA01786; Sat, 27 Jan 2001 16:23:37 -0800 (PST) Date: Sat, 27 Jan 2001 16:23:37 -0800 From: Wei Dai To: Tatu Ylonen Cc: ietf-ssh@clinet.fi Subject: Re: zlib partial flush Message-ID: <20010127162337.N17465@eskimo.com> References: <20010126230737.H17465@eskimo.com> <20010127055832.J17465@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010127055832.J17465@eskimo.com>; from weidai@eskimo.com on Sat, Jan 27, 2001 at 05:58:32AM -0800 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Sat, Jan 27, 2001 at 05:58:32AM -0800, Wei Dai wrote: > Here's the compatible version: > > A partial flush means that the current compressed block is ended and all > data will be output. One or more empty blocks are added after the > compressed block to ensure that there are at least 9 bits counting from > the start of the last Huffman code not coding for end-of-block to the end > of the packet payload. I looked at the zlib source code a bit more, and it seems the definition I suggested above does not correspond exactly to what zlib does now. The above definition may be sufficient to work around the zlib bug, but since it's not what's actually implemented today, I can't be sure. Here's a better definition: A partial flush means that the current compressed block is ended and all data will be output. If the current block is not a stored block, one or more empty blocks are added after the current block to ensure that there are at least 8 bits counting from the start of the end-of-block code of the current block to the end of the packet payload. From owner-ietf-ssh@clinet.fi Sat Jan 27 21:51:15 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20385 for ; Sat, 27 Jan 2001 21:51:15 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA16498 for ietf-ssh-outgoing; Sun, 28 Jan 2001 02:43:49 +0200 Received: from relay.oss.ru (relay.oss.ru [212.119.32.10]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id CAA16495 for ; Sun, 28 Jan 2001 02:43:48 +0200 Received: from cd638917 ([212.119.34.80]) by relay.oss.ru (8.9.3/8.9.3) with SMTP id DAA33715 for ; Sun, 28 Jan 2001 03:48:28 +0300 (MSK) Message-Id: <200101280048.DAA33715@relay.oss.ru> From: petrboris To: ietf-ssh@clinet.fi Subject: Предлагаем базы данных X-Mailer: Mail Bomber Reply-To: cd_moscow@email.com Date: Sun, 28 Jan 2001 03:43:54 +0300 Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to base64 by mail.clinet.fi id CAA16498 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id VAA20385 Уважаемые дамы и господа! Предлагаем Вашему вниманию базы данных: 1. Новая база по предприятиям Москвы - март 2000 г. (в трех частях на 3-х компакт-дисках). 2. База данных ГИБДД Москвы - июнь 2000 г. 3. Телефонный справочник по Московскому региону - 1999 г. 4. Владельцы водительских прав в Москве. 5. Департамент муниципального жилья (жилые помещения и их собственники). 6. База данных ГИБДД Москвы - сентябрь 2000 г. (на 2-х компакт-дисках). Цена каждого компакт-диска - 10 у.е. Доставка курьером по Москве бесплатная. Прайсы на CD-Rom и АудиоСД высылаются по запросу. E-mail: cd_moscow@email.com Для получения заказа сообщите адрес доставки, телефон - и рассчитайтесь с курьером. From owner-ietf-ssh@clinet.fi Sun Jan 28 14:00:42 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09930 for ; Sun, 28 Jan 2001 14:00:41 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA03661 for ietf-ssh-outgoing; Sun, 28 Jan 2001 19:21:20 +0200 Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by mail.clinet.fi (8.9.3/8.9.3) with SMTP id TAA03657 for ; Sun, 28 Jan 2001 19:21:19 +0200 Received: (qmail 15494 invoked by uid 0); 28 Jan 2001 17:20:49 -0000 Received: from pd901c55d.dip.t-dialin.net (HELO qserver.gmx.net) (217.1.197.93) by mail.gmx.net (mp016-rz3) with SMTP; 28 Jan 2001 17:20:49 -0000 Message-Id: <4.3.1.0.20010128181930.00a79100@pop.gmx.net> X-Sender: 2302470 @pop.gmx.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 28 Jan 2001 18:21:38 +0100 To: ietf-ssh@clinet.fi From: qINVADERp Subject: secure connection from win to unix Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Hello, i look for a mailclient there check mails from a ssl Unx system. But this program must run under windows98 pleace help me, thanks Invader From owner-ietf-ssh@clinet.fi Sun Jan 28 15:15:14 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10295 for ; Sun, 28 Jan 2001 15:15:13 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA08225 for ietf-ssh-outgoing; Sun, 28 Jan 2001 20:31:56 +0200 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA08212 for ; Sun, 28 Jan 2001 20:31:51 +0200 Received: from nox.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [209.151.24.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id NAA26155 for ; Sun, 28 Jan 2001 13:31:33 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [209.151.24.20]) by nox.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f0SIvXn14976 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sun, 28 Jan 2001 10:57:34 -0800 (PST) Received: from marajade.sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [127.0.0.1]) by marajade.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f0SIKbu15420 for ; Sun, 28 Jan 2001 13:20:37 -0500 (EST) Message-Id: <200101281820.f0SIKbu15420@marajade.sandelman.ottawa.on.ca> To: ietf-ssh@clinet.fi Subject: Re: draft-ietf-secsh-publickeyfile-00.txt In-reply-to: Your message of "Thu, 25 Jan 2001 22:02:00 +0200." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 28 Jan 2001 13:20:37 -0500 From: Michael Richardson Sender: owner-ietf-ssh@clinet.fi Precedence: bulk >>>>> "Tatu" == Tatu Ylonen writes: >> 30 years of experience transfering files between heterogeneous systems >> are being ignored in this protocol. Transfering everything as binary >> data is fine when using homogeneous systems. But it is not acceptable >> when transfering text files among heterogeneous systems. Just look at >> what happens when you attempt to transfer a makefile produced on >> Windows to a Unix host. Or worse, to a Macintosh. Tatu> Most people hardly ever transfer a Makefile between Unix, Windows, Tatu> or Macintosh. They transfer a tgz, a zip, or an hqx. Tatu> Transferring plain ASCII files is becoming extremely rare. Even Tatu> the simplest memos now most often go with the mime type Tatu> application/msword. Postscript has been replaced by pdf. Images Tatu> are gifs, jpgs, tiffs, or some other binary format. HTML pages Recall that this is being argued under the subject of the public key file format. I will make the following comments: 1) I've most frequently transfered it via cut&paste. cat ~/.ssh/identity.pub cat >>~/.ssh/authorized_keys 2) I've sometimes had to uuencode it to get around xterm's with limited line length support. 3) finally, i've used scp. I'd like to see "sftp" be capable of passing a MIME type for each file. Tatu> frequently have national characters from iso8859-x or some Japanese Tatu> character set. Spreadsheets are usually made with Excel and Tatu> presentations with Powerpoint. All these formats are binary. I Tatu> don't see a big move back to non-binary formats in the future. If one assumes the trend that you list, which is best characterized as "Microsoft Office" dominance in file formats, then the format won't be ASCII, but rather will explicitely be "sequence of OLE objects", which is a structured format. Tatu> I will make the claim that automatically defaulting to ASCII mode Tatu> is HARMFUL, and is becoming MORE HARMFUL as time goes by. If the Tatu> user explicitly wants to convert, he/she can then specify Tatu> conversion type to the client (e.g., convert for VAX/VMS). I think that the topic of "defaults" is really a client issue. The protocol should explicitely specify it one way or another. Tatu> I vote against adding the complexity of ASCII conversions into the Tatu> protocol. My reason for this opinion is that I think it can be Tatu> implemented in the client with the same complexity without Tatu> modifying the protocol (also thinking of what the user has to do to Tatu> enable it), and keeping it as a client implementation issue avoids Tatu> bloating the complexity of the protocol and of server Tatu> implementations. I strongly suggest putting MIME types in. If I open a file in "text/*" then that may mean something. It does mean that I know what the conventions are! they are specifically those defined in SMTP. ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ietf-ssh@clinet.fi Sun Jan 28 15:58:56 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10388 for ; Sun, 28 Jan 2001 15:58:55 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id VAA10229 for ietf-ssh-outgoing; Sun, 28 Jan 2001 21:02:52 +0200 Received: from alcove.wittsend.com (IDENT:root@alcove.wittsend.com [130.205.0.20]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id VAA10226 for ; Sun, 28 Jan 2001 21:02:50 +0200 Received: (from mhw@localhost) by alcove.wittsend.com (8.9.3/8.9.3) id OAA23802; Sun, 28 Jan 2001 14:02:21 -0500 Date: Sun, 28 Jan 2001 14:02:21 -0500 From: "Michael H. Warfield" To: qINVADERp Cc: ietf-ssh@clinet.fi Subject: Re: secure connection from win to unix Message-ID: <20010128140221.E23716@alcove.wittsend.com> References: <4.3.1.0.20010128181930.00a79100@pop.gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.2i In-Reply-To: <4.3.1.0.20010128181930.00a79100@pop.gmx.net>; from qINVADERp@gmx.net on Sun, Jan 28, 2001 at 06:21:38PM +0100 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Sun, Jan 28, 2001 at 06:21:38PM +0100, qINVADERp wrote: > Hello, > i look for a mailclient there check mails from a ssl Unx system. > But this program must run under windows98 Are you looking for a mail client on Unix that can access an mail server using ssl? Mutt does this as does fetchmail. There are several others, and you can set up an ssl tunnel or ssl proxy. But why are you asking this on the IETF-SSH mailing list? This has nothing to do with either SSH or the IETF. > pleace help me, thanks > Invader Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-ietf-ssh@clinet.fi Sun Jan 28 19:57:22 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11088 for ; Sun, 28 Jan 2001 19:57:21 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id AAA24362 for ietf-ssh-outgoing; Mon, 29 Jan 2001 00:58:27 +0200 Received: from mystery.acr.fi (ip212-226-160-97.adsl.kpnqwest.fi [212.226.160.97]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id AAA24358 for ; Mon, 29 Jan 2001 00:58:26 +0200 Received: from localhost (ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) with ESMTP id AAA24902; Mon, 29 Jan 2001 00:56:05 +0200 X-Authentication-Warning: mystery.acr.fi: ylo owned process doing -bs Date: Mon, 29 Jan 2001 00:56:05 +0200 (EET) From: Tatu Ylonen X-Sender: ylo@mystery.acr.fi To: Michael Richardson cc: ietf-ssh@clinet.fi Subject: Re: draft-ietf-secsh-publickeyfile-00.txt In-Reply-To: <200101281820.f0SIKbu15420@marajade.sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > I strongly suggest putting MIME types in. If I open a file in "text/*" > then that may mean something. It does mean that I know what the conventions > are! they are specifically those defined in SMTP. I strongly oppose. The server usually has no more information available than the client for determining the mime type. Tatu From owner-ietf-ssh@clinet.fi Sun Jan 28 21:27:43 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11355 for ; Sun, 28 Jan 2001 21:27:42 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA29866 for ietf-ssh-outgoing; Mon, 29 Jan 2001 02:36:10 +0200 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id CAA29862 for ; Mon, 29 Jan 2001 02:36:09 +0200 Received: from nox.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [209.151.24.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id TAA29710 for ; Sun, 28 Jan 2001 19:36:08 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [209.151.24.20]) by nox.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f0T129n15180 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sun, 28 Jan 2001 17:02:10 -0800 (PST) Received: from marajade.sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [127.0.0.1]) by marajade.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f0T0PBu26355 for ; Sun, 28 Jan 2001 19:25:11 -0500 (EST) Message-Id: <200101290025.f0T0PBu26355@marajade.sandelman.ottawa.on.ca> To: ietf-ssh@clinet.fi Subject: mime types in sftp In-reply-to: Your message of "Mon, 29 Jan 2001 00:56:05 +0200." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 28 Jan 2001 19:25:11 -0500 From: Michael Richardson Sender: owner-ietf-ssh@clinet.fi Precedence: bulk >>>>> "Tatu" == Tatu Ylonen writes: >> I strongly suggest putting MIME types in. If I open a file in "text/*" >> then that may mean something. It does mean that I know what the >> conventions are! they are specifically those defined in SMTP. Tatu> I strongly oppose. The server usually has no more information Tatu> available than the client for determining the mime type. On Unix systems, I agree. If the server doesn't know, it can use "application/octet-stream" and be done with it. On other systems (particularly Mac), I disagree. The hint is very useful if it allows the receiving system to decide how to do the fopen(). ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ietf-ssh@clinet.fi Sun Jan 28 22:01:39 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12376 for ; Sun, 28 Jan 2001 22:01:39 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA30444 for ietf-ssh-outgoing; Mon, 29 Jan 2001 02:50:04 +0200 Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id CAA30441 for ; Mon, 29 Jan 2001 02:50:03 +0200 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id TAA19856; Sun, 28 Jan 2001 19:49:54 -0500 (EST) Date: Sun, 28 Jan 2001 19:49:50 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Tatu Ylonen Cc: Michael Richardson , ietf-ssh@clinet.fi Subject: Re: draft-ietf-secsh-publickeyfile-00.txt In-Reply-To: Your message of Mon, 29 Jan 2001 00:56:05 +0200 (EET) Message-ID: Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > > I strongly suggest putting MIME types in. If I open a file in "text/*" > > then that may mean something. It does mean that I know what the conventions > > are! they are specifically those defined in SMTP. > > I strongly oppose. The server usually has no more information available > than the client for determining the mime type. > > Tatu > I completely agree. Unless the server stores mime types in the file system as a file attribute, the mime is nothing more than a guess. From owner-ietf-ssh@clinet.fi Mon Jan 29 00:27:18 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA14355 for ; Mon, 29 Jan 2001 00:27:18 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id FAA06063 for ietf-ssh-outgoing; Mon, 29 Jan 2001 05:28:32 +0200 Received: from levitator.1div0.com (node.061-0.ty.link.si [213.250.43.61]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id FAA06060 for ; Mon, 29 Jan 2001 05:28:30 +0200 Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id EAA23508 for ; Mon, 29 Jan 2001 04:11:59 +0100 Reply-To: From: "denis bider" To: Subject: server public key fingerprint? Date: Mon, 29 Jan 2001 04:27:52 +0100 Message-ID: <003301c089a3$766c2f90$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Hello everyone, is there a standardized fingerprint calculation method for verifying the integrity of a server's public key? I searched the archives for the string 'finger', and it only occurs once - in a PGP-related header field of a single message... I would think a standardized fingerprinting method would be necessary in order to facilitate interoperation of clients and servers from different vendors. How can you call up a server's administrator to verify the public key if your client calculates the fingerprint in a manner that is incompatible with the server? Regards, denis From owner-ietf-ssh@clinet.fi Mon Jan 29 00:30:16 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA14392 for ; Mon, 29 Jan 2001 00:30:15 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id FAA05539 for ietf-ssh-outgoing; Mon, 29 Jan 2001 05:15:49 +0200 Received: from kado.mindrot.org (foobar@CPE-203-45-24-18.vic.bigpond.net.au [203.45.24.18]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id FAA05534 for ; Mon, 29 Jan 2001 05:15:47 +0200 Received: from toad.mindrot.org (toad.mindrot.org [203.44.118.252]) by kado.mindrot.org (Postfix) with ESMTP id 52DB09003; Mon, 29 Jan 2001 13:06:03 +1100 (EST) Received: from mothra.mindrot.org (mothra.mindrot.org [203.44.118.225]) by toad.mindrot.org (Postfix) with ESMTP id 8EAD91A1C2; Mon, 29 Jan 2001 14:15:43 +1100 (EST) Received: by mothra.mindrot.org (Postfix, from userid 500) id 3D9D53C08B; Mon, 29 Jan 2001 14:15:42 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by mothra.mindrot.org (Postfix) with ESMTP id 3BC033C08A; Mon, 29 Jan 2001 14:15:42 +1100 (EST) Date: Mon, 29 Jan 2001 14:15:42 +1100 (EST) From: Damien Miller To: Michael Richardson Cc: ietf-ssh@clinet.fi Subject: Re: mime types in sftp In-Reply-To: <200101290025.f0T0PBu26355@marajade.sandelman.ottawa.on.ca> 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: owner-ietf-ssh@clinet.fi Precedence: bulk on Sun, 28 Jan 2001, Michael Richardson wrote: > Tatu> I strongly oppose. The server usually has no more information > Tatu> available than the client for determining the mime type. > > On Unix systems, I agree. If the server doesn't know, it can use > "application/octet-stream" and be done with it. > > On other systems (particularly Mac), I disagree. The hint is very useful > if it allows the receiving system to decide how to do the fopen(). This seems like overkill for identifying text from binary and could be accomodated using the existing SSH_FILEXFER_ATTR_EXTENDED mechanism. -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From owner-ietf-ssh@clinet.fi Mon Jan 29 01:56:26 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20604 for ; Mon, 29 Jan 2001 01:56:25 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id GAA09760 for ietf-ssh-outgoing; Mon, 29 Jan 2001 06:39:32 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id GAA09757 for ; Mon, 29 Jan 2001 06:39:31 +0200 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03805 for ; Sun, 28 Jan 2001 20:39:30 -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 XAA04081 for ; Sun, 28 Jan 2001 23:39:29 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id f0T4dT5151388 for ; Sun, 28 Jan 2001 23:39:29 -0500 (EST) Message-Id: <200101290439.f0T4dT5151388@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@clinet.fi Subject: Subsystems. Reply-to: sommerfeld@east.sun.com Date: Sun, 28 Jan 2001 23:39:29 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk The apparent consensus of the working group is that subsystems, not channels, should be used for "large scale" extensions along the lines of sftp. The exact means by which a secure shell server starts an instance of a particular subsystem is purely a local implementation / quality of implementation issue, out of scope for the working group. Server implementors should ensure that whatever means they use to start subsystems is robust; however, exactly how they do this is a local matter. As the subsystem interface is intended to be "pluggable", it's always possible that misconfiguration on the part of the administrator or end user may cause a requested subsystem to fail to start correctly. - Bill From owner-ietf-ssh@clinet.fi Mon Jan 29 07:26:56 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00171 for ; Mon, 29 Jan 2001 07:26:54 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA12264 for ietf-ssh-outgoing; Mon, 29 Jan 2001 12:39:05 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id MAA12197 for ; Mon, 29 Jan 2001 12:38:46 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id DCDDB2408234; Mon, 29 Jan 2001 10:38:44 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id LAA01689; Mon, 29 Jan 2001 11:38:44 +0100 (MET) To: sommerfeld@orchard.arlington.ma.us Cc: Wei Dai , Tatu Ylonen , ietf-ssh@clinet.fi Subject: Re: zlib partial flush References: <20010127150438.8B5642A4B@orchard.arlington.ma.us> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 29 Jan 2001 11:38:44 +0100 In-Reply-To: Bill Sommerfeld's message of "Sat, 27 Jan 2001 10:04:32 -0500" Message-ID: Lines: 22 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Bill Sommerfeld writes: > One of my alter egos is a performance tweaker, so fixing this (by > creating an alternate zlib-2 compression method) has a definite > appeal. Another alternative may be to define zlib partial flush accordning to Wei Dai's first definition, and add an implementation note saying what current zlib-based implemtations need? That would make the protocol simpler, while leaving to implementors and user's to deal with zlib bug-compatibility and configuration thereof. > So, what we can do is create a separate zlib-2 draft, and when that > gets suitably mature fold that into the transport draft.. Sounds reasonable to me. If we feel that it is important to include zlib-bug-compatibility negotiation in the general algorithm negotiation. /Niels From owner-ietf-ssh@clinet.fi Mon Jan 29 09:04:35 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02883 for ; Mon, 29 Jan 2001 09:04:34 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id NAA29659 for ietf-ssh-outgoing; Mon, 29 Jan 2001 13:47:19 +0200 Received: from nic.appgate.com (nic.appgate.com [193.12.107.226]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id NAA29655 for ; Mon, 29 Jan 2001 13:47:18 +0200 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id 9ED423BD31; Mon, 29 Jan 2001 12:47:18 +0100 (MET) Received: from pelee.firedoor.se (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 4EC9E6C019; Mon, 29 Jan 2001 12:47:18 +0100 (CET) Received: from appgate.com (pelee.firedoor.se [172.23.2.10]) by pelee.firedoor.se (Postfix) with ESMTP id 175D1317AF; Mon, 29 Jan 2001 12:47:05 +0100 (MET) Date: Mon, 29 Jan 2001 12:47:18 +0100 (MET) From: Martin Forssen Subject: Re: zlib partial flush To: nisse@lysator.liu.se Cc: sommerfeld@orchard.arlington.ma.us, weidai@eskimo.com, ylo@ssh.com, ietf-ssh@clinet.fi In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20010129114705.175D1317AF@pelee.firedoor.se> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > Bill Sommerfeld writes: >> So, what we can do is create a separate zlib-2 draft, and when that >> gets suitably mature fold that into the transport draft.. Why not define zlib-N where N is a digit between 0-9 and denotes the desired compression level? /MaF From owner-ietf-ssh@clinet.fi Mon Jan 29 10:47:37 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04204 for ; Mon, 29 Jan 2001 10:47:37 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA27198 for ietf-ssh-outgoing; Mon, 29 Jan 2001 15:45:06 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA27184 for ; Mon, 29 Jan 2001 15:45:04 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 5E459240318F; Mon, 29 Jan 2001 14:45:03 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id OAA04659; Mon, 29 Jan 2001 14:45:03 +0100 (MET) To: Michael Richardson Cc: ietf-ssh@clinet.fi Subject: Re: draft-ietf-secsh-publickeyfile-00.txt References: <200101281820.f0SIKbu15420@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 29 Jan 2001 14:45:02 +0100 In-Reply-To: Michael Richardson's message of "Sun, 28 Jan 2001 13:20:37 -0500" Message-ID: Lines: 21 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Michael Richardson writes: > I strongly suggest putting MIME types in. If I open a file in "text/*" > then that may mean something. It does mean that I know what the conventions > are! they are specifically those defined in SMTP. If you want MIME content types (and the system where the file lives happens to know the content type), put the content type in the SSH_FILEXFER_ATTR_EXTENDED. Not in the core protocol. Actually, after some more thinking, I think that approach is preferable als in the discussion of utf-8 filenames. In the core protocol, treat the names of files as arbitrary octet strings, with no structure or interpretation beyond using the /-character as a directory separator. Treat the contents of files as octet streams. If fancy conversions of file names and file contents, negotiation of conventions on both sides, etc, are desired, add those features as extensions, don't add them to the core protocol. /Niels From owner-ietf-ssh@clinet.fi Mon Jan 29 10:53:51 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04262 for ; Mon, 29 Jan 2001 10:53:50 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id QAA31607 for ietf-ssh-outgoing; Mon, 29 Jan 2001 16:02:42 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id QAA31597 for ; Mon, 29 Jan 2001 16:02:38 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 66747240A8F0; Mon, 29 Jan 2001 15:02:37 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id PAA21940; Mon, 29 Jan 2001 15:02:36 +0100 (MET) To: Cc: Subject: Re: server public key fingerprint? References: <003301c089a3$766c2f90$0201010a@intergalactic> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 29 Jan 2001 15:02:36 +0100 In-Reply-To: "denis bider"'s message of "Mon, 29 Jan 2001 04:27:52 +0100" Message-ID: Lines: 15 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk "denis bider" writes: > is there a standardized fingerprint calculation method for verifying the > integrity of a server's public key? I searched the archives for the string > 'finger', and it only occurs once - in a PGP-related header field of a > single message... LSH currently uses the SHA1 hash of the canonical SPKI encoding of the public key. I believe that OpenSSH calculates the fingerprint as the SHA1 hash of the keyblob. And then PGP uses yet another different fingerprinting method. Some coordination would be desirable. /Niels From owner-ietf-ssh@clinet.fi Mon Jan 29 11:53:01 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05689 for ; Mon, 29 Jan 2001 11:53:00 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA29933 for ietf-ssh-outgoing; Mon, 29 Jan 2001 15:55:52 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA29808 for ; Mon, 29 Jan 2001 15:55:07 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 5CBD02402808; Mon, 29 Jan 2001 14:55:06 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id OAA14495; Mon, 29 Jan 2001 14:55:05 +0100 (MET) To: sommerfeld@east.sun.com Cc: ietf-ssh@clinet.fi Subject: Re: Subsystems. References: <200101290439.f0T4dT5151388@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 29 Jan 2001 14:55:04 +0100 In-Reply-To: Bill Sommerfeld's message of "Sun, 28 Jan 2001 23:39:29 -0500" Message-ID: Lines: 32 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Bill Sommerfeld writes: > > > The apparent consensus of the working group is that subsystems, not > channels, should be used for "large scale" extensions along the lines > of sftp. I'm not sure I understand this paragraph. But I don't quite agree with it. For instance, I believe that a file transfer service which uses one channel for each open file would be a useful and natural way to take advantage of the channel mechanism, even if sftp happens to do things differently. I agree fully with your other paragraphs. Regards, /Niels > The exact means by which a secure shell server starts an instance of a > particular subsystem is purely a local implementation / quality of > implementation issue, out of scope for the working group. > > Server implementors should ensure that whatever means they use to > start subsystems is robust; however, exactly how they do this is a > local matter. > > As the subsystem interface is intended to be "pluggable", it's always > possible that misconfiguration on the part of the administrator or end > user may cause a requested subsystem to fail to start correctly. > > - Bill From owner-ietf-ssh@clinet.fi Mon Jan 29 17:09:04 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10673 for ; Mon, 29 Jan 2001 17:09:04 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA10530 for ietf-ssh-outgoing; Mon, 29 Jan 2001 22:16:43 +0200 Received: from mystery.acr.fi (ip212-226-160-97.adsl.kpnqwest.fi [212.226.160.97]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id WAA10525 for ; Mon, 29 Jan 2001 22:16:43 +0200 Received: from localhost (ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) with ESMTP id WAA26026; Mon, 29 Jan 2001 22:13:49 +0200 X-Authentication-Warning: mystery.acr.fi: ylo owned process doing -bs Date: Mon, 29 Jan 2001 22:13:49 +0200 (EET) From: Tatu Ylonen X-Sender: ylo@mystery.acr.fi To: Martin Forssen cc: nisse@lysator.liu.se, sommerfeld@orchard.arlington.ma.us, weidai@eskimo.com, ietf-ssh@clinet.fi Subject: Re: zlib partial flush In-Reply-To: <20010129114705.175D1317AF@pelee.firedoor.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk I considered this when originally designing SSH2. However, the compression level is basically a local policy issue of the sending side. Also, I think I recall a little bit of experimenting and finding little advantage (but much higher computational cost) in the higher compression levels. Tatu On Mon, 29 Jan 2001, Martin Forssen wrote: > > Bill Sommerfeld writes: > >> So, what we can do is create a separate zlib-2 draft, and when that > >> gets suitably mature fold that into the transport draft.. > > Why not define zlib-N where N is a digit between 0-9 and denotes the > desired compression level? > > /MaF > From owner-ietf-ssh@clinet.fi Mon Jan 29 19:17:55 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12479 for ; Mon, 29 Jan 2001 19:17:54 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id AAA19922 for ietf-ssh-outgoing; Tue, 30 Jan 2001 00:49:06 +0200 Received: from levitator.1div0.com (node.061-0.ty.link.si [213.250.43.61]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id AAA19915 for ; Tue, 30 Jan 2001 00:49:04 +0200 Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id XAA25743; Mon, 29 Jan 2001 23:32:22 +0100 Reply-To: From: "denis bider" To: "'Niels Mvller'" , Subject: RE: server public key fingerprint? Date: Mon, 29 Jan 2001 23:47:34 +0100 Message-ID: <004601c08a45$793ea8e0$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit > > is there a standardized fingerprint calculation method for > > verifying the integrity of a server's public key? I searched > > the archives for the string 'finger', and it only occurs once > > - in a PGP-related header field of a > > single message... > > LSH currently uses the SHA1 hash of the canonical SPKI encoding of the > public key. I believe that OpenSSH calculates the fingerprint as the > SHA1 hash of the keyblob. And then PGP uses yet another different > fingerprinting method. > > Some coordination would be desirable. Thanks to Niels for the above reply. In the absence of any other comments, I would like to reiterate that this issue seems crucial to me. I see no way to verify a public key fingerprint unless the client and the server both support the same fingerprinting method. Currently, this only seems to be the case when both the client and the server are from the same vendor. But if the assumption of this standard is that all clients will communicate with servers of the same vendor, why bother with standardization of the SSH protocol in the first place? Clearly, the assumption should be that clients from various vendors will communicate with servers from various other vendors. Since verifying the fingerprint of a server's public key is a key element of establishing a secure connection, I think a method should be recommended, or even mandated, by the SSH standard. So, my suggestion would be that someone [who has more experience with SSH than I do] drafts a paragraph to this effect and inserts it in a visible spot of the SSH specification. Perhaps such a recommendation could be added to the "SECSH Public Key File Format" document...? Regards, denis From owner-ietf-ssh@clinet.fi Mon Jan 29 19:57:43 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12996 for ; Mon, 29 Jan 2001 19:57:42 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA22287 for ietf-ssh-outgoing; Tue, 30 Jan 2001 01:26:36 +0200 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id BAA22273 for ; Tue, 30 Jan 2001 01:26:34 +0200 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA17230; Mon, 29 Jan 2001 15:26:15 -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 SAA19872; Mon, 29 Jan 2001 18:26:12 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id f0TNQB5151568; Mon, 29 Jan 2001 18:26:11 -0500 (EST) Message-Id: <200101292326.f0TNQB5151568@thunk.east.sun.com> From: Bill Sommerfeld To: Tatu Ylonen cc: Martin Forssen , nisse@lysator.liu.se, sommerfeld@orchard.arlington.ma.us, weidai@eskimo.com, ietf-ssh@clinet.fi Subject: Re: zlib partial flush In-reply-to: Your message of "Mon, 29 Jan 2001 22:13:49 +0200." Reply-to: sommerfeld@east.sun.com Date: Mon, 29 Jan 2001 18:26:10 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > I considered this when originally designing SSH2. However, the > compression level is basically a local policy issue of the sending side. > Also, I think I recall a little bit of experimenting and finding little > advantage (but much higher computational cost) in the higher compression > levels. for what it's worth, I've seen a similar analysis of time vs. space for gzip -1 through -9 (a long time ago, shortly after gzip was released). The compression level seems like something best left under the control of the sender; i don't think some folks will take too kindly to an option which allows clients tell their servers to burn N times more cpu on -9 level compression to squeeze out the last 0.1% of space.. - Bill From owner-ietf-ssh@clinet.fi Mon Jan 29 21:17:11 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13966 for ; Mon, 29 Jan 2001 21:17:10 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA26556 for ietf-ssh-outgoing; Tue, 30 Jan 2001 02:44:51 +0200 Received: from mail.robin.net ([63.229.68.34]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id CAA26552 for ; Tue, 30 Jan 2001 02:44:49 +0200 Received: from robin.net ([63.229.68.33]) by mail.robin.net (8.8.7/8.8.7) with ESMTP id RAA15562 for ; Mon, 29 Jan 2001 17:58:42 -0700 Message-ID: <3A760E3D.4926A856@robin.net> Date: Mon, 29 Jan 2001 17:43:41 -0700 From: Robin Walker X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ssh@clinet.fi Subject: Using SSH Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I've installed zlib, OpenSSL, and OpenSSH 2.3.0p1. The installation instructions were great and the man pages look like execellent reference material. However, I'm an uninitiated SSH enthusiast am unclear how to actually *use* it. I installed both these packages as root on two machines. Then I fired up sshd on the "server" and went to the other machine (client) to try it out (it seems like installing ssh client is a by-product of installing the server). Here's where I'm at: [root@client]# ssh -v -l root server SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. Compiled with SSL (0x0090600f). debug: Reading configuration data /usr/local/etc/ssh_config debug: Seeding random number generator debug: ssh_connect: getuid 0 geteuid 0 anon 0 debug: Connecting to server [ip address] port 22. debug: Seeding random number generator debug: Allocated local port 886. And then it just hangs. I also tried ssh'ing to localhost on the server, and I got this: [root@server]# ssh localhost root@localhost's password: (password entered) Permission denied, please try again. I'm using i386 RedHat 6.2. Does anyone have any words of advice? My main concern is that I don't understand the high level key generation and key comparison process and that I may have more installion or configuration steps that have been totally left out. Or that there is a configuration problem with somehow defining hosts that are allowed to connect. But basically I'm really unclear at this point. Thank you, -Robin From owner-ietf-ssh@clinet.fi Tue Jan 30 04:19:43 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02369 for ; Tue, 30 Jan 2001 04:19:42 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id JAA28860 for ietf-ssh-outgoing; Tue, 30 Jan 2001 09:44:04 +0200 Received: from nic.appgate.com (nic.appgate.com [193.12.107.226]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id JAA28845 for ; Tue, 30 Jan 2001 09:44:00 +0200 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id C46053BD18; Tue, 30 Jan 2001 08:43:59 +0100 (MET) Received: from pelee.firedoor.se (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 83A8B6C007; Tue, 30 Jan 2001 08:43:59 +0100 (CET) Received: from appgate.com (pelee.firedoor.se [172.23.2.10]) by pelee.firedoor.se (Postfix) with ESMTP id 2A1D6317AF; Tue, 30 Jan 2001 08:43:51 +0100 (MET) Date: Tue, 30 Jan 2001 08:44:06 +0100 (MET) From: Martin Forssen Subject: Re: zlib partial flush To: sommerfeld@east.sun.com Cc: ietf-ssh@clinet.fi In-Reply-To: <200101292326.f0TNQB5151568@thunk.east.sun.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20010130074351.2A1D6317AF@pelee.firedoor.se> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On 29 Jan, Bill Sommerfeld wrote: >> I considered this when originally designing SSH2. However, the >> compression level is basically a local policy issue of the sending >> side. Also, I think I recall a little bit of experimenting and >> finding little advantage (but much higher computational cost) in the >> higher compression levels. > > for what it's worth, I've seen a similar analysis of time vs. space > for gzip -1 through -9 (a long time ago, shortly after gzip was > released). Ok, I just did a litle experimenting myself and found that indeed the difference between -9 and -1 to gzip was indeed quite small (I had expected the difference to be much bigger). So it does not seem worth the hassle to define different compression levels. I therefore withdraw my proposal. /MaF From owner-ietf-ssh@clinet.fi Tue Jan 30 06:39:00 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03240 for ; Tue, 30 Jan 2001 06:38:59 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA31473 for ietf-ssh-outgoing; Tue, 30 Jan 2001 12:08:10 +0200 Received: from faui02.informatik.uni-erlangen.de (msfriedl@faui02.informatik.uni-erlangen.de [131.188.30.102]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id MAA31458 for ; Tue, 30 Jan 2001 12:08:09 +0200 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id LAA14603 for ietf-ssh@clinet.fi; Tue, 30 Jan 2001 11:08:07 +0100 (MET) Date: Tue, 30 Jan 2001 11:08:07 +0100 From: Markus Friedl To: ietf-ssh@clinet.fi Subject: Re: I-D ACTION:draft-ietf-secsh-filexfer-00.txt Message-ID: <20010130110807.A14374@faui02.informatik.uni-erlangen.de> References: <200101101146.GAA13351@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <200101101146.GAA13351@ietf.org>; from Internet-Drafts@ietf.org on Wed, Jan 10, 2001 at 06:46:16AM -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > 6.6. Creating and Deleting Directories > > New directories can be created using the SSH_FXP_MKDIR request. It has > the following format: > > uint32 id > string path the existing clients sftp-also send file attributes when creating a directory: ATTRS attrs does this behaviour changed with the draft? or is the draft just incomplete? i vote for including ATTRS (with SSH_FILEXFER_ATTR_PERMISSIONS) in SSH_FXP_MKDIR, this is also consistent with SSH_FXP_OPEN. -markus From owner-ietf-ssh@clinet.fi Tue Jan 30 20:44:15 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20126 for ; Tue, 30 Jan 2001 20:44:14 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA15501 for ietf-ssh-outgoing; Wed, 31 Jan 2001 02:10:14 +0200 Received: from mystery.acr.fi (ip212-226-160-97.adsl.kpnqwest.fi [212.226.160.97]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id CAA15496 for ; Wed, 31 Jan 2001 02:10:12 +0200 Received: from localhost (ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) with ESMTP id CAA07863; Wed, 31 Jan 2001 02:07:56 +0200 X-Authentication-Warning: mystery.acr.fi: ylo owned process doing -bs Date: Wed, 31 Jan 2001 02:07:56 +0200 (EET) From: Tatu Ylonen X-Sender: ylo@mystery.acr.fi To: Markus Friedl cc: ietf-ssh@clinet.fi Subject: Re: I-D ACTION:draft-ietf-secsh-filexfer-00.txt In-Reply-To: <20010130110807.A14374@faui02.informatik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk I think it is an error in the draft. I tried to make it upwards compatible with current SCP, and apparently forgot the ATTRS for MKDIR. It clearly makes sense to send the attributes also when creating a directory, since directories have permissions etc. Tatu On Tue, 30 Jan 2001, Markus Friedl wrote: > > > 6.6. Creating and Deleting Directories > > > > New directories can be created using the SSH_FXP_MKDIR request. It has > > the following format: > > > > uint32 id > > string path > > the existing clients sftp-also send file attributes when > creating a directory: > > ATTRS attrs > > does this behaviour changed with the draft? or is the draft > just incomplete? > > i vote for including ATTRS (with SSH_FILEXFER_ATTR_PERMISSIONS) > in SSH_FXP_MKDIR, this is also consistent with SSH_FXP_OPEN. > > -markus > From owner-ietf-ssh@clinet.fi Wed Jan 31 07:58:36 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11001 for ; Wed, 31 Jan 2001 07:58:35 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id NAA06599 for ietf-ssh-outgoing; Wed, 31 Jan 2001 13:24:28 +0200 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id NAA06437 for ; Wed, 31 Jan 2001 13:23:47 +0200 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id NAA07525; Wed, 31 Jan 2001 13:23:44 +0200 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14967.62912.409091.728266@asgard.tky.hut.fi> Date: Wed, 31 Jan 2001 13:23:44 +0200 To: Tatu Ylonen Cc: Mats Andersson , Damien Miller , Markus Friedl , "Jeff P. Van Dyke" , ietf-ssh@clinet.fi, openssh@openbsd.org Subject: Re: Are we going to add a magic cookie to sftp? In-Reply-To: References: X-Mailer: VM 6.87 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Been out of the loop for a few days (no net at my new apartment), sorry. Tatu Ylonen, on January 25. 2001, wrote: : > On Thu, 25 Jan 2001, Damien Miller wrote: : > > Why not skip the shell initialisation altogether for subsystems? : : The reason for shell initialization for subsystems was related to the sftp : umask issue. I have a slight preference for executing : subsystems directly (not reading users .cshrc, and not setting : user's default umask), whereas at least Sami Lehtinen preferred to have : subsystems run through the user's shell (which means umask can default to : user's umask). My preference for running it with the user's shell is because a) it has worked reasonably well b) sysadmin's use login shell's as a control mechanism c) with filexfer, the shell startup scripts are where a user sets their umasks (without this, the umask would have to be set in the daemon (system-wide setting)). : So we must basically decide on the subsystem execution method and the : user's default umask at the same time. Correct. Commenting on the "magic cookie" paragraph: as Neils correctly pointed out, the magic cookie would be the SSH_FXP_VERSION packet (or SSH_FXP_INIT, depending on which side does the filtering). So no special "SSH_FXP_MAGIC" packet would be added. The section in the draft-ietf-secsh-connect is just an implementation hint. -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Wed Jan 31 21:08:42 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00435 for ; Wed, 31 Jan 2001 21:08:42 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA09292 for ietf-ssh-outgoing; Thu, 1 Feb 2001 02:23:27 +0200 Received: from smtp1.clinet.fi (smtp1.clinet.fi [194.100.2.57]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id CAA09289 for ; Thu, 1 Feb 2001 02:23:26 +0200 Received: from kado.mindrot.org (CPE-203-45-24-18.vic.bigpond.net.au [203.45.24.18]) by smtp1.clinet.fi (Postfix) with ESMTP id C69BA1DF for ; Thu, 1 Feb 2001 02:23:25 +0200 (EET) Received: from toad.mindrot.org (toad.mindrot.org [203.44.118.252]) by kado.mindrot.org (Postfix) with ESMTP id 4D690906D for ; Thu, 1 Feb 2001 09:21:26 +1100 (EST) Received: from mothra.mindrot.org (mothra.mindrot.org [203.44.118.225]) by toad.mindrot.org (Postfix) with ESMTP id 8BAD41A1CB for ; Thu, 1 Feb 2001 11:23:23 +1100 (EST) Received: by mothra.mindrot.org (Postfix, from userid 500) id E80C03C08A; Thu, 1 Feb 2001 11:23:22 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by mothra.mindrot.org (Postfix) with ESMTP id E463A3C088 for ; Thu, 1 Feb 2001 11:23:22 +1100 (EST) Date: Thu, 1 Feb 2001 11:23:22 +1100 (EST) From: Damien Miller To: ietf-ssh@clinet.fi Subject: User and group information in sftp attributes 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: owner-ietf-ssh@clinet.fi Precedence: bulk Currently the filexfer draft encodes user and group info as ints. Would it make sense to send the textual user and group as strings as well? This would enable the receiver to maintain ownership where the same names are present, but the uids and gids differ, a situation which is pretty common. Something like: uint32 flags uint64 size present only if flag SSH_FILEXFER_ATTR_SIZE string owner present only if flag SSH_FILEXFER_ATTR_UIDGID string group present only if flag SSH_FILEXFER_ATTR_UIDGID uint32 uid present only if flag SSH_FILEXFER_ATTR_UIDGID uint32 gid present only if flag SSH_FILEXFER_ATTR_UIDGID ... -d -- | ``We've all heard that a million monkeys banging on | Damien Miller - | a million typewriters will eventually reproduce the | | works of Shakespeare. Now, thanks to the Internet, / | we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org From owner-ietf-ssh@clinet.fi Wed Jan 31 22:19:51 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02999 for ; Wed, 31 Jan 2001 22:19:50 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id DAA13394 for ietf-ssh-outgoing; Thu, 1 Feb 2001 03:45:41 +0200 Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id DAA13389 for ; Thu, 1 Feb 2001 03:45:39 +0200 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id RAA21894 for ; Wed, 31 Jan 2001 17:45:36 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id RAA08232 for ietf-ssh@clinet.fi; Wed, 31 Jan 2001 17:45:35 -0800 (PST) Date: Wed, 31 Jan 2001 17:45:35 -0800 From: Wei Dai To: ietf-ssh@clinet.fi Subject: zlib is not GNU Message-ID: <20010131174535.G1507@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-ietf-ssh@clinet.fi Precedence: bulk zlib is refered to as "GNU ZLIB (LZ77) compression" in the transport draft, but I don't think zlib (either the library for the compression format) has anything to do with GNU (either the organization or the license). I suggest the word "GNU" be taken out.