From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 1 15:20:24 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21243 for ; Thu, 1 Mar 2001 15:20:23 -0500 (EST) Received: (qmail 24642 invoked by uid 605); 1 Mar 2001 20:20:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24626 invoked from network); 1 Mar 2001 20:20:14 -0000 Received: from smtp2.cistron.nl (195.64.68.41) by mail.netbsd.org with SMTP; 1 Mar 2001 20:20:14 -0000 Received: from picard.cistron.nl ([195.64.65.20]) by smtp2.cistron.nl with esmtp (Exim 3.12 #1 (Debian)) id 14YZYa-0001K2-00 for ; Thu, 01 Mar 2001 21:20:12 +0100 Received: (from jhm@localhost) by picard.cistron.nl (8.9.3/8.9.3/Debian 8.9.3-6) id VAA27938 for ietf-ssh@netbsd.org; Thu, 1 Mar 2001 21:20:11 +0100 Date: Thu, 1 Mar 2001 21:20:10 +0100 From: "J.H.M. Dassen \(Ray\)" To: ietf-ssh@netbsd.org Subject: Re: (off topic) list archive technology? Message-ID: <20010301212010.A27027@cistron.nl> References: <200103010010.f210AAj04165@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: <200103010010.f210AAj04165@thunk.east.sun.com>; from sommerfeld@east.sun.com on Wed, Feb 28, 2001 at 07:10:10PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Feb 28, 2001 at 19:10:10 -0500, Bill Sommerfeld wrote: > I got a comment from an implementor that public access to the list > archives could be improved. > > Any suggestions for which package to use? The Debian project has been using MHonArc (http://www.mhonarc.org/) for several years now for its archives (http://lists.debian.org); it has proven to be quite scalable and reliable. HTH, Ray -- LEADERSHIP A form of self-preservation exhibited by people with auto- destructive imaginations in order to ensure that when it comes to the crunch it'll be someone else's bones which go crack and not their own. - The Hipcrime Vocab by Chad C. Mulligan From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 5 06:46:32 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11328 for ; Mon, 5 Mar 2001 06:46:31 -0500 (EST) Received: (qmail 19305 invoked by uid 605); 5 Mar 2001 11:46:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19298 invoked from network); 5 Mar 2001 11:46:19 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 5 Mar 2001 11:46:19 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11237; Mon, 5 Mar 2001 06:46:01 -0500 (EST) Message-Id: <200103051146.GAA11237@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-auth-kbdinteract-01.txt Date: Mon, 05 Mar 2001 06:46:01 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : Generic Message Exchange Authentication For SSH Author(s) : M. Forssen, F. Cusack Filename : draft-ietf-secsh-auth-kbdinteract-01.txt Pages : 8 Date : 02-Mar-01 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard. The major goal of this method is to allow the SSH client to have little or no knowledge of the underlying authentication mechanism(s) used by the SSH server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-auth-kbdinteract-01.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-auth-kbdinteract-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-auth-kbdinteract-01.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: <20010302132304.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-auth-kbdinteract-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-auth-kbdinteract-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010302132304.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 5 07:11:47 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12043 for ; Mon, 5 Mar 2001 07:11:46 -0500 (EST) Received: (qmail 21385 invoked by uid 605); 5 Mar 2001 12:11:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21376 invoked from network); 5 Mar 2001 12:11:38 -0000 Received: from nic.appgate.com (193.12.107.226) by mail.netbsd.org with SMTP; 5 Mar 2001 12:11:38 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id 9ABE23BD0D; Mon, 5 Mar 2001 13:11:36 +0100 (MET) Received: from pelee.firedoor.se (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 9F4FE6C007; Mon, 5 Mar 2001 13:13:59 +0100 (CET) Received: from appgate.com (pelee.firedoor.se [172.23.2.10]) by pelee.firedoor.se (Postfix) with ESMTP id C8EB13176C; Mon, 5 Mar 2001 13:11:23 +0100 (MET) Date: Mon, 5 Mar 2001 13:11:43 +0100 (MET) From: Martin Forssen Subject: Re: I-D ACTION:draft-ietf-secsh-auth-kbdinteract-01.txt To: Internet-Drafts@ietf.org Cc: ietf-ssh@netbsd.org In-Reply-To: <200103051146.GAA11237@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20010305121123.C8EB13176C@pelee.firedoor.se> Sender: ietf-ssh-owner@netbsd.org Precedence: list On 5 Mar, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Secure Shell Working > Group of the IETF. > > Title : Generic Message Exchange Authentication For SSH > Author(s) : M. Forssen, F. Cusack > Filename : draft-ietf-secsh-auth-kbdinteract-01.txt > Pages : 8 > Date : 02-Mar-01 > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-secsh-auth-kbdinteract-01.txt This annuncement is only partly right. It version 02 which I recently submitted not 01. The given link also points to the 01-version of the draft rather than the 02. The new version of the draft I submitted can be found at the following URL: http://www.ietf.org/internet-drafts/draft-ietf-secsh-auth-kbdinteract-02.txt There has been no changes to the actual protocol defined by the draft. Instead I have tried to clarified the language in several places and added a coupld of small requirements (like that the server may only have one oustanding request). /MaF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 6 06:51:59 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08051 for ; Tue, 6 Mar 2001 06:51:59 -0500 (EST) Received: (qmail 29219 invoked by uid 605); 6 Mar 2001 11:51:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29212 invoked from network); 6 Mar 2001 11:51:40 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 6 Mar 2001 11:51:40 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07985; Tue, 6 Mar 2001 06:51:38 -0500 (EST) Message-Id: <200103061151.GAA07985@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-userauth-10.txt Date: Tue, 06 Mar 2001 06:51:38 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Authentication Protocol Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-userauth-10.txt Pages : 11 Date : 05-Mar-01 The Secure Shell Remote Login Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the Secure Shell authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The Secure Shell Authentication Protocol runs on top of the Secure Shell Transport Layer Protocol and provides a single authenticated tunnel for the Secure Shell Connection Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-10.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-userauth-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-userauth-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010305132217.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-userauth-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-userauth-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010305132217.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 6 06:52:12 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08098 for ; Tue, 6 Mar 2001 06:52:11 -0500 (EST) Received: (qmail 29479 invoked by uid 605); 6 Mar 2001 11:51:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29416 invoked from network); 6 Mar 2001 11:51:46 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 6 Mar 2001 11:51:46 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07972; Tue, 6 Mar 2001 06:51:34 -0500 (EST) Message-Id: <200103061151.GAA07972@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-publickeyfile-01.txt Date: Tue, 06 Mar 2001 06:51:34 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SECSH Public Key File Format Author(s) : J. Galbraith, R. Thayer Filename : draft-ietf-secsh-publickeyfile-01.txt Pages : 4 Date : 05-Mar-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-01.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-01.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-01.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: <20010305132208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-publickeyfile-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-publickeyfile-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010305132208.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 6 06:52:27 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08155 for ; Tue, 6 Mar 2001 06:52:27 -0500 (EST) Received: (qmail 29476 invoked by uid 605); 6 Mar 2001 11:51:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29322 invoked from network); 6 Mar 2001 11:51:44 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 6 Mar 2001 11:51:44 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08007; Tue, 6 Mar 2001 06:51:42 -0500 (EST) Message-Id: <200103061151.GAA08007@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-connect-10.txt Date: Tue, 06 Mar 2001 06:51:42 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Connection Protocol Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-connect-10.txt Pages : 17 Date : 05-Mar-01 The Secure Shell Remote Login Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the Secure Shell Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel. The Secure Shell Con- nection Protocol has been designed to run on top of the Secure Shell transport layer and user authentication protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-10.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-connect-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-connect-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010305132226.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-connect-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-connect-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010305132226.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 6 06:52:51 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08216 for ; Tue, 6 Mar 2001 06:52:50 -0500 (EST) Received: (qmail 29534 invoked by uid 605); 6 Mar 2001 11:51:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29436 invoked from network); 6 Mar 2001 11:51:48 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 6 Mar 2001 11:51:48 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08020; Tue, 6 Mar 2001 06:51:47 -0500 (EST) Message-Id: <200103061151.GAA08020@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-filexfer-01.txt Date: Tue, 06 Mar 2001 06:51:46 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH File Transfer Protocol Author(s) : T. Ylonen, S. Lehtinen Filename : draft-ietf-secsh-filexfer-01.txt Pages : 19 Date : 05-Mar-01 The Secure Shell File Transfer Protocol provides secure file transfer functionality over any reliable data stream. It is the standard file transfer protocol for use with the Secure Shell Remote Login Protocol. This document describes the file transfer protocol and its interface to the Secure Shell protocol suite. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-01.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-01.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-01.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: <20010305132236.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-filexfer-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-filexfer-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010305132236.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 6 06:53:17 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08228 for ; Tue, 6 Mar 2001 06:53:16 -0500 (EST) Received: (qmail 29687 invoked by uid 605); 6 Mar 2001 11:51:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29510 invoked from network); 6 Mar 2001 11:51:52 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 6 Mar 2001 11:51:52 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08032; Tue, 6 Mar 2001 06:51:51 -0500 (EST) Message-Id: <200103061151.GAA08032@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-architecture-08.txt Date: Tue, 06 Mar 2001 06:51:51 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Protocol Architecture Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-architecture-08.txt Pages : 12 Date : 05-Mar-01 The Secure Shell Remote Login Protocol is a suite of protocols for secure remote logins and other secure network services over an insecure network. This document describes the overall architecture of the Secure Shell protocols, as well as the notation and terminology used in the protocol documents. It also discusses the algorithm naming system that allows local extensions. The Secure Shell protocol consists of three major components: The Transport Layer Protocol provides server authenti- cation, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logi- cal channels. Details of these protocols are described in separate doc- uments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-08.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-architecture-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-architecture-08.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: <20010305132246.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-architecture-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-architecture-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010305132246.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 6 06:53:40 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08254 for ; Tue, 6 Mar 2001 06:53:40 -0500 (EST) Received: (qmail 29769 invoked by uid 605); 6 Mar 2001 11:52:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29629 invoked from network); 6 Mar 2001 11:51:56 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 6 Mar 2001 11:51:56 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08044; Tue, 6 Mar 2001 06:51:55 -0500 (EST) Message-Id: <200103061151.GAA08044@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-transport-10.txt Date: Tue, 06 Mar 2001 06:51:55 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Transport Layer Protocol Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-transport-10.txt Pages : 23 Date : 05-Mar-01 The Secure Shell Remote Login Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the Secure Shell transport layer protocol which typi- cally runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compres- sion. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the Secure Shell transport layer protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-10.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-transport-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-transport-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010305132303.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-transport-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-transport-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010305132303.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ssh@clinet.fi Tue Mar 6 08:53: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 IAA11751 for ; Tue, 6 Mar 2001 08:53:54 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id NAA27572 for ietf-ssh-outgoing; Tue, 6 Mar 2001 13:42:55 +0200 Received: from www.direct.caravan.ru (direct.caravan.ru [217.23.142.42]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id NAA27537 for ; Tue, 6 Mar 2001 13:42:48 +0200 Received: from direct by www.direct.caravan.ru with local (Exim 3.14 #1) id 14aFrU-000JDk-00 for ietf-ssh@clinet.fi; Tue, 06 Mar 2001 14:42:40 +0300 From: MIME-Version: 1.0 Subject: SasLib.ru Content-Type: text/plain; charset=koi8-r Message-Id: To: ietf-ssh@clinet.fi Date: Tue, 06 Mar 2001 14:42:40 +0300 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to base64 by mail.clinet.fi id NAA27572 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id IAA11751 Если эта информация Вам не интересна √ приносим свои извинения. Представляем крупнейший центр в runet. Задуманные массштабы пока не до конца реализованны. На февраль 2001 обогнали всех в своей области. Гордимся. Не хватает новых мнений для оценки направлений развития, а так все есть. Адрес на сложный √ www.saslib.ru. ================================================================================ Esli dannaya informatsiya Vam ne interesna √ prinosim svoi izvineniya. Predstavlyaem krupneishiy centr v runet. Zadumannie masshtabi poka ne do kontsa realizovanni. Na fevral 2001 obognali vseh v svoey oblasty. Gordimsya. Ne hvataet novih mneniy dlya otsenki napravleniy razvitiya, a tak vse est. Adres prostoy - www.saslib.ru. Vsem uspehov! Gruppa sozdateley Всем успехов! Группа создателей. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 6 12:41:39 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19106 for ; Tue, 6 Mar 2001 12:41:38 -0500 (EST) Received: (qmail 21895 invoked by uid 605); 6 Mar 2001 17:41:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21888 invoked from network); 6 Mar 2001 17:41:19 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 6 Mar 2001 17:41:19 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05610; Tue, 6 Mar 2001 09:41:17 -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 MAA13438; Tue, 6 Mar 2001 12:41:16 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f26HfB902617; Tue, 6 Mar 2001 12:41:11 -0500 (EST) Message-Id: <200103061741.f26HfB902617@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Cc: jis@mit.edu Subject: SSH-> Secure Shell renaming is *not* official. Reply-to: sommerfeld@east.sun.com Date: Tue, 06 Mar 2001 12:41:11 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list You may have seen the announcements for the recently posted set of drafts: draft-ietf-secsh-userauth-10.txt draft-ietf-secsh-connect-10.txt draft-ietf-secsh-architecture-08.txt draft-ietf-secsh-transport-10.txt These drafts contain a change in document title (replacing "SSH" with "Secure Shell" and/or "Secure Shell Remote Login Protocol"). I was not notified or consulted in advance of these title changes and they appear to have been made unilaterally by the document author(s) and are not the result of working group consensus. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 6 17:07:56 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00368 for ; Tue, 6 Mar 2001 17:07:55 -0500 (EST) Received: (qmail 8591 invoked by uid 605); 6 Mar 2001 22:07:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8584 invoked from network); 6 Mar 2001 22:07:46 -0000 Received: from ip212-226-160-97.adsl.kpnqwest.fi (HELO mystery.acr.fi) (212.226.160.97) by mail.netbsd.org with SMTP; 6 Mar 2001 22:07:46 -0000 Received: (from ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) id AAA01720; Wed, 7 Mar 2001 00:01:16 +0200 Date: Wed, 7 Mar 2001 00:01:16 +0200 Message-Id: <200103062201.AAA01720@mystery.acr.fi> X-Authentication-Warning: mystery.acr.fi: ylo set sender to ylo@mystery.acr.fi using -f From: Tatu Ylonen To: Bill Sommerfeld CC: ietf-ssh@netbsd.org, jis@mit.edu, mleech@nortelnetworks.com Subject: Re: SSH-> Secure Shell renaming is *not* official. Organization: SSH Communications Security, Finland Sender: ietf-ssh-owner@netbsd.org Precedence: list > These drafts contain a change in document title (replacing "SSH" with > "Secure Shell" and/or "Secure Shell Remote Login Protocol"). > > I was not notified or consulted in advance of these title changes and > they appear to have been made unilaterally by the document author(s) > and are not the result of working group consensus. I went ahead and made the editorial changes unilaterally in view of the recent discussions regarding our trademark claims, particularly since the IETF declared the trademark debate "out of scope" of the working group. I was trying to clarify the working drafts and avoid further problems, because people have been saying that the trademark section in the previous drafts was not acceptable. There were no changes to the bits on the wire (except in the file transfer protocol, and those are unrelated to the trademark issue). Here is a summary of the changes in the drafts: - clarification in X11 forwarding ("e.g. MIT-MAGIC-COOKIE-1") - changed GNU ZLIB -> ZLIB - several changes in file transfer protocol, as requested by the working group - cleaned up use of terms "SSH" and "Secure Shell" to conform to the trademark usage guidelines and SSH's policy statement (we are contributing the "Secure Shell" name to the public domain so that it can be used to identify the Secure Shell protocol and any Secure Shell implementation, but "ssh" is our brand name and trademark, and it can only be used under a license from us and such use must conform to our trademark guidelines; see www.ssh.com for more information). This change avoids the trademark issue for the working group entirely. - changed the "Trademark issues" paragraph to be just a trademark notice (noting the fact that "ssh" is a registered trademark); a separate notice will be posted on the IETF Intellectual Property Rights Notices page. Let's discuss this further in the working group meeting in Minneapolis. Note also that we have decided to abandon our trademark application for the name "Secure Shell" and dedicate it to public use. We understand that the phrase Secure Shell is well known withing the community to describe the secure remote login protocol that I originally developed. Tatu -- SSH Communications Security http://www.ssh.com/ SSH IPSEC Toolkit http://www.ipsec.com/ SSH Secure Shell http://www.ssh.com/ssh From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 6 17:46:26 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01453 for ; Tue, 6 Mar 2001 17:46:25 -0500 (EST) Received: (qmail 16664 invoked by uid 605); 6 Mar 2001 22:46:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16657 invoked from network); 6 Mar 2001 22:46:15 -0000 Received: from shiner-bock.cs.stevens-tech.edu (155.246.89.200) by mail.netbsd.org with SMTP; 6 Mar 2001 22:46:15 -0000 Received: (from tls@localhost) by maximator.cs.stevens-tech.edu (8.11.0/8.10.1) id f26MQ5P09201; Tue, 6 Mar 2001 17:26:05 -0500 (EST) Date: Tue, 6 Mar 2001 17:26:05 -0500 From: Thor Simon To: Tatu Ylonen Cc: ietf-ssh@netbsd.org, jis@mit.edu, mleech@nortelnetworks.com, tls@rek.tjls.com Subject: Re: SSH-> Secure Shell renaming is *not* official. Message-ID: <20010306172605.A9141@cs.stevens-tech.edu> References: <200103062201.AAA01720@mystery.acr.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103062201.AAA01720@mystery.acr.fi>; from ylo@ssh.com on Wed, Mar 07, 2001 at 12:01:16AM +0200 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Mar 07, 2001 at 12:01:16AM +0200, Tatu Ylonen wrote: > > These drafts contain a change in document title (replacing "SSH" with > > "Secure Shell" and/or "Secure Shell Remote Login Protocol"). > > > > I was not notified or consulted in advance of these title changes and > > they appear to have been made unilaterally by the document author(s) > > and are not the result of working group consensus. > > I went ahead and made the editorial changes unilaterally in view of But you are not the working group chair, and nobody asked about consensus on the working group mailing list, and it certainly appears to me that there is, in fact, no consensus that that change should be made. In other words, as you have repeatedly done throughout this present unpleasantness, you once again publically misrepresented your authority, your actions, and the views and actions of others. > - cleaned up use of terms "SSH" and "Secure Shell" to conform to the > trademark usage guidelines and SSH's policy statement (we are > contributing the "Secure Shell" name to the public domain so that > it can be used to identify the Secure Shell protocol and any > Secure Shell implementation, but "ssh" is our brand name and > trademark, and it can only be used under a license from us and > such use must conform to our trademark guidelines; see www.ssh.com > for more information). This change avoids the trademark issue > for the working group entirely. There is no consensus whatsoever in the working group that the protocol or drafts should be renamed, as you well know since you are on the same mailing list the rest of the WG members are on; certainly you know full well that the subject of consensus on this issue wasn't even discussed, much less decided upon. Once more, you publically misrepresent the nature and extent of your trademark claims to "ssh". The plain fact is that you do _not_ have a trademark on "ssh"; you have a trademark on one particular graphical representation of the letters "ssh", and you did not even seek a trademark on the plain-text word "ssh", whether upper or lower-case, as your own attorney confirmed in his response to the first correspondence from the trademark examiner in your U.S. trademark file (I will be happy to provide copies of this file to anyone who wants it). Since you do not have an actual trademark on "ssh" as plain text, and your trademark on "ssh" rendered in a particular way is irrelevant to the work of the working group, the name of the protocol, or the names of the drafts, I see no reason (and I suspect that few others do) that we should rename anything at this time. If you _did_ own such a mark, more working group members might be in favor of renaming the protocol as a means of sidestepping your unethical behaviour but as it stands, I doubt that we will reach consensus on rewarding your failed attempt at blackmail! > - changed the "Trademark issues" paragraph to be just a trademark > notice (noting the fact that "ssh" is a registered trademark); a > separate notice will be posted on the IETF Intellectual Property > Rights Notices page. A "trademark notice" is not appropriate in the documents either; see RFC 2026. Furthermore, at this point you know full well that your rights in this area are not what you would like to be able to publically represent them to be; I find it the very epitome of highanded arrogance that you have represented that you were authorized to submit new drafts of the working-group's documents without consensus, when that's plainly false, so that you could use those new drafts to have the IETF further your own agenda of publically misrepresenting the extent of your trademark rights. > Let's discuss this further in the working group meeting in Minneapolis. > > Note also that we have decided to abandon our trademark application > for the name "Secure Shell" and dedicate it to public use. We > understand that the phrase Secure Shell is well known withing the > community to describe the secure remote login protocol that I > originally developed. How nice. I suspect that at this point you are aware that I instructed my counsel several weeks ago to oppose the issuance of that mark on the grounds that the name in question is generic; I mention this only lest anyone think that you had "decided" to do anything altruistic rather than merely cynically attempt to create the appearance that you had done so. Thor From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 6 18:05:57 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02174 for ; Tue, 6 Mar 2001 18:05:56 -0500 (EST) Received: (qmail 23945 invoked by uid 605); 6 Mar 2001 23:05:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23839 invoked from network); 6 Mar 2001 23:05:34 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 6 Mar 2001 23:05:34 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA23202; Tue, 6 Mar 2001 15:05:28 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA19912; Tue, 6 Mar 2001 18:05:17 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f26N5B903411; Tue, 6 Mar 2001 18:05:12 -0500 (EST) Message-Id: <200103062305.f26N5B903411@thunk.east.sun.com> From: Bill Sommerfeld To: Tatu Ylonen cc: Bill Sommerfeld , ietf-ssh@netbsd.org, jis@mit.edu, mleech@nortelnetworks.com Subject: Re: SSH -> Secure Shell renaming is *not* official. In-reply-to: Your message of "Wed, 07 Mar 2001 00:01:16 +0200." <200103062201.AAA01720@mystery.acr.fi> Reply-to: sommerfeld@east.sun.com Date: Tue, 06 Mar 2001 18:05:11 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list It is *NOT* your prerogative to unilaterally rename the IETF protocol from SSH to "Secure Shell". > I went ahead and made the editorial changes unilaterally You appear to have missed my previous statement: I am reluctant to initiate renaming unless I see SMOOTH CONSENSUS. Based on the feedback I've been getting in private mail, we have nothing vaguely resembling consensus. > in view of the recent discussions regarding our trademark claims, > particularly since the IETF declared the trademark debate "out of > scope" of the working group. Discussions of the validity (or not) of the trademark are out of scope. (It's fair to say that different lawyers have different opinions at the moment). HOWEVER, discussions of whether or not the protocol needs to be renamed are most certainly in scope. If we resolve that issue in favor of renaming, it is up to the WORKING GROUP to pick the new name, since it is the WORKING GROUP which has change control over the protocol. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 6 18:07:50 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02223 for ; Tue, 6 Mar 2001 18:07:50 -0500 (EST) Received: (qmail 24883 invoked by uid 605); 6 Mar 2001 23:07:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24876 invoked from network); 6 Mar 2001 23:07:43 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 6 Mar 2001 23:07:43 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA24315 for ; Tue, 6 Mar 2001 15:07:42 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA20172 for ; Tue, 6 Mar 2001 18:07:41 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f26N7Z903430 for ; Tue, 6 Mar 2001 18:07:35 -0500 (EST) Message-Id: <200103062307.f26N7Z903430@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: do we need to rename? Reply-to: sommerfeld@east.sun.com Date: Tue, 06 Mar 2001 18:07:35 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list I'd like to open discussion on the following question: - Is it necessary to rename the SSH protocol? As I stated before: It's fair to say that there are no shortage of possible alternate names. Let's not waste time enumerating them until we agree that renaming is inevitable. Until we have consensus on the question of renaming, discussion of possible alternate names for the WG and its protocols are OUT OF SCOPE. Here's a quick, and necessarily incomplete, list of pros/cons of renaming, in no particular order: - extracts the IETF from the trademark dispute, letting us get underway with standardization again. - we may be able to proceed more quickly once we have picked a new name. - there are a fair number of folks who are unhappy with the apparent unix-centric nature of the "Secure Shell" name. - renaming may be interpreted (incorrectly) as a statement by the IETF that the trademark is valid, which may have bearing on the trademark dispute itself. - renaming will introduce confusion in the marketplace and for end users. - renaming will not eliminate the need to use the "SSH" word in documentation -- implementors will still have a need to cite that they implement the protocol-formerly-known-as-SSH for the forseeable future. - historic evidence indicates that the IETF is not particulary successful at renaming deployed protocols; for instance, see S/Key -> OTP and SSL -> TLS, neither of which really seems to have "stuck". - renaming may not actually prevent dilution of the trademark, since folks will still know the protocol as SSH and will likely still use the old name generically out of habit even if we rename the protocol. Send comments to the list or to me directly. - Bill From sommerfeld@netbsd.org Tue Mar 6 20:06:30 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05684 for ; Tue, 6 Mar 2001 20:06:29 -0500 (EST) From: sommerfeld@netbsd.org Received: (qmail 24254 invoked by uid 1099); 7 Mar 2001 01:06:28 -0000 Date: 7 Mar 2001 01:06:28 -0000 Message-ID: <20010307010628.24253.qmail@mail.netbsd.org> To: secsh-archive@ietf.org Subject: mail test.. testing mail archive.. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 7 07:47:05 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01618 for ; Wed, 7 Mar 2001 07:47:05 -0500 (EST) Received: (qmail 23977 invoked by uid 605); 7 Mar 2001 12:46:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23970 invoked from network); 7 Mar 2001 12:46:52 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 7 Mar 2001 12:46:52 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01583; Wed, 7 Mar 2001 07:46:46 -0500 (EST) Message-Id: <200103071246.HAA01583@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-gsskeyex-01.txt Date: Wed, 07 Mar 2001 07:46:46 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : Using GSSAPI authentication for key exchange in Secure Shell Author(s) : J. Hutzelman, J. Salowey Filename : draft-ietf-secsh-gsskeyex-01.txt Pages : 16 Date : 06-Mar-01 This memo describes a method for using the Generic Security Service Application Program Interface [2] for key exchange in the Secure Shell protocol, by defining a class of SSH key exchange methods which use GSSAPI to authenticate the Diffie-Hellman exchange described in [10]. This memo also defines a new host public key algorithm which can be used when no operations are needed using a host's public key, and a new user authentication method which allows an authorization name to be used in conjunction with any authentication which has already occurred as a side-effect of key exchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-gsskeyex-01.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-gsskeyex-01.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-gsskeyex-01.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: <20010306125937.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-gsskeyex-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-gsskeyex-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010306125937.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 7 08:19:17 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02839 for ; Wed, 7 Mar 2001 08:19:17 -0500 (EST) Received: (qmail 29085 invoked by uid 605); 7 Mar 2001 13:19:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29078 invoked from network); 7 Mar 2001 13:19:09 -0000 Received: from lox.sandelman.ottawa.on.ca (root@209.151.24.2) by mail.netbsd.org with SMTP; 7 Mar 2001 13:19:09 -0000 Received: from marajade.sandelman.ottawa.on.ca (root@localhost [127.0.0.1]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id IAA09960 for ; Wed, 7 Mar 2001 08:19:07 -0500 (EST) 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 f271sTa05168 for ; Tue, 6 Mar 2001 20:54:34 -0500 (EST) Message-Id: <200103070154.f271sTa05168@marajade.sandelman.ottawa.on.ca> To: ietf-ssh@netbsd.org Subject: Re: SSH-> Secure Shell renaming is *not* official. In-reply-to: Your message of "Wed, 07 Mar 2001 00:01:16 +0200." <200103062201.AAA01720@mystery.acr.fi> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 06 Mar 2001 20:54:29 -0500 From: Michael Richardson Sender: ietf-ssh-owner@netbsd.org Precedence: list >>>>> "Tatu" == Tatu Ylonen writes: Tatu> - cleaned up use of terms "SSH" and "Secure Shell" to conform to the Tatu> trademark usage guidelines and SSH's policy statement (we are Tatu> contributing the "Secure Shell" name to the public domain so that Tatu> it can be used to identify the Secure Shell protocol and any So, we should be changing: % grep 22 /etc/services ssh 22/tcp # Secure Shell to: secsh 22/tcp # Secure Shell From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 7 08:55:00 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04244 for ; Wed, 7 Mar 2001 08:54:59 -0500 (EST) Received: (qmail 6384 invoked by uid 605); 7 Mar 2001 13:54:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6377 invoked from network); 7 Mar 2001 13:54:51 -0000 Received: from hutcs.cs.hut.fi (kivinen@130.233.192.7) by mail.netbsd.org with SMTP; 7 Mar 2001 13:54:51 -0000 Received: (from kivinen@localhost) by hutcs.cs.hut.fi (8.9.3/8.9.3) id PAA18537; Wed, 7 Mar 2001 15:54:38 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 7 Mar 2001 15:54:38 +0200 (EET) From: Tero Kivinen To: Michael Richardson Cc: ietf-ssh@netbsd.org Subject: Re: SSH-> Secure Shell renaming is *not* official. In-Reply-To: <200103070154.f271sTa05168@marajade.sandelman.ottawa.on.ca> References: <200103062201.AAA01720@mystery.acr.fi> <200103070154.f271sTa05168@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <15014.15076.443097.779877@hutcs.cs.hut.fi> Organization: Helsinki University of Technology X-Edit-Time: 5 min X-Total-Time: 11 min Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Michael Richardson writes: > So, we should be changing: > % grep 22 /etc/services > ssh 22/tcp # Secure Shell > to: > secsh 22/tcp # Secure Shell I think secure-shell 22/tcp # Secure Shell would be more correct, if we decide to change the protocol name to Secure Shell. If we decide to change it to something else then we change the port number name to something else. I don't really think this change is going to affect anybody. I think all implementations of the protocol use hard coded port 22 (or the port number is given in the config file), they do not normally use getservbyname, so no matter what we put to the /etc/services the programs still work. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 7 10:51:40 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08385 for ; Wed, 7 Mar 2001 10:51:39 -0500 (EST) Received: (qmail 27976 invoked by uid 605); 7 Mar 2001 15:51:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27969 invoked from network); 7 Mar 2001 15:51:31 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 7 Mar 2001 15:51:31 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 4B16682F528; Wed, 7 Mar 2001 16:51:29 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id QAA29132; Wed, 7 Mar 2001 16:51:26 +0100 (MET) To: Tero Kivinen Cc: Michael Richardson , ietf-ssh@netbsd.org Subject: Re: SSH-> Secure Shell renaming is *not* official. References: <200103062201.AAA01720@mystery.acr.fi> <200103070154.f271sTa05168@marajade.sandelman.ottawa.on.ca> <15014.15076.443097.779877@hutcs.cs.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 07 Mar 2001 16:51:26 +0100 In-Reply-To: Tero Kivinen's message of "Wed, 7 Mar 2001 15:54:38 +0200 (EET)" Message-ID: Lines: 11 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Tero Kivinen writes: > I think all implementations of the protocol use hard coded port 22 > (or the port number is given in the config file), they do not > normally use getservbyname, so no matter what we put to the > /etc/services the programs still work. For the record, my implementation uses getservbyname and falls back to 22 if the name "ssh" isn't found. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 7 11:11:22 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09108 for ; Wed, 7 Mar 2001 11:11:22 -0500 (EST) Received: (qmail 3865 invoked by uid 605); 7 Mar 2001 16:11:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3848 invoked from network); 7 Mar 2001 16:11:00 -0000 Received: from zcars04e.nortelnetworks.com (47.129.242.56) by mail.netbsd.org with SMTP; 7 Mar 2001 16:11:00 -0000 Received: from rftzy232.ca.nortel.com by zcars04e.nortelnetworks.com; Wed, 7 Mar 2001 10:01:37 -0500 Received: from NORTELNETWORKS.COM (wftzh00e.ca.nortel.com [47.130.116.9]) by rftzy232.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id FXAYD8J2; Wed, 7 Mar 2001 09:55:19 -0500 Message-ID: <3AA64C7D.9FC58967@NORTELNETWORKS.COM> Date: Wed, 07 Mar 2001 09:58:05 -0500 From: "Marcus Leech" X-Mailer: Mozilla 4.73C-CCK-MCD [en] (X11; U; HP-UX B.10.20 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: Tatu Ylonen CC: Bill Sommerfeld , ietf-ssh@netbsd.org, jis@mit.edu, "Marcus Leech" Subject: Re: SSH-> Secure Shell renaming is *not* official. References: <200103062201.AAA01720@mystery.acr.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Tatu Ylonen wrote: > > > These drafts contain a change in document title (replacing "SSH" with > > "Secure Shell" and/or "Secure Shell Remote Login Protocol"). > > > > I was not notified or consulted in advance of these title changes and > > they appear to have been made unilaterally by the document author(s) > > and are not the result of working group consensus. > > I went ahead and made the editorial changes unilaterally in view of > the recent discussions regarding our trademark claims, particularly > since the IETF declared the trademark debate "out of scope" of the > working group. I was trying to clarify the working drafts and avoid > further problems, because people have been saying that the trademark > section in the previous drafts was not acceptable. > Tatu, it is inappropriate for you to act on any of this without the consensus of the working group. Bill Sommerfeld was entirely justified in objecting to this action. -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M70, MS 012, FITZ Advisor Phone: (ESN) 393-9145 +1 613 763 9145 Security Architecture and Planning Fax: (ESN) 393-9435 +1 613 763 9435 Nortel Networks mleech@nortelnetworks.com -----------------Expressed opinions are my own, not my employer's------ From owner-ietf-ssh@clinet.fi Wed Mar 7 14:33: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 OAA19175 for ; Wed, 7 Mar 2001 14:33:53 -0500 (EST) From: owner-ietf-ssh@clinet.fi Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA21874 for ietf-ssh-outgoing; Wed, 7 Mar 2001 19:12:04 +0200 Received: from mail.autoclick.co.kr ([211.36.83.119]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA21871 for ; Wed, 7 Mar 2001 19:12:02 +0200 Received: from 64.228.109.58 [64.228.109.58] by mail.autoclick.co.kr (SMTPD32-6.00) id A6E95002A2; Sun, 25 Feb 2001 09:50:49 +0900 To: Subject: good morning 17287 Date: Sat, 24 Feb 2001 19:26:47 -0800 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Message-Id: <200102250950807.SM00136@64.228.109.58> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: quoted-printable

To enter this celebs site, please CLICK HERE.

Please click here to be REMOVED<= /a> from our mailing list.
From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 8 02:23:32 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19493 for ; Thu, 8 Mar 2001 02:23:31 -0500 (EST) Received: (qmail 12790 invoked by uid 605); 8 Mar 2001 07:23:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12783 invoked from network); 8 Mar 2001 07:23:23 -0000 Received: from yeah-baby.shagadelic.org (HELO dr-evil.shagadelic.org) (208.176.2.162) by mail.netbsd.org with SMTP; 8 Mar 2001 07:23:23 -0000 Received: by dr-evil.shagadelic.org (Postfix, from userid 7518) id 1D92B18B66; Wed, 7 Mar 2001 23:22:53 -0800 (PST) Date: Wed, 7 Mar 2001 23:22:52 -0800 From: Jason R Thorpe To: Bill Sommerfeld Cc: ietf-ssh@netbsd.org Subject: Re: do we need to rename? Message-ID: <20010307232252.U17734@dr-evil.shagadelic.org> Reply-To: thorpej@zembu.com Mail-Followup-To: Jason R Thorpe , Bill Sommerfeld , ietf-ssh@netbsd.org References: <200103062307.f26N7Z903430@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: <200103062307.f26N7Z903430@thunk.east.sun.com>; from sommerfeld@east.sun.com on Tue, Mar 06, 2001 at 06:07:35PM -0500 Organization: Zembu Labs, Inc. Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Mar 06, 2001 at 06:07:35PM -0500, Bill Sommerfeld wrote: > - renaming may be interpreted (incorrectly) as a statement by the > IETF that the trademark is valid, which may have bearing on the > trademark dispute itself. It seems to me that this reason, just on its own, is enough justification for NOT renaming. -- -- Jason R. Thorpe From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 8 08:59:03 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26570 for ; Thu, 8 Mar 2001 08:59:03 -0500 (EST) Received: (qmail 10886 invoked by uid 605); 8 Mar 2001 13:58:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10877 invoked from network); 8 Mar 2001 13:58:52 -0000 Received: from hutcs.cs.hut.fi (kivinen@130.233.192.7) by mail.netbsd.org with SMTP; 8 Mar 2001 13:58:52 -0000 Received: (from kivinen@localhost) by hutcs.cs.hut.fi (8.9.3/8.9.3) id PAA25107; Thu, 8 Mar 2001 15:54:09 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 8 Mar 2001 15:54:08 +0200 (EET) From: Tero Kivinen To: "Marcus Leech" Cc: Tatu Ylonen , Bill Sommerfeld , ietf-ssh@netbsd.org, jis@mit.edu Subject: Re: SSH-> Secure Shell renaming is *not* official. In-Reply-To: <3AA64C7D.9FC58967@NORTELNETWORKS.COM> References: <200103062201.AAA01720@mystery.acr.fi> <3AA64C7D.9FC58967@NORTELNETWORKS.COM> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <15015.31291.702440.788396@hutcs.cs.hut.fi> Organization: Helsinki University of Technology X-Edit-Time: 49 min X-Total-Time: 88 min Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Marcus Leech writes: > Tatu Ylonen wrote: > > I went ahead and made the editorial changes unilaterally in view of > Tatu, it is inappropriate for you to act on any of this without the consensus > of the working group. Bill Sommerfeld was entirely justified in objecting > to this action. I think changing the document title should be in the hands of the document editor. Of course WG might be against the renaming and ask the editor to change it back or to something else. In this case Tatu renamed the documents to match the official working group name. Comment about IETF way of selecting names of draft earlier on the ietf-ssh list from the RJ Atkinson : ---------------------------------------------------------------------- From: RJ Atkinson To: Cc: Subject: RE: Renaming SSH-the-standard Date: Fri, 16 Feb 2001 10:36:47 -0500 Message-Id: <5.0.0.25.2.20010216103331.00a28480@10.30.15.2> ... Names of drafts in MANY working groups are not the same as the official name of the WG. In practice, names of drafts are generally chosen by the editors of those drafts, not as an official choice by the WG or IETF. Perhaps you're new to our wacky ways of doing things in the IETF ? ... ---------------------------------------------------------------------- There has been other cases where there has been no discussion on the ietf mailing list before renaming the protocol (for example ISAKMP/Oakley resolution protocol was renamed to IKE without any previous discussion on the ipsec-list. There might have been some discussion about renaming in the IETF meeting or in the vpn-backoff, but no discussion on the list). Bill Sommerfeld said in his email: ---------------------------------------------------------------------- From: Bill Sommerfeld Sender: owner-ietf-ssh@clinet.fi To: ietf-ssh@clinet.fi Subject: Your working group chair is GRUMPY. Message-Id: <200102161827.f1GIRQ923087@thunk.east.sun.com> ... - At the present time, based both on comments to the mailing list and to me in private I do not see consensus either for or against renaming the working group and protocol. - I am reluctant to initiate renaming unless I see SMOOTH CONSENSUS. ... ---------------------------------------------------------------------- Counting from the ietf-ssh list there hasn't been single clear "no to renaming" before new drafts came out. Before Sommerfeld's email there had been at least two yes on the list (one suggesting it, in the first place, and another saying that, yes we can rename), so I assume there has been some private emails to Sommerfeld against the renaming based on his wording on the email. After that the situation on the ietf-list didn't change at all, there was just some discussion about names (good or bad) but no more yes or no votes. When Tatu called me on the Friday afternoon and asked would it be ok to submit the new version of drafts, that also had been renamed, or not to submit them at all (the deadline was in few hours), I didn't see any reason why not submit. There hadn't been single person saying "No" on the ietf-ssh list, thus I think we had consensus, or most people simply dont care. If there has been private discussion somewhere, I don't know about it. Here is my summary of the renameing discussion between the first email suggesting it (Feb 16 15:07:20) and when the draft announcements came out (Mar 6 16:27:40). Yes to rename: ---------------------------------------------------------------------- Robert Elz Suggested renaming in the ietf-ssh list "denis bider" "We can rename the standard, and from the naming point of view, it would make sense to do so - "secure shell" doesn't resemble what the protocol does." ---------------------------------------------------------------------- No to renaming ---------------------------------------------------------------------- (none) ---------------------------------------------------------------------- No clear yes or no to renaming: ---------------------------------------------------------------------- Jason R Thorpe Discussion about names, no clear yes or no. RJ Atkinson Said that secure shell name is ok, but didn't say anything about ssh name. ---------------------------------------------------------------------- After that drafts came out there has been three more "No" emails to the list from Bill Sommerfeld, Thor Simon and Jason Thorpe. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 8 10:53:16 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00593 for ; Thu, 8 Mar 2001 10:53:11 -0500 (EST) Received: (qmail 29289 invoked by uid 605); 8 Mar 2001 15:53:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29282 invoked from network); 8 Mar 2001 15:53:03 -0000 Received: from guinness.cs.stevens-tech.edu (155.246.89.8) by mail.netbsd.org with SMTP; 8 Mar 2001 15:53:03 -0000 Received: (from tls@localhost) by guinness.cs.stevens-tech.edu (8.9.3/8.9.3) id KAA1942038; Thu, 8 Mar 2001 10:44:07 -0500 (EST) Date: Thu, 8 Mar 2001 10:44:06 -0500 From: Thor Simon To: Tero Kivinen Cc: Marcus Leech , sommerfeld@east.sun.com, ietf-ssh@netbsd.org, jis@mit.edu, tls@cs.stevens-tech.edu Subject: Re: SSH-> Secure Shell renaming is *not* official. Message-ID: <20010308104406.A1901489@cs.stevens-tech.edu> References: <200103062201.AAA01720@mystery.acr.fi> <3AA64C7D.9FC58967@NORTELNETWORKS.COM> <15015.31291.702440.788396@hutcs.cs.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: <15015.31291.702440.788396@hutcs.cs.hut.fi>; from kivinen@mail.niksula.cs.hut.fi on Thu, Mar 08, 2001 at 03:54:08PM +0200 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Mar 08, 2001 at 03:54:08PM +0200, Tero Kivinen wrote: > > When Tatu called me on the Friday afternoon and asked would it be ok > to submit the new version of drafts, that also had been renamed, or > not to submit them at all (the deadline was in few hours), I didn't > see any reason why not submit. There hadn't been single person saying > "No" on the ietf-ssh list, thus I think we had consensus, or most > people simply dont care. If there has been private discussion > somewhere, I don't know about it. That's nice, but I think that it is rather highly disingenuous. The plain fact is that Tatu suggested that the protocol and drafts *must* be renamed, and that a long, painful discussion of the falsity of that claim ensued both on and off the WG mailing list. How could you possibly think, given that very nasty and public situation involving, primarily, working group members, not to mention the extension of the chaos onto the WG mailing list, that there was anything even approaching consensus? I find it interesting that the only person supporting Tatu's actions here is one of his employees. I note that another of Tatu's employees recently applied related, sudden, unilateral changes to the SSH FAQ. Thor From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 8 10:54:29 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00638 for ; Thu, 8 Mar 2001 10:54:28 -0500 (EST) Received: (qmail 136 invoked by uid 605); 8 Mar 2001 15:54:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 129 invoked from network); 8 Mar 2001 15:54:14 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 8 Mar 2001 15:54:14 -0000 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 RAA06877; Thu, 8 Mar 2001 17:32:31 +0100 Reply-To: From: "denis bider" To: , Subject: RE: do we need to rename? Date: Thu, 8 Mar 2001 16:53:59 +0100 Message-ID: <005601c0a7e7$fe4c2160$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: <200103062307.f26N7Z903430@thunk.east.sun.com> Importance: Normal Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Bill Sommerfeld writes: > - renaming may be interpreted (incorrectly) as a statement by the > - renaming will introduce confusion in the marketplace and for end > - renaming will not eliminate the need to use the "SSH" word in > - IETF is not particulary successful at renaming deployed protocols; > - renaming may not actually prevent dilution of the trademark, since (my personal opinion) Although Reason#1 as currently phrased sounds like a matter of pride, which would put it in a bit of a shady light, the other 4 reasons are very sound. All of them together, they support Reason#1 very well. My personal opinion would be that the causes AGAINST renaming definitely outweigh the causes FOR renaming. I wouldn't rename; not because of pride, but because, given the background, I don't see it as a positive thing to do. I see it as a retreat without any valid justification. Retreats must have valid justifications. Regards, denis From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 8 11:15:21 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01773 for ; Thu, 8 Mar 2001 11:15:20 -0500 (EST) Received: (qmail 10828 invoked by uid 605); 8 Mar 2001 16:15:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10821 invoked from network); 8 Mar 2001 16:15:14 -0000 Received: from hutcs.cs.hut.fi (kivinen@130.233.192.7) by mail.netbsd.org with SMTP; 8 Mar 2001 16:15:14 -0000 Received: (from kivinen@localhost) by hutcs.cs.hut.fi (8.9.3/8.9.3) id SAA29134; Thu, 8 Mar 2001 18:15:06 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 8 Mar 2001 18:15:06 +0200 (EET) From: Tero Kivinen To: Thor Simon Cc: Marcus Leech , sommerfeld@east.sun.com, ietf-ssh@netbsd.org, jis@mit.edu Subject: Re: SSH-> Secure Shell renaming is *not* official. In-Reply-To: <20010308104406.A1901489@cs.stevens-tech.edu> References: <200103062201.AAA01720@mystery.acr.fi> <3AA64C7D.9FC58967@NORTELNETWORKS.COM> <15015.31291.702440.788396@hutcs.cs.hut.fi> <20010308104406.A1901489@cs.stevens-tech.edu> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <15015.44318.156440.471595@hutcs.cs.hut.fi> Organization: Helsinki University of Technology X-Edit-Time: 9 min X-Total-Time: 12 min Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Thor Simon writes: > That's nice, but I think that it is rather highly disingenuous. > The plain fact is that Tatu suggested that the protocol and drafts > *must* be renamed, and that a long, painful discussion of the falsity of > that claim ensued both on and off the WG mailing list. How could you Can you give me a reference to that email of Tatu about that to the ietf-ssh list? At least I cannot find it from my ietf-ssh archive. It might of course be that mailing list at clinet managed to destroy that mail, and didn't send it to me. I cannot also find this long painful discussion about the protocol renaming on the list. I have seen Tatu's email about the OpenSSH and requesting them to change the name, that working group and protocol name discussion came after that and I haven't seen Tatu commenting that on the ietf-ssh list. > I find it interesting that the only person supporting Tatu's actions here > is one of his employees. I note that another of Tatu's employees recently > applied related, sudden, unilateral changes to the SSH FAQ. I am also one of the authors of the draft, and I was involved in the case by saying Tatu that "yes, I think it is OK to rename". -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 8 11:32:30 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02561 for ; Thu, 8 Mar 2001 11:32:29 -0500 (EST) Received: (qmail 15109 invoked by uid 605); 8 Mar 2001 16:32:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14869 invoked from network); 8 Mar 2001 16:32:00 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 8 Mar 2001 16:32:00 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id CE3D682F55F for ; Thu, 8 Mar 2001 17:31:58 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id RAA24003; Thu, 8 Mar 2001 17:31:58 +0100 (MET) To: ietf-ssh@netbsd.org Subject: Channel close logic, needs clarification? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 08 Mar 2001 17:31:58 +0100 Message-ID: Lines: 62 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Do we need to make some more detailed recommendations about channel close logic? Different behaviour can cause interoperability problems. For instance, I have heard reports that when logging in with the openssh client to a recent lshd, the client will hang after logout. I'll describe the logic that lsh and lshd uses. The basic rules are as follows: 1. When SSH_MSG_CHANNEL_CLOSE is both sent and received, the channel is killed. This is unconditionally required by the spec. 2. When SSH_MSG_CHANNEL_EOF is both sent and received, SSH_MSG_CHANNEL_CLOSE is sent (unless it wasn't sent earlier). This makes sense in almost all cases (and the only exceptions I'm aware of seem out-of-scope here, they are related to proxying or gatewaying channels). So, what is left to decide is when to send SSH_MSG_CHANNEL_EOF. In most cases, the decision is easy, but sometimes it is not. Consider the scenario where a client creates a session channel, gets a login shell, and later exits the shell by explicitly typing exit or logout. The result, at the server side, is * The server handles SIGCLD, discovers that its child process died, and sends an SSH_MSG_CHANNEL_REQUEST "exit-status". This is of course not done directly by the signal handler, but some time later from the main loop. * The server gets an EOF condition on the process' stdout and stderr (unless their are any grand children that still has one or the other open). When EOF has occured on both stdout and stderr, the server sends an SSH_MSG_CHANNEL_EOF. The two events above can occur in more or less random order. The server has not received any SSH_MSG_CHANNEL_EOF, so rule 2 doesn't apply. The channel is still open. What happens at the client? When the lsh client receives an SSH_MSG_CHANNEL_REQUEST "exit-status" message, it decides that it's time to stop talking, and it sends an SSH_MSG_CHANNEL_EOF. Now rule 2 applies, and the channel gets closed properly. It's not obvious that the channel should be closed at this time; there may be some grand child process that is still alive. If the client has received a SSH_MSG_CHANNEL_EOF that implies that no process has its *output* connected to the channel, but even in this case (which lsh doesn't try to look for), there may be some process with input still connected to the channel. And this is why the server doesn't close the channel automatically at process death; the user may still have some processes alive to talk to, and the client is more likely than the server to know what the user really wants. But appearantly, this logic doesn't work right when talking to the openssh client. It doesn't send any SSH_MSG_CHANNEL_EOF, and to the user it appears that the system just hangs. Does the lsh behaviour above make sense to you? What are other implementations doing? Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 8 12:52:45 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05960 for ; Thu, 8 Mar 2001 12:52:44 -0500 (EST) Received: (qmail 12685 invoked by uid 605); 8 Mar 2001 17:52:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12673 invoked from network); 8 Mar 2001 17:52:34 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 8 Mar 2001 17:52:34 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15452; Thu, 8 Mar 2001 09:51:47 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20728; Thu, 8 Mar 2001 12:51:38 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f28HpW904520; Thu, 8 Mar 2001 12:51:32 -0500 (EST) Message-Id: <200103081751.f28HpW904520@thunk.east.sun.com> From: Bill Sommerfeld To: Tero Kivinen cc: "Marcus Leech" , Tatu Ylonen , Bill Sommerfeld , ietf-ssh@netbsd.org, jis@mit.edu Subject: Re: SSH -> Secure Shell renaming is *not* official. In-reply-to: Your message of "Thu, 08 Mar 2001 15:54:08 +0200." <15015.31291.702440.788396@hutcs.cs.hut.fi> Reply-to: sommerfeld@east.sun.com Date: Thu, 08 Mar 2001 12:51:32 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Tero, In the IETF, it is the *working group chair* who is the judge of whether or not consensus exists. Tatu should have called me, and I would have told him: - I was uncertain of consensus - until consensus was clear it would be inappropriate to change anything. Moreover, I informed Tatu of exactly how I wanted to handle any potential renaming on several occasions. In a private message I sent on 13 Feb 2001 to Tatu, I stated: The appropriate thing to do is for me to announce [this request for renaming] to the working group, and have the WG pick a new name for itself. I'll send message to the WG about this when I get some spare cycles. In another message I sent on 16 Feb 2001 to Tatu, I stated: The secure shell working group really needs to come to consensus on whether or not renaming is necessary before we can discuss alternate names. This should have made it sufficiently clear that he should have checked with me before taking any action. > Here is my summary of the renameing discussion between the first > email suggesting it (Feb 16 15:07:20) and when the draft announcements > came out (Mar 6 16:27:40). Given that the working group mailing list had been flaky until I moved it to its new home, judging by what made it through to the list and/or ended up in the archives is risky at best. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 8 12:56:45 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06168 for ; Thu, 8 Mar 2001 12:56:44 -0500 (EST) Received: (qmail 15424 invoked by uid 605); 8 Mar 2001 17:56:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15411 invoked by uid 1007); 8 Mar 2001 17:56:34 -0000 Date: Thu, 8 Mar 2001 09:56:34 -0800 From: "Charles M. Hannum" To: denis bider Cc: sommerfeld@east.sun.com, ietf-ssh@netbsd.org Subject: Re: do we need to rename? Message-ID: <20010308095634.M2139@mail.netbsd.org> References: <200103062307.f26N7Z903430@thunk.east.sun.com> <005601c0a7e7$fe4c2160$0201010a@intergalactic> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <005601c0a7e7$fe4c2160$0201010a@intergalactic>; from denis.bider@denisbider.com on Thu, Mar 08, 2001 at 04:53:59PM +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Mar 08, 2001 at 04:53:59PM +0100, denis bider wrote: > > I wouldn't rename; not because of pride, but because, given the background, > I don't see it as a positive thing to do. I see it as a retreat without any > valid justification. Retreats must have valid justifications. Speaking of `retreats' suggests pretty strongly that it *is* a matter of pride. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 8 13:02:53 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06450 for ; Thu, 8 Mar 2001 13:02:52 -0500 (EST) Received: (qmail 17229 invoked by uid 605); 8 Mar 2001 18:02:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17221 invoked from network); 8 Mar 2001 18:02:43 -0000 Received: from 209-9-249-62.sdsl.cais.net (HELO gnat.inet.org) (209.9.249.62) by mail.netbsd.org with SMTP; 8 Mar 2001 18:02:43 -0000 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 3E3678266E; Thu, 8 Mar 2001 13:02:08 -0500 (EST) Message-Id: <5.0.2.1.2.20010308125856.00a8c020@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 08 Mar 2001 13:02:17 -0500 To: Tero Kivinen From: RJ Atkinson Subject: Re: SSH-> Secure Shell renaming is *not* official. Cc: ietf-ssh@netbsd.org In-Reply-To: <15015.31291.702440.788396@hutcs.cs.hut.fi> References: <3AA64C7D.9FC58967@NORTELNETWORKS.COM> <200103062201.AAA01720@mystery.acr.fi> <3AA64C7D.9FC58967@NORTELNETWORKS.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 08:54 08/03/01, Tero Kivinen wrote: >I think changing the document title should be in the hands of the >document editor. Understood, but Bill is WG Chair. Moreover, the applicable Security AD has already spoken in favour of Bill's comments, so there can be no question that my earlier misunderstanding was wrong and that Bill's assertion is correct. Tatu could have avoided this entire mess by handling matters in a more clear and more civilised manner much earlier on. Its a pity he didn't do so, but we are where we are. Ran rja@inet.org From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 8 13:04:28 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06524 for ; Thu, 8 Mar 2001 13:04:27 -0500 (EST) Received: (qmail 18007 invoked by uid 605); 8 Mar 2001 18:04:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18000 invoked from network); 8 Mar 2001 18:04:19 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 8 Mar 2001 18:04:19 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19843 for ; Thu, 8 Mar 2001 10:04:18 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id KAA16136 for ; Thu, 8 Mar 2001 10:04:18 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.11.3+Sun/8.11.3) with SMTP id f28I4Hv566189 for ; Thu, 8 Mar 2001 10:04:17 -0800 (PST) Message-Id: <200103081804.f28I4Hv566189@jurassic.eng.sun.com> Date: Thu, 8 Mar 2001 10:04:17 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: SSH -> Secure Shell renaming is *not* official. To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: DDELFrG6TTxztRa7v9Smyw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_26 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list I'm guessing here but the fact that there is a legal dispute going on might be the reason why some people are unable to express an opnion on wither or not to rename since by doing so it declares their companies position on the validity of the trademark. Maybe this is best disucussed in the meeting (or maybe not since it is a very emotional issue). -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 8 13:10:54 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06838 for ; Thu, 8 Mar 2001 13:10:52 -0500 (EST) Received: (qmail 18884 invoked by uid 605); 8 Mar 2001 18:10:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18872 invoked from network); 8 Mar 2001 18:10:39 -0000 Received: from ns0.fries.net (HELO fries.net) (todd@206.30.141.10) by mail.netbsd.org with SMTP; 8 Mar 2001 18:10:39 -0000 Received: (from todd@localhost) by fries.net (8.11.2/8.11.2) id f28IAbq01960 for ietf-ssh@netbsd.org; Thu, 8 Mar 2001 12:10:37 -0600 (CST) Date: Thu, 8 Mar 2001 12:10:37 -0600 From: "Todd T. Fries" To: ietf-ssh@netbsd.org Subject: Fwd: cleanup Message-ID: <20010308121037.B20504@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 X-URL: http://todd.fries.net X-tra-email: todd@fries.net, toddf@acm.org, todd@openbsd.org, toddfries@yahoo.com Sender: ietf-ssh-owner@netbsd.org Precedence: list In light of the current discussion, I feel I should have sent this email to the list instead of the authors in the referenced documents. ----- Forwarded message from "Todd T. Fries" ----- Date: Tue, 6 Mar 2001 10:01:10 -0600 From: "Todd T. Fries" To: galb@vandyke.com, kivinen@ssh.com, rodney@tillerman.to, sjl@ssh.com, tri@ssh.com, ylo@ssh.com Subject: cleanup X-tra-email: todd@fries.net, toddf@acm.org, todd@openbsd.org, toddfries@yahoo.com You have received this email because you are an author of a draft of the secsh working group and I believe there is still an issue with them. Basically, I'd like to remove the entire blurbage about "ssh" being a trademark, because mentioning a logo trademark is quite outside the scope of this working group, especially considering RFC2026: "The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Putting a trademark referencing a logo under 'Trademark Issues' tends to contradict the above. Please consider removing this `issue' from the drafts so that the drafts can move onto becoming standards. Thank you, -- Todd Fries .. todd@fries.net Index: draft-ietf-secsh-architecture.txt =================================================================== RCS file: /u/todd/src/.cvs/home/ref/drafts/draft-ietf-secsh-architecture.txt,v retrieving revision 1.9 diff -u -r1.9 draft-ietf-secsh-architecture.txt --- draft-ietf-secsh-architecture.txt 2001/03/06 15:15:41 1.9 +++ draft-ietf-secsh-architecture.txt 2001/03/06 15:48:26 @@ -75,9 +75,8 @@ 6. Message Numbers . . . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 -9. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . . 10 -10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 -11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 +9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 +10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction @@ -556,13 +555,8 @@ disabled. The Secure Shell protocol does not protect against message alteration if no MAC is used. -9. Trademark Issues +9. References -"ssh" is a registered trademark of SSH Communications Security Corp in -the United States and/or other countries. - -10. References - [FIPS-186] Federal Information Processing Standards Publication (FIPS PUB) 186, Digital Signature Standard, 18 May 1994. @@ -614,7 +608,7 @@ [SECSH-CONNECT] Ylonen, T., et al: "Secure Shell Connection Protocol", Internet-Draft, draft-ietf-secsh-connect-10.txt -11. Authors' Addresses +10. Authors' Addresses Tatu Ylonen SSH Communications Security Corp Index: draft-ietf-secsh-connect.txt =================================================================== RCS file: /u/todd/src/.cvs/home/ref/drafts/draft-ietf-secsh-connect.txt,v retrieving revision 1.11 diff -u -r1.11 draft-ietf-secsh-connect.txt --- draft-ietf-secsh-connect.txt 2001/03/06 15:17:41 1.11 +++ draft-ietf-secsh-connect.txt 2001/03/06 15:48:28 @@ -87,9 +87,8 @@ 6. Encoding of Terminal Modes . . . . . . . . . . . . . . . . . . . 13 7. Summary of Message Numbers . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 15 -9. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . . 16 -10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 -11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 +9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 +10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 @@ -901,13 +900,8 @@ dangerous features (e.g. agent forwarding, X11 forwarding, and TCP/IP forwarding) if the host key has changed. -9. Trademark Issues +9. References -"ssh" is a registered trademark of SSH Communications Security Corp in -the United States and/or other countries. - -10. References - [RFC-1766] Alvestrand, H: "Tags for the Identification of Languages", March 1995. @@ -934,7 +928,7 @@ [SECSH-USERAUTH] Ylonen, T., et al: "Secure Shell Authentication Protocol", Internet-Draft, draft-ietf-secsh-userauth-10.txt -11. Authors' Addresses +10. Authors' Addresses Tatu Ylonen SSH Communications Security Corp Index: draft-ietf-secsh-filexfer.txt =================================================================== RCS file: /u/todd/src/.cvs/home/ref/drafts/draft-ietf-secsh-filexfer.txt,v retrieving revision 1.2 diff -u -r1.2 draft-ietf-secsh-filexfer.txt --- draft-ietf-secsh-filexfer.txt 2001/03/06 15:18:33 1.2 +++ draft-ietf-secsh-filexfer.txt 2001/03/06 15:48:32 @@ -85,9 +85,8 @@ 10.1. Changes between versions 3 and 2 . . . . . . . . . . . . . 18 10.2. Changes between versions 2 and 1 . . . . . . . . . . . . . 18 10.3. Changes between versions 1 and 0 . . . . . . . . . . . . . 18 -11. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . 18 -12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 -13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 +11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 +12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 @@ -1062,13 +1061,8 @@ INTERNET-DRAFT 2 March, 2001 -11. Trademark Issues +11. References -"ssh" is a registered trademark of SSH Communications Security Corp in -the United States and/or other countries. - -12. References - [RFC-2246] Dierks, T. and Allen, C.: "The TLS Protocol Version 1.0", January 1999 @@ -1088,7 +1082,7 @@ [SECSH-CONNECT] Ylonen, T., et al: "Secure Shell Connection Protocol", Internet-Draft, draft-ietf-secsh-connect-10.txt -13. Authors' Addresses +12. Authors' Addresses Tatu Ylonen SSH Communications Security Corp Index: draft-ietf-secsh-publickeyfile.txt =================================================================== RCS file: /u/todd/src/.cvs/home/ref/drafts/draft-ietf-secsh-publickeyfile.txt,v retrieving revision 1.2 diff -u -r1.2 draft-ietf-secsh-publickeyfile.txt --- draft-ietf-secsh-publickeyfile.txt 2001/03/06 15:19:45 1.2 +++ draft-ietf-secsh-publickeyfile.txt 2001/03/06 15:48:33 @@ -230,4 +230,4 @@ J. Galbraith, R. Thayer [Page 4] - \ No newline at end of file + Index: draft-ietf-secsh-transport.txt =================================================================== RCS file: /u/todd/src/.cvs/home/ref/drafts/draft-ietf-secsh-transport.txt,v retrieving revision 1.11 diff -u -r1.11 draft-ietf-secsh-transport.txt --- draft-ietf-secsh-transport.txt 2001/03/06 15:24:14 1.11 +++ draft-ietf-secsh-transport.txt 2001/03/06 15:48:37 @@ -91,9 +91,8 @@ 9.4. Reserved Messages . . . . . . . . . . . . . . . . . . . . . 20 10. Summary of Message Numbers . . . . . . . . . . . . . . . . . . 20 11. Security Considerations . . . . . . . . . . . . . . . . . . . . 20 -12. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . 21 -13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 -14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 +12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 +13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 @@ -1203,13 +1202,8 @@ recipient has no reliable way to verify whether such information is being sent. -12. Trademark Issues +12. References -"ssh" is a registered trademark of SSH Communications Security Corp in -the United States and/or other countries. - -13. References - [FIPS-186] Federal Information Processing Standards Publication (FIPS PUB) 186, Digital Signature Standard, 18 May 1994. @@ -1270,7 +1264,7 @@ [SECSH-CONNECT] Ylonen, T., et al: "Secure Shell Connection Protocol", Internet-Draft, draft-ietf-secsh-connect-10.txt -14. Authors' Addresses +13. Authors' Addresses Tatu Ylonen SSH Communications Security Corp Index: draft-ietf-secsh-userauth.txt =================================================================== RCS file: /u/todd/src/.cvs/home/ref/drafts/draft-ietf-secsh-userauth.txt,v retrieving revision 1.11 diff -u -r1.11 draft-ietf-secsh-userauth.txt --- draft-ietf-secsh-userauth.txt 2001/03/06 15:28:31 1.11 +++ draft-ietf-secsh-userauth.txt 2001/03/06 15:48:39 @@ -73,9 +73,8 @@ 5. Password Authentication Method: password . . . . . . . . . . . . 7 6. Host-Based Authentication: hostbased . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 -8. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . . 10 -9. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 -10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 +8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 +9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 @@ -582,18 +581,13 @@ messages may reveal surprising amounts of information about the host if not properly designed. Debug messages can be disabled (during user authentication phase) if high security is required. -8. Trademark Issues - T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne and S. Lehtinen [page 10] INTERNET-DRAFT 2 March, 2001 -"ssh" is a registered trademark of SSH Communications Security Corp in -the United States and/or other countries. - -9. References +8. References [RFC-1766] Alvestrand, H: "Tags for the Identification of Languages", March 1995. @@ -610,7 +604,7 @@ [SECSH-CONNECT] Ylonen, T., et al: "Secure Shell Connection Protocol", Internet-Draft, draft-secsh-connect-10.txt -10. Authors' Addresses +9. Authors' Addresses Tatu Ylonen SSH Communications Security Corp ----- End forwarded message ----- -- Todd Fries .. todd@fries.net From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 8 13:48:31 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08065 for ; Thu, 8 Mar 2001 13:48:30 -0500 (EST) Received: (qmail 507 invoked by uid 605); 8 Mar 2001 18:48:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 495 invoked from network); 8 Mar 2001 18:48:22 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 8 Mar 2001 18:48:22 -0000 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 UAA07227; Thu, 8 Mar 2001 20:26:48 +0100 Reply-To: From: "denis bider" To: "'Charles M. Hannum'" Cc: , Subject: RE: do we need to rename? Date: Thu, 8 Mar 2001 19:48:16 +0100 Message-ID: <005901c0a800$56f7ca40$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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: <20010308095634.M2139@mail.netbsd.org> Importance: Normal Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > > I wouldn't rename; not because of pride, but because, given > > the background, I don't see it as a positive thing to do. > > I see it as a retreat without any valid justification. > > Retreats must have valid justifications. > > Speaking of `retreats' suggests pretty strongly that it *is* > a matter of pride. I would guess that you posted this comment inadvertently before you could hit the Cancel button, because this is simply not so. If one has a strong case, then choosing to retreat because one fears the bully is unethical, because it unnecessarily advances the bully's unfair cause. If one has a weak case, then choosing to retreat is wise, and deciding not to retreat regardless is a symptom of not being able to control one's pride. I believe we have a strong case, therefore pride is not an issue. Rather, I believe it would be unethical for us to retreat in fear of SSH Communications Security; because by doing so, we would be passively promoting an unsound business practice, thereby increasing the possibility of this behavior occuring again in the future. I think it is in our interest (i.e., the interest of the ssh-working-group minus participants employed by ssh-the-company) to prevent or, failing that, at least discourage this behavior in the future. Regards, denis From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 8 14:30:21 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09749 for ; Thu, 8 Mar 2001 14:30:20 -0500 (EST) Received: (qmail 12720 invoked by uid 605); 8 Mar 2001 19:30:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12713 invoked from network); 8 Mar 2001 19:30:14 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 8 Mar 2001 19:30:14 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12103; Thu, 8 Mar 2001 11:29:35 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08524; Thu, 8 Mar 2001 14:29:34 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f28JTO904847; Thu, 8 Mar 2001 14:29:24 -0500 (EST) Message-Id: <200103081929.f28JTO904847@thunk.east.sun.com> From: Bill Sommerfeld To: Tero Kivinen cc: Thor Simon , Marcus Leech , sommerfeld@east.sun.com, ietf-ssh@netbsd.org, jis@mit.edu Subject: Re: SSH-> Secure Shell renaming is *not* official. In-reply-to: Your message of "Thu, 08 Mar 2001 18:15:06 +0200." <15015.44318.156440.471595@hutcs.cs.hut.fi> Reply-to: sommerfeld@east.sun.com Date: Thu, 08 Mar 2001 14:29:24 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > Can you give me a reference to that email of Tatu about that to the > ietf-ssh list? Based on at least one reply to Tatu's message, from Matthiew Weigel, on Friday 16 Feb 2001, I believe it made it at least one of the lists on the CC: line (but not ietf-ssh). To: Tatu Ylonen cc: ietf-ssh@clinet.fi, ssh@clinet.fi, openssh-unix-dev@mindrot.org Subject: Re: ssh(R) trademark issues: comments and proposal In-reply-to: Your message of "Fri, 16 Feb 2001 12:51:06 +0200." <200102161051.MAA09237@mystery.acr.fi> Date: Fri, 16 Feb 2001 14:21:05 -0500 From: Matthew Weigel I sent a copy to Tero and Thor. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 8 14:34:45 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09902 for ; Thu, 8 Mar 2001 14:34:45 -0500 (EST) Received: (qmail 14126 invoked by uid 605); 8 Mar 2001 19:34:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14118 invoked from network); 8 Mar 2001 19:34:39 -0000 Received: from riot.sweden.hp.com (15.254.225.1) by mail.netbsd.org with SMTP; 8 Mar 2001 19:34:39 -0000 Received: from b0fh.sweden.hp.com (b0fh.sweden.hp.com [15.164.6.26]) by riot.sweden.hp.com (Postfix) with ESMTP id C4A42865; Thu, 8 Mar 2001 20:33:37 +0100 (MET) Received: from rush ([15.126.45.158]) by b0fh.sweden.hp.com (8.9.3/8.9.3) with ESMTP id UAA26718; Thu, 8 Mar 2001 20:33:34 +0100 (MET) Date: Thu, 8 Mar 2001 20:33:51 +0100 (MET) From: Kevin Steves X-X-Sender: To: Darren Moffat Cc: Subject: Re: SSH -> Secure Shell renaming is *not* official. In-Reply-To: <200103081804.f28I4Hv566189@jurassic.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, 8 Mar 2001, Darren Moffat wrote: : I'm guessing here but the fact that there is a legal dispute going on : might be the reason why some people are unable to express an opnion on : wither or not to rename since by doing so it declares their companies : position on the validity of the trademark. no. it is wrong to assume that someone posting with a some-entity.com address represents some-entity's legal position on this matter, unless the message clearly states that it does. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 8 16:14:41 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13609 for ; Thu, 8 Mar 2001 16:14:40 -0500 (EST) Received: (qmail 5071 invoked by uid 605); 8 Mar 2001 21:14:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5052 invoked from network); 8 Mar 2001 21:14:31 -0000 Received: from cvs.openbsd.org (root@199.185.137.3) by mail.netbsd.org with SMTP; 8 Mar 2001 21:14:31 -0000 Received: from cvs.openbsd.org (IDENT:deraadt@localhost [127.0.0.1]) by cvs.openbsd.org (8.11.2/8.10.1) with ESMTP id f28LCgl01133 for ; Thu, 8 Mar 2001 14:12:42 -0700 (MST) Message-Id: <200103082112.f28LCgl01133@cvs.openbsd.org> To: ietf-ssh@netbsd.org Subject: Re: SSH-> Secure Shell renaming is *not* official. Date: Thu, 08 Mar 2001 14:12:42 -0700 From: Theo de Raadt Sender: ietf-ssh-owner@netbsd.org Precedence: list Tero Kivinen (who is apparently an employee of ssh.com posting from another place probably so he will look like an independent thinker) said: > When Tatu called me on the Friday afternoon and asked would it be ok > to submit the new version of drafts, that also had been renamed, or > not to submit them at all (the deadline was in few hours), I didn't > see any reason why not submit. There hadn't been single person saying > "No" on the ietf-ssh list, thus I think we had consensus, or most > people simply dont care. If there has been private discussion > somewhere, I don't know about it. I think it is clear that you live in a different universe. I don't understand where you get this. Many other vendors of SSH implementations have been very outspoken against the change, because SSH is a generic term referring to programs which do the SSH protocol. Note -- no trademark. We feel that ssh.com is making invalid claims, and if ssh.com feels so strongly otherwise, go ahead -- sue us. If you don't sue us, you are not defending it. But if you sue us, you may expect to have it invalided in court.... Basically, anyone who has a name which includes SSH in it is pretty much saying "we do SSH protocol". Looking around, I do not see many vendors using the term "Secure Shell". Of course, if a judge decides that SSH is an acronym for "Secure Shell"... Here in OpenSSH land, we all very firmy believe that a name change would needlessly create user community confusion. BTW, check out the graphs at http://ssh-research.ucs.ualberta.ca/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 8 16:20:28 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13740 for ; Thu, 8 Mar 2001 16:20:27 -0500 (EST) Received: (qmail 6279 invoked by uid 605); 8 Mar 2001 21:20:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6272 invoked from network); 8 Mar 2001 21:20:20 -0000 Received: from mail.websidestory.com (209.75.20.4) by mail.netbsd.org with SMTP; 8 Mar 2001 21:20:20 -0000 Received: from elya ([10.100.96.59]) by mail.websidestory.com (8.9.1a/8.9.1) with SMTP id NAA13927 for ; Thu, 8 Mar 2001 13:20:03 -0800 (PST) Reply-To: From: "Elya Kurktchi" To: Subject: RE: SSH-> Secure Shell renaming is *not* official. Date: Thu, 8 Mar 2001 13:19:50 -0800 Message-ID: <008601c0a815$9d79aaf0$3b60640a@elya> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal In-Reply-To: <200103082112.f28LCgl01133@cvs.openbsd.org> Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit I agree. However, on http://www.ssh.com website, it says that SSH, SSH Secure Shell and SSH Sentinel are registered trademarks or trademarks of SSH Communications Security Corp in the U.S. and/or other countries. Elya. -----Original Message----- From: ietf-ssh-owner@netbsd.org [mailto:ietf-ssh-owner@netbsd.org]On Behalf Of Theo de Raadt Sent: Thursday, March 08, 2001 1:13 PM To: ietf-ssh@netbsd.org Subject: Re: SSH-> Secure Shell renaming is *not* official. Tero Kivinen (who is apparently an employee of ssh.com posting from another place probably so he will look like an independent thinker) said: > When Tatu called me on the Friday afternoon and asked would it be ok > to submit the new version of drafts, that also had been renamed, or > not to submit them at all (the deadline was in few hours), I didn't > see any reason why not submit. There hadn't been single person saying > "No" on the ietf-ssh list, thus I think we had consensus, or most > people simply dont care. If there has been private discussion > somewhere, I don't know about it. I think it is clear that you live in a different universe. I don't understand where you get this. Many other vendors of SSH implementations have been very outspoken against the change, because SSH is a generic term referring to programs which do the SSH protocol. Note -- no trademark. We feel that ssh.com is making invalid claims, and if ssh.com feels so strongly otherwise, go ahead -- sue us. If you don't sue us, you are not defending it. But if you sue us, you may expect to have it invalided in court.... Basically, anyone who has a name which includes SSH in it is pretty much saying "we do SSH protocol". Looking around, I do not see many vendors using the term "Secure Shell". Of course, if a judge decides that SSH is an acronym for "Secure Shell"... Here in OpenSSH land, we all very firmy believe that a name change would needlessly create user community confusion. BTW, check out the graphs at http://ssh-research.ucs.ualberta.ca/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 8 16:47:37 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14374 for ; Thu, 8 Mar 2001 16:47:36 -0500 (EST) Received: (qmail 11812 invoked by uid 605); 8 Mar 2001 21:47:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11645 invoked from network); 8 Mar 2001 21:47:16 -0000 Received: from 209-9-249-62.sdsl.cais.net (HELO gnat.inet.org) (209.9.249.62) by mail.netbsd.org with SMTP; 8 Mar 2001 21:47:16 -0000 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 6846D8266E; Thu, 8 Mar 2001 16:46:36 -0500 (EST) Message-Id: <5.0.2.1.2.20010308164519.009fc3e0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 08 Mar 2001 16:46:45 -0500 To: From: RJ Atkinson Subject: RE: SSH-> Secure Shell renaming is *not* official. Cc: In-Reply-To: <008601c0a815$9d79aaf0$3b60640a@elya> References: <200103082112.f28LCgl01133@cvs.openbsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 16:19 08/03/01, Elya Kurktchi wrote: >I agree. However, on http://www.ssh.com website, it says that SSH, SSH >Secure Shell >and SSH Sentinel are registered trademarks or trademarks of SSH >Communications >Security Corp in the U.S. and/or other countries. Just because one has registered a trademark (in any country) does not mean the trademark claim is valid or invalid. It is easy to register anything as a trademark. The courts are the place where the validity of a trademark (and its limitations, if any) are ultimately established. Ran From owner-ietf-ssh@clinet.fi Thu Mar 8 17:34: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 RAA15702 for ; Thu, 8 Mar 2001 17:34:27 -0500 (EST) From: owner-ietf-ssh@clinet.fi Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA23555 for ietf-ssh-outgoing; Thu, 8 Mar 2001 22:45:04 +0200 Message-Id: <200103082045.WAA23555@mail.clinet.fi> Received: from unknown (p156-n67.dip.aha.ru [195.2.67.156]) by mail.clinet.fi (8.9.3/8.9.3) with SMTP id WAA23536; Thu, 8 Mar 2001 22:44:45 +0200 Date: вР, 8 ЛЮП 2001 20:10:02 Subject: хМРЕПЕЯМНЕ ОПЕДКНФЕМХЕ Sender: owner-ietf-ssh@clinet.fi Precedence: bulk сБЮФЮЕЛШЕ ЦНЯОНДЮ! оПХМНЯХЛ ХГБХМЕМХЪ, ЕЯКХ ДЮММНЕ ОХЯЭЛН ДКЪ бЮЯ МЕ ХЛЕЕР ЖЕММНЯРХ. дКЪ РЕУ ЙРН, ХЛЕЕР ОЕПЯНМЮКЭМШИ ЙНЛОЭЧРЕП, ХКХ ПЮАНРЮЕР Б ЯТЕПЕ ЙНЛОЭЧРЕПМНЦН АХГМЕЯЮ, ХКХ ОНЙЮ МЕ ХЛЕЕР, МН НОПЕДЕКЕММН ФЕКЮЕР, БНГЛНФМН, МЮЬЕ ОПЕДКНФЕМХЕ АСДЕР ХМРЕПЕЯМН. лШ ОПЕДКЮЦЮЕЛ ОНЯРЮБЙХ ЙНЛОЭЧРЕПНБ Х ЙНЛОКЕЙРСЧЫХУ Й МХЛ ОН ПЕЮКЭМН МХГЙХЛ ЖЕМЮЛ НОРНЛ Х Б ПНГМХЖС, ГЮ МЮКХВМШИ Х АЕГМЮКХВМШИ ПЮЯВЕР. оПНХГБНДХЛ ЛНДЕПМХГЮЖХЧ ОЕПЯНМЮКЭМНЦН ЙНЛОЭЧРЕПЮ Я ГЮВЕРНЛ ЯРНХЛНЯРХ ЯРЮПШУ ЙНЛОКЕЙРСЧЫХУ. нЯСЫЕЯРБКЪЕЛ ЯАНПЙС ЙНЛОЭЧРЕПЮ "ОНД ЙКЧВ" ОН ХМДХБХДСЮКЭМНЛС ГЮЙЮГС КЧАНИ ЯКНФМНЯРХ, Я ОНЯКЕДСЧЫХЛ ЦЮПЮМРХИМШЛ НАЯКСФХБЮМХЕЛ. оПЕДНЯРЮБКЪЕЛ БШЦНДМШЕ СЯКНБХЪ ДКЪ НОРНБШУ ОНЙСОЮРЕКЕИ: - ЬХПНЙХИ ЮЯЯНПРХЛЕМР РНБЮПЮ; - ХМДХБХДСЮКЭМШИ ОНДУНД Х ЯСЫЕЯРБЕММШЕ ЯЙХДЙХ; - НОЕПЮРХБМНЕ БШОНКМЕМХЕ ГЮЙЮГЮ; - ДНЯРЮБЙЮ, Х НРОПЮБКЕМХЕ ЦПСГНБ Б ПЕЦХНМШ; - КЭЦНРМНЕ ЦЮПЮМРХИМНЕ НАЯКСФХБЮМХЕ Х Р.Д. мЮЬ ОНКМШИ ОПЮИЯ-КХЯР бШ ЛНФМН ОНКСВХРЭ ОН ЩКЕЙРПНММНИ ОНВРЕ: ОПНЯРН ОНЬКХРЕ ОХЯЭЛН Я ОНЛЕРЙНИ "PRICE". йНМРЮЙРМШЕ РЕКЕТНМШ: (095) 747-72-31, 268-01-27, 268-46-33, ОМ-ОР Я 10 ДН 19, ЯА Я 11 ДН 17. мЮДЕЕЛЯЪ, ВРН МЮЬЕ ОПЕДКНФЕМХЕ МЕ НЯРЮБХР бЮЯ ПЮБМНДСЬМШЛХ. P.S. оПЕДНЯРЮБКЪЕЛ СЯКСЦХ ОН ПЮГАКНЙХПНБЮМХЧ, ПСЯХТХЙЮЖХХ, ЛНДЕПМХГЮЖХХ РЕКЕТНММШУ ЮООЮПЮРНБ GSM. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 8 19:21:34 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18465 for ; Thu, 8 Mar 2001 19:21:34 -0500 (EST) Received: (qmail 13061 invoked by uid 605); 9 Mar 2001 00:21:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13054 invoked from network); 9 Mar 2001 00:21:27 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 9 Mar 2001 00:21:27 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA03378 for ; Thu, 8 Mar 2001 16:21:26 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA15830 for ; Thu, 8 Mar 2001 19:21:25 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f290LJ908895 for ; Thu, 8 Mar 2001 19:21:19 -0500 (EST) Message-Id: <200103090021.f290LJ908895@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: summary of responses to "do we need to rename?" In-reply-to: Your message of "Tue, 06 Mar 2001 18:07:35 EST." <200103062307.f26N7Z903430@thunk.east.sun.com> Reply-to: sommerfeld@east.sun.com Date: Thu, 08 Mar 2001 19:21:19 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list I've reviewed both the messages to this list and the messages sent to me privately. I received 11 private messages on the topic. Three were variants of "wait and see"; of them, one suggested punting the problem up to the IESG/IAB, while two merely wanted to wait for the external trademark dispute to be resolved; these two also hoped that renaming would not be necessary. The remaining 8 were all strongly against renaming, and came from folks involved with at least three or four different implementations. Based on a combination of this input and the messages to the working group list over the past several days, I have to conclude that there is no possibility that we can achieve consensus in favor of renaming the protocol at this time. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 8 21:33:12 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20034 for ; Thu, 8 Mar 2001 21:33:11 -0500 (EST) Received: (qmail 8574 invoked by uid 605); 9 Mar 2001 02:33:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8567 invoked from network); 9 Mar 2001 02:33:05 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 9 Mar 2001 02:33:05 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA07066 for ; Thu, 8 Mar 2001 18:33:05 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id SAA02531 for ; Thu, 8 Mar 2001 18:33:05 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.11.3+Sun/8.11.3) with SMTP id f292X3v678582 for ; Thu, 8 Mar 2001 18:33:03 -0800 (PST) Message-Id: <200103090233.f292X3v678582@jurassic.eng.sun.com> Date: Thu, 8 Mar 2001 18:33:03 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: message lang tags verse SSH_MSG_KEXINIT To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: lAJ1qXZIaoa+0g6YHv0VRw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_26 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list In Section 6 of draft-ietf-secsh-filexfer-01.txt SSH_FXP_STATUS packet is defined as follows: The format of the data portion of the SSH_FXP_STATUS response is as follows: uint32 id uint32 error/status code string error message (ISO-10646 UTF-8 [RFC-2279]) string language tag (as defined in [RFC-1766]) This isn't the only place this occurs, it just happens to be the one I have infront of me at the moment and the one that prompted me to look into the issue, infact I believe it is consistant thought the drafts that language tags are sent with free format messages. My interpretation of the SSH_MSG_KEXINIT language negotiation was that the client and server would agree on a language and (if possible) send all futher communication in that language. As an example, an implmenation of this on unix might use setlocale() to change the locale of the client and server processes to be the negotiated language, thus automatically generating all messages in the appropriate language. Are the drafts saying that I should send the language tag the client and server agreed on at SSH_MSG_KEXINIT time as every message is sent ? So I guess I'm saying I don't understand the need for a language tag for individual messages when the language was negotiated at the SSH_MSG_KEXINIT packet stage. Any clarification greatly appreciated. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 8 21:50:00 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21103 for ; Thu, 8 Mar 2001 21:50:00 -0500 (EST) Received: (qmail 10897 invoked by uid 605); 9 Mar 2001 02:49:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10888 invoked from network); 9 Mar 2001 02:49:55 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 9 Mar 2001 02:49:55 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA26367 for ; Thu, 8 Mar 2001 18:49:54 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA06730; Thu, 8 Mar 2001 21:49:53 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f292nl909123; Thu, 8 Mar 2001 21:49:47 -0500 (EST) Message-Id: <200103090249.f292nl909123@thunk.east.sun.com> From: Bill Sommerfeld To: Darren Moffat cc: ietf-ssh@netbsd.org Subject: Re: message lang tags verse SSH_MSG_KEXINIT In-reply-to: Your message of "Thu, 08 Mar 2001 18:33:03 PST." <200103090233.f292X3v678582@jurassic.eng.sun.com> Reply-to: sommerfeld@east.sun.com Date: Thu, 08 Mar 2001 21:49:47 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > As an example, an implmenation of this on unix might use setlocale() > to change the locale of the client and server processes to be the > negotiated language, thus automatically generating all messages in > the appropriate language. > > Are the drafts saying that I should send the language tag the client > and server agreed on at SSH_MSG_KEXINIT time as every message is > sent ? one possible rationale has occurred to me: Even if the peers negotiated that all messages will be in, say, martian, the server might not have translations for all possible messages, and might need to send some messages in a "default" language, in which case it should be tagged as such so it gets displayed appropriately (e.g., not using martian letters). - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 8 22:03:28 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA21279 for ; Thu, 8 Mar 2001 22:03:28 -0500 (EST) Received: (qmail 12194 invoked by uid 605); 9 Mar 2001 03:03:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12187 invoked from network); 9 Mar 2001 03:03:23 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 9 Mar 2001 03:03:23 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA12693 for ; Thu, 8 Mar 2001 19:03:22 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id TAA06794 for ; Thu, 8 Mar 2001 19:03:23 -0800 (PST) Received: from spica1 (spica1.Eng.Sun.COM [129.146.81.114]) by jurassic.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f2933Ev681865; Thu, 8 Mar 2001 19:03:14 -0800 (PST) Date: Thu, 8 Mar 2001 19:01:49 -0800 (PST) From: Alok Aggarwal X-Sender: aalok@spica1 To: Bill Sommerfeld cc: Darren Moffat , ietf-ssh@netbsd.org Subject: Re: message lang tags verse SSH_MSG_KEXINIT In-Reply-To: <200103090249.f292nl909123@thunk.east.sun.com> Message-ID: "From: Alok.Aggarwal@Eng.Sun.COM" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list > one possible rationale has occurred to me: > > Even if the peers negotiated that all messages will be in, say, > martian, the server might not have translations for all possible > messages, and might need to send some messages in a "default" > language, in which case it should be tagged as such so it gets If the server didn't have support for, say, martian, it shouldn't have negotiated martian as the language with the client in first place. Although if it did initially agree on talking in martian then it should be capable of translating all the messages. Do you have a particular case in mind where what you are saying would supersede this? -Alok From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 9 00:41:24 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24402 for ; Fri, 9 Mar 2001 00:41:23 -0500 (EST) Received: (qmail 25303 invoked by uid 605); 9 Mar 2001 05:41:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25296 invoked from network); 9 Mar 2001 05:41:16 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 9 Mar 2001 05:41:16 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA06284; Thu, 8 Mar 2001 21:41:11 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA17709; Fri, 9 Mar 2001 00:41:11 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f295f5909545; Fri, 9 Mar 2001 00:41:05 -0500 (EST) Message-Id: <200103090541.f295f5909545@thunk.east.sun.com> From: Bill Sommerfeld To: RJ Atkinson cc: Tero Kivinen , ietf-ssh@netbsd.org Subject: Re: SSH-> Secure Shell renaming is *not* official. In-reply-to: Your message of "Thu, 08 Mar 2001 13:02:17 EST." <5.0.2.1.2.20010308125856.00a8c020@10.30.15.2> Reply-to: sommerfeld@east.sun.com Date: Fri, 09 Mar 2001 00:41:05 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > so there can be no question that my earlier misunderstanding > was wrong and that Bill's assertion is correct. Ran, Having reviewed your message, Tero clearly took your comment (about title choice) out of context. The initial choice of a document title or protocol name is indeed normally up to the document's original author, and I believe that that's what you were referring to in the message Tero summarized. However, as a working group forms a consensus around a document, the role of the wordsmith gradually changes from author to editor, and the amount of discretion available to the wordsmith decreases dramatically, particularly once a document gets to the Last Call stage. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 9 05:41:07 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10654 for ; Fri, 9 Mar 2001 05:41:06 -0500 (EST) Received: (qmail 13183 invoked by uid 605); 9 Mar 2001 10:41:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13173 invoked from network); 9 Mar 2001 10:41:00 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 9 Mar 2001 10:41:00 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id ADE6B82F524; Fri, 9 Mar 2001 11:40:58 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id LAA27931; Fri, 9 Mar 2001 11:40:57 +0100 (MET) To: Darren Moffat Cc: ietf-ssh@netbsd.org Subject: Re: message lang tags verse SSH_MSG_KEXINIT References: <200103090233.f292X3v678582@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 09 Mar 2001 11:40:57 +0100 In-Reply-To: Darren Moffat's message of "Thu, 8 Mar 2001 18:33:03 -0800 (PST)" Message-ID: Lines: 50 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Darren Moffat writes: > My interpretation of the SSH_MSG_KEXINIT language negotiation was that > the client and server would agree on a language and (if possible) send > all futher communication in that language. I think the problem is that languages aren't really negotiated the same way the other parameters in the SSH_MSG_KEXINIT are. languages This is a comma-separated list of language tags in order of preference [RFC-1766]. Both parties MAY ignore this list. If there are no language preferences, this list SHOULD be empty. (It is not entirely clear to me if an implementation is allowed to send a non-empty list, and at the same time ignore the other side's list, but it seems like a reasonable thing to do for an implementation that supports a single language). I think it is better to view the language list as user preferences than as negotiated values. One scenario that makes some sense to me is as follows: An SSH server doesn't have any preferences, so it sends an empty list for both "languages_client_to_server" and "languages_server_to_client". The client sends the list "sv,dk,en" (I'm not sure the syntax is right here, but the idea is that the client prefers messages in Swedish, Danish and English, in that order). Now, various modules and subsystems in the server generate messages, The modules may be written by different persons, come for different sources, or simply have different sets of languages available. Then, it would make sense for each module to use the language that it knows and which is first on the client's preference list. The end result is that not all messages use the same language. The indivudual language tags provides information. A more simple example is a server that sends an empty language list, and a client that sends a single language, say "sv". After the initial negotiation, the client has no way of knowing if the server will be honoring or ignoring the client's language preference. I agree the language negotiation is far from not crystal clear. Another minor point is that languages_client_to_server seems to be completely unused, I guess the mainr eason it's in the spec at all is symmetry. /Niels From owner-ietf-ssh@clinet.fi Fri Mar 9 08:57: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 IAA13810 for ; Fri, 9 Mar 2001 08:57:51 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id OAA11752 for ietf-ssh-outgoing; Fri, 9 Mar 2001 14:13:45 +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 OAA11741 for ; Fri, 9 Mar 2001 14:13:41 +0200 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 14bLm8-0001Id-00; Fri, 09 Mar 2001 12:13:40 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@clinet.fi Cc: Niels MЖller In-Reply-To: Subject: Re: message lang tags verse SSH_MSG_KEXINIT Message-Id: Date: Fri, 09 Mar 2001 12:13:40 +0000 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Niels MЖller wrote: > I agree the language negotiation is far from not crystal clear. > Another minor point is that languages_client_to_server seems to be > completely unused, I guess the main reason it's in the spec at all is > symmetry. Surely languages_client_to_server is used when the client is selecting a language to send a message to the server? This does happen in a few cases: consider the reason message sent in SSH_MSG_DISCONNECT. Cheers, Simon -- Simon Tatham "My heart bleeds. (That's how it works.)" -- Gareth Taylor From owner-ietf-ssh@clinet.fi Fri Mar 9 10:32:59 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 KAA17565 for ; Fri, 9 Mar 2001 10:32:58 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA02793 for ietf-ssh-outgoing; Fri, 9 Mar 2001 15:46:43 +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 PAA02790 for ; Fri, 9 Mar 2001 15:46: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 0948082F534; Fri, 9 Mar 2001 14:46:40 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id OAA14482; Fri, 9 Mar 2001 14:46:39 +0100 (MET) To: Simon Tatham Cc: ietf-ssh@clinet.fi Subject: Re: message lang tags verse SSH_MSG_KEXINIT References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 From: nisse@lysator.liu.se (Niels MЖller) Date: 09 Mar 2001 14:46:39 +0100 In-Reply-To: Simon Tatham's message of "Fri, 09 Mar 2001 12:13:40 +0000" 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 PAA02793 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA17565 Simon Tatham writes: > Niels MЖller wrote: > > I agree the language negotiation is far from not crystal clear. > > Another minor point is that languages_client_to_server seems to be > > completely unused, I guess the main reason it's in the spec at all is > > symmetry. ... > This does happen in a few cases: consider the reason message sent in > SSH_MSG_DISCONNECT. You're right, of course. Other cases are SSH_MSG_DEBUG and SSH_MSG_CHANNEL_OPEN_FAILURE. Those three are the only messages with language tags that I can find and which it makes sense for the client to send. So who is the target for these messages? The most likely answer is the sysadm of the server, so the server's preferences would equal the sysadm's. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 11 07:54:50 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09731 for ; Sun, 11 Mar 2001 07:54:49 -0500 (EST) Received: (qmail 20940 invoked by uid 605); 11 Mar 2001 12:54:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20933 invoked from network); 11 Mar 2001 12:54:40 -0000 Received: from faui02.informatik.uni-erlangen.de (msfriedl@131.188.30.102) by mail.netbsd.org with SMTP; 11 Mar 2001 12:54:40 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id NAA29395; Sun, 11 Mar 2001 13:54:09 +0100 (MET) Date: Sun, 11 Mar 2001 13:54:09 +0100 From: Markus Friedl To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: ietf-ssh@netbsd.org Subject: Re: Channel close logic, needs clarification? Message-ID: <20010311135409.A28526@faui02.informatik.uni-erlangen.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: ; from nisse@lysator.liu.se on Thu, Mar 08, 2001 at 05:31:58PM +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit On Thu, Mar 08, 2001 at 05:31:58PM +0100, Niels MЖller wrote: > Do we need to make some more detailed recommendations about channel > close logic? Different behaviour can cause interoperability problems. Yes, I think so :) I'm quoting all of your message since the context is important. > For instance, I have heard reports that when logging in with the > openssh client to a recent lshd, the client will hang after logout. Yes, I can reproduce this problem. Do other SSH client implementations hang, too? > I'll describe the logic that lsh and lshd uses. The basic rules are as > follows: > > 1. When SSH_MSG_CHANNEL_CLOSE is both sent and received, the channel > is killed. This is unconditionally required by the spec. So does OpenSSH. > 2. When SSH_MSG_CHANNEL_EOF is both sent and received, > SSH_MSG_CHANNEL_CLOSE is sent (unless it wasn't sent earlier). This > makes sense in almost all cases (and the only exceptions I'm aware > of seem out-of-scope here, they are related to proxying or > gatewaying channels). I'm not sure that you can rely on getting an EOF message. > So, what is left to decide is when to send SSH_MSG_CHANNEL_EOF. In > most cases, the decision is easy, but sometimes it is not. > > Consider the scenario where a client creates a session channel, gets a > login shell, and later exits the shell by explicitly typing exit or > logout. The result, at the server side, is > > * The server handles SIGCLD, discovers that its child process died, > and sends an SSH_MSG_CHANNEL_REQUEST "exit-status". This is of > course not done directly by the signal handler, but some time later > from the main loop. > > * The server gets an EOF condition on the process' stdout and stderr > (unless their are any grand children that still has one or the other > open). When EOF has occured on both stdout and stderr, the server > sends an SSH_MSG_CHANNEL_EOF. Same here (more or less). > The two events above can occur in more or less random order. The > server has not received any SSH_MSG_CHANNEL_EOF, so rule 2 doesn't > apply. The channel is still open. Same here. > What happens at the client? When the lsh client receives > an SSH_MSG_CHANNEL_REQUEST "exit-status" message, it decides that it's > time to stop talking, and it sends an SSH_MSG_CHANNEL_EOF. Now rule 2 > applies, and the channel gets closed properly. The OpenSSH client considers the "exit-status" message just informational and does _not_ send an EOF message back. > But appearantly, this logic doesn't work right when talking to the > openssh client. It doesn't send any SSH_MSG_CHANNEL_EOF, and to the > user it appears that the system just hangs. The OpenSSH server does not wait for the EOF message from the client. However, since the servers' child process is dead, the server decides that it will not write to more data to the 'stdin' handle and does _not_ wait for the EOF message from the client. This way the the channel is correctly closed. > Does the lsh behaviour above make sense to you? What are other > implementations doing? Yes, I'm really interested in what other SSH implementations are doing in these cases. -markus From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 11 10:54:05 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11411 for ; Sun, 11 Mar 2001 10:54:04 -0500 (EST) Received: (qmail 25982 invoked by uid 605); 11 Mar 2001 15:53:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25975 invoked from network); 11 Mar 2001 15:53:56 -0000 Received: from hutcs.cs.hut.fi (kivinen@130.233.192.7) by mail.netbsd.org with SMTP; 11 Mar 2001 15:53:56 -0000 Received: (from kivinen@localhost) by hutcs.cs.hut.fi (8.9.3/8.9.3) id RAA09734; Sun, 11 Mar 2001 17:53:45 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 11 Mar 2001 17:53:44 +0200 (EET) From: Tero Kivinen To: Theo de Raadt Cc: ietf-ssh@netbsd.org Subject: Re: SSH-> Secure Shell renaming is *not* official. In-Reply-To: <200103082112.f28LCgl01133@cvs.openbsd.org> References: <200103082112.f28LCgl01133@cvs.openbsd.org> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <15019.40421.715063.810297@hutcs.cs.hut.fi> Organization: Helsinki University of Technology X-Edit-Time: 7 min X-Total-Time: 6 min Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Theo de Raadt writes: > Tero Kivinen (who is apparently an > employee of ssh.com posting from another place probably so he will > look like an independent thinker) said: If I have understood correctly in the IETF people are always supposed to be individuals not representatives of the companies unless theyself states so. The reason I am posting from the different host is historic. I subscribed to the ssh mailing list while I still worked at the university and I haven't moved the ssh-mailing lists from there to fill up my work mailbox. I want to keep my work mailbox only for work related issues (currently mostly IPsec and IKE, not much secure shell). Anyways I don't think this issue has anything to do with the secure shell working group. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 11 12:54:00 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12503 for ; Sun, 11 Mar 2001 12:53:59 -0500 (EST) Received: (qmail 17205 invoked by uid 605); 11 Mar 2001 17:53:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17198 invoked from network); 11 Mar 2001 17:53:51 -0000 Received: from letku241.adsl.netsonic.fi (HELO liskot.org) (194.29.195.241) by mail.netbsd.org with SMTP; 11 Mar 2001 17:53:51 -0000 Received: (from sjl@localhost) by liskot.org (8.9.3/8.9.3) id TAA30101; Sun, 11 Mar 2001 19:52:49 +0200 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <15019.47985.154293.426860@liskot.org> Date: Sun, 11 Mar 2001 19:52:49 +0200 To: Markus Friedl Cc: =?iso-8859-1?Q?Niels_M=F6ller?= , ietf-ssh@netbsd.org Subject: Re: Channel close logic, needs clarification? In-Reply-To: <20010311135409.A28526@faui02.informatik.uni-erlangen.de> References: <20010311135409.A28526@faui02.informatik.uni-erlangen.de> X-Mailer: VM 6.87 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Markus Friedl, on March 11. 2001, wrote: : On Thu, Mar 08, 2001 at 05:31:58PM +0100, Niels MЖller wrote: : > For instance, I have heard reports that when logging in with the : > openssh client to a recent lshd, the client will hang after logout. : : Yes, I can reproduce this problem. Do other SSH client implementations : hang, too? I can reproduce this with our client and lshd version 1.1.7. : > I'll describe the logic that lsh and lshd uses. The basic rules are as : > follows: : > : > 1. When SSH_MSG_CHANNEL_CLOSE is both sent and received, the channel : > is killed. This is unconditionally required by the spec. : : So does OpenSSH. So does ssh2. : > What happens at the client? When the lsh client receives : > an SSH_MSG_CHANNEL_REQUEST "exit-status" message, it decides that it's : > time to stop talking, and it sends an SSH_MSG_CHANNEL_EOF. Now rule 2 : > applies, and the channel gets closed properly. : : The OpenSSH client considers the "exit-status" message just informational : and does _not_ send an EOF message back. ssh2 doesn't send an EOF message, either. : > But appearantly, this logic doesn't work right when talking to the : > openssh client. It doesn't send any SSH_MSG_CHANNEL_EOF, and to the : > user it appears that the system just hangs. : : The OpenSSH server does not wait for the EOF message from the client. : However, since the servers' child process is dead, the server decides : that it will not write to more data to the 'stdin' handle and does _not_ : wait for the EOF message from the client. This way the the channel is : correctly closed. sshd2 sends an SSH_MSG_CHANNEL_CLOSE when the shell exists for session channels. 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 Sun Mar 11 14: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 OAA13144 for ; Sun, 11 Mar 2001 14:04:34 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA23349 for ietf-ssh-outgoing; Sun, 11 Mar 2001 19:26:23 +0200 Received: from mx-out.daemonmail.net (mx-out.daemonmail.net [209.75.5.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA23346 for ; Sun, 11 Mar 2001 19:26:21 +0200 Received: from mx0.daemonmail.net (serv17.tierra.net [209.75.4.27]) by mx-out.daemonmail.net (8.9.3/8.9.3) with ESMTP id JAA15915 for ; Sun, 11 Mar 2001 09:26:20 -0800 (PST) (envelope-from user27090@mx0.daemonmail.net) Received: (from user27090@localhost) by mx0.daemonmail.net (8.9.3/8.9.3) id JAA23130; Sun, 11 Mar 2001 09:26:20 -0800 (PST) Date: Sun, 11 Mar 2001 09:26:20 -0800 (PST) Message-Id: <200103111726.JAA23130@mx0.daemonmail.net> To: ietf-ssh@clinet.fi From: "Sam Wallece" Subject: Re: direct marketing 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 TAA23349 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id OAA13144 МЫ ПОМОЖЕМ СДЕЛАТЬ ВАШ БИЗНЕС БОЛЕЕ ПРИБЫЛЬНЫМ. Для того, чтобы напрямую предложить своим потенциальным клиентам приобрести партию того или иного товара, стать Вашим дилером или дистрибьютором, убедить их воспользоваться Вашими услугами, пригласить на нужные Вам мероприятия (выставки, ярмарки, семинары, презентации, совещания, пресс-конференции) или поздравить с наступающими праздниками, необходимо иметь актуальную адресную информацию. НАЙДИТЕ ВАШИХ БУДУЩИХ ПОКУПАТЕЛЕЙ В НАШИХ БАЗАХ ДАННЫХ. Мы специализируемся на создании баз данных, справочников и рассылочных списков для телемаркетинга и почтовой рекламы, которые помогут Вам значительно повысить объемы продаж Вашей продукции или услуг, получить максимальную отдачу от уже существующих клиентов, возобновить связь с теми из них, которые уже воспользовались Вашими услугами и найти новых партнеров. если Вас заинтересовало наше предложение пишите на наш адрес samw@epatra.com From owner-ietf-ssh@clinet.fi Sun Mar 11 14:17: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 OAA13287 for ; Sun, 11 Mar 2001 14:17:46 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA24558 for ietf-ssh-outgoing; Sun, 11 Mar 2001 19:48:10 +0200 Received: from mx-out.daemonmail.net (mx-out.daemonmail.net [209.75.5.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA24555 for ; Sun, 11 Mar 2001 19:48:08 +0200 Received: from mx0.daemonmail.net (serv17.tierra.net [209.75.4.27]) by mx-out.daemonmail.net (8.9.3/8.9.3) with ESMTP id JAA31486 for ; Sun, 11 Mar 2001 09:48:06 -0800 (PST) (envelope-from user27090@mx0.daemonmail.net) Received: (from user27090@localhost) by mx0.daemonmail.net (8.9.3/8.9.3) id JAA33263; Sun, 11 Mar 2001 09:48:03 -0800 (PST) Date: Sun, 11 Mar 2001 09:48:03 -0800 (PST) Message-Id: <200103111748.JAA33263@mx0.daemonmail.net> To: ietf-ssh@clinet.fi From: "Sam Wallece" Subject: Re: direct marketing 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 TAA24558 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id OAA13287 МЫ ПОМОЖЕМ СДЕЛАТЬ ВАШ БИЗНЕС БОЛЕЕ ПРИБЫЛЬНЫМ. Для того, чтобы напрямую предложить своим потенциальным клиентам приобрести партию того или иного товара, стать Вашим дилером или дистрибьютором, убедить их воспользоваться Вашими услугами, пригласить на нужные Вам мероприятия (выставки, ярмарки, семинары, презентации, совещания, пресс-конференции) или поздравить с наступающими праздниками, необходимо иметь актуальную адресную информацию. НАЙДИТЕ ВАШИХ БУДУЩИХ ПОКУПАТЕЛЕЙ В НАШИХ БАЗАХ ДАННЫХ. Мы специализируемся на создании баз данных, справочников и рассылочных списков для телемаркетинга и почтовой рекламы, которые помогут Вам значительно повысить объемы продаж Вашей продукции или услуг, получить максимальную отдачу от уже существующих клиентов, возобновить связь с теми из них, которые уже воспользовались Вашими услугами и найти новых партнеров. если Вас заинтересовало наше предложение пишите на наш адрес samw@epatra.ru From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 11 15:43:37 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13953 for ; Sun, 11 Mar 2001 15:43:36 -0500 (EST) Received: (qmail 16187 invoked by uid 605); 11 Mar 2001 20:43:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16180 invoked from network); 11 Mar 2001 20:43:28 -0000 Received: from ip212-226-160-97.adsl.kpnqwest.fi (HELO mystery.acr.fi) (212.226.160.97) by mail.netbsd.org with SMTP; 11 Mar 2001 20:43:28 -0000 Received: from localhost (ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) with ESMTP id WAA12578; Sun, 11 Mar 2001 22:41:02 +0200 X-Authentication-Warning: mystery.acr.fi: ylo owned process doing -bs Date: Sun, 11 Mar 2001 22:41:00 +0200 (EET) From: Tatu Ylonen X-Sender: ylo@mystery.acr.fi To: Markus Friedl cc: =?iso-8859-1?Q?Niels_M=F6ller?= , ietf-ssh@netbsd.org Subject: Re: Channel close logic, needs clarification? In-Reply-To: <20010311135409.A28526@faui02.informatik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list > > 2. When SSH_MSG_CHANNEL_EOF is both sent and received, > > SSH_MSG_CHANNEL_CLOSE is sent (unless it wasn't sent earlier). This > > makes sense in almost all cases (and the only exceptions I'm aware > > of seem out-of-scope here, they are related to proxying or > > gatewaying channels). > > I'm not sure that you can rely on getting an EOF message. > > > So, what is left to decide is when to send SSH_MSG_CHANNEL_EOF. In > > most cases, the decision is easy, but sometimes it is not. The intention here was that the EOF message simply means "I am not going to send more". It is similar to TCP half-close. However, SSH_MSG_CHANNEL_EOF alone is not intended to initiate closing down the channel. However, in some situations it is possible that both sides determine simulatenously that they will not be sending more. A side should initiate closing the channel (by sending SSH_MSG_CHANNEL_CLOSE) when if it has both sent and received EOF. It is legal to send other messages, e.g. channel requests, after both sending and receing EOF. However, it is illegal to send ANYTHING after sending SSH_MSG_CHANNEL_CLOSE. > The OpenSSH client considers the "exit-status" message just informational > and does _not_ send an EOF message back. This is correct behavior. It is intended as simply a notification. > > But appearantly, this logic doesn't work right when talking to the > > openssh client. It doesn't send any SSH_MSG_CHANNEL_EOF, and to the > > user it appears that the system just hangs. > > The OpenSSH server does not wait for the EOF message from the client. > However, since the servers' child process is dead, the server decides > that it will not write to more data to the 'stdin' handle and does _not_ > wait for the EOF message from the client. This way the the channel is > correctly closed. It is legal to send SSH_MSG_CHANNEL_CLOSE before receiving/sending EOF (it is illegal to send anything, including EOF, after sending SSH_MSG_CHANNEL_CLOSE). The channel data structures can be freed when CLOSE has been both sent and received (in either order). Tatu SSH Communications Security http://www.ssh.com/ SSH IPSEC Toolkit http://www.ipsec.com/ SSH Secure Shell http://www.ssh.com/products/ssh From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 11 17:02:23 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14632 for ; Sun, 11 Mar 2001 17:02:23 -0500 (EST) Received: (qmail 10278 invoked by uid 605); 11 Mar 2001 22:02:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10271 invoked from network); 11 Mar 2001 22:02:15 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 11 Mar 2001 22:02:15 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 7293782F4B3; Sun, 11 Mar 2001 23:02:13 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id XAA02847; Sun, 11 Mar 2001 23:02:13 +0100 (MET) To: Markus Friedl Cc: ietf-ssh@netbsd.org Subject: Re: Channel close logic, needs clarification? References: <20010311135409.A28526@faui02.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit From: nisse@lysator.liu.se (Niels MЖller) Date: 11 Mar 2001 23:02:12 +0100 In-Reply-To: Markus Friedl's message of "Sun, 11 Mar 2001 13:54:09 +0100" Message-ID: Lines: 73 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Markus Friedl writes: > On Thu, Mar 08, 2001 at 05:31:58PM +0100, Niels MЖller wrote: > > > 2. When SSH_MSG_CHANNEL_EOF is both sent and received, > > SSH_MSG_CHANNEL_CLOSE is sent (unless it wasn't sent earlier). This > > makes sense in almost all cases (and the only exceptions I'm aware > > of seem out-of-scope here, they are related to proxying or > > gatewaying channels). > > I'm not sure that you can rely on getting an EOF message. I'm not sure what you're saying here. I'm saying that the "normal" reason the channel close process is initiated is that CHANNEL_EOF is both sent and received. There are other, less "normal", reasons. For instance, if lsh or lshd receives a CHANNEL_CLOSE, that is not preceded by a CHANNEL_EOF, it displays a warning message "unexpected channel close", and then it replies with CHANNEL_CLOSE so that the channel goes away. > > What happens at the client? When the lsh client receives > > an SSH_MSG_CHANNEL_REQUEST "exit-status" message, it decides that it's > > time to stop talking, and it sends an SSH_MSG_CHANNEL_EOF. Now rule 2 > > applies, and the channel gets closed properly. > > The OpenSSH client considers the "exit-status" message just informational > and does _not_ send an EOF message back. That seems reasonable (as the client can't really know if the server implements exit-status), but on the other hand that message is the only reliable hint the client gets that it will not be able to send any more data. The alternative is for the server to send CHANNEL_CLOSE after the exit-status message. If I understand you and Sami correctly, that is what both the ssh2 and openssh servers do. But the server can't do that *immediately* after process death, because then it may lose some of the data on stdout/stderr. Rather, the rule has to be that the server sends CHANNEL_CLOSE after *all* these events have occured: * Process death * EOF on stderr * EOF on stdout Is that what you are doing? I considered doing that in lshd, and the reason I didn't was the following scenario: 1. Client sends CHANNEL_EOF 2. The process' stdin is closed by the server. 3. The process dies, and its stderr and stdout is closed automatically by the system. 4. The server happens to notice the EOF conditions before it notices the process death. So the server sends CHANNEL_EOF. 5. Now, the "CHANNEL_EOF both sent and received" kicks in, and the server sends CHANNEL_CLOSE. Problem: No exit-status is ever sent (and the client exits with the "default exit code" of 17, so my lsh testsuite at least has a chance to notice the problem). So in addition to the conditions above, one needs a special exception to the "CHANNEL_EOF both sent and received" rule, which makes things even more complex. Is this still the Right Way to go? Suggestions? /Niels From owner-ietf-ssh@clinet.fi Sun Mar 11 18:22: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 SAA15378 for ; Sun, 11 Mar 2001 18:22:22 -0500 (EST) From: owner-ietf-ssh@clinet.fi Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA02945 for ietf-ssh-outgoing; Sun, 11 Mar 2001 22:54:19 +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 WAA02939; Sun, 11 Mar 2001 22:54:15 +0200 Received: from unknown (unknown [195.146.80.8]) by smtp1.clinet.fi (Postfix) with SMTP id 147EB28D; Sun, 11 Mar 2001 22:54:11 +0200 (EET) Date: бЯ, 11 ЛЮП 2001 20:19:31 Subject: хМРЕПЕЯМНЕ ОПЕДКНФЕМХЕ Message-Id: <20010311205411.147EB28D@smtp1.clinet.fi> To: undisclosed-recipients:; Sender: owner-ietf-ssh@clinet.fi Precedence: bulk сБЮФЮЕЛШЕ ЦНЯОНДЮ! оПХМНЯХЛ ХГБХМЕМХЪ, ЕЯКХ ДЮММНЕ ОХЯЭЛН ДКЪ бЮЯ МЕ ХЛЕЕР ЖЕММНЯРХ. дКЪ РЕУ ЙРН, ХЛЕЕР ОЕПЯНМЮКЭМШИ ЙНЛОЭЧРЕП, ХКХ ПЮАНРЮЕР Б ЯТЕПЕ ЙНЛОЭЧРЕПМНЦН АХГМЕЯЮ, ХКХ ОНЙЮ МЕ ХЛЕЕР, МН НОПЕДЕКЕММН ФЕКЮЕР, БНГЛНФМН, МЮЬЕ ОПЕДКНФЕМХЕ АСДЕР ХМРЕПЕЯМН. лШ ОПЕДКЮЦЮЕЛ ОНЯРЮБЙХ ЙНЛОЭЧРЕПНБ Х ЙНЛОКЕЙРСЧЫХУ Й МХЛ ОН ПЕЮКЭМН МХГЙХЛ ЖЕМЮЛ НОРНЛ Х Б ПНГМХЖС, ГЮ МЮКХВМШИ Х АЕГМЮКХВМШИ ПЮЯВЕР. оПНХГБНДХЛ ЛНДЕПМХГЮЖХЧ ОЕПЯНМЮКЭМНЦН ЙНЛОЭЧРЕПЮ Я ГЮВЕРНЛ ЯРНХЛНЯРХ ЯРЮПШУ ЙНЛОКЕЙРСЧЫХУ. нЯСЫЕЯРБКЪЕЛ ЯАНПЙС ЙНЛОЭЧРЕПЮ "ОНД ЙКЧВ" ОН ХМДХБХДСЮКЭМНЛС ГЮЙЮГС КЧАНИ ЯКНФМНЯРХ, Я ОНЯКЕДСЧЫХЛ ЦЮПЮМРХИМШЛ НАЯКСФХБЮМХЕЛ. оПЕДНЯРЮБКЪЕЛ БШЦНДМШЕ СЯКНБХЪ ДКЪ НОРНБШУ ОНЙСОЮРЕКЕИ: - ЬХПНЙХИ ЮЯЯНПРХЛЕМР РНБЮПЮ; - ХМДХБХДСЮКЭМШИ ОНДУНД Х ЯСЫЕЯРБЕММШЕ ЯЙХДЙХ; - НОЕПЮРХБМНЕ БШОНКМЕМХЕ ГЮЙЮГЮ; - ДНЯРЮБЙЮ, Х НРОПЮБКЕМХЕ ЦПСГНБ Б ПЕЦХНМШ; - КЭЦНРМНЕ ЦЮПЮМРХИМНЕ НАЯКСФХБЮМХЕ Х Р.Д. мЮЬ ОНКМШИ ОПЮИЯ-КХЯР бШ ЛНФМН ОНКСВХРЭ ОН ЩКЕЙРПНММНИ ОНВРЕ: ОПНЯРН ОНЬКХРЕ ОХЯЭЛН Я ОНЛЕРЙНИ "PRICE". йНМРЮЙРМШЕ РЕКЕТНМШ: (095) 747-72-31, 268-01-27, 268-46-33, ОМ-ОР Я 10 ДН 19, ЯА Я 11 ДН 17. мЮДЕЕЛЯЪ, ВРН МЮЬЕ ОПЕДКНФЕМХЕ МЕ НЯРЮБХР бЮЯ ПЮБМНДСЬМШЛХ. P.S. оПЕДНЯРЮБКЪЕЛ СЯКСЦХ ОН ПЮГАКНЙХПНБЮМХЧ, ПСЯХТХЙЮЖХХ, ЛНДЕПМХГЮЖХХ РЕКЕТНММШУ ЮООЮПЮРНБ GSM. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 11 18:32:49 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15443 for ; Sun, 11 Mar 2001 18:32:48 -0500 (EST) Received: (qmail 134 invoked by uid 605); 11 Mar 2001 23:32:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 127 invoked from network); 11 Mar 2001 23:32:37 -0000 Received: from muedi4-145-253-166-099.arcor-ip.net (HELO folly.informatik.uni-erlangen.de) (@145.253.166.99) by mail.netbsd.org with SMTP; 11 Mar 2001 23:32:37 -0000 Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 13087103D; Mon, 12 Mar 2001 00:32:13 +0100 (CET) Date: Mon, 12 Mar 2001 00:32:13 +0100 From: Markus Friedl To: Tatu Ylonen Cc: =?iso-8859-1?Q?Niels_M=F6ller?= , ietf-ssh@netbsd.org Subject: Re: Channel close logic, needs clarification? Message-ID: <20010312003213.B28291@folly> References: <20010311135409.A28526@faui02.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ylo@ssh.com on Sun, Mar 11, 2001 at 10:41:00PM +0200 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sun, Mar 11, 2001 at 10:41:00PM +0200, Tatu Ylonen wrote: > It is legal to send other messages, e.g. channel requests, after both > sending and receing EOF. Is it legal to send SSH_MSG_CHANNEL_EXTENDED_DATA after a EOF is sent? I asume that the EOF refers to both SSH_MSG_CHANNEL_DATA and SSH_MSG_CHANNEL_EXTENDED_DATA. > > The OpenSSH server does not wait for the EOF message from the client. > > However, since the servers' child process is dead, the server decides > > that it will not write to more data to the 'stdin' handle and does _not_ > > wait for the EOF message from the client. This way the the channel is > > correctly closed. > > It is legal to send SSH_MSG_CHANNEL_CLOSE before receiving/sending EOF I think this is a typo. Is it really legal to send a SSH_MSG_CHANNEL_CLOSE before a SSH_MSG_CHANNEL_EOF is sent? -markus From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 11 18:41:32 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15631 for ; Sun, 11 Mar 2001 18:41:32 -0500 (EST) Received: (qmail 1305 invoked by uid 605); 11 Mar 2001 23:41:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1297 invoked from network); 11 Mar 2001 23:41:24 -0000 Received: from muedi4-145-253-166-099.arcor-ip.net (HELO folly.informatik.uni-erlangen.de) (@145.253.166.99) by mail.netbsd.org with SMTP; 11 Mar 2001 23:41:24 -0000 Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 72FEA103D; Mon, 12 Mar 2001 00:41:06 +0100 (CET) Date: Mon, 12 Mar 2001 00:41:06 +0100 From: Markus Friedl To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: ietf-ssh@netbsd.org Subject: Re: Channel close logic, needs clarification? Message-ID: <20010312004106.C28291@folly> References: <20010311135409.A28526@faui02.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from nisse@lysator.liu.se on Sun, Mar 11, 2001 at 11:02:12PM +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit On Sun, Mar 11, 2001 at 11:02:12PM +0100, Niels MЖller wrote: > > I'm not sure that you can rely on getting an EOF message. > > I'm not sure what you're saying here. I'm saying that the "normal" > reason the channel close process is initiated is that CHANNEL_EOF is > both sent and received. There are other, less "normal", reasons. For > instance, if lsh or lshd receives a CHANNEL_CLOSE, that is not > preceded by a CHANNEL_EOF, it displays a warning message "unexpected > channel close", I don't think this is correct. A CLOSE without an EOF is completely legal in the SSH 2 protocol. > and then it replies with CHANNEL_CLOSE so that the > channel goes away. > > > > What happens at the client? When the lsh client receives > > > an SSH_MSG_CHANNEL_REQUEST "exit-status" message, it decides that it's > > > time to stop talking, and it sends an SSH_MSG_CHANNEL_EOF. Now rule 2 > > > applies, and the channel gets closed properly. > > > > The OpenSSH client considers the "exit-status" message just informational > > and does _not_ send an EOF message back. > > That seems reasonable (as the client can't really know if the server > implements exit-status), but on the other hand that message is the > only reliable hint the client gets that it will not be able to send > any more data. > > The alternative is for the server to send CHANNEL_CLOSE after the > exit-status message. If I understand you and Sami correctly, that is > what both the ssh2 and openssh servers do. When the login shell dies, the OpenSSH server sends the CLOSE message after: 1) all data is read from the pipe/socket (that connects the server to the login-shell) and 2) this data is sent to the client. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 11 20:21:16 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16353 for ; Sun, 11 Mar 2001 20:21:16 -0500 (EST) Received: (qmail 18014 invoked by uid 605); 12 Mar 2001 01:21:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18007 invoked from network); 12 Mar 2001 01:21:07 -0000 Received: from letku241.adsl.netsonic.fi (HELO liskot.org) (194.29.195.241) by mail.netbsd.org with SMTP; 12 Mar 2001 01:21:07 -0000 Received: (from sjl@localhost) by liskot.org (8.9.3/8.9.3) id DAA31003; Mon, 12 Mar 2001 03:20:12 +0200 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15020.9292.163766.373434@liskot.org> Date: Mon, 12 Mar 2001 03:20:12 +0200 To: Markus Friedl Cc: =?iso-8859-1?Q?Niels_M=F6ller?= , ietf-ssh@netbsd.org Subject: Re: Channel close logic, needs clarification? In-Reply-To: <20010312004106.C28291@folly> References: <20010311135409.A28526@faui02.informatik.uni-erlangen.de> <20010312004106.C28291@folly> X-Mailer: VM 6.87 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Markus Friedl, on March 12. 2001, wrote: : > I'm not sure what you're saying here. I'm saying that the "normal" : > reason the channel close process is initiated is that CHANNEL_EOF is : > both sent and received. There are other, less "normal", reasons. For : > instance, if lsh or lshd receives a CHANNEL_CLOSE, that is not : > preceded by a CHANNEL_EOF, it displays a warning message "unexpected : > channel close", : : I don't think this is correct. A CLOSE without an EOF is completely : legal in the SSH 2 protocol. I agree with Markus. : When the login shell dies, the OpenSSH server sends : the CLOSE message after: : 1) all data is read from the pipe/socket (that connects the : server to the login-shell) and : 2) this data is sent to the client. Ditto in ssh2. 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 ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 12 04:23:48 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06107 for ; Mon, 12 Mar 2001 04:23:47 -0500 (EST) Received: (qmail 2871 invoked by uid 605); 12 Mar 2001 09:23:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2864 invoked from network); 12 Mar 2001 09:23:33 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 12 Mar 2001 09:23:33 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id A6D6F82F407; Mon, 12 Mar 2001 10:23:31 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id KAA12614; Mon, 12 Mar 2001 10:23:31 +0100 (MET) To: Sami Lehtinen Cc: Markus Friedl , ietf-ssh@netbsd.org Subject: Re: Channel close logic, needs clarification? References: <20010311135409.A28526@faui02.informatik.uni-erlangen.de> <20010312004106.C28291@folly> <15020.9292.163766.373434@liskot.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 12 Mar 2001 10:23:30 +0100 In-Reply-To: Sami Lehtinen's message of "Mon, 12 Mar 2001 03:20:12 +0200" Message-ID: Lines: 14 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Sami Lehtinen writes: > : I don't think this is correct. A CLOSE without an EOF is completely > : legal in the SSH 2 protocol. > > I agree with Markus. I understand that it is legal, I just think that it is unusual. If I change the lsh and lshd behaviour to match ssh and openssh, it will still not send CLOSE without first sending an EOF. But it will sometimes send CLOSE without having _received_ any EOF. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 12 04:33:03 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06237 for ; Mon, 12 Mar 2001 04:33:01 -0500 (EST) Received: (qmail 4267 invoked by uid 605); 12 Mar 2001 09:32:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4260 invoked from network); 12 Mar 2001 09:32:46 -0000 Received: from ixion.tartarus.org (195.153.205.133) by mail.netbsd.org with SMTP; 12 Mar 2001 09:32:46 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 14cOh2-0008Mt-00; Mon, 12 Mar 2001 09:32:44 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <20010312003213.B28291@folly> Subject: Re: Channel close logic, needs clarification? Message-Id: Date: Mon, 12 Mar 2001 09:32:44 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list > On Sun, Mar 11, 2001 at 10:41:00PM +0200, Tatu Ylonen wrote: >> It is legal to send SSH_MSG_CHANNEL_CLOSE before receiving/sending EOF Markus Friedl wrote: > I think this is a typo. Is it really legal to send > a SSH_MSG_CHANNEL_CLOSE before a SSH_MSG_CHANNEL_EOF is sent? I think Tatu meant `without', rather than `before': it's legal to send SSH_MSG_CHANNEL_CLOSE _without_ having received or sent EOF. It is not legal to send EOF once you've done that. Cheers, Simon -- Simon Tatham What do we want? ROT13! When do we want it? ABJ! From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 12 12:02:03 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14112 for ; Mon, 12 Mar 2001 12:02:02 -0500 (EST) Received: (qmail 6483 invoked by uid 605); 12 Mar 2001 17:01:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6476 invoked from network); 12 Mar 2001 17:01:53 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 12 Mar 2001 17:01:53 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA13481; Mon, 12 Mar 2001 09:01:47 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28110; Mon, 12 Mar 2001 12:01:46 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f2CH1f910623; Mon, 12 Mar 2001 12:01:41 -0500 (EST) Message-Id: <200103121701.f2CH1f910623@thunk.east.sun.com> From: Bill Sommerfeld To: Markus Friedl cc: =?iso-8859-1?Q?Niels_M=F6ller?= , ietf-ssh@netbsd.org Subject: Re: Channel close logic, needs clarification? In-reply-to: Your message of "Mon, 12 Mar 2001 00:41:06 +0100." <20010312004106.C28291@folly> Reply-to: sommerfeld@east.sun.com Date: Mon, 12 Mar 2001 12:01:40 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > When the login shell dies, the OpenSSH server sends > the CLOSE message after: > 1) all data is read from the pipe/socket (that connects the > server to the login-shell) and > 2) this data is sent to the client. Just to clarify, is this "all immediately available data" (what you can get from a non-blocking read) or "all data until an EOF indication is received"? - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 12 12:09:20 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14281 for ; Mon, 12 Mar 2001 12:09:19 -0500 (EST) Received: (qmail 8338 invoked by uid 605); 12 Mar 2001 17:09:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8331 invoked from network); 12 Mar 2001 17:09:14 -0000 Received: from faui02.informatik.uni-erlangen.de (msfriedl@131.188.30.102) by mail.netbsd.org with SMTP; 12 Mar 2001 17:09:14 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id SAA26128; Mon, 12 Mar 2001 18:09:08 +0100 (MET) Date: Mon, 12 Mar 2001 18:09:08 +0100 From: Markus Friedl To: Bill Sommerfeld Cc: =?iso-8859-1?Q?Niels_M=F6ller?= , ietf-ssh@netbsd.org Subject: Re: Channel close logic, needs clarification? Message-ID: <20010312180908.B21452@faui02.informatik.uni-erlangen.de> References: <20010312004106.C28291@folly> <200103121701.f2CH1f910623@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <200103121701.f2CH1f910623@thunk.east.sun.com>; from sommerfeld@east.sun.com on Mon, Mar 12, 2001 at 12:01:40PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Mar 12, 2001 at 12:01:40PM -0500, Bill Sommerfeld wrote: > > When the login shell dies, the OpenSSH server sends > > the CLOSE message after: > > 1) all data is read from the pipe/socket (that connects the > > server to the login-shell) and > > 2) this data is sent to the client. > > Just to clarify, is this "all immediately available data" (what you > can get from a non-blocking read) or "all data until an EOF indication > is received"? OpenSSH's SSH v2 implementation reads until it gets EOF or an error. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 12 14:20:28 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17562 for ; Mon, 12 Mar 2001 14:20:27 -0500 (EST) Received: (qmail 12795 invoked by uid 605); 12 Mar 2001 19:20:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12788 invoked from network); 12 Mar 2001 19:20:18 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 12 Mar 2001 19:20:18 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08142 for ; Mon, 12 Mar 2001 11:20:16 -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 OAA16810 for ; Mon, 12 Mar 2001 14:20:16 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f2CJKA910817 for ; Mon, 12 Mar 2001 14:20:10 -0500 (EST) Message-Id: <200103121920.f2CJKA910817@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: civility in the working group. In-reply-to: Your message of "Sun, 11 Mar 2001 17:53:44 +0200." <15019.40421.715063.810297@hutcs.cs.hut.fi> Reply-to: sommerfeld@east.sun.com Date: Mon, 12 Mar 2001 14:20:10 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Tero Kivinen writes: > If I have understood correctly in the IETF people are always supposed > to be individuals not representatives of the companies unless theyself > states so. Tero is correct. Participants in the IETF should be presumed to be speaking for themselves, not speaking for their employers. In this case, it is silly for anyone to think that the identity and affiliation of one of the authors of the core SSH drafts is unknown to participants in the working group. Let's keep things civil, folks. If you feel that someone has made inappropriate remarks about you or another participant, let me know via private email and I'll make an attempt to deal with the situation. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 12 15:31:04 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19579 for ; Mon, 12 Mar 2001 15:31:03 -0500 (EST) Received: (qmail 523 invoked by uid 605); 12 Mar 2001 20:30:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 516 invoked from network); 12 Mar 2001 20:30:53 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 12 Mar 2001 20:30:53 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA06111 for ; Mon, 12 Mar 2001 12:30:52 -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 PAA29880 for ; Mon, 12 Mar 2001 15:30:51 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f2CKUj911210 for ; Mon, 12 Mar 2001 15:30:45 -0500 (EST) Message-Id: <200103122030.f2CKUj911210@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: Secure Shell (secsh) WG meeting agenda requests.. Reply-to: sommerfeld@east.sun.com Date: Mon, 12 Mar 2001 15:30:45 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list We will be meeting next monday at the minneapolis ietf meeting. I'd like to see discussion on our current drafts: Core drafts: - issues from the last call (I'll be sending out a list shortly) Others: - sftp - pubkey file format - D-H group exchange - kbd-interactive - gssapi authentication. if you have any other suggested topics for the agenda, send them to me. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 12 17:35:44 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23230 for ; Mon, 12 Mar 2001 17:35:43 -0500 (EST) Received: (qmail 7175 invoked by uid 605); 12 Mar 2001 22:35:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7168 invoked from network); 12 Mar 2001 22:35:36 -0000 Received: from mail1.panix.com (166.84.0.212) by mail.netbsd.org with SMTP; 12 Mar 2001 22:35:36 -0000 Received: from panix1.panix.com (panix1.panix.com [166.84.0.226]) by mail1.panix.com (Postfix) with ESMTP id 66B6E48D00; Mon, 12 Mar 2001 17:31:30 -0500 (EST) Received: (from tls@localhost) by panix1.panix.com (8.11.0/8.7.1/PanixN1.0) id f2CMVUs02810; Mon, 12 Mar 2001 17:31:30 -0500 (EST) Date: Mon, 12 Mar 2001 17:31:30 -0500 From: Thor Lancelot Simon To: Markus Friedl , ssh@clinet.fi, openssh-unix-dev@mindrot.org Cc: ietf-ssh@netbsd.org Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems Message-ID: <20010312173130.A2713@rek.tjls.com> Reply-To: tls@rek.tjls.com References: <20010312144035.A1174@faui02.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010312144035.A1174@faui02.informatik.uni-erlangen.de>; from Markus.Friedl@informatik.uni-erlangen.de on Mon, Mar 12, 2001 at 02:40:35PM +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Mar 12, 2001 at 02:40:35PM +0100, Markus Friedl wrote: > On Mon, Mar 12, 2001 at 08:31:48AM -0500, Jeffrey Altman wrote: > > > In this case (i.e. in the case of wanting to "ftp" over SSH) the issue > > > is with the stupid user interface. Naive users are looking for some SSH > > > file copying tool that works just like their FTP clients, i.e. where > > > they can see a list of files on the server and click/drag/whatever them > > > to effect the copy. > > > > Why do you need to use FTP over SSH when FTP is "securable" using any > > number of methods? The most common methods are > > > > SSL/TLS > > > > GSSAPI > > > > Kerberos > > > > SRP > > > > > > When using any of these methods both the command and data channels > > used by FTP are authenticated, encrypted and integrity checked. In > > other words, they are secure. > > so does SFTP. so what's the point? I think the point is that the development of the SSH protocol has involved a great deal of reinvention of wheels. Some people think that this is regrettable and wish that the SSH working group paid a bit more attention to integration with other IETF protocols rather than rampaging ahead inventing new ones. I personally think that the SFTP protocol is a pretty gratuitous addition; a whole lot of complexity, and it really doesn't buy you much. But then again, I think that reinventing most of what TLS does for the SSHv2 transport layer instead of politely asking the TLS folks for a record-oriented interface was rather silly, too. We have those things now; there's not much point thinking about what we _could_ have done. However, it's a valid question to ask what the point of implementing something like SFTP in _any particular implementation of other bits of the SSH suite_ is; I don't really think that the "anonymous" bits of its function are well served by its design, worse served, in fact, than by simply using FTP secured with TLS, GSSAPI, or other standard methods, and it's massive overkill compared to the simple BSD-rcp protocol used by the old "scp" application, when that's going to be 99% of what it's used for in the real world, ISTM. Ergo, a small, lightweight SSH implementation, even one that did v2, might quite reasonably choose to *not* implement SFTP; to me, at least, it sure seems to bring very little to the table in return for a lot of increase in code size and maintenance. But that's just my point of view; clearly some people have put a lot of work into advancing SFTP and they must have a more substantial use for it than I do. -- Thor Lancelot Simon tls@rek.tjls.com And now he couldn't remember when this passion had flown, leaving him so foolish and bewildered and astray: can any man? William Styron From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 12 18:13:06 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24139 for ; Mon, 12 Mar 2001 18:13:05 -0500 (EST) Received: (qmail 19540 invoked by uid 605); 12 Mar 2001 23:13:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19528 invoked from network); 12 Mar 2001 23:13:00 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 12 Mar 2001 23:13:00 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 3E05282F559; Tue, 13 Mar 2001 00:12:50 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id AAA15881; Tue, 13 Mar 2001 00:12:46 +0100 (MET) To: tls@rek.tjls.com Cc: Markus Friedl , ssh@clinet.fi, openssh-unix-dev@mindrot.org, ietf-ssh@netbsd.org Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems References: <20010312144035.A1174@faui02.informatik.uni-erlangen.de> <20010312173130.A2713@rek.tjls.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 13 Mar 2001 00:12:46 +0100 In-Reply-To: Thor Lancelot Simon's message of "Mon, 12 Mar 2001 17:31:30 -0500" Message-ID: Lines: 34 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Thor Lancelot Simon writes: > But then again, I think that reinventing most of what TLS does for > the SSHv2 transport layer instead of politely asking the TLS folks > for a record-oriented interface was rather silly, too. I've implemented both TLS (ok, it was actually SSL version 3 back then) and ssh2. I'd say the ssh2 transport is better. It's cleaner, more secure, more flexible, and its spec is a lot easier to understand. And then a lot of the complexity in ssh is in the connection layer, which isn't comparable to TLS in any way. > Ergo, a small, lightweight SSH implementation, even one that did v2, > might quite reasonably choose to *not* implement SFTP; to me, at least, > it sure seems to bring very little to the table in return for a lot > of increase in code size and maintenance. The ssh implementation and the sftp implementation are quite independent. They have a common origin and uses a common language and terminology, but you can run the sftp over any secure bidirectional connection. The only feature in the ssh core protocol that makes sftp easier is the subsystem request that lets a client start a program without knowing an exact path, and without knowing whether or not it is an external program or part of the ssh server. If I get involved in a complete sftp implementation, it will run just as well using lsh, kerberized rsh, or plain old insecure rsh if anybody is still using that. Furthermore, the server part (i.e. the subsystem) is not big, I expect the one I started to write to be a self contained program of at most 5000-10000 lines of C code. Say about twice as large as GNU ls. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 12 18:49:04 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24755 for ; Mon, 12 Mar 2001 18:49:03 -0500 (EST) Received: (qmail 29841 invoked by uid 605); 12 Mar 2001 23:48:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29833 invoked from network); 12 Mar 2001 23:48:55 -0000 Received: from cpe-203-45-24-18.vic.bigpond.net.au (HELO kado.mindrot.org) (foobar@203.45.24.18) by mail.netbsd.org with SMTP; 12 Mar 2001 23:48:55 -0000 Received: from toad.mindrot.org (unknown [203.44.118.252]) by kado.mindrot.org (Postfix) with ESMTP id A5BB0906E; Mon, 12 Mar 2001 18:51:52 +1100 (EST) Received: from mothra.mindrot.org (mothra.mindrot.org [203.44.118.225]) by toad.mindrot.org (Postfix) with ESMTP id 8D8581A1F3; Tue, 13 Mar 2001 09:50:54 +1100 (EST) Received: by mothra.mindrot.org (Postfix, from userid 500) id 1885D96FD4; Tue, 13 Mar 2001 09:50:52 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by mothra.mindrot.org (Postfix) with ESMTP id 17CB596FD3; Tue, 13 Mar 2001 09:50:52 +1100 (EST) Date: Tue, 13 Mar 2001 09:50:52 +1100 (EST) From: Damien Miller To: Thor Lancelot Simon Cc: Markus Friedl , , , Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems In-Reply-To: <20010312173130.A2713@rek.tjls.com> Message-ID: X-Paranoia: just because you're paranoid doesn't mean they aren't out to get you MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, 12 Mar 2001, Thor Lancelot Simon wrote: > I think the point is that the development of the SSH protocol has > involved a great deal of reinvention of wheels. Some people think > that this is regrettable and wish that the SSH working group paid a > bit more attention to integration with other IETF protocols rather > than rampaging ahead inventing new ones. > > > I personally think that the SFTP protocol is a pretty gratuitous > addition; a whole lot of complexity, and it really doesn't buy you > much. IMO sftp is not very complex and a worthwhile addition to SSH. Compared to rfc959, sftp is a very clean protocol and a breeze to implement (the client end at least). > But then again, I think that reinventing most of what TLS > does for the SSHv2 transport layer instead of politely asking the > TLS folks for a record-oriented interface was rather silly, too. TLS is pretty intimately wed to x.509 and we still have not seen it specified for other PK systems (except for an expired OpenPGP draft). -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 12 18:49:13 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24773 for ; Mon, 12 Mar 2001 18:49:12 -0500 (EST) Received: (qmail 193 invoked by uid 605); 12 Mar 2001 23:49:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 140 invoked from network); 12 Mar 2001 23:49:02 -0000 Received: from guinness.cs.stevens-tech.edu (155.246.89.8) by mail.netbsd.org with SMTP; 12 Mar 2001 23:49:02 -0000 Received: (from tls@localhost) by guinness.cs.stevens-tech.edu (8.9.3/8.9.3) id SAA2083985 for ietf-ssh@netbsd.org; Mon, 12 Mar 2001 18:49:01 -0500 (EST) Date: Mon, 12 Mar 2001 18:49:01 -0500 From: Thor Simon To: ietf-ssh@netbsd.org Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems Message-ID: <20010312184901.A2110397@cs.stevens-tech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit On Tue, Mar 13, 2001 at 12:12:46AM +0100, Niels MЖller wrote: > Thor Lancelot Simon writes: > > > But then again, I think that reinventing most of what TLS does for > > the SSHv2 transport layer instead of politely asking the TLS folks > > for a record-oriented interface was rather silly, too. > > I've implemented both TLS (ok, it was actually SSL version 3 back > then) and ssh2. I'd say the ssh2 transport is better. It's cleaner, > more secure, more flexible, and its spec is a lot easier to > understand. And then a lot of the complexity in ssh is in the > connection layer, which isn't comparable to TLS in any way. Nonetheless, we have two IETF-standardized secure transport layers which serve essentially the same purpose. I find this regrettable, particularly from the point of view of a small system which, these days, may be forced to carry around the code to do both. > The ssh implementation and the sftp implementation are quite > independent. They have a common origin and uses a common language and Yeah, that's my point. I think it's entirely reasonable to *not* implement sftp in an ssh implementation, given its large size and general crustiness. [...snip...] > Furthermore, the server part (i.e. the subsystem) is not big, I expect > the one I started to write to be a self contained program of at most > 5000-10000 lines of C code. Say about twice as large as GNU ls. That's pretty darned big; the entire SSHv1 server implementation we shipped to Redback, for example, was just about 5000 lines, and we had a working minimal server at an earlier point in our development that was perhaps 2/3 that big. The entire world is NOT a Unix machine with a multi-gigabyte hard drive. I don't think that GNU ls is a particularly good example of a small program -- it's three times as long as the /bin/ls in the current NetBSD sources, for example. Thor From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 12 19:00:05 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24986 for ; Mon, 12 Mar 2001 19:00:04 -0500 (EST) Received: (qmail 1487 invoked by uid 605); 12 Mar 2001 23:59:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1480 invoked from network); 12 Mar 2001 23:59:57 -0000 Received: from cpe-203-45-24-18.vic.bigpond.net.au (HELO kado.mindrot.org) (foobar@203.45.24.18) by mail.netbsd.org with SMTP; 12 Mar 2001 23:59:57 -0000 Received: from toad.mindrot.org (toad.mindrot.org [203.44.118.252]) by kado.mindrot.org (Postfix) with ESMTP id B0CD09036; Tue, 13 Mar 2001 10:04:09 +1100 (EST) Received: from mothra.mindrot.org (mothra.mindrot.org [203.44.118.225]) by toad.mindrot.org (Postfix) with ESMTP id CAFE11A42F; Tue, 13 Mar 2001 10:57:01 +1100 (EST) Received: by mothra.mindrot.org (Postfix, from userid 500) id 28E0696FD6; Tue, 13 Mar 2001 10:56:57 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by mothra.mindrot.org (Postfix) with ESMTP id 282DA96FD5; Tue, 13 Mar 2001 10:56:57 +1100 (EST) Date: Tue, 13 Mar 2001 10:56:57 +1100 (EST) From: Damien Miller To: Thor Simon Cc: Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems In-Reply-To: <20010312184901.A2110397@cs.stevens-tech.edu> Message-ID: X-Paranoia: just because you're paranoid doesn't mean they aren't out to get you MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, 12 Mar 2001, Thor Simon wrote: > > The ssh implementation and the sftp implementation are quite > > independent. They have a common origin and uses a common language and > > Yeah, that's my point. I think it's entirely reasonable to *not* > implement sftp in an ssh implementation, given its large size and > general crustiness. I don't think that you have demonstrated that sftp is either large or 'crusty'. Could you give examples of the latter? > [...snip...] > > Furthermore, the server part (i.e. the subsystem) is not big, I expect > > the one I started to write to be a self contained program of at most > > 5000-10000 lines of C code. Say about twice as large as GNU ls. > > That's pretty darned big; the entire SSHv1 server implementation we > shipped to Redback, for example, was just about 5000 lines, and we had > a working minimal server at an earlier point in our development that > was perhaps 2/3 that big. The entire world is NOT a Unix machine with > a multi-gigabyte hard drive. The sftp-server that we ship with OpenSSH is 1028 lines, not counting the infrastructure shared with the rest of the implementation. BTW I don't think that SSH1 is a valid benchmark for comparison. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 12 19:07:30 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25140 for ; Mon, 12 Mar 2001 19:07:29 -0500 (EST) Received: (qmail 4185 invoked by uid 605); 13 Mar 2001 00:07:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4178 invoked from network); 13 Mar 2001 00:07:23 -0000 Received: from guinness.cs.stevens-tech.edu (155.246.89.8) by mail.netbsd.org with SMTP; 13 Mar 2001 00:07:23 -0000 Received: (from tls@localhost) by guinness.cs.stevens-tech.edu (8.9.3/8.9.3) id TAA2019679 for ietf-ssh@netbsd.org; Mon, 12 Mar 2001 19:07:22 -0500 (EST) Date: Mon, 12 Mar 2001 19:07:22 -0500 From: Thor Simon To: ietf-ssh@netbsd.org Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems Message-ID: <20010312190722.A1977483@cs.stevens-tech.edu> References: <20010312184901.A2110397@cs.stevens-tech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from djm@mindrot.org on Tue, Mar 13, 2001 at 10:56:57AM +1100 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Mar 13, 2001 at 10:56:57AM +1100, Damien Miller wrote: > On Mon, 12 Mar 2001, Thor Simon wrote: > > > > The ssh implementation and the sftp implementation are quite > > > independent. They have a common origin and uses a common language and > > > > Yeah, that's my point. I think it's entirely reasonable to *not* > > implement sftp in an ssh implementation, given its large size and > > general crustiness. > > I don't think that you have demonstrated that sftp is either large or > 'crusty'. Could you give examples of the latter? I think I'd have to define it a bit better first. :-) Later tonight maybe. > The sftp-server that we ship with OpenSSH is 1028 lines, not counting > the infrastructure shared with the rest of the implementation. BTW I > don't think that SSH1 is a valid benchmark for comparison. Well, Niels suggested 5000-10000 lines. That's "big" by my definition, and I do think that it was reasonable to point out that at that size, it'd be larger than an entire v1 implementation; that implementation was already too damned big for an embedded system, as far as I was concerned. Anyone got a line count for the sftp client and server in the ssh.com code? I'd look myself, but for various reasons I don't read through that codebase, just the specifications. You can't get much simpler than "rcp", and it works. It's a shame that the traditional BSD "rcmd" semantics don't patch stderr, which forces you to ship a whole separate "scp" command instead of just using your system rcp (the wire protocol is the same). Thor From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 12 19:31:19 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25789 for ; Mon, 12 Mar 2001 19:31:18 -0500 (EST) Received: (qmail 10626 invoked by uid 605); 13 Mar 2001 00:31:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10619 invoked from network); 13 Mar 2001 00:31:12 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 13 Mar 2001 00:31:12 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11552; Mon, 12 Mar 2001 16:31:10 -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 TAA06640; Mon, 12 Mar 2001 19:31:09 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f2D0V4912324; Mon, 12 Mar 2001 19:31:04 -0500 (EST) Message-Id: <200103130031.f2D0V4912324@thunk.east.sun.com> From: Bill Sommerfeld To: Thor Simon cc: ietf-ssh@netbsd.org Subject: SSL/TLS vs SSH (embedded footprint) In-reply-to: Your message of "Mon, 12 Mar 2001 19:07:22 EST." <20010312190722.A1977483@cs.stevens-tech.edu> Reply-to: sommerfeld@east.sun.com Date: Mon, 12 Mar 2001 19:31:04 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list [working group chair hat off. totally random commentary time.] In a past job I worked on a small portable IP stack for embedded platforms. For the embedded world, one other attraction in favor of SSL/TLS-based protocols is that, due to the proliferation of web-based management schemes, embedded boxes which care about security are pretty likely to have an SSL/TLS implementation in there already for "secure" web-based mgmt... - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 12 19:38:55 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25958 for ; Mon, 12 Mar 2001 19:38:55 -0500 (EST) Received: (qmail 11880 invoked by uid 605); 13 Mar 2001 00:38:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11873 invoked from network); 13 Mar 2001 00:38:49 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 13 Mar 2001 00:38:49 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id B249B82F4F2; Tue, 13 Mar 2001 01:38:47 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id BAA09750; Tue, 13 Mar 2001 01:38:47 +0100 (MET) To: Thor Simon Cc: ietf-ssh@netbsd.org Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems References: <20010312184901.A2110397@cs.stevens-tech.edu> <20010312190722.A1977483@cs.stevens-tech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 13 Mar 2001 01:38:47 +0100 In-Reply-To: Thor Simon's message of "Mon, 12 Mar 2001 19:07:22 -0500" Message-ID: Lines: 32 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Thor Simon writes: > > The sftp-server that we ship with OpenSSH is 1028 lines, not counting > > the infrastructure shared with the rest of the implementation. BTW I > > don't think that SSH1 is a valid benchmark for comparison. > > Well, Niels suggested 5000-10000 lines. That's "big" by my definition, > and I do think that it was reasonable to point out that at that size, > it'd be larger than an entire v1 implementation; that implementation > was already too damned big for an embedded system, as far as I was > concerned. Well, that's because my sftp code by intention is *not* sharing any infrastructure with anything. I'm copying some code from GNU fileutils, though, for creating the "longname" strings and caching info about users and groups. This is kind-of an experiment. I don't particularly like having to write yet another sftp server. Markus kindly provided me with (an early version of) his sftp code for me to look at. But it seemed too tied in with the rest of openssh for me to use directly. So I'd like to have a standalone sftp program that isn't particularly tied to either lsh or openssh. I don't know if the openssh folks are interested in that, I understand that it is easier to just reuse the openssh code that they have around. And it may end up smaller than 10K lines, that was a very crude guess. The current count is 2000 lines including *everything* except libc, so perhaps it can be completed well under 3-4K lines. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 12 19:40:21 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25987 for ; Mon, 12 Mar 2001 19:40:21 -0500 (EST) Received: (qmail 13491 invoked by uid 605); 13 Mar 2001 00:40:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13484 invoked from network); 13 Mar 2001 00:40:14 -0000 Received: from etoh.eviladmin.org (HELO eviladmin.org) (206.145.58.62) by mail.netbsd.org with SMTP; 13 Mar 2001 00:40:14 -0000 Received: from localhost (mouring@localhost) by eviladmin.org (8.11.0/8.11.0) with ESMTP id f2D0dZn16312; Mon, 12 Mar 2001 18:39:35 -0600 Date: Mon, 12 Mar 2001 18:39:35 -0600 (CST) From: mouring@etoh.eviladmin.org To: Thor Lancelot Simon cc: Markus Friedl , ssh@clinet.fi, openssh-unix-dev@mindrot.org, ietf-ssh@netbsd.org Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems In-Reply-To: <20010312173130.A2713@rek.tjls.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, 12 Mar 2001, Thor Lancelot Simon wrote: [..] > > Ergo, a small, lightweight SSH implementation, even one that did v2, > might quite reasonably choose to *not* implement SFTP; to me, at least, > it sure seems to bring very little to the table in return for a lot > of increase in code size and maintenance. But that's just my point > of view; clearly some people have put a lot of work into advancing > SFTP and they must have a more substantial use for it than I do. > How do you assure Windows end-users can transfer and manage files to a webserver in a secure way? Is there publicly accessable IPSec software for Windows 98? What about TLS? What about GSSAPI? How much added load do they put on a 200mhz - 400mhz machine? Are they 100% stable and usable? How do they interact over dialups? What unforseen issues will crop up for day to day usage online and offline? You seem to be suggesting that I should have to suffer for two to ten years before older technology that is not progressing at any decent rate to be cross-platform supported and commonly used. Or maybe your suggestion I need to wait twenty or more years before UNIX (Linux, BSD, etc) are common desktop machines and this technology is then native. I consider it pretty unacceptable. I need something today that will allow me to security against poorly written ftpd attacks, against password sniffing, etc. When we gained sftp server support I started in look for a sftp client solution for my end-users. sftp is totally optional. It's not even part of the main v2 specs. It is an add-on draft that is no required. So if you don't want it. Don't enable it. - Ben From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 12 21:40:31 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28506 for ; Mon, 12 Mar 2001 21:40:31 -0500 (EST) Received: (qmail 1715 invoked by uid 605); 13 Mar 2001 02:40:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1708 invoked from network); 13 Mar 2001 02:40:24 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 13 Mar 2001 02:40:24 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA28837 for ; Mon, 12 Mar 2001 18:40:24 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id SAA19643 for ; Mon, 12 Mar 2001 18:40:28 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with SMTP id f2D2eLq7205967 for ; Mon, 12 Mar 2001 18:40:22 -0800 (PST) Message-Id: <200103130240.f2D2eLq7205967@jurassic.eng.sun.com> Date: Mon, 12 Mar 2001 18:40:21 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: message lang tags verse SSH_MSG_KEXINIT To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: kmofCbYLWisK9hIrKFfB4w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_26 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >I agree the language negotiation is far from not crystal clear. If others agree with this point I think this presents a hurdle for progressing the core drafts. It seems at the moment that nobody on the list actually knows how this is supposed to work. May be if I explain how I see it being used in a unix environment as an example: Client sends in languages_client_to_server the current locale as returned by setlocale() Server sends in languages_server_to_client the list of all languages it currently has installed for the ssh server (I'm assuming there is a way to find this out) If the client gets back the value of languages_client_to_server in the list provided in languages_server_to_client it knows that the server supports its currently running locale (I don't think the client would actually do anything with this). If the server gets a value in languages_client_to_server that it sent in languages_server_to_client then it uses setlocale() to change the locale of the currently running sshd. The goal is to have the server run in the same locale as the client, the client is running in a user choosen locale so if I want to run my client in "fr" then I set my locale to "fr" before running my ssh client program. Using the language fields in the SSH_MSG_KEXINIT the server gets to find this out and switches its locale to match my client (if it has the relevant language files installed). I can't see a use for a client sending multiple entries in languages_client_to_server in an environment that uses setlocale() (ie LC_* variables, but I can if the client config has a list of preffered languages - like what netscape has for webpages). How does my understanding of this match that of the person who wrote this section in the core drafts ? As for the language tags I could see that a subsystem provided by a 3rd party may not have the same (even any) language files that are provided by the core server, so it may need to use the message language tags to say that the messages are different. Other than that I can't see a general use for the per message tags. If my interpretation of the languages_client_to_server and server_to_client above is correct, must an implmenation that does that also send the language tag with every message ? Eg the above resulting in the server setting its locale to "fr" do I need to add "fr" to every message in the language tag field or do I only need to add a language tag if it is different ? If there is no agreement on this before the WG meeting can we have this as an agenda item - I believe it is important we have no ambiquous sections in the drafts before moving them onwards to being RFCs. Thanks to those who have replied so far (and those that have taken the time to read this far ;-)) - I know this isn't the most interesting part of the drafts but it is a very important part for me - particularly if there is an ambiquity. One final question has anyone got an implemenation that does anything with language tags either the client_to_server/server_to_client of the per message tags ? -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 12 21:41:34 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28531 for ; Mon, 12 Mar 2001 21:41:34 -0500 (EST) Received: (qmail 2130 invoked by uid 605); 13 Mar 2001 02:41:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2121 invoked from network); 13 Mar 2001 02:41:29 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 13 Mar 2001 02:41:29 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA22593 for ; Mon, 12 Mar 2001 18:41:28 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id SAA19788 for ; Mon, 12 Mar 2001 18:41:32 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with SMTP id f2D2fPq7206140; Mon, 12 Mar 2001 18:41:26 -0800 (PST) Message-Id: <200103130241.f2D2fPq7206140@jurassic.eng.sun.com> Date: Mon, 12 Mar 2001 18:41:26 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: Secure Shell (secsh) WG meeting agenda requests.. To: sommerfeld@east.sun.com Cc: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: O8LZr84QzWNbbsqq1OOOyA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_26 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >From: Bill Sommerfeld >To: ietf-ssh@netbsd.org >Subject: Secure Shell (secsh) WG meeting agenda requests.. >Date: Mon, 12 Mar 2001 15:30:45 -0500 > >We will be meeting next monday at the minneapolis ietf meeting. > >I'd like to see discussion on our current drafts: > >Core drafts: > - issues from the last call > (I'll be sending out a list shortly) > >Others: > - sftp > - pubkey file format > - D-H group exchange > - kbd-interactive > - gssapi authentication. > >if you have any other suggested topics for the agenda, send them to me. language tags - since there doesn't seem to be consensus on how they are intended to work - this relates to the core drafts. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 13 00:56:10 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA01299 for ; Tue, 13 Mar 2001 00:56:09 -0500 (EST) Received: (qmail 2984 invoked by uid 605); 13 Mar 2001 05:56:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2974 invoked from network); 13 Mar 2001 05:56:00 -0000 Received: from syrinx.oankali.net (root@206.243.169.50) by mail.netbsd.org with SMTP; 13 Mar 2001 05:56:00 -0000 Received: (from res@localhost) by syrinx.oankali.net (8.9.3/8.9.3) id AAA02777; Tue, 13 Mar 2001 00:55:40 -0500 Date: Tue, 13 Mar 2001 00:55:40 -0500 (EST) From: "Richard E. Silverman" X-Sender: res@syrinx.oankali.net Reply-To: "Richard E. Silverman" To: ietf-ssh@netbsd.org Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems In-Reply-To: <20010312173130.A2713@rek.tjls.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id AAA01299 On Mon, 12 Mar 2001, Thor Lancelot Simon wrote: > On Mon, Mar 12, 2001 at 02:40:35PM +0100, Markus Friedl wrote: > > On Mon, Mar 12, 2001 at 08:31:48AM -0500, Jeffrey Altman wrote: > > > > > > Why do you need to use FTP over SSH when FTP is "securable" using any > > > number of methods? The most common methods are > > > > > > SSL/TLS > > > > > > GSSAPI > > > > > > Kerberos > > > > > > SRP Because while FTP may be "securable" using these methods, the fact is that it has not actually been secured this way in real life. Implementations of these things have existed for a while, and have simply not caught on. I will not debate why, but is is true. In the short time that it has existed, my impression is that SSH has achieved much more widespread use than any of these techniques. Hence, an easy-to-use, comprehensive file-transfer protocol that operates over SSH has a good chance of succeeding where these various secured FTP's have failed. FTP has successfully been secured using SSH; cf the SecureFX product from Van Dyke, and the FTP protocol forwarding in the latest version of SSH2 from ssh.com. However, it's nasty. The basic FTP techniques of using multiple, separate TCP connections for data transfers, and carrying IP addresses inside the command channel, make it badly suited to today's Internet filled with restrictive firewalls and NAT. A much better idea is to have a protocol which requires nothing but a single, reliable, full-duplex byte stream as its transport. To my knowledge, there simply isn't such a thing available. rcp is too simple; it doesn't allow for directory listings or generally fetching information about remote files, and doesn't lend itself to conducting a file-transfer "session," as opposed to just pushing or pulling a singly-specified set of files. I haven't looked at the protocols used by rsync, sup, etc. to see if they would have been good alternatives -- but they are not standardized, either. If there's an existing IETF-standard file-transfer protocol that meets these needs, I'd like to hear about it. I agree that on the face of it, engineering such a thing in the context of the SSH wg is a little odd; it has no direct connection with SSH at all. But in a practical sense, it does. People have two immediate needs when connecting to remote computers: getting a remote command shell, and transferring files. SSH inherently provides the former. By providing the latter as well as a standard feature, SSH will be more widely used, enhancing security in the Internet. Since there is no existing, widely-used, sufficiently general file-transfer protocol which is easily securable via SSH, creating a new one is justified. > I think the point is that the development of the SSH protocol has > involved a great deal of reinvention of wheels. Some people think > that this is regrettable and wish that the SSH working group paid a > bit more attention to integration with other IETF protocols rather > than rampaging ahead inventing new ones. > > ... But then again, I think that reinventing most of what TLS > does for the SSHv2 transport layer instead of politely asking the > TLS folks for a record-oriented interface was rather silly, too. Tatu YlЖnen wrote SSH1 in 1995, a year before the TLS wg was even formed. The first version of the SSH-2 protocol was designed by SSH Communications Security in 1996, and the SSH wg formed in 1997. RFC 2246 documenting TLS 1.0 did not appear until 1999. So the claim that the SSH people should have used TLS instead seems a bit stretched; it did not exist at the time. SSL in its earlier versions existed, but as I noted before, it had not (and to this day still has not) achieved much use outside of HTTPS. Why would Tatu or others have turned to a technology that, for whatever reasons, had simply failed to do the job in the field? Its dependence on an eagerly-awaited-but-never-quite-there-yet global X.509-based PKI, plus dependence on the overly complex ASN.1/BER/DER suite, were liabilities just not worth the trouble. > We have those things now; there's not much point thinking about what > we _could_ have done. An odd statement, considering that you have just spent a fair amount of space doing exactly this, and berating people for it. > I don't really think that the "anonymous" bits of its function are well > served by its design, worse served, in fact, than by simply using FTP > secured with TLS, GSSAPI, or other standard methods These methods, no matter how much they may appeal to our sense of elegance or our like of reusing of existing technology, have simply not taken hold. They have been rejected by the users. SSH, on the other hand, is spreading and gaining acceptance. A file-transfer method that works over SSH is therefore a good bet, and in the absence of a good existing candidate, we are building a new one for the purpose. > and it's massive overkill compared to the simple BSD-rcp protocol used > by the old "scp" application, when that's going to be 99% of what it's > used for in the real world, ISTM. In the real world, people want long-lived file-transfer sessions including the ability to list remote directories, push and pull various files during that single session, perhaps initiate a long transfer and then continue to list other directories and transfer other files while that long task continues. rcp is just not general enough to meet these needs. -- Richard Silverman slade@shore.net From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 13 01:00:50 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01352 for ; Tue, 13 Mar 2001 01:00:49 -0500 (EST) Received: (qmail 4004 invoked by uid 605); 13 Mar 2001 06:00:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3997 invoked from network); 13 Mar 2001 06:00:44 -0000 Received: from ginger.cmf.nrl.navy.mil (@134.207.10.161) by mail.netbsd.org with SMTP; 13 Mar 2001 06:00:44 -0000 Received: from cmf.nrl.navy.mil (pendragon.cmf.nrl.navy.mil [134.207.5.3]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id f2D60f927463 for ; Tue, 13 Mar 2001 01:00:41 -0500 (EST) Message-Id: <200103130600.f2D60f927463@ginger.cmf.nrl.navy.mil> To: ietf-ssh@netbsd.org Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems In-reply-to: Your message of "Tue, 13 Mar 2001 00:55:40 EST." X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Tue, 13 Mar 2001 01:00:41 -0500 From: Ken Hornstein Sender: ietf-ssh-owner@netbsd.org Precedence: list >Because while FTP may be "securable" using these methods, the fact is that >it has not actually been secured this way in real life. I (and 5000 other people I know) use GSSAPI authenticated ftp every day for real work. Sure, I believe that ssh easily has more users, but just because you don't use it doesn't mean it doesn't exist. (I'm ambivalant about sftp, personally). --Ken From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 13 01:33:44 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA04907 for ; Tue, 13 Mar 2001 01:33:44 -0500 (EST) Received: (qmail 7909 invoked by uid 605); 13 Mar 2001 06:33:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7902 invoked from network); 13 Mar 2001 06:33:38 -0000 Received: from syrinx.oankali.net (root@206.243.169.50) by mail.netbsd.org with SMTP; 13 Mar 2001 06:33:38 -0000 Received: (from res@localhost) by syrinx.oankali.net (8.9.3/8.9.3) id BAA03004; Tue, 13 Mar 2001 01:33:38 -0500 Date: Tue, 13 Mar 2001 01:33:37 -0500 (EST) From: "Richard E. Silverman" X-Sender: res@syrinx.oankali.net Reply-To: "Richard E. Silverman" To: ietf-ssh@netbsd.org Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems In-Reply-To: <200103130600.f2D60f927463@ginger.cmf.nrl.navy.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 13 Mar 2001, Ken Hornstein wrote: > >Because while FTP may be "securable" using these methods, the fact is that > >it has not actually been secured this way in real life. > > I (and 5000 other people I know) use GSSAPI authenticated ftp every day > for real work. > > Sure, I believe that ssh easily has more users, but just because you don't > use it doesn't mean it doesn't exist. Perhaps you received a garbled or incomplete version of the message I posted. I did not claim that GSSAPI-secured FTP doesn't exist; in fact, if you read past that first sentence which you quoted out of context, I specifically said that it and other secured FTP implementations exist and have been around for a while. They have their users, especially within specific, controlled communities. They have not, however, achieved widespread use in the Internet in general, whereas SSH has a good start at that and seems quite likely to be ubiquitous shortly. That was all I said, and all I meant. -- Richard Silverman slade@shore.net From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 13 01:50:08 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06815 for ; Tue, 13 Mar 2001 01:50:07 -0500 (EST) Received: (qmail 13043 invoked by uid 605); 13 Mar 2001 06:50:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13036 invoked from network); 13 Mar 2001 06:50:02 -0000 Received: from ginger.cmf.nrl.navy.mil (@134.207.10.161) by mail.netbsd.org with SMTP; 13 Mar 2001 06:50:02 -0000 Received: from cmf.nrl.navy.mil (pendragon.cmf.nrl.navy.mil [134.207.5.3]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id f2D6nx927770 for ; Tue, 13 Mar 2001 01:49:59 -0500 (EST) Message-Id: <200103130649.f2D6nx927770@ginger.cmf.nrl.navy.mil> To: ietf-ssh@netbsd.org Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems In-reply-to: Your message of "Tue, 13 Mar 2001 01:33:37 EST." X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Tue, 13 Mar 2001 01:49:58 -0500 From: Ken Hornstein Sender: ietf-ssh-owner@netbsd.org Precedence: list >Perhaps you received a garbled or incomplete version of the message I >posted. I did not claim that GSSAPI-secured FTP doesn't exist; in fact, >if you read past that first sentence which you quoted out of context, I >specifically said that it and other secured FTP implementations exist and >have been around for a while. They have their users, especially within >specific, controlled communities. They have not, however, achieved >widespread use in the Internet in general, whereas SSH has a good start at >that and seems quite likely to be ubiquitous shortly. That was all I >said, and all I meant. In my mind, there's a LARGE difference between: "they have not, however, achieved widespread use in the Internet in general" which you used in your most recent message, and "the fact is that it has not actually been secured this way in real life" which you used in your original message. I'm not sure I really know what the first one means, actually. I'd believe that GSSAPI-authenticated ftp doesn't meet the first criteria, but I'm not sure what your definition of "widespread" is. I take HUGE issue with your characterization that these protocols are not used "in real life". As for being quoted out of context ... you were responding to the original poster's comment about different technologies used for securing ftp! How is that not in-context to this discussion? --Ken From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 13 02:06:21 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA14921 for ; Tue, 13 Mar 2001 02:06:20 -0500 (EST) Received: (qmail 14651 invoked by uid 605); 13 Mar 2001 07:06:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14643 invoked from network); 13 Mar 2001 07:06:13 -0000 Received: from syrinx.oankali.net (root@206.243.169.50) by mail.netbsd.org with SMTP; 13 Mar 2001 07:06:13 -0000 Received: (from res@localhost) by syrinx.oankali.net (8.9.3/8.9.3) id CAA03143; Tue, 13 Mar 2001 02:05:57 -0500 Date: Tue, 13 Mar 2001 02:05:57 -0500 (EST) From: "Richard E. Silverman" X-Sender: res@syrinx.oankali.net Reply-To: "Richard E. Silverman" To: ietf-ssh@netbsd.org Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems In-Reply-To: <200103130649.f2D6nx927770@ginger.cmf.nrl.navy.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 13 Mar 2001, Ken Hornstein wrote: > In my mind, there's a LARGE difference between: > > "they have not, however, achieved widespread use in the Internet in general" > > which you used in your most recent message, and > > "the fact is that it has not actually been secured this way in real life" > > which you used in your original message. The second sentence merely paraphrases what I wrote to begin with, which I did to avoid having to repeat it, which I will now do anyway since you're ignoring it. Here is what I wrote: "Because while FTP may be "securable" using these methods, the fact is that it has not actually been secured this way in real life. Implementations of these things have existed for a while, and have simply not caught on. I will not debate why, but is is true. In the short time that it has existed, my impression is that SSH has achieved much more widespread use than any of these techniques. Hence, an easy-to-use, comprehensive file-transfer protocol that operates over SSH has a good chance of succeeding where these various secured FTP's have failed." The sentences following the first one, explain what I meant: that those other techniques exist and are used, but not generally enough to count as having "secured FTP" in the broadest sense. That's all. > I take HUGE issue with your characterization that these protocols are > not used "in real life". If that were all I had said, without any other explanation for what I meant by that phrase, then I would agree with your objection. However, I think my meaning was sufficiently well explained in the rest of the text. I'm sorry you didn't find it clear enough. > As for being quoted out of context ... you were responding to the > original poster's comment about different technologies used for securing > ftp! How is that not in-context to this discussion? This is very confusing. I did not say that your message was not in context of the discussion. I said that you quoted me out of context. Those are different things. You quoted the phrase "in real life" without the following text which explained what I meant by it, and proceeded to attach a very different meaning to it from that which I clearly articulated in my post. Since we're both clear on what I meant now (I hope), perhaps we could continue to discuss the merits of the protocols in question. -- Richard Silverman slade@shore.net From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 13 02:23:08 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16759 for ; Tue, 13 Mar 2001 02:23:08 -0500 (EST) Received: (qmail 16348 invoked by uid 605); 13 Mar 2001 07:23:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16340 invoked from network); 13 Mar 2001 07:23:02 -0000 Received: from ginger.cmf.nrl.navy.mil (@134.207.10.161) by mail.netbsd.org with SMTP; 13 Mar 2001 07:23:02 -0000 Received: from cmf.nrl.navy.mil (pendragon.cmf.nrl.navy.mil [134.207.5.3]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id f2D7Mx927985 for ; Tue, 13 Mar 2001 02:22:59 -0500 (EST) Message-Id: <200103130722.f2D7Mx927985@ginger.cmf.nrl.navy.mil> To: ietf-ssh@netbsd.org Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems In-reply-to: Your message of "Tue, 13 Mar 2001 02:05:57 EST." X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Tue, 13 Mar 2001 02:22:59 -0500 From: Ken Hornstein Sender: ietf-ssh-owner@netbsd.org Precedence: list Alright, my last message on the topic. I have the following issues with this paragraph, and I did read it all, but I felt that one sentence was enough to sum it up. But in whole: >"Because while FTP may be "securable" using these methods, the fact is that > it has not actually been secured this way in real life. (I think we covered this before). >Implementations > of these things have existed for a while, and have simply not caught on. I disagree that they have not "caught on" - in the communities that use Kerberos, for example, GSSAPI ftp is very popular. I can even think of several commercial implementations of GSSAPI ftp. > I will not debate why, but is is true. Fair enough, but I disagree with the basic premise. >In the short time that it has > existed, my impression is that SSH has achieved much more widespread use > than any of these techniques. I'm not sure about this one, but I'd be going on gut feelings. But without hard numbers to back this up ... it wouldn't be very meaningful. >Hence, an easy-to-use, comprehensive > file-transfer protocol that operates over SSH has a good chance of > succeeding where these various secured FTP's have failed." And again, I disagree that the others have failed in the first place. (Mind you, I don't think that file-transfer over SSH is bad ... I'm just saying that I don't see any evidence that the others have failed). And come on ... you have to admit that saying things like "not used in real life," "not caught on", and saying that the other technologies have "failed" isn't exactly the same as saying they haven't achieved widespread use on the Internet (if we're using the "widespead use over the Internet" benchmark, we should all be working furiously toward getting SMTP-over-TLS and HTTP-over-TLS working better :-) ). >This is very confusing. I did not say that your message was not in >context of the discussion. I said that you quoted me out of context. >Those are different things. You quoted the phrase "in real life" without >the following text which explained what I meant by it, and proceeded to >attach a very different meaning to it from that which I clearly >articulated in my post. Well, I appreciate the clarification (and my apologies for misunderstanding your out-of-context remark) ... but reading back over that paragraph, I still get the same meaning out of it. *shrug* --Ken From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 13 03:29:59 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17277 for ; Tue, 13 Mar 2001 03:29:59 -0500 (EST) Received: (qmail 27542 invoked by uid 605); 13 Mar 2001 08:29:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27535 invoked from network); 13 Mar 2001 08:29:53 -0000 Received: from faui02.informatik.uni-erlangen.de (msfriedl@131.188.30.102) by mail.netbsd.org with SMTP; 13 Mar 2001 08:29:53 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id JAA07814; Tue, 13 Mar 2001 09:29:40 +0100 (MET) Date: Tue, 13 Mar 2001 09:29:40 +0100 From: Markus Friedl To: Thor Simon Cc: ietf-ssh@netbsd.org Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems Message-ID: <20010313092940.A6698@faui02.informatik.uni-erlangen.de> References: <20010312184901.A2110397@cs.stevens-tech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20010312184901.A2110397@cs.stevens-tech.edu>; from tls@cs.stevens-tech.edu on Mon, Mar 12, 2001 at 06:49:01PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Mar 12, 2001 at 06:49:01PM -0500, Thor Simon wrote: > That's pretty darned big; the entire SSHv1 server implementation we Well, you are talking about SSH protocol v1 without any forwarding. Remember that the channel layer is the most complex part of the SSH protocol. TLS does not include anything like the channel layer and this is why SSH gets used: People are forwarding all kind of things over SSH. Without the channel layer SSH would be just something like telnet with encryption. If you are talking about lines, the sftp-server included in OpenSSH is just about 1000 lines, and could probably implemented with less lines if this was an issue. The sftp protocol is not complex at all. > shipped to Redback, for example, was just about 5000 lines, and we had Hm, this is rather big for server-only if you consider that the plan9 SSH protcol v1 client+server+keygen+manpage is about 4000 lines. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 13 03:46:39 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17423 for ; Tue, 13 Mar 2001 03:46:38 -0500 (EST) Received: (qmail 28874 invoked by uid 605); 13 Mar 2001 08:46:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28867 invoked from network); 13 Mar 2001 08:46:30 -0000 Received: from syrinx.oankali.net (root@206.243.169.50) by mail.netbsd.org with SMTP; 13 Mar 2001 08:46:30 -0000 Received: (from res@localhost) by syrinx.oankali.net (8.9.3/8.9.3) id DAA03866; Tue, 13 Mar 2001 03:46:23 -0500 Date: Tue, 13 Mar 2001 03:46:23 -0500 (EST) From: "Richard E. Silverman" X-Sender: res@syrinx.oankali.net Reply-To: "Richard E. Silverman" To: ietf-ssh@netbsd.org Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems In-Reply-To: <200103130722.f2D7Mx927985@ginger.cmf.nrl.navy.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 13 Mar 2001, Ken Hornstein wrote: > I disagree that they have not "caught on" - in the communities that use > Kerberos, for example, GSSAPI ftp is very popular. I can even think of > several commercial implementations of GSSAPI ftp. I did not mean to imply otherwise. Again, I meant "caught on" in the largest sense. I'm thinking in terms of what the average user sees, sitting at home accessing the Internet through a commerical ISP and browsing the Web. I don't see many ISP's or general-access FTP servers providing or advertising GSSAPI-secured FTP, or SSL-secured Telnet, etc. I do see them installing SSH servers with growing frequency, advertising that fact to their customers and suggesting they use it. > > In the short time that it has existed, my impression is that SSH has > > achieved much more widespread use than any of these techniques. > > I'm not sure about this one, but I'd be going on gut feelings. But without > hard numbers to back this up ... it wouldn't be very meaningful. Oh, I'm just going on subjective impressions here as well -- I don't have any research at hand about the the relative numbers of these things deployed in the Internet. If such numbers exist, I'd love to see them. Perhaps I'd be surprised. > > Hence, an easy-to-use, comprehensive file-transfer protocol that > > operates over SSH has a good chance of succeeding where these various > > secured FTP's have failed." > > And again, I disagree that the others have failed in the first place. > (Mind you, I don't think that file-transfer over SSH is bad ... I'm > just saying that I don't see any evidence that the others have failed). Obviously, I did not mean that they failed to work. They work just fine. I meant only that they have failed to become a widespread solution to the problem of insecure file transfers. Whether that's due to technical disadvantages, or merely to historical accident, I wasn't really opining either way. In a certain sense, it doesn't matter -- if SSH becomes widespread and we can piggyback on its success to solve this problem as well, then so much the better. A technically better solution is no better if it's not used. > And come on ... you have to admit that saying things like "not used in > real life," "not caught on", and saying that the other technologies > have "failed" isn't exactly the same as saying they haven't achieved > widespread use on the Internet I'm afraid I still think it's not fair to yank those phrases out of context, concatenate them together, and complain about their meaning when set that way. They were surrounded by text which gave a different story. For instance, those other technologies *have* failed -- to gain the kind of widespread acceptance that SSH appears to be gaining, thus "succeeding where [they] have failed." It still seems clear to me. But then, I wrote it. :) Sorry if I gave a different impression to begin with, but I hope we've cleared that up now. > (if we're using the "widespead use over the Internet" benchmark, we > should all be working furiously toward getting SMTP-over-TLS and > HTTP-over-TLS working better :-) ). No disagreement there. I am frequently frustrated that these options, available in many standard clients, are almost always only available on the server side exactly where they are least needed. You can find SMTP/TLS on mail servers inside secured corporate networks, but almost never on your ISP's mailbox server. My preferred way of allowing updates to a web server is HTTP PUT over TLS -- but most commercial web development packages seem to provide support for vanilla, insecure FTP only (Netscape Composer being the only exception I can think of offhand, though I'm sure there are some others). It's very annoying. -- Richard Silverman slade@shore.net From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 13 18:44:46 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00307 for ; Tue, 13 Mar 2001 18:44:45 -0500 (EST) Received: (qmail 7097 invoked by uid 605); 13 Mar 2001 23:44:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7089 invoked from network); 13 Mar 2001 23:44:39 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 13 Mar 2001 23:44:39 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06905 for ; Tue, 13 Mar 2001 15:44:38 -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 SAA24083 for ; Tue, 13 Mar 2001 18:44:37 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f2DNiV918694 for ; Tue, 13 Mar 2001 18:44:32 -0500 (EST) Message-Id: <200103132344.f2DNiV918694@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: last-call issues.. Reply-to: sommerfeld@east.sun.com Date: Tue, 13 Mar 2001 18:44:31 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list I believe that this is the current list of issues raised in the last call on the core documents. If I missed anything, let me know. Issues in core documents: - Trademark verbiage needs to be struck completely. (editorial change only) - Niels Moeller: RSA signature encoding should be described as mpuint rather than as "string" (editorial change only; touches architecture and transport drafts) - Subsystem robustness: The ".cshrc output mixed into subsystem output" issue is purely a local implementation issue; subsystem cookie text should be deleted. Advice to implementors should state that server implementations which allow for subsystems to be "plugged in" in should to define an interface to subsystem implementations to prevent any extraneous output (perhaps from a shell) from being mixed into the subsystem output sent over the wire. (no wire protocol change involved) Resolution: need volunteer to provide text for this. - Wei Dai pointed out a discrepancy between the zlib spec and the code actually in use which needs to be documented for interoperability reasons relating to zlib partial flush. Resolution: wei dai provided corrected text (see archive) this corrects the spec to match what people have actually implemented and deployed. - Wei Dai pointed out that the compression system should be referred to as "zlib", not "GNU zlib" resolution: trivial editorial change. - Darren Moffat: Should be rationale for why every message gets a language tag. - Niels M. pointed out that there are current interop problems between OpenSSH and lsh relating to channel EOF and channel close; lshd attempts graceful shutdown but doesn't ever get an EOF from OpenSSH's client. Resolution: the "forward output until EOF, then close channel" behavior should be documented as an implementors note. (need volunteer to supply text) Possible additional work items raised in last call. - "denis bider" mentioned the lack of a standard for presenting key fingerprints. Resolution: need volunteer to write a draft for this. - Wei Dai requested an extension to allow for forwarding of a server-chosen port ("pick a port, forward it to me, and tell me what it is"). Resolution: Unresolved. Do we need a new opcode for this or can we overload the meaning of "forward port zero"? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 13 22:51:52 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04275 for ; Tue, 13 Mar 2001 22:51:52 -0500 (EST) Received: (qmail 18077 invoked by uid 605); 14 Mar 2001 03:51:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18069 invoked from network); 14 Mar 2001 03:51:31 -0000 Received: from most.weird.com (?lrRgjnyj2L3rSc5LpANlXBNfhspCItP5F68+eF1bnVz4wRnYqCc/7A6EX8RR/c9bevGG7N80ook=?@204.92.254.2) by mail.netbsd.org with SMTP; 14 Mar 2001 03:51:31 -0000 Received: from proven.weird.com([204.92.254.15]) (2611 bytes) by most.weird.com via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) (ident <[Ku5pUHbnCHUf5OMpRkOxOVCVPWngprRg1RITZy8Q0Qk99Svs2Lm+CwfjoM8tkMkc/PKFSKoyA3S/Ap0XYhf8fg==]> using rfc1413) id for ; Tue, 13 Mar 2001 22:51:11 -0500 (EST) (Smail-3.2.0.112-Pre 2000-Feb-17 #12 built 2001-Feb-5) Received: by proven.weird.com (Postfix, from userid 1000) id 6F32E8C; Tue, 13 Mar 2001 22:51:09 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: woods@weird.com (Greg A. Woods) To: ietf-ssh@netbsd.org Cc: SSH Users Mailing List , openssh-unix-dev@mindrot.org Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems In-Reply-To: <20010313222053.B22241@folly> References: <9DC8BBAD4FF100408FC7D18D1F092286039C96@condor.mhsc.com> <20010312031041.9D7AA8C@proven.weird.com> <20010312222432.A7800@folly> <20010313192046.46CC78C@proven.weird.com> <20010313222053.B22241@folly> X-Mailer: VM 6.90 under Emacs 21.0.97.1 Reply-To: woods@weird.com (Greg A. Woods) Organization: Planix, Inc.; Toronto, Ontario; Canada Message-Id: <20010314035109.6F32E8C@proven.weird.com> Date: Tue, 13 Mar 2001 22:51:09 -0500 (EST) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit [ On Tuesday, March 13, 2001 at 22:20:53 (+0100), Markus Friedl wrote: ] > Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems > > On Tue, Mar 13, 2001 at 02:20:46PM -0500, Greg A. Woods wrote: > > There are a zillion ways on most server-type platforms to do such > > indirection without having to integrate it into SSH, not to mention that > > almost all of those alternatives would then lead to total independence > > of SSH and thus total portability across all generic transport protocols. > > sftp _is_ total independeny of SSH and runs portable across > all generic transport protocols. Well, maybe, but sftp, at least in SSH, currently relies on the "built-in subsystem" feature. I'm sure you could rip it out and make it stand alone (eg. work over rsh), but hmmm... wouldn't doing so also make it independent of the "built-in subsystem" in SSH? Duh! So yes: > > The "built-in subsystem" feature is bad design. It has no business > > being directly in the transport protocol. It is an ugly wart. > > tell ietf-ssh@netbsd.org, not me, i don't care. I tried but the address either you or someone else supplied originally in this thread contained a typo and my message bounced. :-) -- Greg A. Woods +1 416 218-0098 VE3TCP Planix, Inc. ; Secrets of the Weird From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 13 23:26:25 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04450 for ; Tue, 13 Mar 2001 23:26:24 -0500 (EST) Received: (qmail 22765 invoked by uid 605); 14 Mar 2001 04:26:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22758 invoked from network); 14 Mar 2001 04:26:20 -0000 Received: from yeah-baby.shagadelic.org (HELO dr-evil.shagadelic.org) (208.176.2.162) by mail.netbsd.org with SMTP; 14 Mar 2001 04:26:20 -0000 Received: by dr-evil.shagadelic.org (Postfix, from userid 7518) id 260EE18B65; Tue, 13 Mar 2001 20:25:49 -0800 (PST) Date: Tue, 13 Mar 2001 20:25:49 -0800 From: Jason R Thorpe To: "Greg A. Woods" Cc: ietf-ssh@netbsd.org Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems Message-ID: <20010313202548.J16238@dr-evil.shagadelic.org> Reply-To: thorpej@zembu.com Mail-Followup-To: Jason R Thorpe , "Greg A. Woods" , ietf-ssh@netbsd.org References: <9DC8BBAD4FF100408FC7D18D1F092286039C96@condor.mhsc.com> <20010312031041.9D7AA8C@proven.weird.com> <20010312222432.A7800@folly> <20010313192046.46CC78C@proven.weird.com> <20010313222053.B22241@folly> <20010314035109.6F32E8C@proven.weird.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010314035109.6F32E8C@proven.weird.com>; from woods@weird.com on Tue, Mar 13, 2001 at 10:51:09PM -0500 Organization: Zembu Labs, Inc. Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Mar 13, 2001 at 10:51:09PM -0500, Greg A. Woods wrote: > Well, maybe, but sftp, at least in SSH, currently relies on the > "built-in subsystem" feature. Actually, I don't think that's so -- it only needs a bi-directional, stream-oriented communication endpoint, right? "Subsystem" is merely the mechanism that the SSH protocol uses to create that endpoint and start the SFTP server. ...at least, that's how I understand it. Now, a given implementation may choose to make the SFTP server a built-in of the SSH server -- but that is not required. > I'm sure you could rip it out and make it stand alone (eg. work over > rsh), but hmmm... wouldn't doing so also make it independent of the > "built-in subsystem" in SSH? Duh! So yes: > > > > The "built-in subsystem" feature is bad design. It has no business > > > being directly in the transport protocol. It is an ugly wart. ...but I'm not sure I completely agree with this. I can understand the argument, but I'm not sure I buy it :-) I think the problem is the terminology -- "subsystem" ... I think the term "service" would be better ("Hi, please run this service over this secure transport"), maybe, but it's probably a little too late to change it. -- -- Jason R. Thorpe From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 02:48:35 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20638 for ; Wed, 14 Mar 2001 02:48:34 -0500 (EST) Received: (qmail 27901 invoked by uid 605); 14 Mar 2001 07:48:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27893 invoked from network); 14 Mar 2001 07:48:27 -0000 Received: from mindterm.appgate.com (HELO mail.mindbright.se) (postfix@193.12.107.237) by mail.netbsd.org with SMTP; 14 Mar 2001 07:48:27 -0000 Received: by mail.mindbright.se (Postfix, from userid 1001) id 3251B1FF01; Wed, 14 Mar 2001 09:02:20 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by mail.mindbright.se (Postfix) with ESMTP id 2C5301F106; Wed, 14 Mar 2001 09:02:20 +0100 (MET) Date: Wed, 14 Mar 2001 09:02:20 +0100 (MET) From: Mats Andersson X-Sender: mats@mindterm.appgate.com To: SSH Users Mailing List , openssh-unix-dev@mindrot.org Cc: ietf-ssh@netbsd.org, "Greg A. Woods" Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems In-Reply-To: <20010314040017.5B6518C@proven.weird.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi, On Tue, 13 Mar 2001, Greg A. Woods wrote: > I'm talking about the protocols, not the implementation. In SSH-v2 > the SFTP application uses the "built-in subsystem" feature of the > SECSH protocol. I.e. it is not independent of SSH -- it relies on an > inherent feature of the transport protocol. ... > > > The "built-in subsystem" feature is bad design. It has no business > > > being directly in the transport protocol. It is an ugly wart. Good, since we're speaking about the protocols here, this is the only mention of subsystems in the sftp draft I'm aware of: ... When used with the Secure Shell protocol suite, this protocol is intended to be used from the Secure Shell Connection Protocol as a subsystem, as described in [SECSH-CONN], Section ``Starting a Shell or a Command''. The subsystem name used with this protocol is "sftp". ... As you may see this indeed does not state any dependency, it only gives a recomendation for intended usage. You might also have noticed (since I assume you indeed have read the drafts) that the subsystem feature is not part of the transport protocol, it is a (very tiny, one could add) feature in the connection protocol. You have almost surely also seen that one argument was that a subsystem might be built into the ssh server which is probably one good reason for having it in the spec. Apart from this, you are of course also free to define whatever other fancy "independent" protocols you might think of either as subsystems or as ordinary "independent" servers running across stdio (one might note here that there is no difference in practice as for how these should work since both only "see" a stream to its peer). So, what do I want to say with this? Well, people that have different oppinions/suggestions/improvements/complaints on different implementations in general and on the protocols in particular should at least have read the specs (one could add thouroughly here...). Cheers, /Mats From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 03:38:25 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20871 for ; Wed, 14 Mar 2001 03:38:24 -0500 (EST) Received: (qmail 4055 invoked by uid 605); 14 Mar 2001 08:38:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4047 invoked from network); 14 Mar 2001 08:38:14 -0000 Received: from faui02.informatik.uni-erlangen.de (msfriedl@131.188.30.102) by mail.netbsd.org with SMTP; 14 Mar 2001 08:38:14 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id JAA18203; Wed, 14 Mar 2001 09:38:00 +0100 (MET) Date: Wed, 14 Mar 2001 09:38:00 +0100 From: Markus Friedl To: "Greg A. Woods" Cc: ietf-ssh@netbsd.org, SSH Users Mailing List , openssh-unix-dev@mindrot.org Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems Message-ID: <20010314093800.E15426@faui02.informatik.uni-erlangen.de> References: <9DC8BBAD4FF100408FC7D18D1F092286039C96@condor.mhsc.com> <20010312031041.9D7AA8C@proven.weird.com> <20010312222432.A7800@folly> <20010313192046.46CC78C@proven.weird.com> <20010313222053.B22241@folly> <20010314035109.6F32E8C@proven.weird.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20010314035109.6F32E8C@proven.weird.com>; from woods@weird.com on Tue, Mar 13, 2001 at 10:51:09PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Mar 13, 2001 at 10:51:09PM -0500, Greg A. Woods wrote: > > > > sftp _is_ total independeny of SSH and runs portable across > > all generic transport protocols. > > Well, maybe, but sftp, at least in SSH, currently relies on the > "built-in subsystem" feature. implementation bug or feature. the sftp from OpenSSH works over SSH protocol v1, too. running sftp over rsh is simple, too. scp speaks rsh over a transport layer, sftp speaks filexfer over a transport layer. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 03:50:37 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20984 for ; Wed, 14 Mar 2001 03:50:36 -0500 (EST) Received: (qmail 7187 invoked by uid 605); 14 Mar 2001 08:50:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7142 invoked from network); 14 Mar 2001 08:50:10 -0000 Received: from faui02.informatik.uni-erlangen.de (msfriedl@131.188.30.102) by mail.netbsd.org with SMTP; 14 Mar 2001 08:50:10 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id JAA18690; Wed, 14 Mar 2001 09:49:55 +0100 (MET) Date: Wed, 14 Mar 2001 09:49:55 +0100 From: Markus Friedl To: Jason R Thorpe , "Greg A. Woods" , ietf-ssh@netbsd.org Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems Message-ID: <20010314094955.F15426@faui02.informatik.uni-erlangen.de> References: <9DC8BBAD4FF100408FC7D18D1F092286039C96@condor.mhsc.com> <20010312031041.9D7AA8C@proven.weird.com> <20010312222432.A7800@folly> <20010313192046.46CC78C@proven.weird.com> <20010313222053.B22241@folly> <20010314035109.6F32E8C@proven.weird.com> <20010313202548.J16238@dr-evil.shagadelic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20010313202548.J16238@dr-evil.shagadelic.org>; from thorpej@zembu.com on Tue, Mar 13, 2001 at 08:25:49PM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Mar 13, 2001 at 08:25:49PM -0800, Jason R Thorpe wrote: > > Well, maybe, but sftp, at least in SSH, currently relies on the > > "built-in subsystem" feature. > > Actually, I don't think that's so -- it only needs a bi-directional, > stream-oriented communication endpoint, right? yes, you are right. > "Subsystem" is merely > the mechanism that the SSH protocol uses to create that endpoint and > start the SFTP server. you could use a "exec" request as well, but then you need to have sftp-server in the path or know the full pathname on the remote host (OpenSSH's sftp client allows this as a proof of concept). "subsystem" just allows an additional level of indirection. it also allows easy restriction, e.g. a user is allowed to send request only for this and that subsystem. > Now, a given implementation may choose to make the SFTP server > a built-in of the SSH server -- but that is not required. this is useful if you need tighter control over the 'sftp server process' > I think the problem is the terminology -- "subsystem" ... I think the > term "service" would be better ("Hi, please run this service over this > secure transport"), maybe, but it's probably a little too late to change > it. the term "service" is alreay used at a different layer. currently there are 2 "services" defined: "ssh-userauth" and "ssh-connection" However, I think that the term "connection" is a little bit confusing, since the "SSH Connection Protocol" draft only talks about "channels", so it's really a "SSH Channel Protocol" (e.g. draft-ietf-secsh-channel). -markus From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 04:35:25 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21250 for ; Wed, 14 Mar 2001 04:35:24 -0500 (EST) Received: (qmail 12286 invoked by uid 605); 14 Mar 2001 09:35:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12279 invoked from network); 14 Mar 2001 09:35:19 -0000 Received: from ip212-226-160-97.adsl.kpnqwest.fi (HELO mystery.acr.fi) (212.226.160.97) by mail.netbsd.org with SMTP; 14 Mar 2001 09:35:19 -0000 Received: from localhost (ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) with ESMTP id LAA02976; Wed, 14 Mar 2001 11:32:57 +0200 X-Authentication-Warning: mystery.acr.fi: ylo owned process doing -bs Date: Wed, 14 Mar 2001 11:32:57 +0200 (EET) From: Tatu Ylonen X-Sender: ylo@mystery.acr.fi To: Markus Friedl cc: =?iso-8859-1?Q?Niels_M=F6ller?= , ietf-ssh@netbsd.org Subject: Re: Channel close logic, needs clarification? In-Reply-To: <20010312003213.B28291@folly> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list > On Sun, Mar 11, 2001 at 10:41:00PM +0200, Tatu Ylonen wrote: > > It is legal to send other messages, e.g. channel requests, after both > > sending and receing EOF. > > Is it legal to send SSH_MSG_CHANNEL_EXTENDED_DATA after a EOF is > sent? I asume that the EOF refers to both SSH_MSG_CHANNEL_DATA and > SSH_MSG_CHANNEL_EXTENDED_DATA. I actually never thought about this. I think it should be legal, since extended data is used for things like stderr. > > > The OpenSSH server does not wait for the EOF message from the client. > > > However, since the servers' child process is dead, the server decides > > > that it will not write to more data to the 'stdin' handle and does _not_ > > > wait for the EOF message from the client. This way the the channel is > > > correctly closed. > > > > It is legal to send SSH_MSG_CHANNEL_CLOSE before receiving/sending EOF > > I think this is a typo. Is it really legal to send > a SSH_MSG_CHANNEL_CLOSE before a SSH_MSG_CHANNEL_EOF is sent? To be more accurate, it is legal to send SSH_MSG_CHANNEL_CLOSE without sending SSH_MSG_CHANNEL_EOF. A party MUST NOT send anything to the channel after it has sent SSH_MSG_CHANNEL_CLOSE. Tatu SSH Communications Security http://www.ssh.com/ SSH IPSEC Toolkit http://www.ipsec.com/ SSH Secure Shell http://www.ssh.com/products/ssh From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 04:49:06 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21362 for ; Wed, 14 Mar 2001 04:49:05 -0500 (EST) Received: (qmail 14614 invoked by uid 605); 14 Mar 2001 09:49:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14607 invoked from network); 14 Mar 2001 09:49:00 -0000 Received: from faui02.informatik.uni-erlangen.de (msfriedl@131.188.30.102) by mail.netbsd.org with SMTP; 14 Mar 2001 09:49:00 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id KAA22306; Wed, 14 Mar 2001 10:48:55 +0100 (MET) Date: Wed, 14 Mar 2001 10:48:55 +0100 From: Markus Friedl To: Tatu Ylonen Cc: =?iso-8859-1?Q?Niels_M=F6ller?= , ietf-ssh@netbsd.org Subject: Re: Channel close logic, needs clarification? Message-ID: <20010314104855.A20179@faui02.informatik.uni-erlangen.de> References: <20010312003213.B28291@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from ylo@ssh.com on Wed, Mar 14, 2001 at 11:32:57AM +0200 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Mar 14, 2001 at 11:32:57AM +0200, Tatu Ylonen wrote: > > On Sun, Mar 11, 2001 at 10:41:00PM +0200, Tatu Ylonen wrote: > > > It is legal to send other messages, e.g. channel requests, after both > > > sending and receing EOF. > > > > Is it legal to send SSH_MSG_CHANNEL_EXTENDED_DATA after a EOF is > > sent? I asume that the EOF refers to both SSH_MSG_CHANNEL_DATA and > > SSH_MSG_CHANNEL_EXTENDED_DATA. > > I actually never thought about this. > > I think it should be legal, since extended data is used for things like > stderr. Hm, so now I'm even more confused. What does I say if I send an EOF message on a channel? Does it mean: (1) I will not send SSH_MSG_CHANNEL_DATA in the future, or (2) I will neither send SSH_MSG_CHANNEL_DATA nor SSH_MSG_CHANNEL_EXTENDED_DATA in the future. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 04:54:50 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21416 for ; Wed, 14 Mar 2001 04:54:49 -0500 (EST) Received: (qmail 15395 invoked by uid 605); 14 Mar 2001 09:54:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15388 invoked from network); 14 Mar 2001 09:54:44 -0000 Received: from faui02.informatik.uni-erlangen.de (msfriedl@131.188.30.102) by mail.netbsd.org with SMTP; 14 Mar 2001 09:54:44 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id KAA23034; Wed, 14 Mar 2001 10:54:16 +0100 (MET) Date: Wed, 14 Mar 2001 10:54:16 +0100 From: Markus Friedl To: "Greg A. Woods" Cc: SSH Users Mailing List , openssh-unix-dev@mindrot.org, ietf-ssh@netbsd.org Subject: subsystems (was: OpenSSH/scp ->> F-Secure SSH server Problems) Message-ID: <20010314105416.B20179@faui02.informatik.uni-erlangen.de> References: <20010313192046.46CC78C@proven.weird.com> <20010314040017.5B6518C@proven.weird.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20010314040017.5B6518C@proven.weird.com>; from woods@weird.com on Tue, Mar 13, 2001 at 11:00:17PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Mar 13, 2001 at 11:00:17PM -0500, Greg A. Woods wrote: > > > The "built-in subsystem" feature is bad design. It has no business > > > being directly in the transport protocol. It is an ugly wart. > > > > No, it is a robust way of specifying server systems without having to > > rely on locations of binaries, etc. > > [...] > > Point of fact is that this silly protocol wart did not make OpenSSH more > robust [...] If you are talking about "protocol warts", then you should really read the spec again. "subsystem" is more general then both "shell" or "exec", so it's no "protocol wart" at all. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 05:48:33 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21879 for ; Wed, 14 Mar 2001 05:48:33 -0500 (EST) Received: (qmail 25690 invoked by uid 605); 14 Mar 2001 10:48:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25650 invoked from network); 14 Mar 2001 10:48:14 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 14 Mar 2001 10:48:14 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id B449782F524; Wed, 14 Mar 2001 11:48:12 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id LAA28138; Wed, 14 Mar 2001 11:48:12 +0100 (MET) To: sommerfeld@east.sun.com Cc: ietf-ssh@netbsd.org Subject: Re: last-call issues.. References: <200103132344.f2DNiV918694@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 14 Mar 2001 11:48:12 +0100 In-Reply-To: Bill Sommerfeld's message of "Tue, 13 Mar 2001 18:44:31 -0500" Message-ID: Lines: 68 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Bill Sommerfeld writes: > - Niels M. pointed out that there are current interop problems > between OpenSSH and lsh relating to channel EOF and channel close; > lshd attempts graceful shutdown but doesn't ever get an EOF from > OpenSSH's client. > Resolution: the "forward output until EOF, then close channel" > behavior should be documented as an implementors note. > (need volunteer to supply text) I've changed the lsh/lshd behaviour now, and I wrote up a summary in http://www.lsaytor.liu.se/~nisse/lsh/doc/NOTES, appended below. This description is a little lsh specific, but perhaps it could be edited to fit in the draft? > - Wei Dai requested an extension to allow for forwarding of a > server-chosen port ("pick a port, forward it to me, and tell me what > it is"). > > Resolution: Unresolved. Do we need a new opcode for this or can we > overload the meaning of "forward port zero"? Even if the "tcpip-forward" global request, with zero port, is reused for this, a new reply message is still needed. /Niels CLOSING CHANNELS The right conditions for closing a channel, and in particular a session, are even more subtle. The basic rules are: 1. When SSH_MSG_CHANNEL_CLOSE is both sent and received, the channel is killed. This is unconditionally required by the spec. 2. When SSH_MSG_CHANNEL_EOF is both sent and received, SSH_MSG_CHANNEL_CLOSE is sent. This is a rule with a few exceptions, controlled by the CHANNEL_CLOSE_AT_EOF flag, see below. These two rules are sufficient for most channel types. When looking at the channel close logic for session channels, one has to consider these three events that may occur in arbitrary order: * The client sends SSH_MSG_CHANNEL_EOF on the channel. * The server sends SSH_MSG_CHANNEL_EOF on the channel (this happens when there are no more processes which have the files the server has opened for stdout or stderr open). * The child process created by the server dies. An exit-status or exit-signal message is sent to the client. Previous versions of lshd handled these conditions as follows: It closed the channel according to rule (2) above, no exceptions. This causes other clients to hang, because they never send any SSH_MSG_CHANNEL_EOF. Using lsh did work right, only because it responded to the exit-status message with a SSH_MSG_CHANNEL_EOF. But the server can't rely on clients sending SSH_MSG_CHANNEL_EOF. Instead, it must treat process death in much the same way as reception of SSH_MSG_CHANNEL_EOF. The channel is closed once the server has both encountered EOF on the process' stdout and stderr (resulting in a SSH_MSG_CHANNEL_EOF), and sent an exit-status or exit-signal message. As a further complication, rule (2) must be relaxed, because otherwise the channel may get closed before the exit-status message is sent. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 05:57:46 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21934 for ; Wed, 14 Mar 2001 05:57:45 -0500 (EST) Received: (qmail 26997 invoked by uid 605); 14 Mar 2001 10:57:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26985 invoked from network); 14 Mar 2001 10:57:39 -0000 Received: from hutcs.cs.hut.fi (kivinen@130.233.192.7) by mail.netbsd.org with SMTP; 14 Mar 2001 10:57:39 -0000 Received: (from kivinen@localhost) by hutcs.cs.hut.fi (8.9.3/8.9.3) id MAA12173; Wed, 14 Mar 2001 12:57:32 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 14 Mar 2001 12:57:31 +0200 (EET) From: Tero Kivinen To: sommerfeld@east.sun.com Cc: ietf-ssh@netbsd.org Subject: last-call issues.. In-Reply-To: <200103132344.f2DNiV918694@thunk.east.sun.com> References: <200103132344.f2DNiV918694@thunk.east.sun.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <15023.19422.241111.704340@hutcs.cs.hut.fi> Organization: Helsinki University of Technology X-Edit-Time: 12 min X-Total-Time: 11 min Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Bill Sommerfeld writes: > - Subsystem robustness: > > The ".cshrc output mixed into subsystem output" issue is purely a > local implementation issue; subsystem cookie text should be deleted. I don't agree on this change. I think the current text should be in the connect document, but it might need some polishing: ---------------------------------------------------------------------- ... 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. ---------------------------------------------------------------------- -> ---------------------------------------------------------------------- As the user's shell might be used to execute the subsystem, it is good subsystem protocol design to include a "magic cookie" at the beginning of the protocol transaction to distinguish from arbitrary output from shell initialization scripts etc. For example the subsystem protocol version number packet might act as a this kind of "magic cookie". In this case the subsystem protocol can be defined so that it ignores everything before this "magic cookie" version number packet (similar thing is already done for example the transport layer for the protocol version strings). ---------------------------------------------------------------------- > Advice to implementors should state that server implementations which > allow for subsystems to be "plugged in" in should to define an > interface to subsystem implementations to prevent any extraneous > output (perhaps from a shell) from being mixed into the subsystem > output sent over the wire. (no wire protocol change involved) No, I think it more advisable to suggest that subsystem protocols should be desing so that they can ignore the extra data before the actual protocol starts. It makes things much easier for the implementator, adminstrators and users. Note, this "magic cookie" stuff is not part of the transport layer protocol, it is part of the subsystem protocol specification, and we just give here a hint for subsystem protocol designers how to make their protocol resistant to this kind of invalid usage from the adminstrators or from the users. > Resolution: > need volunteer to provide text for this. Is the text above acceptable. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 06:13:18 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22054 for ; Wed, 14 Mar 2001 06:13:18 -0500 (EST) Received: (qmail 29419 invoked by uid 605); 14 Mar 2001 11:13:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29412 invoked from network); 14 Mar 2001 11:13:14 -0000 Received: from faui02.informatik.uni-erlangen.de (msfriedl@131.188.30.102) by mail.netbsd.org with SMTP; 14 Mar 2001 11:13:14 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id MAA27096; Wed, 14 Mar 2001 12:12:57 +0100 (MET) Date: Wed, 14 Mar 2001 12:12:57 +0100 From: Markus Friedl To: Tero Kivinen Cc: sommerfeld@east.sun.com, ietf-ssh@netbsd.org Subject: Re: last-call issues.. Message-ID: <20010314121257.B25704@faui02.informatik.uni-erlangen.de> References: <200103132344.f2DNiV918694@thunk.east.sun.com> <15023.19422.241111.704340@hutcs.cs.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <15023.19422.241111.704340@hutcs.cs.hut.fi>; from kivinen@mail.niksula.cs.hut.fi on Wed, Mar 14, 2001 at 12:57:31PM +0200 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Mar 14, 2001 at 12:57:31PM +0200, Tero Kivinen wrote: > Bill Sommerfeld writes: > > - Subsystem robustness: > > > > The ".cshrc output mixed into subsystem output" issue is purely a > > local implementation issue; subsystem cookie text should be deleted. > > I don't agree on this change. I think the current text should be in > the connect document, but it might need some polishing: no. it's an issue of how your sftp-server implementation and your sshd talk to each other. the can exchange as many cookies as they like before speaking the sftp protocol. the sftp _protocol_ does not need to be touched. the server implementing sftp can print what ever cookies it likes and the sshd has to filter the cookies out. but this is not a _protocol_ issue. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 06:14:07 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22065 for ; Wed, 14 Mar 2001 06:14:06 -0500 (EST) Received: (qmail 29796 invoked by uid 605); 14 Mar 2001 11:14:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29786 invoked from network); 14 Mar 2001 11:14:00 -0000 Received: from faui02.informatik.uni-erlangen.de (msfriedl@131.188.30.102) by mail.netbsd.org with SMTP; 14 Mar 2001 11:14:00 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id MAA27219 for ietf-ssh@netbsd.org; Wed, 14 Mar 2001 12:13:58 +0100 (MET) Date: Wed, 14 Mar 2001 12:13:58 +0100 From: Markus Friedl To: ietf-ssh@netbsd.org Subject: Re: last-call issues.. Message-ID: <20010314121358.C25704@faui02.informatik.uni-erlangen.de> References: <200103132344.f2DNiV918694@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <200103132344.f2DNiV918694@thunk.east.sun.com>; from sommerfeld@east.sun.com on Tue, Mar 13, 2001 at 06:44:31PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Mar 13, 2001 at 06:44:31PM -0500, Bill Sommerfeld wrote: > - "denis bider" mentioned the lack of a > standard for presenting key fingerprints. > > Resolution: need volunteer to write a draft for this. INTERNET-DRAFT Markus Friedl draft-friedl-secsh-fingerprint-00.txt The OpenBSD Project Expires in six months March 2001 SSH Fingerprint Format Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other docu- ments at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Abstract This document formally documents the fingerprint format in use for verifying public keys from SSH clients and servers. Introduction The security of the SSH protocols relies on the verification of public host keys. Since public keys tend to be very large, it is difficult for a human to verify an entire host key. Even with a PKI in place, it is useful to have a standard for exchanging short fingerprints of public keys. This document formally describes the simple key fingerprint format. Fingerprint Format The fingerprint of a public key consists of the output of the MD5 message-digest algorithm [RFC-1321]. The input to the algorithm is the public key blob as described in [SSH-TRANS]. The output of the algorithm is presented to the user as a sequence of 16 bytes printed as hexadecimal with lowercase letters and seperated by colons. For example: "4b:69:6c:72:6f:79:20:77:61:73:20:68:65:72:65:21" References [SSH-TRANS] Ylonen, T., et al: "SSH Transport Layer Protocol", Internet Draft, draft-secsh-transport-09.txt [RFC-1321] R. Rivest: "The MD5 Message-Digest Algorithm", April 1992. [RFC-2026] S. Bradner: "The Internet Standards Process -- Revision 3", October 1996. Author's Address: Markus Friedl markus@openbsd.org Ganghoferstr. 7 Munich, Germany From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 06:40:41 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22204 for ; Wed, 14 Mar 2001 06:40:41 -0500 (EST) Received: (qmail 6927 invoked by uid 605); 14 Mar 2001 11:40:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6920 invoked from network); 14 Mar 2001 11:40:34 -0000 Received: from cpe-203-45-24-18.vic.bigpond.net.au (HELO kado.mindrot.org) (foobar@203.45.24.18) by mail.netbsd.org with SMTP; 14 Mar 2001 11:40:34 -0000 Received: from toad.mindrot.org (toad.mindrot.org [203.44.118.252]) by kado.mindrot.org (Postfix) with ESMTP id D5000900F; Wed, 14 Mar 2001 21:19:01 +1100 (EST) Received: from mothra.mindrot.org (mothra.mindrot.org [203.44.118.225]) by toad.mindrot.org (Postfix) with ESMTP id 784921A1F3; Wed, 14 Mar 2001 22:40:27 +1100 (EST) Received: by mothra.mindrot.org (Postfix, from userid 500) id 019E096FCF; Wed, 14 Mar 2001 22:40:25 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by mothra.mindrot.org (Postfix) with ESMTP id F2AA696FC7; Wed, 14 Mar 2001 22:40:25 +1100 (EST) Date: Wed, 14 Mar 2001 22:40:25 +1100 (EST) From: Damien Miller To: Tero Kivinen Cc: , Subject: Re: last-call issues.. In-Reply-To: <15023.19422.241111.704340@hutcs.cs.hut.fi> Message-ID: X-Paranoia: just because you're paranoid doesn't mean they aren't out to get you MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, 14 Mar 2001, Tero Kivinen wrote: > Bill Sommerfeld writes: > > - Subsystem robustness: > > > > The ".cshrc output mixed into subsystem output" issue is purely a > > local implementation issue; subsystem cookie text should be deleted. > > I don't agree on this change. I think the current text should be in > the connect document, but it might need some polishing: I disagree - the current text mandates that subsystems be executed through a login shell. IMO how subsystems are invoked should be left completely up to the implementation. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 06:45:57 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22259 for ; Wed, 14 Mar 2001 06:45:57 -0500 (EST) Received: (qmail 7494 invoked by uid 605); 14 Mar 2001 11:45:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7486 invoked from network); 14 Mar 2001 11:45:50 -0000 Received: from cpe-203-45-24-18.vic.bigpond.net.au (HELO kado.mindrot.org) (foobar@203.45.24.18) by mail.netbsd.org with SMTP; 14 Mar 2001 11:45:50 -0000 Received: from toad.mindrot.org (toad.mindrot.org [203.44.118.252]) by kado.mindrot.org (Postfix) with ESMTP id 0D100900F; Wed, 14 Mar 2001 21:24:17 +1100 (EST) Received: from mothra.mindrot.org (mothra.mindrot.org [203.44.118.225]) by toad.mindrot.org (Postfix) with ESMTP id 86D571A1F3; Wed, 14 Mar 2001 22:45:47 +1100 (EST) Received: by mothra.mindrot.org (Postfix, from userid 500) id 7883596FCF; Wed, 14 Mar 2001 22:45:42 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by mothra.mindrot.org (Postfix) with ESMTP id 77CF196FC7; Wed, 14 Mar 2001 22:45:42 +1100 (EST) Date: Wed, 14 Mar 2001 22:45:42 +1100 (EST) From: Damien Miller To: "Greg A. Woods" Cc: , SSH Users Mailing List , Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems In-Reply-To: <20010314035109.6F32E8C@proven.weird.com> Message-ID: X-Paranoia: just because you're paranoid doesn't mean they aren't out to get you MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 13 Mar 2001, Greg A. Woods wrote: > > sftp _is_ total independeny of SSH and runs portable across > > all generic transport protocols. > > Well, maybe, but sftp, at least in SSH, currently relies on the > "built-in subsystem" feature. > > I'm sure you could rip it out and make it stand alone (eg. work over > rsh), but hmmm... wouldn't doing so also make it independent of the > "built-in subsystem" in SSH? Duh! So yes: It is not a matter of "ripping" anything out - sftp is already completely independant. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 07:40:06 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22758 for ; Wed, 14 Mar 2001 07:40:05 -0500 (EST) Received: (qmail 19379 invoked by uid 605); 14 Mar 2001 12:40:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19351 invoked from network); 14 Mar 2001 12:39:59 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 14 Mar 2001 12:39:59 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id A112982F524; Wed, 14 Mar 2001 13:39:57 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id NAA13975; Wed, 14 Mar 2001 13:39:57 +0100 (MET) To: Markus Friedl Cc: Tatu Ylonen , ietf-ssh@netbsd.org Subject: Re: Channel close logic, needs clarification? References: <20010312003213.B28291@folly> <20010314104855.A20179@faui02.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 14 Mar 2001 13:39:56 +0100 In-Reply-To: Markus Friedl's message of "Wed, 14 Mar 2001 10:48:55 +0100" Message-ID: Lines: 15 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Markus Friedl writes: > Hm, so now I'm even more confused. What does I say if I > send an EOF message on a channel? Does it mean: > > (1) I will not send SSH_MSG_CHANNEL_DATA in the future, or > > (2) I will neither send SSH_MSG_CHANNEL_DATA nor > SSH_MSG_CHANNEL_EXTENDED_DATA in the future. I have always used the interpretation (2). lsh and lshd currently ignores extended data received after CHANNEL_EOF, and log a message. They could just as well treat it as a fatal protocol error. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 09:03:20 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23586 for ; Wed, 14 Mar 2001 09:03:19 -0500 (EST) Received: (qmail 2247 invoked by uid 605); 14 Mar 2001 14:03:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2240 invoked from network); 14 Mar 2001 14:03:12 -0000 Received: from ixion.tartarus.org (195.153.205.133) by mail.netbsd.org with SMTP; 14 Mar 2001 14:03:12 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 14dBrq-0002wK-00; Wed, 14 Mar 2001 14:03:10 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <15023.19422.241111.704340@hutcs.cs.hut.fi> Subject: Re: last-call issues.. Message-Id: Date: Wed, 14 Mar 2001 14:03:10 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Tero Kivinen wrote: > As the user's shell might be used to execute the subsystem, it is good > subsystem protocol design to include a "magic cookie" at the beginning > of the protocol transaction to distinguish from arbitrary output from > shell initialization scripts etc. This is a horrifyingly ugly way to separate subsystem output from startup script output; not only is it ugly, it's also fragile. Why not do it the ordinary way, by means of using different file descriptors? Here's a Unix implementation sketch, which is roughly similar to one I already suggested to the OpenSSH people (but marginally more coherent in details): - When invoking a subsystem, _don't_ open pipes on the child process's stdin/stdout. Instead, open pipes on some _different_ fds passed to the child. Open /dev/null on the child's stdin and stdout. - The user's login scripts now run, and if they generate any output at all it goes to /dev/null. - The command you pass to the user's login shell is not `subsystem-program'. Instead, it's `subsystem-wrapper subsystem-program', where subsystem-wrapper is a small helper program (in /usr/lib, say). and are the file numbers of the pipes provided by sshd. - subsystem-wrapper first closes its stdin/stdout file descriptors. Then it uses dup2() to move the provided on to fd 0, and move the on to fd 1. Finally, it execs the real subsystem program. So sshd ends up talking directly to the subsystem program, and vice versa. Output from the init scripts automatically goes to /dev/null and doesn't ever need to be filtered out of the same stream. Best of all, the subsystem program _itself_ doesn't need to change in the slightest. It still reads and writes on its stdin and stdout, so it's still easy for people to write custom subsystems. (It could be argued that if the user's startup scripts do anything really interesting involving opening extra fds in the shell, this mechanism might still blow up. Even more robust would be to open named pipes in an appropriately secured subdirectory of /tmp, and pass the names of the pipes to subsystem-wrapper.) I think that, given the existence of properly robust solutions like this, it's inelegant to suggest that implementors should use as fragile a mechanism as magic cookies. Cheers, Simon -- Simon Tatham "Thieves respect property; they only wish the property to be their own, that they may more properly respect it." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 09:08:15 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23636 for ; Wed, 14 Mar 2001 09:08:14 -0500 (EST) Received: (qmail 2833 invoked by uid 605); 14 Mar 2001 14:08:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2826 invoked from network); 14 Mar 2001 14:08:08 -0000 Received: from faui02.informatik.uni-erlangen.de (msfriedl@131.188.30.102) by mail.netbsd.org with SMTP; 14 Mar 2001 14:08:08 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id PAA07745; Wed, 14 Mar 2001 15:08:04 +0100 (MET) Date: Wed, 14 Mar 2001 15:08:04 +0100 From: Markus Friedl To: Simon Tatham Cc: ietf-ssh@netbsd.org Subject: Re: last-call issues.. Message-ID: <20010314150804.A7285@faui02.informatik.uni-erlangen.de> References: <15023.19422.241111.704340@hutcs.cs.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from anakin@pobox.com on Wed, Mar 14, 2001 at 02:03:10PM +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Mar 14, 2001 at 02:03:10PM +0000, Simon Tatham wrote: > `subsystem-program'. Instead, it's `subsystem-wrapper > subsystem-program', where subsystem-wrapper is a small helper > program (in /usr/lib, say). and are the file numbers > of the pipes provided by sshd. the shell will probably close rfd and wfd (you don't need rfd, since stdin is clean, only stdout is a mess). -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 09:47:41 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24229 for ; Wed, 14 Mar 2001 09:47:41 -0500 (EST) Received: (qmail 8710 invoked by uid 605); 14 Mar 2001 14:47:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8650 invoked from network); 14 Mar 2001 14:47:20 -0000 Received: from hutcs.cs.hut.fi (kivinen@130.233.192.7) by mail.netbsd.org with SMTP; 14 Mar 2001 14:47:20 -0000 Received: (from kivinen@localhost) by hutcs.cs.hut.fi (8.9.3/8.9.3) id QAA20246; Wed, 14 Mar 2001 16:47:13 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 14 Mar 2001 16:47:13 +0200 (EET) From: Tero Kivinen To: Markus Friedl Cc: sommerfeld@east.sun.com, ietf-ssh@netbsd.org Subject: Re: last-call issues.. In-Reply-To: <20010314121257.B25704@faui02.informatik.uni-erlangen.de> References: <200103132344.f2DNiV918694@thunk.east.sun.com> <15023.19422.241111.704340@hutcs.cs.hut.fi> <20010314121257.B25704@faui02.informatik.uni-erlangen.de> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <15023.33334.769693.20580@hutcs.cs.hut.fi> Organization: Helsinki University of Technology X-Edit-Time: 9 min X-Total-Time: 9 min Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Markus Friedl writes: > no. it's an issue of how your sftp-server implementation > and your sshd talk to each other. the can exchange as many > cookies as they like before speaking the sftp protocol. > the sftp _protocol_ does not need to be touched. I don't really understand what you are saying above. The transport/connection layer client will talk to transport/connection layer server. The sftp-client will talk to sftp-server. The sftp-client/server will NOT talk to the transport/connection layer server nor client. The transport/connection layer just assumes that when the subsystem is started then everything is up to the subsystem to take care of the input/output, it does not do anything else than pass those bytes from server to client and vice versa. The subsystem can assume that it has some connection between the server and client, and the connection might be transport/connection layer, but it might be rsh, tls, tcp/ip socket or anything. This connection is completely transparent, i.e all characters goes thru. The problem is that in quite common case there is some extra junk involved before the actual protocol starts (linefeeds, some warning/debug messages etc), and if the subsystem protocol has clear and good design it can be ignore that junk, and start processing its own messages only when it sees for example the version number exchange packet from the other end. > the server implementing sftp can print what ever cookies > it likes and the sshd has to filter the cookies out. > but this is not a _protocol_ issue. If we make it that way, then each subsystem implementation is tied to each connection layer implementation, i.e you cannot take SSH Communications Security's sftp-server and run it using lsh server, because the lsh does not know which kind of cookies the sftp-server is going to use. If we define that it is good protocol desing in the subsystems to exchange version number etc any fixed packet in the beginning, which can be used as a "magic cookie", then when the sftp-server of the SSH Communications Security sends this packet the other ends client can ignore everything until it sees this byte stream coming from the connection. The transport/connection layer between does not have to know anything about the subsystems, the subsystems must know about each other. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 09:52:43 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24448 for ; Wed, 14 Mar 2001 09:52:42 -0500 (EST) Received: (qmail 10246 invoked by uid 605); 14 Mar 2001 14:52:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10236 invoked from network); 14 Mar 2001 14:52:37 -0000 Received: from hutcs.cs.hut.fi (kivinen@130.233.192.7) by mail.netbsd.org with SMTP; 14 Mar 2001 14:52:37 -0000 Received: (from kivinen@localhost) by hutcs.cs.hut.fi (8.9.3/8.9.3) id QAA20409; Wed, 14 Mar 2001 16:52:20 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 14 Mar 2001 16:52:20 +0200 (EET) From: Tero Kivinen To: Damien Miller Cc: , Subject: Re: last-call issues.. In-Reply-To: References: <15023.19422.241111.704340@hutcs.cs.hut.fi> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <15023.33928.46027.370236@hutcs.cs.hut.fi> Organization: Helsinki University of Technology X-Edit-Time: 5 min X-Total-Time: 4 min Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Damien Miller writes: > > I don't agree on this change. I think the current text should be in > > the connect document, but it might need some polishing: > I disagree - the current text mandates that subsystems be executed > through a login shell. IMO how subsystems are invoked should be left > completely up to the implementation. Where? Only place I can find any reference to such text is this: ---------------------------------------------------------------------- As the user's shell is usually used to execute the subsystem, ... ---------------------------------------------------------------------- That does not mandate them to be executed using login shell, it just says that they are usually executed using the login shell, and because of that you should desing the subsystem protocols so that they can handle that situation also. Whether the subsystems are executed using the login shell, or if they are built-in to the server or if they are executed using the /usr/games/nethack, is completely up the implementation. In my text I changed that to say: ---------------------------------------------------------------------- As the user's shell might be used to execute the subsystem, ... ---------------------------------------------------------------------- to make it even more clear that subsystems are not necessarely executed using login shell. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 10:04:36 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24909 for ; Wed, 14 Mar 2001 10:04:35 -0500 (EST) Received: (qmail 12845 invoked by uid 605); 14 Mar 2001 15:04:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12838 invoked from network); 14 Mar 2001 15:04:29 -0000 Received: from hutcs.cs.hut.fi (kivinen@130.233.192.7) by mail.netbsd.org with SMTP; 14 Mar 2001 15:04:29 -0000 Received: (from kivinen@localhost) by hutcs.cs.hut.fi (8.9.3/8.9.3) id RAA20748; Wed, 14 Mar 2001 17:04:15 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 14 Mar 2001 17:04:13 +0200 (EET) From: Tero Kivinen To: Simon Tatham Cc: ietf-ssh@netbsd.org Subject: Re: last-call issues.. In-Reply-To: References: <15023.19422.241111.704340@hutcs.cs.hut.fi> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <15023.34399.19784.425378@hutcs.cs.hut.fi> Organization: Helsinki University of Technology X-Edit-Time: 7 min X-Total-Time: 8 min Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Simon Tatham writes: > This is a horrifyingly ugly way to separate subsystem output from > startup script output; not only is it ugly, it's also fragile. Why > not do it the ordinary way, by means of using different file > descriptors? Because doing so is very hard if you try to port it to all possible unix environments that there are. Also quite a lot of shells close ALL filedescriptors when they execute any program, just to get rid of filedescriptors that are accidently left open by the system libraries (like getpwent/getpwnam/getpwuid, which might leave the /etc/passwd filedescriptor open). Also I don't want to even think how this should be done on VMS or IBM Mainframes. Somebody might want to have sftp for those systems also... > I think that, given the existence of properly robust solutions like > this, it's inelegant to suggest that implementors should use as > fragile a mechanism as magic cookies. Cookies work fine, and they are standard way of detecting that data stream is ok. I think they are much more robust than playing around with file descriptors etc. Also even if you can use file descriptors, it does not mean that the other end can and will, thus you still might end up having non working subsystem, because other end sent something you didn't want to ignore before starting the subsystem. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 10:53:00 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26395 for ; Wed, 14 Mar 2001 10:52:59 -0500 (EST) Received: (qmail 22332 invoked by uid 605); 14 Mar 2001 15:52:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22314 invoked from network); 14 Mar 2001 15:52:52 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 14 Mar 2001 15:52:52 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id HAA11984; Wed, 14 Mar 2001 07:52:43 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id HAA26791; Wed, 14 Mar 2001 07:52:42 -0800 (PST) Date: Wed, 14 Mar 2001 07:52:42 -0800 From: Wei Dai To: Bill Sommerfeld Cc: ietf-ssh@netbsd.org Subject: Re: last-call issues.. Message-ID: <20010314075241.D24330@eskimo.com> References: <200103132344.f2DNiV918694@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200103132344.f2DNiV918694@thunk.east.sun.com>; from sommerfeld@east.sun.com on Tue, Mar 13, 2001 at 06:44:31PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Mar 13, 2001 at 06:44:31PM -0500, Bill Sommerfeld wrote: > - Wei Dai requested an extension to allow for forwarding of a > server-chosen port ("pick a port, forward it to me, and tell me what > it is"). > > Resolution: Unresolved. Do we need a new opcode for this or can we > overload the meaning of "forward port zero"? FYI, the latest SOCKS 5 draft overloads the meaning of "forward port zero" for this purpose. See http://www.socks.nec.com/draft/draft-ietf-aft-socks-pro-v5-04.txt. As a seperate issue, I'd also like to see UDP forwarding some time in the future. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 12:02:23 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28164 for ; Wed, 14 Mar 2001 12:02:23 -0500 (EST) Received: (qmail 12973 invoked by uid 605); 14 Mar 2001 17:02:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12962 invoked from network); 14 Mar 2001 17:02:18 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 14 Mar 2001 17:02:18 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA03572; Wed, 14 Mar 2001 09:02:07 -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 MAA01546; Wed, 14 Mar 2001 12:01:42 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f2EH1a919566; Wed, 14 Mar 2001 12:01:36 -0500 (EST) Message-Id: <200103141701.f2EH1a919566@thunk.east.sun.com> From: Bill Sommerfeld To: agenda@ietf.org cc: ietf-ssh@netbsd.org Subject: Secure Shell (secsh) agenda for 50th IETF Reply-to: sommerfeld@east.sun.com Date: Wed, 14 Mar 2001 12:01:36 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Secure Shell working group (secsh) MONDAY, March 19, 2001 at 1530-1730 =================================== CHAIR: Bill Sommerfeld Agenda: Working group status / agenda bashing 5 mins Brief presentations 10 mins - ssh interop event at next Connectathon (Darrin Moffat) - measurements of ssh protocol deployment (Niels Provos) Discussion of core draft last-call issues 45 mins Discussion of extension drafts 45 mins - sftp - pubkey file format - D-H group exchange - keyboard-interactive - gssapi authentication. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 12:31:47 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29092 for ; Wed, 14 Mar 2001 12:31:47 -0500 (EST) Received: (qmail 23979 invoked by uid 605); 14 Mar 2001 17:31:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23972 invoked from network); 14 Mar 2001 17:31:38 -0000 Received: from yeah-baby.shagadelic.org (HELO dr-evil.shagadelic.org) (208.176.2.162) by mail.netbsd.org with SMTP; 14 Mar 2001 17:31:38 -0000 Received: by dr-evil.shagadelic.org (Postfix, from userid 7518) id 02E2818B65; Wed, 14 Mar 2001 09:31:07 -0800 (PST) Date: Wed, 14 Mar 2001 09:31:07 -0800 From: Jason R Thorpe To: Markus Friedl Cc: Tero Kivinen , sommerfeld@east.sun.com, ietf-ssh@netbsd.org Subject: Re: last-call issues.. Message-ID: <20010314093107.R16238@dr-evil.shagadelic.org> Reply-To: thorpej@zembu.com Mail-Followup-To: Jason R Thorpe , Markus Friedl , Tero Kivinen , sommerfeld@east.sun.com, ietf-ssh@netbsd.org References: <200103132344.f2DNiV918694@thunk.east.sun.com> <15023.19422.241111.704340@hutcs.cs.hut.fi> <20010314121257.B25704@faui02.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010314121257.B25704@faui02.informatik.uni-erlangen.de>; from Markus.Friedl@informatik.uni-erlangen.de on Wed, Mar 14, 2001 at 12:12:57PM +0100 Organization: Zembu Labs, Inc. Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Mar 14, 2001 at 12:12:57PM +0100, Markus Friedl wrote: > the server implementing sftp can print what ever cookies > it likes and the sshd has to filter the cookies out. > but this is not a _protocol_ issue. Hm, this doesn't really strike me as good design -- if we all agree that subsystems require only a bi-directional stream communication channel, then it seems like a cop-out to rely on some special in-band-but-filtered-out communication between the sftp server and the transport server. Who's to say one couldn't use sftp over some generic TLS pipe (say, like the one that the stunnel package implements)? I'm with Tero on this one -- recommend that subsystems ignore unrecognized data sent over the channel, up until the subsystem version exchange occurs, and require that no non-subsystem data appear on the channel once the version exchange is complete. -- -- Jason R. Thorpe From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 12:34:09 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29158 for ; Wed, 14 Mar 2001 12:34:09 -0500 (EST) Received: (qmail 24688 invoked by uid 605); 14 Mar 2001 17:34:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24681 invoked from network); 14 Mar 2001 17:34:00 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 14 Mar 2001 17:34:00 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 3724882F525; Wed, 14 Mar 2001 18:33:58 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id SAA03510; Wed, 14 Mar 2001 18:33:57 +0100 (MET) To: Tero Kivinen Cc: Markus Friedl , sommerfeld@east.sun.com, ietf-ssh@netbsd.org Subject: Re: last-call issues.. References: <200103132344.f2DNiV918694@thunk.east.sun.com> <15023.19422.241111.704340@hutcs.cs.hut.fi> <20010314121257.B25704@faui02.informatik.uni-erlangen.de> <15023.33334.769693.20580@hutcs.cs.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 14 Mar 2001 18:33:57 +0100 In-Reply-To: Tero Kivinen's message of "Wed, 14 Mar 2001 16:47:13 +0200 (EET)" Message-ID: Lines: 45 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Tero Kivinen writes: > Markus Friedl writes: > > no. it's an issue of how your sftp-server implementation > > and your sshd talk to each other. the can exchange as many > > cookies as they like before speaking the sftp protocol. > > the sftp _protocol_ does not need to be touched. > > I don't really understand what you are saying above. The > transport/connection layer client will talk to transport/connection > layer server. The sftp-client will talk to sftp-server. The > sftp-client/server will NOT talk to the transport/connection layer > server nor client. I think he's saying that if filtering is done at the server end, clients need not know about it, and it's therefore not a protocol issue at all. I agree that using cookies are a real ugly hack for working around random configuration errors. I can understand that you may want to do that under some circumstances, but if so, please do on the server end, in order to localize the ugliness. > If we make it that way, then each subsystem implementation is tied to > each connection layer implementation, i.e you cannot take SSH > Communications Security's sftp-server and run it using lsh server, > because the lsh does not know which kind of cookies the sftp-server is > going to use. If you just use the first SSH_FXP_VERSION packet as the cookie, that's no problem (except that lshd doesn't do any filtering). A different problem is that the server needs to know how to recognize the start of the real communication for each subsystem. That's a little painful for those who implement filtering, but I think that is the price you have to pay in order to keep the clients from knowing about the ugliness. And it shouldn't be too difficult, you can have a simple table like # Subsystem name program cookie sftp /usr/local/sbin/sftp-subsystem 00000033 and that's all the server needs to know. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 13:06:17 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00088 for ; Wed, 14 Mar 2001 13:06:16 -0500 (EST) Received: (qmail 28211 invoked by uid 605); 14 Mar 2001 18:06:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28204 invoked from network); 14 Mar 2001 18:06:08 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 14 Mar 2001 18:06:08 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id E155582F55B; Wed, 14 Mar 2001 19:06:05 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id TAA25323; Wed, 14 Mar 2001 19:06:05 +0100 (MET) To: thorpej@zembu.com Cc: Markus Friedl , Tero Kivinen , sommerfeld@east.sun.com, ietf-ssh@netbsd.org Subject: Re: last-call issues.. References: <200103132344.f2DNiV918694@thunk.east.sun.com> <15023.19422.241111.704340@hutcs.cs.hut.fi> <20010314121257.B25704@faui02.informatik.uni-erlangen.de> <20010314093107.R16238@dr-evil.shagadelic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 14 Mar 2001 19:06:05 +0100 In-Reply-To: Jason R Thorpe's message of "Wed, 14 Mar 2001 09:31:07 -0800" Message-ID: Lines: 62 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Jason R Thorpe writes: > On Wed, Mar 14, 2001 at 12:12:57PM +0100, Markus Friedl wrote: > > > the server implementing sftp can print what ever cookies > > it likes and the sshd has to filter the cookies out. > > but this is not a _protocol_ issue. > > Hm, this doesn't really strike me as good design -- if we all agree that > subsystems require only a bi-directional stream communication channel, > then it seems like a cop-out to rely on some special in-band-but-filtered-out > communication between the sftp server and the transport server. It relies only on a clean bi-directional stream. If you have that (as is usually the case), none of this cookies-and-filtering stuff is needed at all. The problem is that on systems where both of the conditions below are true, * Subsystems are implemented as external programs that are exec:ed via the user's login shell. * The shell startup scripts, either system global scripts or the user's personal scripts, are broken and send some random junk to the shell's stdout. the connection between the ssh server and the sub-system server is *not* a clean stream, it is polluted. Tero and others that advocate cookies believe that it is important that the protocol works even in this case, where you don't have a clean and tidy channel. There are several possible solutions for cleaning it up: 1. Don't start the login shell, just exec the sub-system server directly. I think the convention to use the login shell is peculiar to unix. Tero seems to believe that VMS and mainframes have similar problems, I don't know but that sounds quite unlikely to me. 2. Fix the scripts. You'd want to do that anyway, a .bashrc that writes to stdout is utterly broken and may cause all sorts of trouble. 3. Let the server tidy up, by looking for some data that resembles the real sub-system protocol data, and filter out everything before that. 4. Require clients to perform the same filtering. Tero seems to argue that (4) is the preferable solution. I think (2) is the only good solution, and if that for some reason is impractical, I'd choose between (1) and (3) (or other local tricks like the fd juggling that someone else proposed). I.e. solve the problem locally. Pushing a server side configuration error over to the clients to deal with seems wrong. And for *all* the solutions but (1), it's *still* possible for both users and sysadms to screw things up by writing stuff in the shell startup scripts. Consider this .bashrc: #! /bin/bash (sleep 17; echo "I'm alive!") & /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 14:00:25 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01434 for ; Wed, 14 Mar 2001 14:00:24 -0500 (EST) Received: (qmail 7533 invoked by uid 605); 14 Mar 2001 19:00:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7516 invoked from network); 14 Mar 2001 19:00:18 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 14 Mar 2001 19:00:18 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA03337; Wed, 14 Mar 2001 11:00:14 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA15011; Wed, 14 Mar 2001 14:00:13 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f2EJ08919921; Wed, 14 Mar 2001 14:00:08 -0500 (EST) Message-Id: <200103141900.f2EJ08919921@thunk.east.sun.com> From: Bill Sommerfeld To: nisse@lysator.liu.se (Niels M ller) cc: ietf-ssh@netbsd.org Subject: subsystem invocation (non-serious message) In-reply-to: Your message of "14 Mar 2001 19:06:05 +0100." Reply-to: sommerfeld@east.sun.com Date: Wed, 14 Mar 2001 14:00:08 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list [working group chair hat off. raving lunatic anti-csh bigot hat on.] So, this whole issue is caused by a well-known and well-understood interaction between naive users and csh; while it is possible to misconfigure other shells in the same way, it appears that, in practice, it happens much less frequently. Simon Tatham's alternative would be perfect, except for one fatal problem -- csh and csh-derived shells (stupidly) close descriptors other than 0, 1, and 2. Traditional sh-derived shells (including ksh, bash, zsh, and others) do not have this bug. This is clearly a local issue, easily fixed by removing the offending shell. [if you take this message seriously, you need a vacation..] - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 14:01:09 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01468 for ; Wed, 14 Mar 2001 14:01:09 -0500 (EST) Received: (qmail 7949 invoked by uid 605); 14 Mar 2001 19:01:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7942 invoked from network); 14 Mar 2001 19:01:03 -0000 Received: from hutcs.cs.hut.fi (kivinen@130.233.192.7) by mail.netbsd.org with SMTP; 14 Mar 2001 19:01:03 -0000 Received: (from kivinen@localhost) by hutcs.cs.hut.fi (8.9.3/8.9.3) id VAA27186; Wed, 14 Mar 2001 21:00:55 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Wed, 14 Mar 2001 21:00:55 +0200 (EET) From: Tero Kivinen To: nisse@lysator.liu.se (Niels MЖller) Cc: Markus Friedl , ietf-ssh@netbsd.org Subject: Re: last-call issues.. In-Reply-To: References: <200103132344.f2DNiV918694@thunk.east.sun.com> <15023.19422.241111.704340@hutcs.cs.hut.fi> <20010314121257.B25704@faui02.informatik.uni-erlangen.de> <15023.33334.769693.20580@hutcs.cs.hut.fi> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <15023.48388.519459.708561@hutcs.cs.hut.fi> Organization: Helsinki University of Technology X-Edit-Time: 12 min X-Total-Time: 12 min Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA01468 Niels MЖller writes: > I think he's saying that if filtering is done at the server end, > clients need not know about it, and it's therefore not a protocol > issue at all. I don't want the transport/connection layer server/client to know too much about the subsystem protocol. The subsystem client/server DO know about the subsystem protocol and they CAN detect if the input is valid subsystem protocol or not. If it is not, then they can ignore stuff until they see something familiar.... > If you just use the first SSH_FXP_VERSION packet as the cookie, that's > no problem (except that lshd doesn't do any filtering). Yes, I exactly think that SSH_FXP_VERSION would be used as a magic cookie, but transport/connection layer server/client does not need to know anything about that. They just let everything through. The other end sftp client/server will know that the first packet will contain xxxx xxxx 02 0000 0003 ... and they should ignore everything before they see that coming from the stdin. > A different problem is that the server needs to know how to recognize > the start of the real communication for each subsystem. That's a > little painful for those who implement filtering, but I think that is > the price you have to pay in order to keep the clients from knowing > about the ugliness. And it shouldn't be too difficult, you can have a > simple table like Simply make the client to say: while (check_if_valid_subsystem_version_packet(input_packet, len) == FAIL) { input_packet++, len--; /* Read more data if there isn't enough in the input_buffer. */ } and then when succeeds, then start the real protocol code. Both your server and client MUST do that already, because there can be extra junk before the SSH-2.0-xxxx version string. I don't want to put this code to the transport/connection server/client, I want to put to the subsystem server/client, as it knows about the subsystem protocol. Also it is not MUST to specify such thing in the subsystem protocol, but it might be good idea to add the text saying so to the subsystem protocol specificiation. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 14:23:46 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01883 for ; Wed, 14 Mar 2001 14:23:45 -0500 (EST) Received: (qmail 10422 invoked by uid 605); 14 Mar 2001 19:23:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10414 invoked from network); 14 Mar 2001 19:23:38 -0000 Received: from yeah-baby.shagadelic.org (HELO dr-evil.shagadelic.org) (208.176.2.162) by mail.netbsd.org with SMTP; 14 Mar 2001 19:23:38 -0000 Received: by dr-evil.shagadelic.org (Postfix, from userid 7518) id 89D2A18B65; Wed, 14 Mar 2001 11:23:07 -0800 (PST) Date: Wed, 14 Mar 2001 11:23:07 -0800 From: Jason R Thorpe To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: ietf-ssh@netbsd.org Subject: Re: last-call issues.. Message-ID: <20010314112307.T16238@dr-evil.shagadelic.org> Reply-To: thorpej@zembu.com Mail-Followup-To: Jason R Thorpe , =?iso-8859-1?Q?Niels_M=F6ller?= , ietf-ssh@netbsd.org References: <200103132344.f2DNiV918694@thunk.east.sun.com> <15023.19422.241111.704340@hutcs.cs.hut.fi> <20010314121257.B25704@faui02.informatik.uni-erlangen.de> <20010314093107.R16238@dr-evil.shagadelic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from nisse@lysator.liu.se on Wed, Mar 14, 2001 at 07:06:05PM +0100 Organization: Zembu Labs, Inc. Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit On Wed, Mar 14, 2001 at 07:06:05PM +0100, Niels MЖller wrote: > 1. Don't start the login shell, just exec the sub-system server > directly. I think the convention to use the login shell is peculiar > to unix. Tero seems to believe that VMS and mainframes have similar > problems, I don't know but that sounds quite unlikely to me. Possibly peculiar to current unix implementations. Unix certainly doesn't require a shell to intervene for programs started by e.g. inetd(8). I seems reasonable to me to do it this way, as well. However, read on :-) > 2. Fix the scripts. You'd want to do that anyway, a .bashrc that > writes to stdout is utterly broken and may cause all sorts of > trouble. > > 3. Let the server tidy up, by looking for some data that resembles the > real sub-system protocol data, and filter out everything before that. > > 4. Require clients to perform the same filtering. > > Tero seems to argue that (4) is the preferable solution. I think (2) > is the only good solution, and if that for some reason is impractical, > I'd choose between (1) and (3) (or other local tricks like the fd juggling > that someone else proposed). I.e. solve the problem locally. > > Pushing a server side configuration error over to the clients to deal > with seems wrong. Well, it's not clear that it's a "configuration error". It could be debugging information that the client could choose to display on the user interface. Let's take a broader look. You say that SFTP requires a "clean bi-directional stream", which is provided by a transport layer. Well, really, the SSH protocol transport layer itself requires the same thing -- it happens to be provided by TCP. However, in the SSH transport setup, we allow "junk" to exist on the "channel" (the TCP connection) up until the protocol version exchange message, and it is the responsibility of the client to cope with this. While the transport document describes the intended use of this feature, it doesn't *require* that it be the only use. Now, since no one is arguing (as far as I can tell) that the transport document should be changed in this regard, I personally see no reason not to be consistent with it when dealing with subsystems. Seriously -- in concept, what is *really* different from the transport that the SSH transport protocol runs over and the transport (the SSH transport) that a subsystem runs over? Nothing! They're both bi-directional streams -- the latter happens to be secured. If they're both conceptually the same, then I think we should treat them the same way. > And for *all* the solutions but (1), it's *still* possible for both > users and sysadms to screw things up by writing stuff in the shell > startup scripts. Consider this .bashrc: > > #! /bin/bash > > (sleep 17; echo "I'm alive!") & Sure, and you could have a buggy TCP implementation on the peer, as well (say, which transmits garbage in one of the segments). What happens in that case? The "channel" that the SSH transport runs on gets killed (by the SSH transport implementation -- presumably, the MAC would fail, or something). If we get a bogus clump of data on the "channel" that the subsystem is using, then the subsystem can kill the channel (by exiting, for example) if it causes a protocol error for the subsystem. -- -- Jason R. Thorpe From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 14:30:19 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02071 for ; Wed, 14 Mar 2001 14:30:18 -0500 (EST) Received: (qmail 12295 invoked by uid 605); 14 Mar 2001 19:30:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12288 invoked from network); 14 Mar 2001 19:30:10 -0000 Received: from most.weird.com (?G7ix1verfB0ugqZvNPGZydKvu5258edR27jyvULB+n90yWTXe2xTHQNH7EVukVdah51cCs9YUnY=?@204.92.254.2) by mail.netbsd.org with SMTP; 14 Mar 2001 19:30:10 -0000 Received: from proven.weird.com([204.92.254.15]) (3323 bytes) by most.weird.com via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) (ident <[PRh2n81pureIVjABPEFYjoY2PMXrcU58RaQUhxcttQv41KdsKAQpSRNpSdWn+bH6VyQHBFJ/Uq0EsDbABy1trg==]> using rfc1413) id for ; Wed, 14 Mar 2001 14:29:34 -0500 (EST) (Smail-3.2.0.112-Pre 2000-Feb-17 #12 built 2001-Feb-5) Received: by proven.weird.com (Postfix, from userid 1000) id C51488C; Wed, 14 Mar 2001 14:29:00 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: woods@weird.com (Greg A. Woods) To: Mats Andersson Cc: SSH Users Mailing List , openssh-unix-dev@mindrot.org, ietf-ssh@netbsd.org Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems In-Reply-To: References: <20010314040017.5B6518C@proven.weird.com> X-Mailer: VM 6.90 under Emacs 21.0.97.1 Reply-To: woods@weird.com (Greg A. Woods) Organization: Planix, Inc.; Toronto, Ontario; Canada Message-Id: <20010314192900.C51488C@proven.weird.com> Date: Wed, 14 Mar 2001 14:29:00 -0500 (EST) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit [ On Wednesday, March 14, 2001 at 09:02:20 (+0100), Mats Andersson wrote: ] > Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems > > > Good, since we're speaking about the protocols here, this is the only > mention of subsystems in the sftp draft I'm aware of: > > ... > When used with the Secure Shell protocol suite, this protocol is intended > to be used from the Secure Shell Connection Protocol as a subsystem, as > described in [SECSH-CONN], Section ``Starting a Shell or a Command''. The > subsystem name used with this protocol is "sftp". > ... > > As you may see this indeed does not state any dependency, it only gives a > recomendation for intended usage. Well, for any amount of inter-operabiltiy it certainly does imply complete dependency. For example no SSH-v2.x implemention which follows this recommendation can possibly inter-operate with any other implementation which does not. > You might also have noticed (since I > assume you indeed have read the drafts) that the subsystem feature is not > part of the transport protocol, it is a (very tiny, one could add) feature > in the connection protocol. Yes, but it it a wart none the less which leads to inter-operatibility problems that have already been seen "in the field." > You have almost surely also seen that one > argument was that a subsystem might be built into the ssh server which is > probably one good reason for having it in the spec. And I've already countered that argument showing that it is totally bogus. > Apart from this, you are of course also free to define whatever other > fancy "independent" protocols you might think of either as subsystems or > as ordinary "independent" servers running across stdio (one might note > here that there is no difference in practice as for how these should work > since both only "see" a stream to its peer). ... leading to even more critical inter-operability problems.... -- Greg A. Woods +1 416 218-0098 VE3TCP Planix, Inc. ; Secrets of the Weird From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 14:37:42 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02576 for ; Wed, 14 Mar 2001 14:37:41 -0500 (EST) Received: (qmail 14739 invoked by uid 605); 14 Mar 2001 19:37:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14725 invoked from network); 14 Mar 2001 19:37:27 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 14 Mar 2001 19:37:27 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20565; Wed, 14 Mar 2001 11:37:24 -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 OAA29508; Wed, 14 Mar 2001 14:37:23 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f2EJbH920087; Wed, 14 Mar 2001 14:37:17 -0500 (EST) Message-Id: <200103141937.f2EJbH920087@thunk.east.sun.com> From: Bill Sommerfeld To: nisse@lysator.liu.se (Niels M ller) cc: ietf-ssh@netbsd.org Subject: subsystem cookies (was Re: last-call issues.. ) In-reply-to: Your message of "14 Mar 2001 19:06:05 +0100." Reply-to: sommerfeld@east.sun.com Date: Wed, 14 Mar 2001 14:37:17 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list I continue to have difficulty seeing this as anything other than a purely local implementation issue, not a matter which requires BIZARRE HACKS in the protocol. My understanding is that the motivation for the "subsystem cookie" hacks originated from vendors of clients for non-UNIX systems who didn't want to have to do basic UNIX support. Given that a client vendor already has to be able to say "it's the server's fault, talk to your server vendor", I don't see what the big deal is, but.. > (sleep 17; echo "I'm alive!") & That's a contrived example. Here are some non-contrived examples which will do similar damage (or worse); I've seen all of the following in practice: - catastrophic error which kills the shell - prompting the user for input and waiting for an answer (with no read timeout) - exec'ing a different shell with different arguments. - running programs such as the X11 "resize" program (which sends an ANSI escape sequence to trigger an answerback message) - starting backgrounded X programs (which will then asynchronously spew error messages into the output stream when they can't find the X server) If we want to be robust against user configuration errors, where do we draw the line? I don't think it's worthwhile to even start down this road. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 14:45:21 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02696 for ; Wed, 14 Mar 2001 14:45:20 -0500 (EST) Received: (qmail 16651 invoked by uid 605); 14 Mar 2001 19:45:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16633 invoked from network); 14 Mar 2001 19:45:12 -0000 Received: from most.weird.com (?KCktxWHGV2uM8UNBt6SfYYj5lEB/IiZlHTy5RAiGRErkGMxNwNxDOFRTsQDmDUp2NLb7EP/v3X0=?@204.92.254.2) by mail.netbsd.org with SMTP; 14 Mar 2001 19:45:12 -0000 Received: from proven.weird.com([204.92.254.15]) (3633 bytes) by most.weird.com via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) (ident <[I5MjZtdAl2bapNgtW60lPtOm0KBLZ7R9JEiLUgfu3N4NKXpAQ0ZRT+p9pnmdZZdxX11ISjdtniJX9bR9DXyJxw==]> using rfc1413) id for ; Wed, 14 Mar 2001 14:43:59 -0500 (EST) (Smail-3.2.0.112-Pre 2000-Feb-17 #12 built 2001-Feb-5) Received: by proven.weird.com (Postfix, from userid 1000) id 8BC218C; Wed, 14 Mar 2001 14:43:49 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: woods@weird.com (Greg A. Woods) To: Markus Friedl Cc: Jason R Thorpe , ietf-ssh@netbsd.org Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems In-Reply-To: <20010314094955.F15426@faui02.informatik.uni-erlangen.de> References: <9DC8BBAD4FF100408FC7D18D1F092286039C96@condor.mhsc.com> <20010312031041.9D7AA8C@proven.weird.com> <20010312222432.A7800@folly> <20010313192046.46CC78C@proven.weird.com> <20010313222053.B22241@folly> <20010314035109.6F32E8C@proven.weird.com> <20010313202548.J16238@dr-evil.shagadelic.org> <20010314094955.F15426@faui02.informatik.uni-erlangen.de> X-Mailer: VM 6.90 under Emacs 21.0.97.1 Reply-To: woods@weird.com (Greg A. Woods) Organization: Planix, Inc.; Toronto, Ontario; Canada Message-Id: <20010314194349.8BC218C@proven.weird.com> Date: Wed, 14 Mar 2001 14:43:49 -0500 (EST) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit [ On Wednesday, March 14, 2001 at 09:49:55 (+0100), Markus Friedl wrote: ] > Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems > > you could use a "exec" request as well, Exactly. > but then you need to have > sftp-server in the path or know the full pathname on the remote host "In the path" or by way of any other suitable platform-specific mechanism to find an appropriate administrator-defined program matching the request. > "subsystem" > just allows an additional level of indirection. That extra indirection has no benefit. First off since as yet there's no registry set up (or even hinted at) to define these names there's inevitably going to be conflict because any name can mean anything (unless perhaps it's defined in some other approved and *referenced* RFC). Only negative impact will result from these already visible inter-operability problems without. Even with a proper subsystem name registry (eg. through IANA) the the danger of such naming schemes in higher level protocols are visible in numerous existing IETF approved protocols (eg. MIME). > it also allows easy > restriction, e.g. a user is allowed to send request only for this > and that subsystem. I'm not sure there's any real security there, and my instinct says there's not.... Unfortunately this is an implementation specific problem and something the protocol specifications will have a hard time mandating (you can mandate security all you want but unless the people making it work are 101% successful your mandate is useless and turns into a very dangerous false sense of security where there is in fact none). In any case given specific implementation details it's fairly likely that one can imagine an exploit where damage of some sort can be done even if the remote client user is restricted to using any given "built-in subsystem". This is particularly true of a file transfer style of application which permits arbitrary file types to be transfered (or to which the real file type can be masked). -- Greg A. Woods +1 416 218-0098 VE3TCP Planix, Inc. ; Secrets of the Weird From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 14:46:35 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02765 for ; Wed, 14 Mar 2001 14:46:35 -0500 (EST) Received: (qmail 17035 invoked by uid 605); 14 Mar 2001 19:46:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17028 invoked from network); 14 Mar 2001 19:46:30 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 14 Mar 2001 19:46:30 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA25245; Wed, 14 Mar 2001 11:46:25 -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 OAA01745; Wed, 14 Mar 2001 14:46:24 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f2EJkI920109; Wed, 14 Mar 2001 14:46:19 -0500 (EST) Message-Id: <200103141946.f2EJkI920109@thunk.east.sun.com> From: Bill Sommerfeld To: Wei Dai cc: Bill Sommerfeld , ietf-ssh@netbsd.org Subject: Re: last-call issues.. In-reply-to: Your message of "Wed, 14 Mar 2001 07:52:42 PST." <20010314075241.D24330@eskimo.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 14 Mar 2001 14:46:18 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > As a seperate issue, I'd also like to see UDP forwarding some time in the > future. "Please send draft". - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 15:10:47 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03192 for ; Wed, 14 Mar 2001 15:10:46 -0500 (EST) Received: (qmail 25947 invoked by uid 605); 14 Mar 2001 20:10:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25939 invoked from network); 14 Mar 2001 20:10:40 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 14 Mar 2001 20:10:40 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02209; Wed, 14 Mar 2001 12:05:37 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29317; Wed, 14 Mar 2001 15:05:36 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f2EK5U920191; Wed, 14 Mar 2001 15:05:30 -0500 (EST) Message-Id: <200103142005.f2EK5U920191@thunk.east.sun.com> From: Bill Sommerfeld To: woods@weird.com (Greg A. Woods) cc: Markus Friedl , Jason R Thorpe , ietf-ssh@netbsd.org Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems In-reply-to: Your message of "Wed, 14 Mar 2001 14:43:49 EST." <20010314194349.8BC218C@proven.weird.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 14 Mar 2001 15:05:30 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > First off since as yet there's > no registry set up (or even hinted at) to define these names there's > inevitably going to be conflict because any name can mean anything > (unless perhaps it's defined in some other approved and *referenced* > RFC). See the IANA considerations section of draft-ietf-secsh-architecture-07.txt, section 7, which is referenced from the various other drafts. "Names with the at-sign ('@') in them are allocated by the owner of DNS name after the at-sign (hierarchical allocation in [RFC-2343])." Subsystem names aren't currently explicitly listed there but we can (and should) fix that easily enough. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 15:24:02 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03518 for ; Wed, 14 Mar 2001 15:24:01 -0500 (EST) Received: (qmail 29969 invoked by uid 605); 14 Mar 2001 20:23:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29962 invoked from network); 14 Mar 2001 20:23:52 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 14 Mar 2001 20:23:52 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA12108; Wed, 14 Mar 2001 12:23:41 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA02609; Wed, 14 Mar 2001 15:23:39 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f2EKNY920231; Wed, 14 Mar 2001 15:23:34 -0500 (EST) Message-Id: <200103142023.f2EKNY920231@thunk.east.sun.com> From: Bill Sommerfeld To: Tero Kivinen cc: Markus Friedl , sommerfeld@east.sun.com, ietf-ssh@netbsd.org Subject: Re: last-call issues.. In-reply-to: Your message of "Wed, 14 Mar 2001 16:47:13 +0200." <15023.33334.769693.20580@hutcs.cs.hut.fi> Reply-to: sommerfeld@east.sun.com Date: Wed, 14 Mar 2001 15:23:34 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > If we make it that way, then each subsystem implementation is tied to > each connection layer implementation, i.e you cannot take SSH > Communications Security's sftp-server and run it using lsh server, > because the lsh does not know which kind of cookies the sftp-server is > going to use. Each server implementation which wants to allow subsystems to plug in needs to define an "API" or "ABI" for this. Such an API/ABI is necessarily OS-family-specific. It would be very cool if all the unix server vendors were to get together and define a common subsystem interface.. but that's not a plausible work item for this working group -- API's are out of scope for the IETF.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 16:49:17 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05160 for ; Wed, 14 Mar 2001 16:49:17 -0500 (EST) Received: (qmail 27455 invoked by uid 605); 14 Mar 2001 21:48:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27443 invoked from network); 14 Mar 2001 21:48:55 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 14 Mar 2001 21:48:55 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 4D8B382F554; Wed, 14 Mar 2001 22:48:54 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id WAA26943; Wed, 14 Mar 2001 22:48:53 +0100 (MET) To: thorpej@zembu.com Cc: ietf-ssh@netbsd.org Subject: Re: last-call issues.. References: <200103132344.f2DNiV918694@thunk.east.sun.com> <15023.19422.241111.704340@hutcs.cs.hut.fi> <20010314121257.B25704@faui02.informatik.uni-erlangen.de> <20010314093107.R16238@dr-evil.shagadelic.org> <20010314112307.T16238@dr-evil.shagadelic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 14 Mar 2001 22:48:53 +0100 In-Reply-To: Jason R Thorpe's message of "Wed, 14 Mar 2001 11:23:07 -0800" Message-ID: Lines: 15 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Jason R Thorpe writes: > Well, it's not clear that it's a "configuration error". It could be > debugging information that the client could choose to display on the > user interface. Any such debugging information should be sent to *stderr*. I've not written any sftp client yet, but I believe any reasonable one should tolerate stderr data and redirect it either to the client's own stderr or to /dev/null. But sending debugging information (from shell startup scripts) to stdout *is* seriously broken, and a configuration error. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 16:59:03 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05324 for ; Wed, 14 Mar 2001 16:59:02 -0500 (EST) Received: (qmail 1210 invoked by uid 605); 14 Mar 2001 21:58:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1193 invoked from network); 14 Mar 2001 21:58:57 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 14 Mar 2001 21:58:57 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 8BBB382F52B; Wed, 14 Mar 2001 22:58:55 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id WAA03748; Wed, 14 Mar 2001 22:58:55 +0100 (MET) To: Tero Kivinen Cc: Markus Friedl , ietf-ssh@netbsd.org Subject: Re: last-call issues.. References: <200103132344.f2DNiV918694@thunk.east.sun.com> <15023.19422.241111.704340@hutcs.cs.hut.fi> <20010314121257.B25704@faui02.informatik.uni-erlangen.de> <15023.33334.769693.20580@hutcs.cs.hut.fi> <15023.48388.519459.708561@hutcs.cs.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit From: nisse@lysator.liu.se (Niels MЖller) Date: 14 Mar 2001 22:58:54 +0100 In-Reply-To: Tero Kivinen's message of "Wed, 14 Mar 2001 21:00:55 +0200 (EET)" Message-ID: Lines: 32 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Tero Kivinen writes: > Niels MЖller writes: > > I think he's saying that if filtering is done at the server end, > > clients need not know about it, and it's therefore not a protocol > > issue at all. > > I don't want the transport/connection layer server/client to know too > much about the subsystem protocol. The subsystem client/server DO know > about the subsystem protocol and they CAN detect if the input is valid > subsystem protocol or not. If it is not, then they can ignore stuff > until they see something familiar.... I think I have talked too much about this already, but let me write a short summary and then I'll try hard to stay quiet for a day or two: You think about filtering as knowledge about the sub-system protocol, which makes it natural to think that the sub-system client should know about it. I think about it as knowing about possible brokenness in the exec-by-login-shell mechanism, which is a somewhat obscure implementation detail in (most) ssh servers on Un*x, and working around that. From that point of view, requiring the client to do the working around is clearly not the right thing to do. It's the transport layer's responsibility to provide a clean channel, with no garbage, for the sub-system layer to use. If the transport layer fails to do that, for any reason, it's not the sub-system's fault. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 17:49:50 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05929 for ; Wed, 14 Mar 2001 17:49:49 -0500 (EST) Received: (qmail 16147 invoked by uid 605); 14 Mar 2001 22:49:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16140 invoked from network); 14 Mar 2001 22:49:43 -0000 Received: from ixion.tartarus.org (195.153.205.133) by mail.netbsd.org with SMTP; 14 Mar 2001 22:49:43 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 14dK5N-0001NQ-00; Wed, 14 Mar 2001 22:49:41 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <200103141900.f2EJ08919921@thunk.east.sun.com> Subject: Re: subsystem invocation (non-serious message) Message-Id: Date: Wed, 14 Mar 2001 22:49:41 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Bill Sommerfeld wrote: > Simon Tatham's alternative would be perfect, except for one fatal > problem -- csh and csh-derived shells (stupidly) close descriptors > other than 0, 1, and 2. Traditional sh-derived shells (including ksh, > bash, zsh, and others) do not have this bug. > > This is clearly a local issue, easily fixed by removing the offending > shell. I did propose a modified method using named pipes which would even work with csh. This was clearly a bug; it sounds as if you'd prefer a method that actively discouraged csh :-) Cheers, Simon -- Simon Tatham "I'm cross. I'm going to have a tantrum. How do I start?" - my uncle From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 14 19:08:05 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06814 for ; Wed, 14 Mar 2001 19:08:04 -0500 (EST) Received: (qmail 429 invoked by uid 605); 15 Mar 2001 00:07:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 420 invoked from network); 15 Mar 2001 00:07:57 -0000 Received: from cpe-203-45-24-18.vic.bigpond.net.au (HELO kado.mindrot.org) (foobar@203.45.24.18) by mail.netbsd.org with SMTP; 15 Mar 2001 00:07:57 -0000 Received: from toad.mindrot.org (toad.mindrot.org [203.44.118.252]) by kado.mindrot.org (Postfix) with ESMTP id 324C09009; Thu, 15 Mar 2001 09:36:04 +1100 (EST) Received: from mothra.mindrot.org (mothra.mindrot.org [203.44.118.225]) by toad.mindrot.org (Postfix) with ESMTP id F3D381A1F3; Thu, 15 Mar 2001 11:07:53 +1100 (EST) Received: by mothra.mindrot.org (Postfix, from userid 500) id E97D896FC7; Thu, 15 Mar 2001 11:07:51 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by mothra.mindrot.org (Postfix) with ESMTP id E8BFD96F71; Thu, 15 Mar 2001 11:07:51 +1100 (EST) Date: Thu, 15 Mar 2001 11:07:51 +1100 (EST) From: Damien Miller To: "Greg A. Woods" Cc: Mats Andersson , SSH Users Mailing List , , Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems In-Reply-To: <20010314192900.C51488C@proven.weird.com> Message-ID: X-Paranoia: just because you're paranoid doesn't mean they aren't out to get you MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, 14 Mar 2001, Greg A. Woods wrote: > > You might also have noticed (since I > > assume you indeed have read the drafts) that the subsystem feature is not > > part of the transport protocol, it is a (very tiny, one could add) feature > > in the connection protocol. > > Yes, but it it a wart none the less which leads to inter-operatibility > problems that have already been seen "in the field." Rubbish - your example of a misconfigured sshd doesn't count. Should we perhaps start regarding misconfigured inetd's as evidence of the brokenness of TCP? -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 15 10:41:31 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01485 for ; Thu, 15 Mar 2001 10:41:31 -0500 (EST) Received: (qmail 18072 invoked by uid 605); 15 Mar 2001 15:41:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18065 invoked from network); 15 Mar 2001 15:41:26 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 15 Mar 2001 15:41:26 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id B39DF82F4F9 for ; Thu, 15 Mar 2001 16:40:39 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id QAA16186; Thu, 15 Mar 2001 16:40:39 +0100 (MET) To: ietf-ssh@netbsd.org Subject: Messages with exit-signal Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 15 Mar 2001 16:40:39 +0100 Message-ID: Lines: 42 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit I'm just updating lsh and lshd to use the current signal-related requests. Two questions: 1. What should I do with unknown signal numbers? I.e. if the OS delivers a signal that my implementation doesn't particularly know about. Some options are: Don't send any message at all. Use the empty string for the signal name. Use a local signal name like "unknown-signal@lysator.liu.se". Use a local signal name like "signal-24@lysator.liu.se". Do the config.guess-hack, using a name like "XCPU@pentium3-pc-linux-gnu.config.guess". I want something simple, so I don't want to go for anything more complex than the first three alternatives unless there is a real chance that it will be both useful and interoperable. I think I'd prefer the second alternative, using an empty string to represent unknown signals. Advice? 2. What should the accompanying message look like? Some of the alternatives are "Segmentation fault" (i.e. whatever strerror returns) "Segmentation fault (core dumped)" "Process died: Segmentation fault" I think I'd prefer the first. If the client chooses to display the message, it has to add some information anyway in order to clearly indicate that the message originated at the remote end, so it seems natural to let the client be responsible for making the message look pretty and only send the information that the client can't figure out by itself, i.e. only send the string returned by strerror. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 15 11:05:02 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01925 for ; Thu, 15 Mar 2001 11:05:02 -0500 (EST) Received: (qmail 20705 invoked by uid 605); 15 Mar 2001 16:04:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20698 invoked from network); 15 Mar 2001 16:04:58 -0000 Received: from ixion.tartarus.org (195.153.205.133) by mail.netbsd.org with SMTP; 15 Mar 2001 16:04:58 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 14daFE-00054y-00; Thu, 15 Mar 2001 16:04:56 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org Subject: Whither USERAUTH_BANNER? Message-Id: Date: Thu, 15 Mar 2001 16:04:56 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list According to the latest userauth draft, the SSH server can send a USERAUTH_BANNER at any time. Presumably, since the purpose of a banner is to be displayed before authentication, it's likely to send the banner as the very first packet of the userauth protocol, right? This presents a problem. I'm currently trying to code banner support into PuTTY. Unlike Unix ssh clients, PuTTY will prompt the user for a username if there isn't one already supplied in the configuration. Of course this must be done _before_ sending the first USERAUTH attempt. But I'd like to print the banner before printing the username prompt. If I were to _know_ the server would send a banner, I could start the userauth protocol by waiting for a banner packet, printing the banner, and then giving the username prompt. But I don't; it's entirely allowable for the server not to send any banner. So if I start by waiting for a packet, I'll block for ever. So what I have to do instead is send a USERAUTH_REQUEST, and _then_ wait for a packet. If the packet is a banner, I print the banner, and then wait for _another_ packet which is the response to the request. Unfortunately, in order to send a USERAUTH_REQUEST, I have to have already prompted for a username. So I'm forced to the conclusion that I MUST show my username prompt _before_ I print the remote banner. (I suppose I could send a USERAUTH_REQUEST type `none' attempting to authenticate as a spurious user, just in order to receive the banner; but then I'd have to switch usernames in the middle of the authentication, and the server is allowed to disconnect if I do that.) Should there be something I can do about this? What I'd like is something like an SSH_MSG_PING, which I can send and then wait for a reply, so that I could then receive the USERAUTH_BANNER while waiting for the PING_REPLY. If you see what I mean. Also, while I'm here ... is there a policy on line-ending conventions within the banner message? Should I be translating \n into my local line end, or should the server be translating its local line end into \r\n, or what? Cheers, Simon -- Simon Tatham These are my opinions. There are many like them but these ones are mine. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 15 12:19:47 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03633 for ; Thu, 15 Mar 2001 12:19:46 -0500 (EST) Received: (qmail 8097 invoked by uid 605); 15 Mar 2001 17:19:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8088 invoked from network); 15 Mar 2001 17:19:37 -0000 Received: from most.weird.com (?VPa1ISdOYJpupPE6Nsoi72SHLpKBn4EnpjcNV2+n5bIYAx2rbI+hdKMv7Hb2cpTLqNio/BNxWtM=?@204.92.254.2) by mail.netbsd.org with SMTP; 15 Mar 2001 17:19:37 -0000 Received: from proven.weird.com([204.92.254.15]) (2187 bytes) by most.weird.com via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) (ident <[pqSw/GqCtpajLcTwMm4PG7mVA82MjXD+R0c5G6GpZd/eAksWLVUgBFg0xwfBRLhP09e8TC3bsusvF5a0liXJLA==]> using rfc1413) id for ; Thu, 15 Mar 2001 12:19:19 -0500 (EST) (Smail-3.2.0.112-Pre 2000-Feb-17 #12 built 2001-Feb-5) Received: by proven.weird.com (Postfix, from userid 1000) id 2007E8C; Thu, 15 Mar 2001 12:19:16 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: woods@weird.com (Greg A. Woods) To: sommerfeld@east.sun.com Cc: Markus Friedl , Jason R Thorpe , ietf-ssh@netbsd.org Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems In-Reply-To: <200103142005.f2EK5U920191@thunk.east.sun.com> References: <20010314194349.8BC218C@proven.weird.com> <200103142005.f2EK5U920191@thunk.east.sun.com> X-Mailer: VM 6.90 under Emacs 21.0.97.1 Reply-To: woods@weird.com (Greg A. Woods) Organization: Planix, Inc.; Toronto, Ontario; Canada Message-Id: <20010315171916.2007E8C@proven.weird.com> Date: Thu, 15 Mar 2001 12:19:16 -0500 (EST) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit [ On Wednesday, March 14, 2001 at 15:05:30 (-0500), Bill Sommerfeld wrote: ] > Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems > > See the IANA considerations section of > draft-ietf-secsh-architecture-07.txt, section 7, which is referenced > from the various other drafts. > > "Names with the at-sign ('@') in them are allocated by the owner of DNS > name after the at-sign (hierarchical allocation in [RFC-2343])." > > Subsystem names aren't currently explicitly listed there but we can > (and should) fix that easily enough. That would certainly help, but it does not excuse the fact that this "subsystems" feature is still an unnecessary wart that will only cause more interoperability problems than it fixes (see my posting of moments ago to the SSH list). -- Greg A. Woods +1 416 218-0098 VE3TCP Planix, Inc. ; Secrets of the Weird From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 15 12:34:54 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04020 for ; Thu, 15 Mar 2001 12:34:53 -0500 (EST) Received: (qmail 10497 invoked by uid 605); 15 Mar 2001 17:34:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10490 invoked from network); 15 Mar 2001 17:34:50 -0000 Received: from faui02.informatik.uni-erlangen.de (msfriedl@131.188.30.102) by mail.netbsd.org with SMTP; 15 Mar 2001 17:34:50 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id SAA00866 for ietf-ssh@netbsd.org; Thu, 15 Mar 2001 18:34:48 +0100 (MET) Date: Thu, 15 Mar 2001 18:34:48 +0100 From: Markus Friedl To: ietf-ssh@netbsd.org Subject: secsh-userauth Message-ID: <20010315183448.A858@faui02.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi, what is the rational for the following paragraphs from draft-ietf-secsh-userauth-09.txt? > 2.1. Authentication Requests > > The user name and service are repeated in every new authentication > attempt, and MAY change. The server implementation MUST carefully check > them in every message, and MUST flush any accumulated authentication > states if they change. If it is unable to flush some authentication > state, it MUST disconnect if the user or service name changes. why does the server have to disconnect if it is unable (or does not want) to flush the current authentication state? is this really a MUST? I'd prefer a SHOULD, especially since one of the next paragraphs say: > If the requested user does not exist, the server MAY disconnect, or MAY > send a bogus list of acceptable authentication methods, but never accept > any. This makes it possible for the server to avoid disclosing > information on which accounts exist. In any case, if the user does not > exist, the authentication request MUST NOT be accepted. So would it be reasonable if the server does the same thing if the username changes during authentication? -markus From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 15 12:38:00 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04103 for ; Thu, 15 Mar 2001 12:37:59 -0500 (EST) Received: (qmail 11338 invoked by uid 605); 15 Mar 2001 17:37:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11331 invoked from network); 15 Mar 2001 17:37:56 -0000 Received: from faui02.informatik.uni-erlangen.de (msfriedl@131.188.30.102) by mail.netbsd.org with SMTP; 15 Mar 2001 17:37:56 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id SAA00854; Thu, 15 Mar 2001 18:34:25 +0100 (MET) Date: Thu, 15 Mar 2001 18:34:24 +0100 From: Markus Friedl To: "Greg A. Woods" Cc: sommerfeld@east.sun.com, Jason R Thorpe , ietf-ssh@netbsd.org Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems Message-ID: <20010315183424.C22196@faui02.informatik.uni-erlangen.de> References: <20010314194349.8BC218C@proven.weird.com> <200103142005.f2EK5U920191@thunk.east.sun.com> <20010315171916.2007E8C@proven.weird.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20010315171916.2007E8C@proven.weird.com>; from woods@weird.com on Thu, Mar 15, 2001 at 12:19:16PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Mar 15, 2001 at 12:19:16PM -0500, Greg A. Woods wrote: > That would certainly help, but it does not excuse the fact that this > "subsystems" feature is still an unnecessary wart that will only cause > more interoperability problems than it fixes (see my posting of moments > ago to the SSH list). why do "subsystems" cause more problems than "shell" or "exec" especially since "subsystems" is much more general than "shell", so "shell" could be really a 'special' kind of "subsystem"? so "shell" is unnecessary, "subsystem" is not. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 15 14:56:41 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06828 for ; Thu, 15 Mar 2001 14:56:40 -0500 (EST) Received: (qmail 14211 invoked by uid 605); 15 Mar 2001 19:56:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14204 invoked from network); 15 Mar 2001 19:56:33 -0000 Received: from ip212-226-160-97.adsl.kpnqwest.fi (HELO mystery.acr.fi) (212.226.160.97) by mail.netbsd.org with SMTP; 15 Mar 2001 19:56:33 -0000 Received: from localhost (ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) with ESMTP id VAA07755; Thu, 15 Mar 2001 21:54:12 +0200 X-Authentication-Warning: mystery.acr.fi: ylo owned process doing -bs Date: Thu, 15 Mar 2001 21:54:12 +0200 (EET) From: Tatu Ylonen X-Sender: ylo@mystery.acr.fi To: Markus Friedl cc: ietf-ssh@netbsd.org Subject: Re: secsh-userauth In-Reply-To: <20010315183448.A858@faui02.informatik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list > > The user name and service are repeated in every new authentication > > attempt, and MAY change. The server implementation MUST carefully check > > them in every message, and MUST flush any accumulated authentication > > states if they change. If it is unable to flush some authentication > > state, it MUST disconnect if the user or service name changes. > > why does the server have to disconnect if it is unable (or does not > want) to flush the current authentication state? is this really a MUST? > I'd prefer a SHOULD, especially since one of the next paragraphs say: It is a MUST, because some authentication methods may accumulate implicit state in global variables. For example, certain styles of implementing PAM or Kerberos based authentication may leave tickets or other data in essentially global data. If the user name changes, it is critical that all such cached data/credentials is destroyed before starting to authenticate as another user. If we permit leaving such globally stored data/credentials hanging around when the user name changes, we may end up in a situation where first trying to (partially) authenticate as one user and then as another user gives you more rights than directly trying to authenticate as yourself. > > If the requested user does not exist, the server MAY disconnect, or MAY > > send a bogus list of acceptable authentication methods, but never accept > > any. This makes it possible for the server to avoid disclosing > > information on which accounts exist. In any case, if the user does not > > exist, the authentication request MUST NOT be accepted. > > So would it be reasonable if the server does the same thing if the username > changes during authentication? Yes, it would be reasonable to say that the server MUST EITHER disconnect OR behave as if the user name did not exist. It is NOT acceptable to just permit login as another user if already created credentials cannot be removed. (Note that we are talking about a mostly theoretical situation. In most cases, one does not create any credentials before the whole login sequence is completeled. However, Kerberos and PAM APIs may leave global credentials in some potentially real cases, and this may become a real security issue when multiple authentications are required for access). This may also be an issue if certain credentials need to be created before login e.g. to access files (such as .shosts) in the user's remotely mounted home directory.) Tatu SSH Communications Security http://www.ssh.com/ SSH IPSEC Toolkit http://www.ipsec.com/ SSH Secure Shell http://www.ssh.com/products/ssh From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 15 15:14:39 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07426 for ; Thu, 15 Mar 2001 15:14:39 -0500 (EST) Received: (qmail 19272 invoked by uid 605); 15 Mar 2001 20:14:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19265 invoked from network); 15 Mar 2001 20:14:34 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 15 Mar 2001 20:14:34 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11833; Thu, 15 Mar 2001 12:14:23 -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 PAA05281; Thu, 15 Mar 2001 15:14:21 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f2FKEF923601; Thu, 15 Mar 2001 15:14:16 -0500 (EST) Message-Id: <200103152014.f2FKEF923601@thunk.east.sun.com> From: Bill Sommerfeld To: Tatu Ylonen cc: Markus Friedl , ietf-ssh@netbsd.org Subject: Re: secsh-userauth In-reply-to: Your message of "Thu, 15 Mar 2001 21:54:12 +0200." Reply-to: sommerfeld@east.sun.com Date: Thu, 15 Mar 2001 15:14:15 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > > So would it be reasonable if the server does the same thing if the username > > changes during authentication? > > Yes, it would be reasonable to say that the server MUST EITHER disconnect > OR behave as if the user name did not exist. i've added this to the last-call issues list. suggested reword: The user name and service are repeated in every new authentication attempt, and MAY change. The server implementation MUST carefully check them in every message, and MUST flush any accumulated authentication states if they change. If it is unable to flush some authentication state, it MAY immediately disconnect; if it does not disconnect, it MUST NOT accept any future authentication requests (handling the client as if it had presented a nonexistant user name, as below). From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 15 15:58:27 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08002 for ; Thu, 15 Mar 2001 15:58:26 -0500 (EST) Received: (qmail 2344 invoked by uid 605); 15 Mar 2001 20:57:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2322 invoked from network); 15 Mar 2001 20:57:51 -0000 Received: from faui02.informatik.uni-erlangen.de (msfriedl@131.188.30.102) by mail.netbsd.org with SMTP; 15 Mar 2001 20:57:51 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id VAA11955; Thu, 15 Mar 2001 21:57:46 +0100 (MET) Date: Thu, 15 Mar 2001 21:57:46 +0100 From: Markus Friedl To: Tatu Ylonen Cc: ietf-ssh@netbsd.org Subject: Re: secsh-userauth Message-ID: <20010315215746.A1046@faui02.informatik.uni-erlangen.de> References: <20010315183448.A858@faui02.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from ylo@ssh.com on Thu, Mar 15, 2001 at 09:54:12PM +0200 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Mar 15, 2001 at 09:54:12PM +0200, Tatu Ylonen wrote: > > > The user name and service are repeated in every new authentication > > > attempt, and MAY change. The server implementation MUST carefully check > > > them in every message, and MUST flush any accumulated authentication > > > states if they change. If it is unable to flush some authentication > > > state, it MUST disconnect if the user or service name changes. > > > > why does the server have to disconnect if it is unable (or does not > > want) to flush the current authentication state? is this really a MUST? > > I'd prefer a SHOULD, especially since one of the next paragraphs say: > > It is a MUST, because some authentication methods may accumulate implicit > state in global variables. For example, certain styles of implementing > PAM or Kerberos based authentication may leave tickets or other data in > essentially global data. yes, i understand this, my question was ambiguous: i was not asking about the 'MUST flush', but the 'MUST disconnect'. > > So would it be reasonable if the server does the same thing if the username > > changes during authentication? > > Yes, it would be reasonable to say that the server MUST EITHER disconnect > OR behave as if the user name did not exist. ok, so this is another issue for the meeting? -markus From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 15 17:51:02 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09755 for ; Thu, 15 Mar 2001 17:51:02 -0500 (EST) Received: (qmail 1509 invoked by uid 605); 15 Mar 2001 22:50:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1502 invoked from network); 15 Mar 2001 22:50:57 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 15 Mar 2001 22:50:57 -0000 Received: from minbar.fac.cs.cmu.edu by minbar.fac.cs.cmu.edu id aa03221; 15 Mar 2001 17:50 EST Date: Thu, 15 Mar 2001 17:50:11 -0500 (EST) From: Jeffrey Hutzelman X-Sender: jhutz@minbar.fac.cs.cmu.edu To: Niels Mller cc: ietf-ssh@netbsd.org Subject: Re: Messages with exit-signal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On 15 Mar 2001, Niels Mller wrote: > 2. What should the accompanying message look like? > > Some of the alternatives are > > "Segmentation fault" (i.e. whatever strerror returns) > "Segmentation fault (core dumped)" > "Process died: Segmentation fault" You won't get these strings from strerror, because signals are not error numbers. You pretty much have to come up with them yourself. See, for example, sh.init.c in tcsh. The message with " (core dumped)" is not merely an alternate form; it's an indication that a core file was actually produced. This is provided as a bit in the process status returned by wait(). It may be an implementation decision whether to make this information visible to the client; some implementations or sites may prefer not to report this for security reasons. > I think I'd prefer the first. If the client chooses to display the > message, it has to add some information anyway in order to clearly > indicate that the message originated at the remote end, so it seems > natural to let the client be responsible for making the message look > pretty and only send the information that the client can't figure out > by itself, i.e. only send the string returned by strerror. This reasoning clearly eliminates the third variant; the "Process died:" part is superfluous. The " (core dumped)", on the other hand, is _not_ information the client can get elsewhere, since even the concept is UNIX-specific. IMHO, auxillary information like this should be included with the signal message. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 15 18:11:10 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10135 for ; Thu, 15 Mar 2001 18:11:10 -0500 (EST) Received: (qmail 4300 invoked by uid 605); 15 Mar 2001 23:10:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4293 invoked from network); 15 Mar 2001 23:10:55 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 15 Mar 2001 23:10:55 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA04312; Thu, 15 Mar 2001 15:10:49 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA15480; Thu, 15 Mar 2001 18:10:46 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f2FNAe923995; Thu, 15 Mar 2001 18:10:40 -0500 (EST) Message-Id: <200103152310.f2FNAe923995@thunk.east.sun.com> From: Bill Sommerfeld To: Jeffrey Hutzelman cc: Niels Mller , ietf-ssh@netbsd.org Subject: Re: Messages with exit-signal In-reply-to: Your message of "Thu, 15 Mar 2001 17:50:11 EST." Reply-to: sommerfeld@east.sun.com Date: Thu, 15 Mar 2001 18:10:40 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list The exact message sent is a local issue, up to the implementation. That said, I'll digress with.. > You won't get these strings from strerror, because signals are not error > numbers. You pretty much have to come up with them yourself. See, for > example, sh.init.c in tcsh. Many systems implement strsignal() (just checked BSD, Linux, and solaris). - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 16 04:04:37 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00945 for ; Fri, 16 Mar 2001 04:04:36 -0500 (EST) Received: (qmail 29133 invoked by uid 605); 16 Mar 2001 09:04:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29124 invoked from network); 16 Mar 2001 09:04:28 -0000 Received: from ixion.tartarus.org (195.153.205.133) by mail.netbsd.org with SMTP; 16 Mar 2001 09:04:28 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 14dq9q-0008Vu-00; Fri, 16 Mar 2001 09:04:26 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: Subject: Re: Whither USERAUTH_BANNER? Message-Id: Date: Fri, 16 Mar 2001 09:04:26 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Simon Tatham wrote: > Should there be something I can do about this? What I'd like is > something like an SSH_MSG_PING, which I can send and then wait for a > reply, so that I could then receive the USERAUTH_BANNER while > waiting for the PING_REPLY. If you see what I mean. I've now thought of a concrete proposal for this. It involves a new message, SSH_MSG_USERAUTH_SEND_BANNER. - The client MAY send USERAUTH_SEND_BANNER after starting the userauth protocol but before sending any USERAUTH_REQUESTs. - The server MUST respond to USERAUTH_SEND_BANNER with either USERAUTH_FAILURE or USERAUTH_BANNER. - Older servers will respond to USERAUTH_SEND_BANNER with MSG_UNIMPLEMENTED but otherwise ignore it. Hence, the possibilities are: - New server with no banner. Client sends USERAUTH_SEND_BANNER; server sends USERAUTH_FAILURE (`I have no banner'). - New server with banner. Client sends USERAUTH_SEND_BANNER; server sends USERAUTH_BANNER. - Old server with no banner. Client sends USERAUTH_SEND_BANNER; server sends MSG_UNIMPLEMENTED. - Old server with banner. Client sends USERAUTH_SEND_BANNER; server had already sent USERAUTH_BANNER. Client receives and prints banner. Subsequently, client sends first USERAUTH_REQUEST. When it reads replies to this, the first thing it receives is MSG_UNIMPLEMENTED with the sequence number of the SEND_BANNER packet. It ignores this and reads another packet, which is the response to USERAUTH_REQUEST. Authentication proceeds as normal. So unless there's a server out there which fails to behave correctly with respect to unimplemented messages, this method should be completely backwards compatible. Cheers, Simon -- Simon Tatham "loop, infinite _see_ infinite loop" - Index, Borland Pascal Language Guide From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 16 04:20:02 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01040 for ; Fri, 16 Mar 2001 04:20:02 -0500 (EST) Received: (qmail 2911 invoked by uid 605); 16 Mar 2001 09:19:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2904 invoked from network); 16 Mar 2001 09:19:55 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 16 Mar 2001 09:19:55 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id DBA8A82F534; Fri, 16 Mar 2001 10:19:53 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id KAA01644; Fri, 16 Mar 2001 10:19:53 +0100 (MET) To: Simon Tatham Cc: ietf-ssh@netbsd.org Subject: Re: Whither USERAUTH_BANNER? References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 16 Mar 2001 10:19:52 +0100 In-Reply-To: Simon Tatham's message of "Thu, 15 Mar 2001 16:04:56 +0000" Message-ID: Lines: 28 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Simon Tatham writes: > (I suppose I could send a USERAUTH_REQUEST type `none' attempting to > authenticate as a spurious user, just in order to receive the > banner; USERAUTH_REQUEST "none" is used as kind of ping for other purposes, like getting the list of suggested userauth methods. > but then I'd have to switch usernames in the middle of the > authentication, and the server is allowed to disconnect if I do > that.) Hmm, why do you think the server will disconnect? > Also, while I'm here ... is there a policy on line-ending > conventions within the banner message? Should I be translating \n > into my local line end, or should the server be translating its > local line end into \r\n, or what? I don't think there's any policy. If there were, the policy should probably say that lines are terminated with \r\n (not that I particularly like that outdated convention, but that is what is used in the only other place in the protocol that talks about lines, and consistency is important). I think that treating \n as end of line and ignoring all \r-characters should work. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 16 05:24:36 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01474 for ; Fri, 16 Mar 2001 05:24:35 -0500 (EST) Received: (qmail 9944 invoked by uid 605); 16 Mar 2001 10:24:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9937 invoked from network); 16 Mar 2001 10:24:30 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 16 Mar 2001 10:24:30 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 8CA4782F52B; Fri, 16 Mar 2001 11:24:29 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id LAA18904; Fri, 16 Mar 2001 11:24:29 +0100 (MET) To: Jeffrey Hutzelman Cc: ietf-ssh@netbsd.org Subject: Re: Messages with exit-signal References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 16 Mar 2001 11:24:28 +0100 In-Reply-To: Jeffrey Hutzelman's message of "Thu, 15 Mar 2001 17:50:11 -0500 (EST)" Message-ID: Lines: 27 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Jeffrey Hutzelman writes: > On 15 Mar 2001, Niels Mller wrote: > > > 2. What should the accompanying message look like? > > > > Some of the alternatives are > > > > "Segmentation fault" (i.e. whatever strerror returns) > > "Segmentation fault (core dumped)" > > "Process died: Segmentation fault" > > You won't get these strings from strerror, because signals are not error > numbers. You pretty much have to come up with them yourself. See, for > example, sh.init.c in tcsh. Ooops. I meant strsignal (or _sys_siglist on older systems). > The " (core dumped)", on the other hand, is _not_ information the > client can get elsewhere, since even the concept is UNIX-specific. > IMHO, auxillary information like this should be included with the > signal message. There's a "boolean core dumped" field in the "exit-signal" request, so this information can indeed be added to the message by the client. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 16 05:30:13 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01527 for ; Fri, 16 Mar 2001 05:30:13 -0500 (EST) Received: (qmail 11378 invoked by uid 605); 16 Mar 2001 10:30:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11371 invoked from network); 16 Mar 2001 10:30:08 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 16 Mar 2001 10:30:08 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 0070D82F52B; Fri, 16 Mar 2001 11:30:06 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id LAA23025; Fri, 16 Mar 2001 11:30:05 +0100 (MET) To: sommerfeld@east.sun.com Cc: Jeffrey Hutzelman , ietf-ssh@netbsd.org Subject: Re: Messages with exit-signal References: <200103152310.f2FNAe923995@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 16 Mar 2001 11:30:05 +0100 In-Reply-To: Bill Sommerfeld's message of "Thu, 15 Mar 2001 18:10:40 -0500" Message-ID: Lines: 18 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Bill Sommerfeld writes: > The exact message sent is a local issue, up to the implementation. Different conventions leads to ugliness when interoperating. If a client expects messages using the "Segmentation fault" convention, and receives "Process died: Segmentation fault (core dumped)" from the server, it will likely display the following message to the client: Remote process died: Process died: Segmentation fault (core dumped) (core dumped) which isn't pretty. But I agree it's not a terribly important issue. I believe other problem is more important: What to send for unknown signals? Unless I get any contrary information, I'll use the empty string and hope that other implementations can deal with that. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 16 06:12:37 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01810 for ; Fri, 16 Mar 2001 06:12:37 -0500 (EST) Received: (qmail 15904 invoked by uid 605); 16 Mar 2001 11:12:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15889 invoked from network); 16 Mar 2001 11:12:32 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 16 Mar 2001 11:12:32 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 90C9182F52B; Fri, 16 Mar 2001 12:12:30 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id MAA24054; Fri, 16 Mar 2001 12:12:30 +0100 (MET) To: Tatu Ylonen Cc: Markus Friedl , ietf-ssh@netbsd.org Subject: Re: secsh-userauth References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 16 Mar 2001 12:12:29 +0100 In-Reply-To: Tatu Ylonen's message of "Thu, 15 Mar 2001 21:54:12 +0200 (EET)" Message-ID: Lines: 38 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Tatu Ylonen writes: > If the user name changes, it is critical that all such cached > data/credentials is destroyed before starting to authenticate as another > user. If we permit leaving such globally stored data/credentials hanging > around when the user name changes, we may end up in a situation where > first trying to (partially) authenticate as one user and then as another > user gives you more rights than directly trying to authenticate as > yourself. Even if servers are permitted to disconnect, or stop responding usefully to userauth requests, once the user name changes, I consider such behaviour abnormal. The recommended way to deal with user name change ought to be to throw away any accumulated state and start over trying to authenticate the new user. In some cases (like strange PAM or kerberos interfaces you refer to, or for an implementation that irreversibly changes it uid when processing the first userauth-request) authenticating a new user may be difficult or impossible, so I agree that behaviour you and Markus describe should be allowed. But I don't think the spec should recommend it. For an extreme example, consider a userauth request with username "" and method "none", followed by a request with username "nisse" and method "password". There may be some odd configuration where the first request actually succeeds, but except for that, I see no reason for the server to collect any state that it is hard to throw away. I view userauth requests processing as a logically stateless process (at least as long as there are no "partial successes"). The server may cache user information between requests, but I view that only as an optimization. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 17 16:18:56 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09491 for ; Sat, 17 Mar 2001 16:18:55 -0500 (EST) Received: (qmail 7743 invoked by uid 605); 17 Mar 2001 21:18:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7736 invoked from network); 17 Mar 2001 21:18:49 -0000 Received: from mx5.sac.fedex.com (sendmail@199.81.194.37) by mail.netbsd.org with SMTP; 17 Mar 2001 21:18:49 -0000 Received: from mx2.sac.fedex.com (sendmail@mx2.sac.fedex.com [199.81.77.40]) by mx5.sac.fedex.com (8.9.3/8.9.3) with ESMTP id PAA59499 for ; Sat, 17 Mar 2001 15:18:44 -0600 (CST) (envelope-from ksb@g09.sac.fedex.com) Received: from g09.sac.fedex.com (root@g09.sac.fedex.com [199.81.105.181]) by mx2.sac.fedex.com (8.9.3/8.9.3) with ESMTP id PAA49135 for ; Sat, 17 Mar 2001 15:18:43 -0600 (CST) (envelope-from ksb@g09.sac.fedex.com) Received: from g09.sac.fedex.com (ksb@localhost [127.0.0.1]) by g09.sac.fedex.com (8.9.3/8.9.3) with ESMTP id PAA58219 for ; Sat, 17 Mar 2001 15:18:43 -0600 (CST) (envelope-from ksb@g09.sac.fedex.com) Message-Id: <200103172118.PAA58219@g09.sac.fedex.com> To: ietf-ssh@netbsd.org Subject: Who has the ball for subsystem startup In-Reply-To: Your message of "Wed, 14 Mar 2001 14:43:49 EST." <20010314194349.8BC218C@proven.weird.com> Date: Sat, 17 Mar 2001 15:18:43 -0600 From: K S Braunsdorf Sender: ietf-ssh-owner@netbsd.org Precedence: list [WRT draft-ietf-secsh-connect-09.txt and recent comments. -- ksb] I know I'm not a regular speaker here, I just lurk a lot. Take my views for what they are worth. Using a `subsystem' must be different than remote execution of a shell command -- because we already have a way to do that. In section 4.5 we either start a shell, an exec, or a subsystem and I think I see why we want each: + the shell lets the service indirect though a local mechanism to pick the program to run, + the exec lets the client (implementor or user) pick the program to run, + the subsystem lets the implementor of the secsh service pick the program to run. So a `subsystem' I view more like a well known service that is provided to the client *without* need for the client side to know the server side details of how it is executed. So the specification should say exactly that. We send the name of the subsystem we want, the server finds it and starts it. All this talk about filtering output from the startup of the subsystem is misplaced -- the server implementation has to manage that startup because we (the client) don't know how it happens. > restriction, e.g. a user is allowed to send request only for this > and that subsystem. We have a way to limit what a login can run on any system I've ever used (be it UNIX's rwx, PC physical access, or RACF rules). We don't need to create another: clients can ask for a subsystem by name and the server can check with the (already negotiated) credentials. I really don't like the hack of trying to put a cookie in the output stream; moving the file descriptors (or similar) is a much more sane tactic. I don't think we should put the burden on the client to make up for poor server implementations. But the point is that the specification should not force the client to filter for any cookie in any case -- it should be contained to the server's startup code because the server "has the ball" for subsystem startup. -- ksb From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 17 18:41:45 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10365 for ; Sat, 17 Mar 2001 18:41:44 -0500 (EST) Received: (qmail 24422 invoked by uid 605); 17 Mar 2001 23:41:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24415 invoked from network); 17 Mar 2001 23:41:41 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 17 Mar 2001 23:41:41 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA02950 for ; Sat, 17 Mar 2001 15:41:40 -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 SAA09534 for ; Sat, 17 Mar 2001 18:41:39 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f2HNfY926356 for ; Sat, 17 Mar 2001 18:41:34 -0500 (EST) Message-Id: <200103172341.f2HNfY926356@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: revised Secure Shell (secsh) agenda for 50th IETF Reply-to: sommerfeld@east.sun.com Date: Sat, 17 Mar 2001 18:41:34 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list [Changes from previous version: - include draft names - add draft-griffin-ssh-host-keys-in-dns-00.txt to extension drafts section] MONDAY, March 19, 2001 at 1530-1730 =================================== CHAIR: Bill Sommerfeld Agenda: Working group status / agenda bashing 5 mins Brief presentations 10 mins - ssh interop event at next Connectathon (Darrin Moffat) - measurements of ssh protocol deployment (Niels Provos) Discussion of core draft last-call issues 45 mins draft-ietf-secsh-architecture-07.txt draft-ietf-secsh-connect-09.txt draft-ietf-secsh-transport-09.txt draft-ietf-secsh-userauth-09.txt Discussion of extension drafts 45 mins - sftp draft-ietf-secsh-filexfer-00.txt - pubkey file format draft-ietf-secsh-publickeyfile-01.txt - D-H group exchange draft-ietf-secsh-dh-group-exchange-00.txt - keyboard-interactive draft-ietf-secsh-auth-kbdinteract-02.txt - gssapi authentication. draft-ietf-secsh-gsskeyex-01.txt - ssh host keys in DNS draft-griffin-ssh-host-keys-in-dns-00.txt From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 18 22:05:30 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15626 for ; Sun, 18 Mar 2001 22:05:30 -0500 (EST) Received: (qmail 25838 invoked by uid 605); 19 Mar 2001 03:05:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25824 invoked from network); 19 Mar 2001 03:05:23 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 19 Mar 2001 03:05:23 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA05512 for ; Sun, 18 Mar 2001 19:05:21 -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 WAA04294 for ; Sun, 18 Mar 2001 22:05:21 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f2J35F926701 for ; Sun, 18 Mar 2001 22:05:15 -0500 (EST) Message-Id: <200103190305.f2J35F926701@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: revised^2 Secure Shell (secsh) agenda for 50th IETF Reply-to: sommerfeld@east.sun.com Date: Sun, 18 Mar 2001 22:05:15 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list [Changes from previous version: - add "protocol naming discussion" at end - mention Niels Moeller's (expired) SRP draft.] MONDAY, March 19, 2001 at 1530-1730 =================================== CHAIR: Bill Sommerfeld Agenda: Working group status / agenda bashing 5 mins Brief presentations 10 mins - ssh interop event at next Connectathon (Darrin Moffat) - measurements of ssh protocol deployment (Niels Provos) Discussion of core draft last-call issues 45 mins draft-ietf-secsh-architecture-07.txt draft-ietf-secsh-connect-09.txt draft-ietf-secsh-transport-09.txt draft-ietf-secsh-userauth-09.txt Discussion of extension drafts 45 mins - sftp draft-ietf-secsh-filexfer-00.txt - pubkey file format draft-ietf-secsh-publickeyfile-01.txt - D-H group exchange draft-ietf-secsh-dh-group-exchange-00.txt - keyboard-interactive draft-ietf-secsh-auth-kbdinteract-02.txt - gssapi authentication. draft-ietf-secsh-gsskeyex-01.txt - ssh host keys in DNS draft-griffin-ssh-host-keys-in-dns-00.txt - niels moeller SRP draft (expired) Protocol name discussion 15 mins Jeff Schiller (Security Area Director) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 19 05:24:35 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07267 for ; Mon, 19 Mar 2001 05:24:35 -0500 (EST) Received: (qmail 18355 invoked by uid 605); 19 Mar 2001 10:24:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18346 invoked from network); 19 Mar 2001 10:24:25 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 19 Mar 2001 10:24:25 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 358FE82F551; Mon, 19 Mar 2001 11:24:23 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id LAA03447; Mon, 19 Mar 2001 11:24:22 +0100 (MET) To: sommerfeld@east.sun.com Cc: ietf-ssh@netbsd.org Subject: Re: revised^2 Secure Shell (secsh) agenda for 50th IETF References: <200103190305.f2J35F926701@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 19 Mar 2001 11:24:22 +0100 In-Reply-To: Bill Sommerfeld's message of "Sun, 18 Mar 2001 22:05:15 -0500" Message-ID: Lines: 10 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Bill Sommerfeld writes: > - niels moeller SRP draft (expired) Ooops. I guess it's too late to do anything about that now. The document is available at http://www.lysator.liu.se/~nisse/lsh/doc/srp-spec.nroff. Best wishes for the meeting. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 19 05:48:20 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07598 for ; Mon, 19 Mar 2001 05:48:20 -0500 (EST) Received: (qmail 21570 invoked by uid 605); 19 Mar 2001 10:48:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21563 invoked from network); 19 Mar 2001 10:48:15 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 19 Mar 2001 10:48:15 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id E239182F4E2; Mon, 19 Mar 2001 11:48:12 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id LAA21412; Mon, 19 Mar 2001 11:48:12 +0100 (MET) To: K S Braunsdorf Cc: ietf-ssh@netbsd.org Subject: Re: Who has the ball for subsystem startup References: <200103172118.PAA58219@g09.sac.fedex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 19 Mar 2001 11:48:12 +0100 In-Reply-To: K S Braunsdorf's message of "Sat, 17 Mar 2001 15:18:43 -0600" Message-ID: Lines: 47 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit K S Braunsdorf writes: > Using a `subsystem' must be different than remote execution of a shell > command -- because we already have a way to do that. In section 4.5 we > either start a shell, an exec, or a subsystem and I think I see why we > want each: > + the shell lets the service indirect though a local mechanism > to pick the program to run, > > + the exec lets the client (implementor or user) pick the program > to run, The difference is probably smaller than you think. If SHELL is the user's login shell, typically "shell" means execl(SHELL, SHELL, NULL) "exec" means execl(SHELL, SHELL, "-c", COMMAND, NULL) So in _both_ cases, the login shell and its $PATH is involved. And it more or less has to be, if you want to support sending a command _line_ to the server. Hmm, the spec doesn't say explicitly that command is a command line, but I believe that is what is intended. I.e. "grep foo /var/log/messages | sort" is a reasonable command to use with exec. In a less platform-specific way, I think one could say that a command that is reasonable for system() on the server platform is also reasonable for the "exec" request . > + the subsystem lets the implementor of the secsh service pick > the program to run. The implementor can also choose to implement it as a part of the same server. Of course, it's _possible_ to look at the command line for "exec" and recognize some commands to be implemented internally, but it is a lot cleaner to do that with "subsystem" than with "exec". I think that is the main justification for "subsystem". > I really don't like the hack of trying to put a cookie in the output stream; > moving the file descriptors (or similar) is a much more sane tactic. I don't > think we should put the burden on the client to make up for poor server > implementations. I agree completely. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 19 08:51:53 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10746 for ; Mon, 19 Mar 2001 08:51:52 -0500 (EST) Received: (qmail 13186 invoked by uid 605); 19 Mar 2001 13:51:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13171 invoked from network); 19 Mar 2001 13:51:45 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 19 Mar 2001 13:51:45 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id BB71282F524; Mon, 19 Mar 2001 14:51:43 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id OAA11118; Mon, 19 Mar 2001 14:51:43 +0100 (MET) To: ietf-ssh@netbsd.org Cc: Tom Holroyd , Tom Wu Subject: Some SRP issues Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 19 Mar 2001 14:51:42 +0100 In-Reply-To: Tom Holroyd's message of "Mon, 19 Mar 2001 20:22:45 +0900 (JST)" Message-ID: Lines: 52 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit I and Tom Holroyd have been discussing SRP key exchange recently, and there are a few questions where I would appreciate advice from Tom Wu and from the working group. My draft is at http://www.lysator.liu.se/~nisse/lsh/srp-spec.nroff. The first issue is the addition of a host key to the messages. Earlier, I didn't want to add that for purity reasons; as it's possible to get a copy of the host key later, using the ssh "connection" protocol, it seemed unnecessary to add it already at the key exchange. Counter arguments are: (i) The key is useful at key reexchange during the same connection, so it belongs to the keyexchange and transport layer, and (ii) it is an easy and convenient way to transfer the authentic host key. That would change the draft by adding an (optional) host key to the SSH_MSG_KEXSRP_REPLY message, and to the exchange hash. A second issue is negotiation of the group (or perhaps more properly, ring) used for the exchange. Tom Holroyd likes to have the ability to negotiate which group is used, analogously to the draft-dh-group-exchange. I don't know the exact details, but I imagine that the groups is stored together with the verifier and therefore choosen by the server. But if the user's secret value x is constructed as x = HASH(s | H(n | p)) like in my draft, this opens for attack. Assume that we are communicating with a bogus server. The server tells us to use a group of its choice, and it chooses a group in which the attacker can compute discrete logarithms. Now the user sends v = g^x to the server, and the server can extract x (modulo the size of his choosen group). Knowing x, the attacker can impersonate the user to the real server. A possible remedy is to make x depend on the group, say, x = HASH(s | description of group | H(n | p)) Would that work? I think this illustrates that adding group negotiation must be done very carefully. (In the dh-group-exchange case, I think the security is saved by the server's signature. The signature provides authentication that doesn't break of the dh group is tampered with). Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 19 11:24:21 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14356 for ; Mon, 19 Mar 2001 11:24:20 -0500 (EST) Received: (qmail 7120 invoked by uid 605); 19 Mar 2001 16:24:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7113 invoked from network); 19 Mar 2001 16:24:09 -0000 Received: from citi.umich.edu (141.211.92.141) by mail.netbsd.org with SMTP; 19 Mar 2001 16:24:09 -0000 Received: from citi.umich.edu (ssh-mapper.citi.umich.edu [141.211.92.147]) by citi.umich.edu (Postfix) with ESMTP id DE56A207C1 for ; Mon, 19 Mar 2001 11:24:08 -0500 (EST) From: Niels Provos Subject: issues To: ietf-ssh@netbsd.org Date: Mon, 19 Mar 2001 11:24:08 -0500 Message-Id: <20010319162408.DE56A207C1@citi.umich.edu> Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi, there are a couple of small issues that should be noted: 1. traffic analysis can determine the length of passwords that have been typed in for authentication or at the command line. a security advisory has been posted at http://www.openwall.com/advisories/OW-003-ssh-traffic-analysis.txt and should appear on the free version of the bugtraq mailing list soon. 2. the choice of private exponents for the diffie-hellman should depend on the size of key material for the negotiated ciphers, i.e. 256-bit AES requires longer exponents than 128-bit AES. this applies to both the transport and the diffie-hellman group exchange draft. These problems do not require any change in the protocol, and we will provide short implementation notes to address the problems, i.e. a description on how to alleviate them. -- Niels Provos finger provos@umich.edu for pgp info "Gravity is the soul of weight." - Anonymous. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 19 14:17:34 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18894 for ; Mon, 19 Mar 2001 14:17:34 -0500 (EST) Received: (qmail 17001 invoked by uid 605); 19 Mar 2001 19:17:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16993 invoked from network); 19 Mar 2001 19:17:26 -0000 Received: from fw.hel.fi.ssh.com (193.64.193.124) by mail.netbsd.org with SMTP; 19 Mar 2001 19:17:26 -0000 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.22) with SMTP id VAA11032 for ; Mon, 19 Mar 2001 21:17:23 +0200 (EET) Received: (qmail 11213 invoked from network); 19 Mar 2001 19:17:23 -0000 Received: from lavuaari.hel.fi.ssh.com (HELO torni.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 19 Mar 2001 19:17:23 -0000 Received: (from mkojo@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.3) id VAA32373; Mon, 19 Mar 2001 21:17:22 +0200 (EET) X-Authentication-Warning: torni.hel.fi.ssh.com: mkojo set sender to mkojo@torni.hel.fi.ssh.com using -f From: Mika Kojo MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15030.23362.577740.33208@torni.hel.fi.ssh.com> Date: Mon, 19 Mar 2001 21:17:22 +0200 To: Niels Provos Cc: ietf-ssh@netbsd.org Subject: issues In-Reply-To: <20010319162408.DE56A207C1@citi.umich.edu> References: <20010319162408.DE56A207C1@citi.umich.edu> X-Mailer: VM 6.88 under Emacs 20.7.2 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Niels Provos writes: > 2. the choice of private exponents for the diffie-hellman should depend > on the size of key material for the negotiated ciphers, i.e. > 256-bit AES requires longer exponents than 128-bit AES. > > this applies to both the transport and the diffie-hellman group > exchange draft. If you let the 256-bit AES to mandate the used Diffie-Hellman group then you will end up with a group with p > 2^13547 (say). This is something that seems quite unreasonable from the performance viewpoint. Changing the exponent size is not enough. (The usual 1024-bit Diffie-Hellman group gives security level similar to a 80-bit block cipher. Here exponent must be more than 160-bits---increasing it would not give any more security, but decreasing it would indeed decrease security.) Perhaps a better solution is to give the user some indication of the security level achieved in a particular session. Of course, it is difficult to measure security exactly, but this is only required to be a rough approximation (say, `very secure` > 2^128, `secure' > 2^80, `broken' <= 2^80, when measured in elementary operations). Best regards, Mika Kojo SSH Communications Security Corp From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 19 14:48:45 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19740 for ; Mon, 19 Mar 2001 14:48:45 -0500 (EST) Received: (qmail 22916 invoked by uid 605); 19 Mar 2001 19:48:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22900 invoked from network); 19 Mar 2001 19:48:38 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 19 Mar 2001 19:48:38 -0000 Received: from centralmail1.Central.Sun.COM ([129.147.62.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07627; Mon, 19 Mar 2001 11:48:35 -0800 (PST) Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id MAA28148; Mon, 19 Mar 2001 12:48:34 -0700 (MST) Received: from Eng.Sun.COM by esun1as-mm. (SMI-8.6/SMI-SVR4) id MAA09960; Mon, 19 Mar 2001 12:50:53 -0700 Message-ID: <3AB665B0.A0D014E3@Eng.Sun.COM> Date: Mon, 19 Mar 2001 12:01:52 -0800 From: Darren J Moffat Organization: Sun Microsystems X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17-21mdk i586) X-Accept-Language: en MIME-Version: 1.0 To: Mika Kojo CC: ietf-ssh@netbsd.org Subject: Re: issues References: <20010319162408.DE56A207C1@citi.umich.edu> <15030.23362.577740.33208@torni.hel.fi.ssh.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Mika Kojo wrote: > Perhaps a better solution is to give the user some indication of the > security level achieved in a particular session. Of course, it is > difficult to measure security exactly, but this is only required to be > a rough approximation (say, `very secure` > 2^128, `secure' > 2^80, > `broken' <= 2^80, when measured in elementary operations). I see it as an implmentation issue, unless you are requesting that some definition of security quality is added to the protocol. Personally I'd be very wary of using definitions like the above and displaying them to a user, they seem very strong. What I would be happy with is displaying a warning to the user (generated either by the client or server) if a known weak combinaition is used, but then we shouldn't be allowing known weak combinations in the definition of the protocol so... -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 19 16:05:37 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21747 for ; Mon, 19 Mar 2001 16:05:36 -0500 (EST) Received: (qmail 10582 invoked by uid 605); 19 Mar 2001 21:05:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10573 invoked from network); 19 Mar 2001 21:05:26 -0000 Received: from fw.hel.fi.ssh.com (193.64.193.124) by mail.netbsd.org with SMTP; 19 Mar 2001 21:05:26 -0000 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.22) with SMTP id XAA16398 for ; Mon, 19 Mar 2001 23:05:24 +0200 (EET) Received: (qmail 29989 invoked from network); 19 Mar 2001 21:05:23 -0000 Received: from lavuaari.hel.fi.ssh.com (HELO torni.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 19 Mar 2001 21:05:23 -0000 Received: (from mkojo@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.3) id XAA10913; Mon, 19 Mar 2001 23:05:23 +0200 (EET) X-Authentication-Warning: torni.hel.fi.ssh.com: mkojo set sender to mkojo@torni.hel.fi.ssh.com using -f From: Mika Kojo MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15030.29842.904735.933798@torni.hel.fi.ssh.com> Date: Mon, 19 Mar 2001 23:05:22 +0200 To: Darren J Moffat Cc: Mika Kojo , ietf-ssh@netbsd.org Subject: Re: issues In-Reply-To: <3AB665B0.A0D014E3@Eng.Sun.COM> References: <20010319162408.DE56A207C1@citi.umich.edu> <15030.23362.577740.33208@torni.hel.fi.ssh.com> <3AB665B0.A0D014E3@Eng.Sun.COM> X-Mailer: VM 6.88 under Emacs 20.7.2 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Darren J Moffat writes: > Mika Kojo wrote: > > > Perhaps a better solution is to give the user some indication of the > > security level achieved in a particular session. Of course, it is > > difficult to measure security exactly, but this is only required to be > > a rough approximation (say, `very secure` > 2^128, `secure' > 2^80, > > `broken' <= 2^80, when measured in elementary operations). > > I see it as an implmentation issue, unless you are requesting > that some definition of security quality is added to the protocol. You are right, it is an implementation issue. It is possible to give some formulas for computing the "security level", but ultimately such formulas would only have informational value. Best regards, Mika Kojo SSH Communications Security Corp From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 19 16:12:26 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21903 for ; Mon, 19 Mar 2001 16:12:25 -0500 (EST) Received: (qmail 12611 invoked by uid 605); 19 Mar 2001 21:12:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12599 invoked from network); 19 Mar 2001 21:12:19 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 19 Mar 2001 21:12:19 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 83EA282F524; Mon, 19 Mar 2001 22:12:17 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id WAA26191; Mon, 19 Mar 2001 22:12:16 +0100 (MET) To: Mika Kojo Cc: Niels Provos , ietf-ssh@netbsd.org Subject: Re: issues References: <20010319162408.DE56A207C1@citi.umich.edu> <15030.23362.577740.33208@torni.hel.fi.ssh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 19 Mar 2001 22:12:16 +0100 In-Reply-To: Mika Kojo's message of "Mon, 19 Mar 2001 21:17:22 +0200" Message-ID: Lines: 37 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Mika Kojo writes: > Niels Provos writes: > > 2. the choice of private exponents for the diffie-hellman should depend > > on the size of key material for the negotiated ciphers, i.e. > > 256-bit AES requires longer exponents than 128-bit AES. I have seen reasoning like this before, and I don't think I understand it. If you want a security level of 2^150, say (I'm not going to try to define security level precisely, and this particular level is just an example), then the important thing is that each component (public-key operations, hashes, bulk ciphers, etc) is at least 2^150-secure. Now, say you happen to choose a cipher with 2^256-security, because that's the only thing you've got that's better than 2^128 (if we count 3des as 2^112). When choosing the other components, it's *still* the 2^150 level that matters. They don't have to *match* the cipher. The important thing is that *each* components is strong enough, not that they all have equal strength. One component being significantly stronger than the others doesn't increase security beyond the weakest part, of course, but it doesn't hurt either. Is there anything I'm missing? > (The usual 1024-bit Diffie-Hellman group gives security level similar > to a 80-bit block cipher. Here exponent must be more than > 160-bits---increasing it would not give any more security, but > decreasing it would indeed decrease security.) If these figures are right, then the conclusion must be that we should offer some bigger groups. Either by adding some diffie-hellam-group2-sha1 key exchange method, or making the group-exchange mechanism mandatory. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 19 17:24:41 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23914 for ; Mon, 19 Mar 2001 17:24:40 -0500 (EST) Received: (qmail 2844 invoked by uid 605); 19 Mar 2001 22:24:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2788 invoked from network); 19 Mar 2001 22:24:26 -0000 Received: from fw.hel.fi.ssh.com (193.64.193.124) by mail.netbsd.org with SMTP; 19 Mar 2001 22:24:26 -0000 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.22) with SMTP id AAA20176 for ; Tue, 20 Mar 2001 00:24:20 +0200 (EET) Received: (qmail 13195 invoked from network); 19 Mar 2001 22:24:19 -0000 Received: from lavuaari.hel.fi.ssh.com (HELO torni.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 19 Mar 2001 22:24:19 -0000 Received: (from mkojo@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.3) id AAA17101; Tue, 20 Mar 2001 00:24:18 +0200 (EET) X-Authentication-Warning: torni.hel.fi.ssh.com: mkojo set sender to mkojo@torni.hel.fi.ssh.com using -f From: Mika Kojo MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <15030.34578.757023.102438@torni.hel.fi.ssh.com> Date: Tue, 20 Mar 2001 00:24:18 +0200 To: nisse@lysator.liu.se (Niels MЖller) Cc: Mika Kojo , Niels Provos , ietf-ssh@netbsd.org Subject: Re: issues In-Reply-To: References: <20010319162408.DE56A207C1@citi.umich.edu> <15030.23362.577740.33208@torni.hel.fi.ssh.com> X-Mailer: VM 6.88 under Emacs 20.7.2 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA23914 Niels MЖller writes: [...] > > (The usual 1024-bit Diffie-Hellman group gives security level similar > > to a 80-bit block cipher. Here exponent must be more than > > 160-bits---increasing it would not give any more security, but > > decreasing it would indeed decrease security.) > > If these figures are right, then the conclusion must be that we should > offer some bigger groups. Either by adding some > diffie-hellam-group2-sha1 key exchange method, or making the > group-exchange mechanism mandatory. It is an easy matter to use the complexity estimates for GNFS to see that (say) RSA of 1024-bits gives about 80-bits of security when measured in elementary bit operations. There is a paper by Lenstra and Verheul on this if you want to see some interesting tabulations. Recall that complexity estimates for discrete log and factorization are pretty much equal (except for some minor bias in the favour of discrete logs). IPsec's IKE groups could be directly taken by SSH2, but even they don't get yet close the 256-bit limit (which requires the mentioned 13K-bit primes). Best regards, Mika Kojo SSH Communications Security Corp From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 19 17:48:55 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24535 for ; Mon, 19 Mar 2001 17:48:54 -0500 (EST) Received: (qmail 5915 invoked by uid 605); 19 Mar 2001 22:48:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5907 invoked from network); 19 Mar 2001 22:48:46 -0000 Received: from unknown (HELO anchorage.arcot.com) (209.247.197.162) by mail.netbsd.org with SMTP; 19 Mar 2001 22:48:46 -0000 Received: from arcot.com (209.247.197.126 [209.247.197.126]) by anchorage.arcot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 17DF029T; Mon, 19 Mar 2001 14:42:17 -0800 Message-ID: <3AB68CED.5A1934A3@arcot.com> Date: Mon, 19 Mar 2001 14:49:17 -0800 From: Tom Wu Organization: Arcot Systems X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Niels =?iso-8859-1?Q?M=F6ller?= CC: ietf-ssh@netbsd.org, Tom Holroyd Subject: Re: Some SRP issues References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit "Niels MЖller" wrote: > > A second issue is negotiation of the group (or perhaps more properly, > ring) used for the exchange. Tom Holroyd likes to have the ability to > negotiate which group is used, analogously to the > draft-dh-group-exchange. I don't know the exact details, but I imagine > that the groups is stored together with the verifier and therefore > choosen by the server. Yes, the server selects the ring beforehand. When a user sets/changes his password, that ring is used to compute the verifier, which is stored on the server. > But if the user's secret value x is constructed as > > x = HASH(s | H(n | p)) > > like in my draft, this opens for attack. Assume that we are > communicating with a bogus server. The server tells us to use a group > of its choice, and it chooses a group in which the attacker can > compute discrete logarithms. > > Now the user sends v = g^x to the server, and the server can extract x > (modulo the size of his choosen group). Knowing x, the attacker can > impersonate the user to the real server. I assume you're referring to a situation where a user is attempting to *set* his password remotely for the very first time on a server, since that is the only time one would ever send "v" over the network. The user's initial password should be set locally. Once that is established, the user can log in securely from anywhere, and can change his password securely. I don't see how the situation you described could ever arise in a real environment. If you want to devise a mechanism to allow a user to do remote password initialization (a very hard, unsolved problem), I'd recommend having the user select the ring and send {N, g, s, v} to the server, encrypted and MACed if possible. > A possible remedy is to make x depend on the group, say, > > x = HASH(s | description of group | H(n | p)) > > Would that work? I think this illustrates that adding group I don't see how this would help, and it would break compatiblity with the installed server base. I agree that the question of how to select rings/groups is a tricky one; this is something I've had to deal with quite a bit when designing SRP and the associated protocols. > negotiation must be done very carefully. (In the dh-group-exchange > case, I think the security is saved by the server's signature. The > signature provides authentication that doesn't break of the dh group > is tampered with). > > Regards, > /Niels -- Tom Wu Principal Software Engineer Arcot Systems (408) 969-6124 "The Borg? Sounds Swedish..." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 19 18:23:08 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25506 for ; Mon, 19 Mar 2001 18:23:08 -0500 (EST) Received: (qmail 11643 invoked by uid 605); 19 Mar 2001 23:23:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11636 invoked from network); 19 Mar 2001 23:23:02 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 19 Mar 2001 23:23:02 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id A08F482F4E6; Tue, 20 Mar 2001 00:23:00 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id AAA09362; Tue, 20 Mar 2001 00:23:00 +0100 (MET) To: Tom Wu Cc: ietf-ssh@netbsd.org, Tom Holroyd Subject: Re: Some SRP issues References: <3AB68CED.5A1934A3@arcot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 20 Mar 2001 00:22:59 +0100 In-Reply-To: Tom Wu's message of "Mon, 19 Mar 2001 14:49:17 -0800" Message-ID: Lines: 32 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Tom Wu writes: > > But if the user's secret value x is constructed as > > > > x = HASH(s | H(n | p)) ... > I assume you're referring to a situation where a user is attempting to > *set* his password remotely for the very first time on a server, since > that is the only time one would ever send "v" over the network. *blush* You're right, of course. It's half a year since I really worked with SRP, and appearantly I'm forgetting important things about it... No, I was not thinking about setting the password, only the key exchange. So what is a correct analysis of the case where the attacker tells the client to use a group of the attackers choice, and the attacker can compute logarithms? The values that the attacker gets are e = g^a, from which a discrete log computation yields the users secret dh value a. f = v + g^b, which doesn't yield anything obvious. So it seems fine. Is there anywhere I can read more about this scenario? /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 19 22:19:11 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02732 for ; Mon, 19 Mar 2001 22:19:09 -0500 (EST) Received: (qmail 22111 invoked by uid 605); 20 Mar 2001 03:19:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22099 invoked from network); 20 Mar 2001 03:19:01 -0000 Received: from unknown (HELO anchorage.arcot.com) (209.247.197.162) by mail.netbsd.org with SMTP; 20 Mar 2001 03:19:01 -0000 Received: from arcot.com (209.247.197.126 [209.247.197.126]) by anchorage.arcot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 17DF0JJR; Mon, 19 Mar 2001 19:12:34 -0800 Message-ID: <3AB6CC48.AEFE7FB7@arcot.com> Date: Mon, 19 Mar 2001 19:19:36 -0800 From: Tom Wu Organization: Arcot Systems X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Niels =?iso-8859-1?Q?M=F6ller?= CC: ietf-ssh@netbsd.org, Tom Holroyd Subject: Re: Some SRP issues References: <3AB68CED.5A1934A3@arcot.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit "Niels MЖller" wrote: > > So what is a correct analysis of the case where the attacker tells the > client to use a group of the attackers choice, and the attacker can > compute logarithms? > > The values that the attacker gets are > > e = g^a, from which a discrete log computation yields the users > secret dh value a. > > f = v + g^b, which doesn't yield anything obvious. Worst case, if the attacker feeds the client a "booby-trapped" safe prime that he can do fast DL in, then he can extract the client's secret "a". He then sends some random string in place of B, gets the client's response hash, and then can run through a list of passwords, guessing possible passwords and checking them against the client's response. The defense is to accept only known, safe parameters (like the Oakley/IPSec moduli) or at least allow only parameters that pass verification *and* are sufficiently long. > /Niels Tom -- Tom Wu Principal Software Engineer Arcot Systems (408) 969-6124 "The Borg? Sounds Swedish..." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 20 04:18:43 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27451 for ; Tue, 20 Mar 2001 04:18:42 -0500 (EST) Received: (qmail 4931 invoked by uid 605); 20 Mar 2001 09:18:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4922 invoked from network); 20 Mar 2001 09:18:35 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 20 Mar 2001 09:18:35 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 45ED982F528; Tue, 20 Mar 2001 10:18:08 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id KAA28366; Tue, 20 Mar 2001 10:18:07 +0100 (MET) To: Tom Wu Cc: ietf-ssh@netbsd.org, Tom Holroyd Subject: Re: Some SRP issues References: <3AB68CED.5A1934A3@arcot.com> <3AB6CC48.AEFE7FB7@arcot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 20 Mar 2001 10:18:07 +0100 In-Reply-To: Tom Wu's message of "Mon, 19 Mar 2001 19:19:36 -0800" Message-ID: Lines: 18 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Tom Wu writes: > Worst case, if the attacker feeds the client a "booby-trapped" safe > prime that he can do fast DL in, then he can extract the client's secret > "a". He then sends some random string in place of B, gets the client's > response hash, and then can run through a list of passwords, guessing > possible passwords and checking them against the client's response. The > defense is to accept only known, safe parameters (like the Oakley/IPSec > moduli) or at least allow only parameters that pass verification *and* > are sufficiently long. Thanks. I don't feel terribly good about requiring the client to check that some prime provided by the server is safe. So I'd prefer a hard coded list (which can be expanded as time goes by). /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 20 15:47:03 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24190 for ; Tue, 20 Mar 2001 15:47:02 -0500 (EST) Received: (qmail 4370 invoked by uid 605); 20 Mar 2001 20:46:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4363 invoked from network); 20 Mar 2001 20:46:54 -0000 Received: from hutcs.cs.hut.fi (kivinen@130.233.192.7) by mail.netbsd.org with SMTP; 20 Mar 2001 20:46:54 -0000 Received: (from kivinen@localhost) by hutcs.cs.hut.fi (8.9.3/8.9.3) id WAA02199; Tue, 20 Mar 2001 22:46:49 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 20 Mar 2001 22:46:49 +0200 (EET) From: Tero Kivinen To: Mika Kojo Cc: nisse@lysator.liu.se (Niels MЖller), Niels Provos , ietf-ssh@netbsd.org Subject: Re: issues In-Reply-To: <15030.34578.757023.102438@torni.hel.fi.ssh.com> References: <20010319162408.DE56A207C1@citi.umich.edu> <15030.23362.577740.33208@torni.hel.fi.ssh.com> <15030.34578.757023.102438@torni.hel.fi.ssh.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <15031.49182.572211.457@hutcs.cs.hut.fi> Organization: Helsinki University of Technology X-Edit-Time: 6 min X-Total-Time: 6 min Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Mika Kojo writes: > IPsec's IKE groups could be directly taken by SSH2, but even they > don't get yet close the 256-bit limit (which requires the mentioned > 13K-bit primes). The current ssh prime is alreadu the ike-prime-2, thus the wg can easily take the other groups from the draft-ietf-ipsec-ike-modp-groups-01.txt if they want so. I will not do anything to this issue, as I have completely lost interest about the secure shell protocol because of the wg meeting yesterday. I have already unsubscribed this mailing list. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 22 15:22:08 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20323 for ; Thu, 22 Mar 2001 15:22:06 -0500 (EST) Received: (qmail 23103 invoked by uid 605); 22 Mar 2001 20:21:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23096 invoked from network); 22 Mar 2001 20:21:57 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 22 Mar 2001 20:21:57 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02284; Thu, 22 Mar 2001 12:21:56 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27733; Thu, 22 Mar 2001 15:21:55 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f2MKLn901964; Thu, 22 Mar 2001 15:21:49 -0500 (EST) Message-Id: <200103222021.f2MKLn901964@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Cc: jis@mit.edu, mleech@nortelnetworks.com Subject: minutes fragment: protocol renaming. Reply-to: sommerfeld@east.sun.com Date: Thu, 22 Mar 2001 15:21:49 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list [I'm still working on minutes; however, since word of the trademark/renaming issue this has reached the media I think it's worth sending this fragment out promptly.] At the meeting on Monday, the working group received a request from Tatu Ylonen to rename the protocol. There was an extended discussion (led/moderated by Jeff Schiller, security AD). While there were people present in favor of granting Tatu's request, it was clear that there is substantial opposition to renaming the protocol at this time. A show of hands at the end of the discussion matched this; the bulk of the working group was clearly against renaming. We will therefore not act on Tatu's request; the documents will proceed under their existing names. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 25 03:08:59 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00343 for ; Sun, 25 Mar 2001 03:08:59 -0500 (EST) Received: (qmail 17956 invoked by uid 605); 25 Mar 2001 08:08:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17949 invoked from network); 25 Mar 2001 08:08:52 -0000 Received: from sm10.texas.rr.com (24.93.35.222) by mail.netbsd.org with SMTP; 25 Mar 2001 08:08:52 -0000 Received: from localhost (cs2773-200.houston.rr.com [24.27.73.200]) by sm10.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f2P81Bjr013083 for ; Sun, 25 Mar 2001 02:07:00 -0600 Message-Id: <200103250807.f2P81Bjr013083@sm10.texas.rr.com> X-Sender: hermag@excite.com From: "hermag@excite.com" To: ietf-ssh@netbsd.org Date: Sun, 25 Mar 2001 02:03:42 -0600 Subject: Would you like to recieve information on how to register your pet online for free? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__18778161_7422.63" Sender: ietf-ssh-owner@netbsd.org Precedence: list This is a Multipart MIME message. ------=_NextPart_000_001__18778161_7422.63 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_000_001__18778161_7422.63 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5VbnRpdGxlZCBEb2N1bWVudDwvdGl0bGU+DQo8bWV0 YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl dD1pc28tODg1OS0xIj4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4 dD0iIzAwMDAwMCI+DQo8cD5IZWxsbyE8L3A+DQo8cD5Xb3VsZCB5b3UgbGlrZSB0byBrbm93 IGhvdyB0byByZWdpc3RlciB5b3VyIHBldCBvbmxpbmUgZm9yIGZyZWU/PC9wPg0KPHA+SWYg eW91IHdvdWxkIGxpa2UgdG8gYmUgcmVtb3ZlZCBmcm9tIGV2ZXIgcmVjZWl2aW5nIGFub3Ro ZXIgZW1haWwgcGxlYXNlIHR5cGUgDQogIFJFTU9WRSBvbmx5IGluIHRoZSByZXR1cm4gc3Vi amVjdCBoZWFkZXIuIFdlIHJlc3BlY3QgeW91ciByaWdodCB0byBwcml2YWN5LjwvcD4NCjxw PklmIHlvdSB3b3VsZCBsaWtlIHRvIHJlY2VpdmUgbW9yZSBpbmZvcm1hdGlvbiBvbiBob3cg dG8gcmVnaXN0ZXIgeW91ciBwZXQgZm9yIA0KICBmcmVlIGp1c3QgcmVwbHkgdG8gdGhpcyBl bWFpbCBtZXNzYWdlIHdpdGggUExFQVNFIFNFTkQgSU5GTyBvbmx5IGluIHRoZSBzdWJqZWN0 IA0KICBoZWFkZXIuPC9wPg0KPHA+PC9wPg0KPHA+VGhhbmsgWW91PGJyPg0KPC9wPg0KPC9i b2R5Pg0KPC9odG1sPg0K ------=_NextPart_000_001__18778161_7422.63-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 27 19:01:41 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03918 for ; Tue, 27 Mar 2001 19:01:40 -0500 (EST) Received: (qmail 20272 invoked by uid 605); 28 Mar 2001 00:01:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20265 invoked from network); 28 Mar 2001 00:01:33 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 28 Mar 2001 00:01:33 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02870 for ; Tue, 27 Mar 2001 16:01:32 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.166]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id QAA14695 for ; Tue, 27 Mar 2001 16:01:33 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.12.0.Beta6+Sun/8.12.0.Beta6) with SMTP id f2S01Pxf429176 for ; Tue, 27 Mar 2001 16:01:26 -0800 (PST) Message-Id: <200103280001.f2S01Pxf429176@jurassic.eng.sun.com> Date: Tue, 27 Mar 2001 16:01:26 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: draft-ietf-secsh-filexfer-00.txt & SFTP name To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: WktqMLazntnNPzR56flIuQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_26 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list It has been brought to my attention today that there is already an RFC from IETF that describes a protocol that goes by the short name of SFTP (http://www.ietf.org/rfc/rfc0913.txt) While draft-ietf-secsh-filexfer-00.txt does not refer to the name of the protocol as sftp it does use the subsystem name sftp which seems to me like a bad thing since it could cause confusion with RFC 913. This coupled with the fact that implementors will tend to choose sftp as the command name because it is the name of the subsystem sets us down a precendent that isn't good as far as names are concerned. Add to the equation that the protocol described in the filexfer draft is not actually like FTP I think the a more appropriate name for the subsystem (and consequently the command names implementors are likely to choose) would be appropriate. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 27 19:19:46 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04447 for ; Tue, 27 Mar 2001 19:19:46 -0500 (EST) Received: (qmail 21775 invoked by uid 605); 28 Mar 2001 00:19:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21768 invoked from network); 28 Mar 2001 00:19:39 -0000 Received: from twin.uoregon.edu (root@128.223.214.27) by mail.netbsd.org with SMTP; 28 Mar 2001 00:19:39 -0000 Received: from localhost (joelja@localhost) by twin.uoregon.edu (8.11.0/8.11.0) with ESMTP id f2S0JcW11730; Tue, 27 Mar 2001 16:19:38 -0800 X-Authentication-Warning: twin.uoregon.edu: joelja owned process doing -bs Date: Tue, 27 Mar 2001 16:19:38 -0800 (PST) From: Joel Jaeggli X-Sender: To: Darren Moffat cc: Subject: Re: draft-ietf-secsh-filexfer-00.txt & SFTP name In-Reply-To: <200103280001.f2S01Pxf429176@jurassic.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list It would tend to follow that if you chose to name things based on what they do, that name collisions would be unavoidable. On Tue, 27 Mar 2001, Darren Moffat wrote: > It has been brought to my attention today that there is already an > RFC from IETF that describes a protocol that goes by the short name > of SFTP (http://www.ietf.org/rfc/rfc0913.txt) > > While draft-ietf-secsh-filexfer-00.txt does not refer to the name of > the protocol as sftp it does use the subsystem name sftp which seems > to me like a bad thing since it could cause confusion with RFC 913. > > This coupled with the fact that implementors will tend to choose sftp > as the command name because it is the name of the subsystem sets us > down a precendent that isn't good as far as names are concerned. > Add to the equation that the protocol described in the filexfer draft > is not actually like FTP I think the a more appropriate name for the sftp (rfc 913) is a lot like ftp except (simpler) although definently not interoperable, suggesting that jon postel and mark lottor weren't immune to name related confusion issues. > subsystem (and consequently the command names implementors are likely > to choose) would be appropriate. > > -- > Darren J Moffat > -- -------------------------------------------------------------------------- Joel Jaeggli joelja@darkwing.uoregon.edu Academic User Services consult@gladstone.uoregon.edu PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -------------------------------------------------------------------------- It is clear that the arm of criticism cannot replace the criticism of arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy of the right, 1843. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 27 19:27:27 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04637 for ; Tue, 27 Mar 2001 19:27:26 -0500 (EST) Received: (qmail 22729 invoked by uid 605); 28 Mar 2001 00:27:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22722 invoked from network); 28 Mar 2001 00:27:20 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 28 Mar 2001 00:27:20 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA21499 for ; Tue, 27 Mar 2001 16:27:17 -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 TAA21493 for ; Tue, 27 Mar 2001 19:27:16 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f2S0RA920439 for ; Tue, 27 Mar 2001 19:27:11 -0500 (EST) Message-Id: <200103280027.f2S0RA920439@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: avoiding reinventing the wheel on file transfer. Reply-to: sommerfeld@east.sun.com Date: Tue, 27 Mar 2001 19:27:10 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list So, I have this concern that we're going to spend a whole lot of time on the file transfer draft, and in the process reinvent a couple wheels which have already been built. Here's a half-formed suggestion for the working group... file transfer involves a bunch of really ugly issues (newline conventions, binary/ascii/... modes, i18n of filenames, etc., etc.). Many of these problems have already been tackled by FTP. A radically different and simpler approach (from a standards-writing viewpoint, at least) may well be to define a way to tunnel "normal" ftp through a collection of ssh channels, so we can avoid refighting all the battles which were fought over FTP... i.e., you start off with one channel for the FTP control channel, and then open up new ssh channels where "normal" FTP would open a new TCP connection.... - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 27 20:00:21 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05624 for ; Tue, 27 Mar 2001 20:00:21 -0500 (EST) Received: (qmail 25765 invoked by uid 605); 28 Mar 2001 01:00:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25758 invoked from network); 28 Mar 2001 01:00:15 -0000 Received: from pianosa.catch22.org (postfix@64.81.48.19) by mail.netbsd.org with SMTP; 28 Mar 2001 01:00:15 -0000 Received: by pianosa.catch22.org (Postfix, from userid 1000) id 85F1117A2; Tue, 27 Mar 2001 17:00:15 -0800 (PST) Date: Tue, 27 Mar 2001 17:00:15 -0800 From: David Terrell To: Bill Sommerfeld Cc: ietf-ssh@netbsd.org Subject: Re: avoiding reinventing the wheel on file transfer. Message-ID: <20010327170015.C30334@pianosa.catch22.org> Reply-To: David Terrell References: <200103280027.f2S0RA920439@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200103280027.f2S0RA920439@thunk.east.sun.com>; from sommerfeld@east.sun.com on Tue, Mar 27, 2001 at 07:27:10PM -0500 X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 4:56PM up 15 days, 17:01, 42 users, load averages: 0.27, 0.28, 0.23 X-Baby: Theodore Marvin Wolpinsky Terrell born 28 days, 3 hours, 10 minutes, 28 seconds ago Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Mar 27, 2001 at 07:27:10PM -0500, Bill Sommerfeld wrote: > So, I have this concern that we're going to spend a whole lot of time > on the file transfer draft, and in the process reinvent a couple > wheels which have already been built. > > Here's a half-formed suggestion for the working group... > > file transfer involves a bunch of really ugly issues (newline > conventions, binary/ascii/... modes, i18n of filenames, etc., etc.). > Many of these problems have already been tackled by FTP. > > A radically different and simpler approach (from a standards-writing > viewpoint, at least) may well be to define a way to tunnel "normal" > ftp through a collection of ssh channels, so we can avoid refighting > all the battles which were fought over FTP... i.e., you start off with > one channel for the FTP control channel, and then open up new ssh > channels where "normal" FTP would open a new TCP connection.... As a point of reference, I believe SecureFX from vandyke does exactly this by using creative PORT commands and dynamic remote port forwarding against an existing FTP daemon on the sshd host. -- David Terrell | "When we said that you needed to cut the dbt@meat.net | wires for ultimate security, we didn't Nebcorp Prime Minister | mean that you should go wireless instead." http://wwn.nebcorp.com/ | - Casper Dik From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 27 20:25:48 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06527 for ; Tue, 27 Mar 2001 20:25:47 -0500 (EST) Received: (qmail 2428 invoked by uid 605); 28 Mar 2001 01:25:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2421 invoked from network); 28 Mar 2001 01:25:37 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 28 Mar 2001 01:25:37 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26830 for ; Tue, 27 Mar 2001 17:25:36 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id RAA08426 for ; Tue, 27 Mar 2001 17:25:42 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.12.0.Beta6+Sun/8.12.0.Beta6) with SMTP id f2S1PXxf445427 for ; Tue, 27 Mar 2001 17:25:33 -0800 (PST) Message-Id: <200103280125.f2S1PXxf445427@jurassic.eng.sun.com> Date: Tue, 27 Mar 2001 17:25:33 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: avoiding reinventing the wheel on file transfer. To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: jEGQnO57ZqRaizpXzvO38Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_26 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >So, I have this concern that we're going to spend a whole lot of time >on the file transfer draft, and in the process reinvent a couple >wheels which have already been built. >Here's a half-formed suggestion for the working group... > >file transfer involves a bunch of really ugly issues (newline >conventions, binary/ascii/... modes, i18n of filenames, etc., etc.). >Many of these problems have already been tackled by FTP. To me it looks like the current filexfer draft is trying to be more than FTP and is starting to look more and more like an early version of NFS so I share the concern. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 27 20:35:20 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06896 for ; Tue, 27 Mar 2001 20:35:20 -0500 (EST) Received: (qmail 5706 invoked by uid 605); 28 Mar 2001 01:35:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5695 invoked from network); 28 Mar 2001 01:35:14 -0000 Received: from p101-44.acedsl.com (HELO mx.databus.com) (160.79.101.44) by mail.netbsd.org with SMTP; 28 Mar 2001 01:35:14 -0000 Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f2S1Ys571728 for ietf-ssh@netbsd.org; Tue, 27 Mar 2001 20:34:54 -0500 (EST) (envelope-from barney) Date: Tue, 27 Mar 2001 20:34:54 -0500 From: Barney Wolff To: ietf-ssh@netbsd.org Subject: Re: avoiding reinventing the wheel on file transfer. Message-ID: <20010327203454.A71695@mx.databus.com> References: <200103280125.f2S1PXxf445427@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200103280125.f2S1PXxf445427@jurassic.eng.sun.com>; from Darren.Moffat@eng.sun.com on Tue, Mar 27, 2001 at 05:25:33PM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list I see two problems with simply redirecting ports to use the existing ftpd: 1. One of the major reasons to run sshd is to be able to shut down telnetd and ftpd, not only because of cleartext logins but also because they have been prone to security bugs. Yes, one could perhaps arrange for ftpd to listen only on localhost, but there is still the possibility of privilege escalation via a buggy ftpd. 2. The two-connection model for file transfer has not, in retrospect, worked out well. (IMHO) Barney Wolff From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 27 20:39:13 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07008 for ; Tue, 27 Mar 2001 20:39:13 -0500 (EST) Received: (qmail 6862 invoked by uid 605); 28 Mar 2001 01:39:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6854 invoked from network); 28 Mar 2001 01:39:08 -0000 Received: from nuinfo.nwu.edu (HELO nuinfo.northwestern.edu) (lunde@129.105.212.72) by mail.netbsd.org with SMTP; 28 Mar 2001 01:39:08 -0000 Received: (from lunde@localhost) by nuinfo.northwestern.edu (8.8.8/8.8.8) id TAA21982; Tue, 27 Mar 2001 19:39:06 -0600 (CST) Message-Id: <200103280139.TAA21982@nuinfo.northwestern.edu> Subject: Re: avoiding reinventing the wheel on file transfer. To: ietf-ssh@netbsd.org Date: Tue, 27 Mar 2001 19:39:06 CST In-Reply-To: <200103280027.f2S0RA920439@thunk.east.sun.com>; from "Bill Sommerfeld" at Mar 27, 2001 7:27 pm From: Albert-Lunde@northwestern.edu (Albert Lunde) Reply-To: Albert-Lunde@northwestern.edu (Albert Lunde) X-Mailer: Elm [revision: 212.5] Sender: ietf-ssh-owner@netbsd.org Precedence: list > Here's a half-formed suggestion for the working group... > > file transfer involves a bunch of really ugly issues (newline > conventions, binary/ascii/... modes, i18n of filenames, etc., etc.). > Many of these problems have already been tackled by FTP. > > A radically different and simpler approach (from a standards-writing > viewpoint, at least) may well be to define a way to tunnel "normal" > ftp through a collection of ssh channels, so we can avoid refighting > all the battles which were fought over FTP... i.e., you start off with > one channel for the FTP control channel, and then open up new ssh > channels where "normal" FTP would open a new TCP connection.... Speaking as one who has had a very minor role in the wu-ftpd testing process the last year or two, there are a lot of mis-features of FTP and/or FTP implementations that _deserve_ to be reinvented. What you describe would fix the firewall-unfriendly pattern of TCP connections, but not other historical warts on the protocol. If you could "profile" the FTP protocol, and throw out, say, half the legacy features, and bless some recently drafted additions, you might have something more plausible. -- Albert Lunde Albert-Lunde@northwestern.edu (new address) Albert-Lunde@nwu.edu (old address) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 27 20:40:25 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07074 for ; Tue, 27 Mar 2001 20:40:24 -0500 (EST) Received: (qmail 7482 invoked by uid 605); 28 Mar 2001 01:40:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7475 invoked from network); 28 Mar 2001 01:40:20 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 28 Mar 2001 01:40:20 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03904; Tue, 27 Mar 2001 17:40:12 -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 UAA27464; Tue, 27 Mar 2001 20:40:12 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f2S1e6921395; Tue, 27 Mar 2001 20:40:06 -0500 (EST) Message-Id: <200103280140.f2S1e6921395@thunk.east.sun.com> From: Bill Sommerfeld To: Barney Wolff cc: ietf-ssh@netbsd.org Subject: Re: avoiding reinventing the wheel on file transfer. In-reply-to: Your message of "Tue, 27 Mar 2001 20:34:54 EST." <20010327203454.A71695@mx.databus.com> Reply-to: sommerfeld@east.sun.com Date: Tue, 27 Mar 2001 20:40:06 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > I see two problems with simply redirecting ports to use the > existing ftpd.. Of course, there are problems with that, which is why it wasn't what I proposed. I proposed running the ftp *protocol* over a collection of ssh channels through a single ssh connection. Most likely an implementation of that could reuse most of an ftp client/server implementation. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 27 21:21:40 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA08662 for ; Tue, 27 Mar 2001 21:21:40 -0500 (EST) Received: (qmail 16786 invoked by uid 605); 28 Mar 2001 02:21:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16779 invoked from network); 28 Mar 2001 02:21:35 -0000 Received: from yeah-baby.shagadelic.org (HELO dr-evil.shagadelic.org) (208.176.2.162) by mail.netbsd.org with SMTP; 28 Mar 2001 02:21:35 -0000 Received: by dr-evil.shagadelic.org (Postfix, from userid 7518) id DC79318B61; Tue, 27 Mar 2001 18:21:04 -0800 (PST) Date: Tue, 27 Mar 2001 18:21:04 -0800 From: Jason R Thorpe To: Barney Wolff Cc: ietf-ssh@netbsd.org Subject: Re: avoiding reinventing the wheel on file transfer. Message-ID: <20010327182104.L458@dr-evil.shagadelic.org> Reply-To: thorpej@zembu.com Mail-Followup-To: Jason R Thorpe , Barney Wolff , ietf-ssh@netbsd.org References: <200103280125.f2S1PXxf445427@jurassic.eng.sun.com> <20010327203454.A71695@mx.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010327203454.A71695@mx.databus.com>; from barney@databus.com on Tue, Mar 27, 2001 at 08:34:54PM -0500 Organization: Zembu Labs, Inc. Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Mar 27, 2001 at 08:34:54PM -0500, Barney Wolff wrote: > 1. One of the major reasons to run sshd is to be able to shut > down telnetd and ftpd, not only because of cleartext logins > but also because they have been prone to security bugs. Yes, > one could perhaps arrange for ftpd to listen only on localhost, > but there is still the possibility of privilege escalation via > a buggy ftpd. This seems like an implementation issue. An implementation could certainly choose to hack ftpd to run on a channel created by sshd (rather than one created by inetd). > 2. The two-connection model for file transfer has not, in retrospect, > worked out well. (IMHO) Passive mode? -- -- Jason R. Thorpe From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 27 21:47:41 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA10848 for ; Tue, 27 Mar 2001 21:47:40 -0500 (EST) Received: (qmail 23287 invoked by uid 605); 28 Mar 2001 02:47:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23280 invoked from network); 28 Mar 2001 02:47:35 -0000 Received: from p101-44.acedsl.com (HELO mx.databus.com) (160.79.101.44) by mail.netbsd.org with SMTP; 28 Mar 2001 02:47:35 -0000 Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f2S2lYi72091 for ietf-ssh@netbsd.org; Tue, 27 Mar 2001 21:47:34 -0500 (EST) (envelope-from barney) Date: Tue, 27 Mar 2001 21:47:34 -0500 From: Barney Wolff To: ietf-ssh@netbsd.org Subject: Re: avoiding reinventing the wheel on file transfer. Message-ID: <20010327214734.A72050@mx.databus.com> References: <200103280125.f2S1PXxf445427@jurassic.eng.sun.com> <20010327203454.A71695@mx.databus.com> <20010327182104.L458@dr-evil.shagadelic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010327182104.L458@dr-evil.shagadelic.org>; from thorpej@zembu.com on Tue, Mar 27, 2001 at 06:21:04PM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list Easy for the initial listen, not so easy for the data conn(s). But as I've been corrected, the proposal is to reuse the protocol, not the intact ftpd. On Tue, Mar 27, 2001 at 06:21:04PM -0800, Jason R Thorpe wrote: > > This seems like an implementation issue. An implementation could > certainly choose to hack ftpd to run on a channel created by sshd > (rather than one created by inetd). > > > 2. The two-connection model for file transfer has not, in retrospect, > > worked out well. (IMHO) > > Passive mode? Still clumsy. The sync issues on aborting a transfer, for example. Third-party transfers. The historical motivations for using a separate data channel no longer apply. Again, imho. But I surely do believe in KISS. Bells and whistles, if any, belong in shareware clients. Barney Wolff From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 28 02:38:30 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA09402 for ; Wed, 28 Mar 2001 02:38:30 -0500 (EST) Received: (qmail 1472 invoked by uid 605); 28 Mar 2001 07:38:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1465 invoked from network); 28 Mar 2001 07:38:24 -0000 Received: from faui02.informatik.uni-erlangen.de (msfriedl@131.188.30.102) by mail.netbsd.org with SMTP; 28 Mar 2001 07:38:24 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id JAA04249; Wed, 28 Mar 2001 09:37:49 +0200 (MET DST) Date: Wed, 28 Mar 2001 09:37:49 +0200 From: Markus Friedl To: Bill Sommerfeld Cc: ietf-ssh@netbsd.org Subject: Re: avoiding reinventing the wheel on file transfer. Message-ID: <20010328093749.B3563@faui02.informatik.uni-erlangen.de> References: <200103280027.f2S0RA920439@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <200103280027.f2S0RA920439@thunk.east.sun.com>; from sommerfeld@east.sun.com on Tue, Mar 27, 2001 at 07:27:10PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Mar 27, 2001 at 07:27:10PM -0500, Bill Sommerfeld wrote: > A radically different and simpler approach (from a standards-writing > viewpoint, at least) may well be to define a way to tunnel "normal" > ftp through a collection of ssh channels, so we can avoid refighting > all the battles which were fought over FTP... i.e., you start off with > one channel for the FTP control channel, and then open up new ssh > channels where "normal" FTP would open a new TCP connection.... there is no need to 'define' this approach, it has already been implemented with success -- VanDyke's SecureFX shows this. however, i think that a SFTP subsystem is still useful since it implements a much simpler protocol than FTP. if you want to reuse existing FTP clients, than you can implement a ftp-sftp bridge like the one from mindbright.se. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 28 03:13:37 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA11523 for ; Wed, 28 Mar 2001 03:13:36 -0500 (EST) Received: (qmail 7165 invoked by uid 605); 28 Mar 2001 08:13:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7157 invoked from network); 28 Mar 2001 08:13:30 -0000 Received: from ixion.tartarus.org (195.153.205.133) by mail.netbsd.org with SMTP; 28 Mar 2001 08:13:30 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 14iB57-0001Ia-00; Wed, 28 Mar 2001 09:13:29 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <200103280027.f2S0RA920439@thunk.east.sun.com> Subject: Re: avoiding reinventing the wheel on file transfer. Message-Id: Date: Wed, 28 Mar 2001 09:13:29 +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list Bill Sommerfeld wrote: > file transfer involves a bunch of really ugly issues (newline > conventions, binary/ascii/... modes, i18n of filenames, etc., etc.). > Many of these problems have already been tackled by FTP. I'd applaud any efforts to use existing solutions to these ugly issues, but I for one do like SFTP as a concept. It has useful things that FTP doesn't and probably couldn't without serious effort: - a well-defined, portable and securable chmod (SITE EXEC doesn't cut it, not least because it's hard to vet carefully at the server end and so most FTP servers simply don't bother to support it AFAICT). - a well-defined machine readable format for directory listings, so you can write automated clients that do complex manipulation of the remote fs, because they can look at a dir listing and reliably get things like file sizes back out. Also you can sensibly write a GUI client which displays sizes in a separate Windows-like column, without having to parse the size data out of an ASCII listing which you're _assuming_ has the format you expect. - no reliance on command line details at the server end. In FTP, if you want a long listing, or a short listing, or a listing in columns, or a listing sorted by this or that, you have to know what command line options the server's `ls' binary happens to take - and in general, the server doesn't even tell you this! Whereas in SFTP, you can process command line options (or whatever local equivalent you like) locally, which means you can _document_ them carefully and fully for your users. Then you retrieve raw dir listing data from the server, and you format and sort it exactly as you like. - SFTP has the extensibility philosophy of SSH2 in general; I can define an extension, publish documentation of it, and rely on nobody else's extension clashing with it or interoperating badly with it. I know I have no official clout with the WG, but if I did, I would strongly oppose any move to abandon SFTP in favour of a thinly modified FTP. By all means look at FTP to see how it solves problems SFTP still needs to solve, but _please_ don't throw the baby out with the bathwater. SFTP is a massive improvement on FTP in many areas, and really we want a protocol with the best features of _both_. Cheers, Simon -- Simon Tatham "Imagine what the world would be like if there were no hypothetical situations..." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 28 04:59:56 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18575 for ; Wed, 28 Mar 2001 04:59:55 -0500 (EST) Received: (qmail 25024 invoked by uid 605); 28 Mar 2001 09:59:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25017 invoked from network); 28 Mar 2001 09:59:49 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 28 Mar 2001 09:59:49 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 6709F82F4FE; Wed, 28 Mar 2001 11:59:47 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id LAA02800; Wed, 28 Mar 2001 11:59:46 +0200 (MET DST) To: sommerfeld@east.sun.com Cc: ietf-ssh@netbsd.org Subject: Re: avoiding reinventing the wheel on file transfer. References: <200103280027.f2S0RA920439@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 28 Mar 2001 11:59:46 +0200 In-Reply-To: Bill Sommerfeld's message of "Tue, 27 Mar 2001 19:27:10 -0500" Message-ID: Lines: 51 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Bill Sommerfeld writes: > file transfer involves a bunch of really ugly issues (newline > conventions, binary/ascii/... modes, i18n of filenames, etc., etc.). > Many of these problems have already been tackled by FTP. > ... i.e., you start off with > one channel for the FTP control channel, and then open up new ssh > channels where "normal" FTP would open a new TCP connection.... It would probably be good somebody could write up the details of this, so we could compare it to sftp. I would also like to see a summary of how ftp have dealt with the problems you mention. For binary/ascii, my understanding of the ftp "solution" is that the client has to know a priory whether or not a file is text or binary and invoke the appropriate mode (some servers seem to sometimes default to binary, but a client can't *rely* on the server choosing the right mode). It's not obvious to me how that is significantly easier for the client to know than also knowing which new-line conventions are used for a text file and convert it locally. As for i18n of filenames, I don't know what the ftp solution is, but I do know that there are some hard problems. Before saying that ftp is better than sftp in this respect, I'd like to see some evidence that ftp has *solved* the problems, not just "tackled" them. (From the discussion on this list, it seems that the hardest problem is how to do both of (i) proper normalization, and (ii) support for systems where file names really are octet strings with no associated character set. My current preference is to let the base protocol treat file names as plain octet strings, and use some extension to negotiate character sets when that is desired). If we're serious about starting over with file transfer stuff, we should probably start with some requirements document. I mean, we want to solve at least the problems solved by the current sftp and scp, and probably some more, and we really need to know what problems we want to solve before we can evaluate ftp-based (or, for that matter, http-based) variants. FTP was the kitchen-sink protocol of the 70:s and perhaps 80:s (look at RFC 737 and RFC 743...), while HTTP is today's kitchen-sink. Directory listings with FTP sucks (as has already been pointed out), and HTTP is even worse. Is that really what we want? Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 28 05:35:42 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20129 for ; Wed, 28 Mar 2001 05:35:41 -0500 (EST) Received: (qmail 2561 invoked by uid 605); 28 Mar 2001 10:35:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2554 invoked from network); 28 Mar 2001 10:35:37 -0000 Received: from cpe-203-45-24-18.vic.bigpond.net.au (HELO kado.mindrot.org) (foobar@203.45.24.18) by mail.netbsd.org with SMTP; 28 Mar 2001 10:35:37 -0000 Received: from shitei.mindrot.org (unknown [203.44.118.253]) by kado.mindrot.org (Postfix) with ESMTP id 6DD019038; Wed, 28 Mar 2001 16:14:24 +1000 (EST) Received: from mothra.mindrot.org (mothra.mindrot.org [203.44.118.225]) by shitei.mindrot.org (Postfix) with ESMTP id 067C227D81; Wed, 28 Mar 2001 20:35:35 +1000 (EST) Received: by mothra.mindrot.org (Postfix, from userid 500) id 4C49196FC9; Wed, 28 Mar 2001 20:35:31 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by mothra.mindrot.org (Postfix) with ESMTP id 4BAA996FC3; Wed, 28 Mar 2001 20:35:31 +1000 (EST) Date: Wed, 28 Mar 2001 20:35:31 +1000 (EST) From: Damien Miller To: Bill Sommerfeld Cc: Subject: Re: avoiding reinventing the wheel on file transfer. In-Reply-To: <200103280027.f2S0RA920439@thunk.east.sun.com> Message-ID: X-Paranoia: just because you're paranoid doesn't mean they aren't out to get you MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 27 Mar 2001, Bill Sommerfeld wrote: > So, I have this concern that we're going to spend a whole lot of time > on the file transfer draft, and in the process reinvent a couple > wheels which have already been built. > > Here's a half-formed suggestion for the working group... > > file transfer involves a bunch of really ugly issues (newline > conventions, binary/ascii/... modes, i18n of filenames, etc., etc.). > Many of these problems have already been tackled by FTP. > > A radically different and simpler approach (from a standards-writing > viewpoint, at least) may well be to define a way to tunnel "normal" > ftp through a collection of ssh channels, so we can avoid refighting > all the battles which were fought over FTP... i.e., you start off with > one channel for the FTP control channel, and then open up new ssh > channels where "normal" FTP would open a new TCP connection.... I can't say this appeals to me. Special-casing a clean protocol so we can use it to wrap an ugly one for a few dubious features doesn't seem like a win to me. Others have observed that sftp is more NFS-like than FTP-like anyway, perhaps it would server as a better source of inspiration wrt issues such as i18n (I haven't been convinced that binary/ascii is even an issue). -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 28 09:09:44 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28141 for ; Wed, 28 Mar 2001 09:09:43 -0500 (EST) Received: (qmail 5707 invoked by uid 605); 28 Mar 2001 14:09:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5700 invoked from network); 28 Mar 2001 14:09:36 -0000 Received: from watsun.cc.columbia.edu (cu51491@128.59.39.2) by mail.netbsd.org with SMTP; 28 Mar 2001 14:09:36 -0000 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id JAA19558; Wed, 28 Mar 2001 09:09:34 -0500 (EST) Date: Wed, 28 Mar 2001 9:09:31 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu Cc: sommerfeld@east.sun.com, ietf-ssh@netbsd.org Subject: Re: avoiding reinventing the wheel on file transfer. In-Reply-To: Your message of 28 Mar 2001 11:59:46 +0200 Message-ID: Sender: ietf-ssh-owner@netbsd.org Precedence: list I can agree with Bill's desire to not re-invent the wheel. But I also agree with Niels that the FTP solution is hardly clean and does not really solve many of the issues it is attempting to address. If you really want a protocol that is going to replace FTP (RFC 959 ...) then you need to make it OS and file system independent. It needs to be able to provide a standardized wire format for: . file format (binary, ascii, record based, ...) . attributes (MacOS resources, OS/2 EAs, Unix permissions, owner, groups, time/date info, ACLs, ...) . directory structures (not everything uses slashes or is a single rooted tree) . character-set issues (for ascii files there needs to be a standard character-set. at this point the choice is easy, something based on Unicode.) Not all of this information is useable by all OSs. But when two systems of the same type communicate you want files to be transfered in their entirety. When they move between systems, you want them to be as close as possible. These issues do not appear to be addressed by the SSH group because there is no representation from non-Unix communities. Or because the SSH group believes that anything that is non-Unix (or Win32) should no longer be used. Before a decision can be made as to whether reusing FTP (RFC 959) or building something else, you need to have a requirements document that explains your needs. Otherwise, you will never be happy with what is produced. The Kermit project built the Internet Kermit Service (RFC 2839) in order to create a secure, single channel solution which addresses the requirements of transfering data among heterogeneous platforms. I strongly recommend that you look at the work that was done before coming to any conclusion about how you should proceed. 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 ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 29 09:08:39 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14761 for ; Thu, 29 Mar 2001 09:08:38 -0500 (EST) Received: (qmail 12847 invoked by uid 605); 29 Mar 2001 14:08:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12840 invoked from network); 29 Mar 2001 14:08:31 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 29 Mar 2001 14:08:31 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 20C3E82F489 for ; Thu, 29 Mar 2001 16:08:30 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id QAA27321; Thu, 29 Mar 2001 16:08:29 +0200 (MET DST) To: ietf-ssh@netbsd.org Subject: uint64 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 29 Mar 2001 16:08:29 +0200 Message-ID: Lines: 21 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit draft-ietf-secsh-architecture-07.txt defines the type uint64, uint64 Represents a 64-bit unsigned integer. Stored as eight bytes in the order of decreasing significance (network byte order). It is currently used only from by the filexfer document, for file sizes, offsets and the like. I'd like to ask if we really need this type. The alternative is to use mpint (or mpuint, if that is added) for any numbers that can be expected to grow larger than an uint32. All implementations can be expected to have a native uint32 and a bignum type. They may or may not have an 64 bit integer type. By using mpint, the protocol stays agnostic. An implementation will convert the mpint value to its natural offset type (be that 32 bit, 64 bit, or whatever), or return an appropriate error message if the number is too big. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 29 10:55:25 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20141 for ; Thu, 29 Mar 2001 10:55:25 -0500 (EST) Received: (qmail 670 invoked by uid 605); 29 Mar 2001 15:52:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 662 invoked from network); 29 Mar 2001 15:52:57 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 29 Mar 2001 15:52:57 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 7FE3A82F48B for ; Thu, 29 Mar 2001 17:52:56 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id RAA09439; Thu, 29 Mar 2001 17:52:55 +0200 (MET DST) To: ietf-ssh@netbsd.org Subject: sftp, SSH_FXP_MKDIR lacks attributes. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 29 Mar 2001 17:52:52 +0200 Message-ID: Lines: 5 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit I don't remember if someone already mentioned this, but the SSH_FXP_MKDIR message should include attribute information for the new directory. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 29 13:29:33 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00640 for ; Thu, 29 Mar 2001 13:29:32 -0500 (EST) Received: (qmail 5959 invoked by uid 605); 29 Mar 2001 18:29:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5952 invoked from network); 29 Mar 2001 18:29:24 -0000 Received: from mail.vandyke.com (204.134.9.1) by mail.netbsd.org with SMTP; 29 Mar 2001 18:29:24 -0000 Received: from king ([192.168.0.17]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 63; Thu, 29 Mar 2001 11:37:09 -0700 Message-ID: <006901c0b87e$1a665cc0$1100a8c0@vandyke.com> From: "David B. Coningham" To: "David Terrell" Cc: References: <200103280027.f2S0RA920439@thunk.east.sun.com> <20010327170015.C30334@pianosa.catch22.org> Subject: Re: avoiding reinventing the wheel on file transfer. Date: Thu, 29 Mar 2001 11:28:51 -0700 Organization: Van Dyke Technologies, Inc. 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: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > > So, I have this concern that we're going to spend a whole lot of time > > on the file transfer draft, and in the process reinvent a couple > > wheels which have already been built. > > > > Here's a half-formed suggestion for the working group... > > > > file transfer involves a bunch of really ugly issues (newline > > conventions, binary/ascii/... modes, i18n of filenames, etc., etc.). > > Many of these problems have already been tackled by FTP. > > > > A radically different and simpler approach (from a standards-writing > > viewpoint, at least) may well be to define a way to tunnel "normal" > > ftp through a collection of ssh channels, so we can avoid refighting > > all the battles which were fought over FTP... i.e., you start off with > > one channel for the FTP control channel, and then open up new ssh > > channels where "normal" FTP would open a new TCP connection.... > > As a point of reference, I believe SecureFX from vandyke does > exactly this by using creative PORT commands and dynamic remote > port forwarding against an existing FTP daemon on the sshd host. Thank you for pointing this out. SecureFX does indeed perform FTP transfers over a single SSH connection (establishing one channel for the control connection and one channel each time a data connection is required). One minor point of correction to the above statement is that SecureFX uses PASV to establish the data connection rather than PORT. PORT currently cannot be used very effectively because of a limitation with the remote port forwarding mechanism: it does not provide a way to determine the actual port number to which the listening socket is bound (if 0 is requested). For this reason it would be desirable to see the remote port forwarding response changed to include the port number. --- David Coningham dbc-pub@vandyke.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 29 14:56:17 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07232 for ; Thu, 29 Mar 2001 14:56:16 -0500 (EST) Received: (qmail 26618 invoked by uid 605); 29 Mar 2001 19:56:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26611 invoked from network); 29 Mar 2001 19:56:09 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 29 Mar 2001 19:56:09 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18723 for ; Thu, 29 Mar 2001 11:56:08 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id LAA26417 for ; Thu, 29 Mar 2001 11:56:17 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.12.0.Beta6+Sun/8.12.0.Beta6) with SMTP id f2TJu2WI429840 for ; Thu, 29 Mar 2001 11:56:03 -0800 (PST) Message-Id: <200103291956.f2TJu2WI429840@jurassic.eng.sun.com> Date: Thu, 29 Mar 2001 11:56:03 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: uint64 To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: /zku8ttP432pL9VhjsQlbA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_26 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >draft-ietf-secsh-architecture-07.txt defines the type uint64, > > uint64 > Represents a 64-bit unsigned integer. Stored as eight bytes in > the order of decreasing significance (network byte order). > >It is currently used only from by the filexfer document, for file >sizes, offsets and the like. If it is only used by filexfer then I don't think it should be mentioned in architecture at all - especially since filexfer is supposed to be independant of the SSH protocol. >I'd like to ask if we really need this type. The alternative is to use >mpint (or mpuint, if that is added) for any numbers that can be >expected to grow larger than an uint32. Do you have any in mind for the core drafts that do need to grow larger than uint32 or might need to within a few years ? -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 30 01:55:34 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01009 for ; Fri, 30 Mar 2001 01:55:32 -0500 (EST) Received: (qmail 20771 invoked by uid 605); 30 Mar 2001 06:55:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20764 invoked from network); 30 Mar 2001 06:55:24 -0000 Received: from nic.appgate.com (193.12.107.226) by mail.netbsd.org with SMTP; 30 Mar 2001 06:55:24 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id 8AB1C3BDE4; Fri, 30 Mar 2001 08:55:22 +0200 (MET DST) Received: from pelee.firedoor.se (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 3DC166C007; Fri, 30 Mar 2001 09:00:41 +0200 (CEST) Received: from appgate.com (pelee.firedoor.se [172.23.2.10]) by pelee.firedoor.se (Postfix) with ESMTP id 39D03317B7; Fri, 30 Mar 2001 08:55:16 +0200 (MEST) Date: Fri, 30 Mar 2001 08:55:39 +0200 (MEST) From: Martin Forssen Subject: Re: avoiding reinventing the wheel on file transfer. To: dbc-pub@vandyke.com Cc: dbt@meat.net, ietf-ssh@netbsd.org In-Reply-To: <006901c0b87e$1a665cc0$1100a8c0@vandyke.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20010330065516.39D03317B7@pelee.firedoor.se> Sender: ietf-ssh-owner@netbsd.org Precedence: list On 29 Mar, David B. Coningham wrote: > Thank you for pointing this out. SecureFX does indeed perform FTP > transfers over a single SSH connection (establishing one channel for > the control connection and one channel each time a data connection is > required). Just to give another data-point I can mention that we at AppGate have implemented an ftp-proxy which uses one single channel for both command and data. This allows us to handle both active and passive ftp. However I am not saying we should adapt this solution for the filexfer draft. I am also of the opinion that we need to find something better than ftp. /MaF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 30 02:08:50 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA10379 for ; Fri, 30 Mar 2001 02:08:49 -0500 (EST) Received: (qmail 21945 invoked by uid 605); 30 Mar 2001 07:08:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21938 invoked from network); 30 Mar 2001 07:08:43 -0000 Received: from mindterm.appgate.com (HELO mail.mindbright.se) (postfix@193.12.107.237) by mail.netbsd.org with SMTP; 30 Mar 2001 07:08:43 -0000 Received: by mail.mindbright.se (Postfix, from userid 1001) id 74AA01FF03; Fri, 30 Mar 2001 09:22:52 +0200 (MEST) Received: from localhost (localhost [127.0.0.1]) by mail.mindbright.se (Postfix) with ESMTP id 6869A1F106; Fri, 30 Mar 2001 09:22:52 +0200 (MEST) Date: Fri, 30 Mar 2001 09:22:52 +0200 (MEST) From: Mats Andersson X-Sender: mats@mindterm.appgate.com To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: ietf-ssh@netbsd.org Subject: Re: sftp, SSH_FXP_MKDIR lacks attributes. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id CAA10379 Hi, On 29 Mar 2001, Niels MЖller wrote: > I don't remember if someone already mentioned this, but the > SSH_FXP_MKDIR message should include attribute information for the new > directory. ? draft-ietf-secsh-filexfer-01.txt: ... New directories can be created using the SSH_FXP_MKDIR request. It has the following format: uint32 id string path ATTRS attrs ... Cheers, /Mats From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 30 03:21:00 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA19477 for ; Fri, 30 Mar 2001 03:20:59 -0500 (EST) Received: (qmail 6574 invoked by uid 605); 30 Mar 2001 08:20:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6563 invoked from network); 30 Mar 2001 08:20:41 -0000 Received: from mindterm.appgate.com (HELO mail.mindbright.se) (postfix@193.12.107.237) by mail.netbsd.org with SMTP; 30 Mar 2001 08:20:41 -0000 Received: by mail.mindbright.se (Postfix, from userid 1001) id 24DEF1FF03; Fri, 30 Mar 2001 10:34:51 +0200 (MEST) Received: from localhost (localhost [127.0.0.1]) by mail.mindbright.se (Postfix) with ESMTP id 1E1EF1F106; Fri, 30 Mar 2001 10:34:51 +0200 (MEST) Date: Fri, 30 Mar 2001 10:34:51 +0200 (MEST) From: Mats Andersson X-Sender: mats@mindterm.appgate.com To: "David B. Coningham" Cc: David Terrell , ietf-ssh@netbsd.org Subject: Re: avoiding reinventing the wheel on file transfer. In-Reply-To: <006901c0b87e$1a665cc0$1100a8c0@vandyke.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi, On Thu, 29 Mar 2001, David B. Coningham wrote: > uses PASV to establish the data connection rather than PORT. PORT > currently cannot be used very effectively because of a limitation with > the remote port forwarding mechanism: it does not provide a way to > determine the actual port number to which the listening socket is > bound (if 0 is requested). You can of course support PORT too (which we do) since you can just loop and take a random high port to listen to and see if it works (almost always works on first attempt also so mostly not very inefficient :-). > For this reason it would be desirable to see the remote port > forwarding response changed to include the port number. However, as you say (and many have said earlier) it would be a nice (and trivial) addition that listening on 0 remotely replies with an extra field with the actual port number if succesful. Cheers, /Mats From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 30 06:43:03 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08098 for ; Fri, 30 Mar 2001 06:43:03 -0500 (EST) Received: (qmail 13149 invoked by uid 605); 30 Mar 2001 11:42:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13142 invoked from network); 30 Mar 2001 11:42:53 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 30 Mar 2001 11:42:53 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 99ABD82F4F8; Fri, 30 Mar 2001 13:42:51 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id NAA12426; Fri, 30 Mar 2001 13:42:51 +0200 (MET DST) To: Darren Moffat Cc: ietf-ssh@netbsd.org Subject: Re: uint64 References: <200103291956.f2TJu2WI429840@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 30 Mar 2001 13:42:46 +0200 In-Reply-To: Darren Moffat's message of "Thu, 29 Mar 2001 11:56:03 -0800 (PST)" Message-ID: Lines: 23 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Darren Moffat writes: > If it is only used by filexfer then I don't think it should be mentioned > in architecture at all - especially since filexfer is supposed to be > independant of the SSH protocol. To me, it makes sense to have all the encoding rules for all basic types in one place. > >I'd like to ask if we really need this type. The alternative is to use > >mpint (or mpuint, if that is added) for any numbers that can be > >expected to grow larger than an uint32. > > Do you have any in mind for the core drafts that do need to grow larger > than uint32 or might need to within a few years ? Offsets and times in filexfer are the ones I'm thinking of now. In the other drafts, all big numbers are already specified as mpint. For other numbers in the protocol, packet sizes are limited, and 32-bit channel numbers and window sizes seem reasonable to me. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 30 06:47:09 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08340 for ; Fri, 30 Mar 2001 06:47:08 -0500 (EST) Received: (qmail 13572 invoked by uid 605); 30 Mar 2001 11:47:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13562 invoked from network); 30 Mar 2001 11:47:00 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 30 Mar 2001 11:47:00 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 1688582F4F8; Fri, 30 Mar 2001 13:46:59 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id NAA16553; Fri, 30 Mar 2001 13:46:58 +0200 (MET DST) To: Mats Andersson Cc: ietf-ssh@netbsd.org Subject: Re: sftp, SSH_FXP_MKDIR lacks attributes. References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 30 Mar 2001 13:46:58 +0200 In-Reply-To: Mats Andersson's message of "Fri, 30 Mar 2001 09:22:52 +0200 (MEST)" Message-ID: Lines: 28 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Mats Andersson writes: > draft-ietf-secsh-filexfer-01.txt: Hmm. I can't find that document (or any of the other recent updates) at ftp://ftp.ietf.org/internet-drafts. The full list of wg documents there is -rwxrw-r-- 1 ftpuser ftpusers 27345 Jan 9 08:51 draft-ietf-secsh-architecture-07.txt -rwxrw-r-- 1 ftpuser ftpusers 16117 Mar 2 07:32 draft-ietf-secsh-auth-kbdinteract-02.txt -rwxrw-r-- 1 ftpuser ftpusers 36516 Jan 9 08:51 draft-ietf-secsh-connect-09.txt -rw-rw-r-- 1 ftpuser ftpusers 14222 Jan 30 11:48 draft-ietf-secsh-dh-group-exchange-00.txt -rwxrw-r-- 1 ftpuser ftpusers 41987 Jan 9 13:05 draft-ietf-secsh-filexfer-00.txt -rw-rw-r-- 1 ftpuser ftpusers 26676 Mar 6 12:37 draft-ietf-secsh-gsskeyex-01.txt -rw-rw-r-- 1 ftpuser ftpusers 6779 Mar 5 12:10 draft-ietf-secsh-publickeyfile-01.txt -rwxrw-r-- 1 ftpuser ftpusers 53476 Jan 9 08:51 draft-ietf-secsh-transport-09.txt -rwxrw-r-- 1 ftpuser ftpusers 26537 Jan 9 08:51 draft-ietf-secsh-userauth-09.txt > New directories can be created using the SSH_FXP_MKDIR request. It has > the following format: > > uint32 id > string path > ATTRS attrs Ah, that looks better. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 30 09:09:00 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16140 for ; Fri, 30 Mar 2001 09:08:59 -0500 (EST) Received: (qmail 5407 invoked by uid 605); 30 Mar 2001 14:08:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5400 invoked from network); 30 Mar 2001 14:08:46 -0000 Received: from mail.vandyke.com (204.134.9.1) by mail.netbsd.org with SMTP; 30 Mar 2001 14:08:46 -0000 Received: from joseph ([192.168.0.1]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 240; Fri, 30 Mar 2001 07:16:35 -0700 Message-ID: <025801c0b923$b489fd70$140210ac@Galbraith.Local> From: "Joseph Galbraith" To: Cc: =?iso-8859-1?Q?Niels_M=F6ller?= References: Subject: Re: uint64 Date: Fri, 30 Mar 2001 07:14: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: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > draft-ietf-secsh-architecture-07.txt defines the type uint64, > > uint64 > Represents a 64-bit unsigned integer. Stored as eight bytes in > the order of decreasing significance (network byte order). > > It is currently used only from by the filexfer document, for file > sizes, offsets and the like. > > I'd like to ask if we really need this type. The alternative is to use > mpint (or mpuint, if that is added) for any numbers that can be > expected to grow larger than an uint32. > > All implementations can be expected to have a native uint32 and a > bignum type. They may or may not have an 64 bit integer type. By using > mpint, the protocol stays agnostic. An implementation will convert the > mpint value to its natural offset type (be that 32 bit, 64 bit, or > whatever), or return an appropriate error message if the number is too > big. I think mpint would be a mistake. This would be a new requirement for the sftp subsystem, which currently does not require a bignum library to implement. An architecture that doesn't natively support 64 bit integer types probably doesn't have 64 bit API's to pass the number into, or such interfaces are probably something like uint32 highPart, uint32 lowPart. Regardless, such an implementation should treat a uint64 as uint32 highPart uint32 lowPart and fail the operation if highPart != 0 and it can't support it. This is a simple solution that doesn't require the addition of another large, complicated library to the sftp subsystem. It wouldn't bother me if we wanted to strike uint64 and simply use uint32 highPart uint32 lowPart This is actually the way I have to have the data anyway, since that is how the Win32 file-system calls are done. But, having uint64 doesn't really bother me either, and is, perhaps, conceptually cleaner. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 30 09:17:14 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16574 for ; Fri, 30 Mar 2001 09:17:13 -0500 (EST) Received: (qmail 6251 invoked by uid 605); 30 Mar 2001 14:17:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6244 invoked from network); 30 Mar 2001 14:17:02 -0000 Received: from faui02.informatik.uni-erlangen.de (msfriedl@131.188.30.102) by mail.netbsd.org with SMTP; 30 Mar 2001 14:17:02 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id QAA06549; Fri, 30 Mar 2001 16:16:57 +0200 (MET DST) Date: Fri, 30 Mar 2001 16:16:57 +0200 From: Markus Friedl To: Joseph Galbraith Cc: ietf-ssh@netbsd.org, =?iso-8859-1?Q?Niels_M=F6ller?= Subject: Re: uint64 Message-ID: <20010330161657.A2689@faui02.informatik.uni-erlangen.de> References: <025801c0b923$b489fd70$140210ac@Galbraith.Local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <025801c0b923$b489fd70$140210ac@Galbraith.Local>; from galb-list@vandyke.com on Fri, Mar 30, 2001 at 07:14:13AM -0700 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 30, 2001 at 07:14:13AM -0700, Joseph Galbraith wrote: > I think mpint would be a mistake. I agree with Joseph, the sftp subsystem should not depend on bignum libraries. Early versions of OpenSSH's sftp-server used the approach suggested by Joseph with success: > Regardless, such an implementation should treat > a uint64 as > > uint32 highPart > uint32 lowPart > > and fail the operation if highPart != 0 and it > can't support it. -markus From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 30 09:32:16 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17365 for ; Fri, 30 Mar 2001 09:32:15 -0500 (EST) Received: (qmail 8006 invoked by uid 605); 30 Mar 2001 14:32:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7992 invoked from network); 30 Mar 2001 14:32:06 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 30 Mar 2001 14:32:06 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 7C96F82F51A; Fri, 30 Mar 2001 16:32:04 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id QAA04513; Fri, 30 Mar 2001 16:32:03 +0200 (MET DST) To: "Joseph Galbraith" Cc: Subject: Re: uint64 References: <025801c0b923$b489fd70$140210ac@Galbraith.Local> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels MЖller) Date: 30 Mar 2001 16:32:02 +0200 In-Reply-To: "Joseph Galbraith"'s message of "Fri, 30 Mar 2001 07:14:13 -0700" Message-ID: Lines: 39 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit "Joseph Galbraith" writes: > I think mpint would be a mistake. > > This would be a new requirement for the sftp subsystem, > which currently does not require a bignum library to > implement. You don't need a full bignum library just because you use the mpint representation. I'm imagining a decoding function that's somthing like off_t get_offset(input_buffer *b) { uint32_t length = get_uint32(b); uint32_t i; off_t offset; if (length > sizeof(off_t)) /* Fail, preferably in some more graceful way */ fatal(); for (offset = 0, i = 0; i