From owner-ietf-ssh@clinet.fi Thu Feb 1 04:29:50 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA22338 for ; Thu, 1 Feb 2001 04:29:50 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id JAA10812 for ietf-ssh-outgoing; Thu, 1 Feb 2001 09:28:22 +0200 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id JAA10799 for ; Thu, 1 Feb 2001 09:27:58 +0200 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA06491; Wed, 31 Jan 2001 23:27:50 -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) with ESMTP id XAA19730; Wed, 31 Jan 2001 23:27:49 -0800 (PST) Received: from Eng.Sun.COM (dsl-192-32.Eng.Sun.COM [129.146.192.32]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f117RXR336393; Wed, 31 Jan 2001 23:27:33 -0800 (PST) Message-ID: <3A791078.B7413534@Eng.Sun.COM> Date: Wed, 31 Jan 2001 23:30:01 -0800 From: Darren J Moffat Organization: Sun Microsystems Inc - Solaris Security Technologies Group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: Damien Miller CC: ietf-ssh@clinet.fi Subject: Re: User and group information in sftp attributes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Damien Miller wrote: > > Currently the filexfer draft encodes user and group info as ints. > Would it make sense to send the textual user and group as strings > as well? > > This would enable the receiver to maintain ownership where the same > names are present, but the uids and gids differ, a situation which > is pretty common. I can see the rational but I don't think this is a good idea my first reaction is that this is what nameservices are deployed for ie, consistant mapping from name to number. It is inconsistant with what NFS does and what FTP does. I can't think of a security vulnerability it just doesn't give me the warm fuzzies. -- Darren J Moffat From owner-ietf-ssh@clinet.fi Thu Feb 1 07:26: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 HAA24537 for ; Thu, 1 Feb 2001 07:26:53 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA21969 for ietf-ssh-outgoing; Thu, 1 Feb 2001 12:33:11 +0200 Received: from faui02.informatik.uni-erlangen.de (msfriedl@faui02.informatik.uni-erlangen.de [131.188.30.102]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id MAA21893 for ; Thu, 1 Feb 2001 12:32:47 +0200 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id LAA08864; Thu, 1 Feb 2001 11:32:39 +0100 (MET) Date: Thu, 1 Feb 2001 11:32:39 +0100 From: Markus Friedl To: Damien Miller Cc: ietf-ssh@clinet.fi Subject: Re: User and group information in sftp attributes Message-ID: <20010201113239.A8792@faui02.informatik.uni-erlangen.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from djm@mindrot.org on Thu, Feb 01, 2001 at 11:23:22AM +1100 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Thu, Feb 01, 2001 at 11:23:22AM +1100, Damien Miller wrote: > Currently the filexfer draft encodes user and group info as ints. > Would it make sense to send the textual user and group as strings > as well? > > This would enable the receiver to maintain ownership where the same > names are present, but the uids and gids differ, a situation which > is pretty common. well, you could use SSH_FILEXFER_ATTR_EXTENDED if you need this feature. From owner-ietf-ssh@clinet.fi Thu Feb 1 09:28:51 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27817 for ; Thu, 1 Feb 2001 09:28:51 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id OAA21203 for ietf-ssh-outgoing; Thu, 1 Feb 2001 14:37:18 +0200 Received: from faui02.informatik.uni-erlangen.de (msfriedl@faui02.informatik.uni-erlangen.de [131.188.30.102]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id OAA21199 for ; Thu, 1 Feb 2001 14:37:15 +0200 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id NAA19915 for ietf-ssh@clinet.fi; Thu, 1 Feb 2001 13:37:13 +0100 (MET) Date: Thu, 1 Feb 2001 13:37:13 +0100 From: Markus Friedl To: ietf-ssh@clinet.fi Subject: Re: server public key fingerprint? Message-ID: <20010201133713.A19881@faui02.informatik.uni-erlangen.de> References: <003301c089a3$766c2f90$0201010a@intergalactic> <20010131161116.A25834@faui02.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20010131161116.A25834@faui02.informatik.uni-erlangen.de>; from Markus.Friedl@informatik.uni-erlangen.de on Wed, Jan 31, 2001 at 04:11:16PM +0100 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk hi, tried to send this earlier, but it did not arrive on the list: http://wwwcip.informatik.uni-erlangen.de/~msfriedl/fp.txt contains a short drafts about pubkey-fingerprints. -m On Wed, Jan 31, 2001 at 04:11:16PM +0100, Markus Friedl wrote: > On Mon, Jan 29, 2001 at 04:27:52AM +0100, denis bider wrote: > > Hello everyone, > > > > is there a standardized fingerprint calculation method for verifying the > > integrity of a server's public key? I searched the archives for the string > > 'finger', and it only occurs once - in a PGP-related header field of a > > single message... > > > > I would think a standardized fingerprinting method would be necessary in > > order to facilitate interoperation of clients and servers from different > > vendors. How can you call up a server's administrator to verify the public > > key if your client calculates the fingerprint in a manner that is > > incompatible with the server? > > openssh is using fingerprints for more than a year i think, so > i wrote this short draft. > > any comments appreciated. > > Cheers, > -markus From owner-ietf-ssh@clinet.fi Thu Feb 1 12:46:31 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04246 for ; Thu, 1 Feb 2001 12:46:30 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA30779 for ietf-ssh-outgoing; Thu, 1 Feb 2001 18:03:29 +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 SAA30772 for ; Thu, 1 Feb 2001 18:03:27 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 56A412403193; Thu, 1 Feb 2001 17:03:26 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id RAA26816; Thu, 1 Feb 2001 17:03:25 +0100 (MET) To: Markus Friedl Cc: ietf-ssh@clinet.fi Subject: Re: server public key fingerprint? References: <003301c089a3$766c2f90$0201010a@intergalactic> <20010131161116.A25834@faui02.informatik.uni-erlangen.de> <20010201133713.A19881@faui02.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 01 Feb 2001 17:03:24 +0100 In-Reply-To: Markus Friedl's message of "Thu, 1 Feb 2001 13:37:13 +0100" Message-ID: Lines: 13 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Markus Friedl writes: > hi, tried to send this earlier, but it did not arrive on > the list: > > http://wwwcip.informatik.uni-erlangen.de/~msfriedl/fp.txt > > contains a short drafts about pubkey-fingerprints. Thanks. Is there any particular reason why you use md5, and not sha1 (or truncated sha1, if the size is an issue)? /Niels From owner-ietf-ssh@clinet.fi Thu Feb 1 13:35:28 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06264 for ; Thu, 1 Feb 2001 13:35:27 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA02233 for ietf-ssh-outgoing; Thu, 1 Feb 2001 18:41:09 +0200 Received: from faui02.informatik.uni-erlangen.de (msfriedl@faui02.informatik.uni-erlangen.de [131.188.30.102]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA02229 for ; Thu, 1 Feb 2001 18:41:08 +0200 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id RAA10306; Thu, 1 Feb 2001 17:41:06 +0100 (MET) Date: Thu, 1 Feb 2001 17:41:06 +0100 From: Markus Friedl To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: ietf-ssh@clinet.fi, bg@sics.se Subject: Re: server public key fingerprint? Message-ID: <20010201174106.A10137@faui02.informatik.uni-erlangen.de> References: <003301c089a3$766c2f90$0201010a@intergalactic> <20010131161116.A25834@faui02.informatik.uni-erlangen.de> <20010201133713.A19881@faui02.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 In-Reply-To: ; from nisse@lysator.liu.se on Thu, Feb 01, 2001 at 05:03:24PM +0100 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id SAA02233 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA06264 On Thu, Feb 01, 2001 at 05:03:24PM +0100, Niels Mцller wrote: > Thanks. Is there any particular reason why you use md5, and not sha1 > (or truncated sha1, if the size is an issue)? fingerprinting was Bjoern's idea (bg@sics.se) and since his OSSH did only contain md5 we decided that there is no need for sha1. so now OpenSSH and OSSH use md5-fingerprints since October 1999. -markus From owner-ietf-ssh@clinet.fi Thu Feb 1 14:07:44 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08126 for ; Thu, 1 Feb 2001 14:07:44 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA07627 for ietf-ssh-outgoing; Thu, 1 Feb 2001 19:38:49 +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 TAA07624 for ; Thu, 1 Feb 2001 19:38:48 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 4215A240B98B; Thu, 1 Feb 2001 18:38:48 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id SAA09786; Thu, 1 Feb 2001 18:38:47 +0100 (MET) To: Markus Friedl Cc: ietf-ssh@clinet.fi, bg@sics.se Subject: Re: server public key fingerprint? References: <003301c089a3$766c2f90$0201010a@intergalactic> <20010131161116.A25834@faui02.informatik.uni-erlangen.de> <20010201133713.A19881@faui02.informatik.uni-erlangen.de> <20010201174106.A10137@faui02.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 01 Feb 2001 18:38:44 +0100 In-Reply-To: Markus Friedl's message of "Thu, 1 Feb 2001 17:41:06 +0100" Message-ID: Lines: 13 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Markus Friedl writes: > fingerprinting was Bjoern's idea (bg@sics.se) and since his OSSH > did only contain md5 we decided that there is no need for sha1. > > so now OpenSSH and OSSH use md5-fingerprints since October 1999. Ok. I'll see if I can add compatible fingerprinting to lsh. I liked SPKI hashes as fingerprints because it isn't application specific. But perhaps that doesn't matter, people won't (or perhaps even shouldn't) use the same keys for several applications. /Niels From owner-ietf-ssh@clinet.fi Thu Feb 1 18:54:03 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14941 for ; Thu, 1 Feb 2001 18:54:02 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA26808 for ietf-ssh-outgoing; Thu, 1 Feb 2001 23:47:20 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA26803 for ; Thu, 1 Feb 2001 23:47:18 +0200 Received: from king ([192.168.0.17]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 537 for ; Thu, 1 Feb 2001 14:53:15 -0700 Message-ID: <01ed01c08c98$883ab3c0$1100a8c0@vandyke.com> From: "David B. Coningham" To: References: <003301c089a3$766c2f90$0201010a@intergalactic> <20010131161116.A25834@faui02.informatik.uni-erlangen.de> <20010201133713.A19881@faui02.informatik.uni-erlangen.de> Subject: Re: server public key fingerprint? Date: Thu, 1 Feb 2001 14:47:10 -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: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit > hi, tried to send this earlier, but it did not arrive on > the list: > > http://wwwcip.informatik.uni-erlangen.de/~msfriedl/fp.txt > > contains a short drafts about pubkey-fingerprints. Thanks to Markus for posting this draft. The SSH Communications software presents the fingerprint in what they describe as "the ingenious Bubble Babble format," which appears to be a string of 11 words made up of 5 seemingly-random characters. Since "Bubble Babble" is a much longer random string than the hex string proposed in the draft, is there any reason for using it instead of the hex string format? If having a string of words is the reason, should a string of words like the one defined for one-time passwords (OTP) in RFC2289 be used instead? This would yield, I believe, 12 words, which a user may find easier to compare than 32 characters. If something like this is truly useful, should it be added to the draft? Is there any documentation available for the "Bubble Babble" format? --- David B. Coningham dbc-pub@vandyke.com From owner-ietf-ssh@clinet.fi Thu Feb 1 20:35:12 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16761 for ; Thu, 1 Feb 2001 20:35:11 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA02259 for ietf-ssh-outgoing; Fri, 2 Feb 2001 01:59:09 +0200 Received: from faui02.informatik.uni-erlangen.de (msfriedl@faui02.informatik.uni-erlangen.de [131.188.30.102]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id BAA02255 for ; Fri, 2 Feb 2001 01:59:08 +0200 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id AAA04831; Fri, 2 Feb 2001 00:59:03 +0100 (MET) Date: Fri, 2 Feb 2001 00:59:03 +0100 From: Markus Friedl To: "David B. Coningham" Cc: ietf-ssh@clinet.fi Subject: Re: server public key fingerprint? Message-ID: <20010202005903.A4667@faui02.informatik.uni-erlangen.de> References: <003301c089a3$766c2f90$0201010a@intergalactic> <20010131161116.A25834@faui02.informatik.uni-erlangen.de> <20010201133713.A19881@faui02.informatik.uni-erlangen.de> <01ed01c08c98$883ab3c0$1100a8c0@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <01ed01c08c98$883ab3c0$1100a8c0@vandyke.com>; from dbc-pub@vandyke.com on Thu, Feb 01, 2001 at 02:47:10PM -0700 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Thu, Feb 01, 2001 at 02:47:10PM -0700, David B. Coningham wrote: > Since "Bubble Babble" is a much longer random string than the hex > string proposed in the draft, is there any reason for using it instead > of the hex string format? i don't know. perhaps its easier to memorize than hex strings? but i don't memorize fingerprints, i just compare them. > If having a string of words is the reason, > should a string of words like the one defined for one-time passwords > (OTP) in RFC2289 be used instead? yes, i think this is a much better option than the "Bubble Babble". the OTP words are in use for a long time. i was thinking about this before but decided that the hex format is simple and already in use by some clients. > This would yield, I believe, 12 > words, which a user may find easier to compare than 32 characters. > > If something like this is truly useful, should it be added to the draft? why not. feel free to edit the draft. cheers, -markus From owner-ietf-ssh@clinet.fi Fri Feb 2 09:12:17 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 JAA09369 for ; Fri, 2 Feb 2001 09:12:16 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id OAA09167 for ietf-ssh-outgoing; Fri, 2 Feb 2001 14:22:55 +0200 Received: from levitator.1div0.com (node.061-0.ty.link.si [213.250.43.61]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id OAA09140 for ; Fri, 2 Feb 2001 14:22:50 +0200 Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id NAA04544 for ; Fri, 2 Feb 2001 13:06:15 +0100 Reply-To: From: "denis bider" To: Subject: RE: server public key fingerprint? Date: Fri, 2 Feb 2001 13:21:29 +0100 Message-ID: <009d01c08d12$ac63e710$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20010202005903.A4667@faui02.informatik.uni-erlangen.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit > > This would yield, I believe, 12 words, which a user > > may find easier to compare than 32 characters. > > > > If something like this is truly useful, should it be added > > to the draft? > > why not. feel free to edit the draft. I think it would be best if the fingerprint specification mandated a single fingerprint format, not multiple formats; and that the single fingerprint format be simple to implement. In other words - it's OK if you want to define 5 different fingerprint formats in the specification, as long as you point out a single one that is THE fingerprint format, and make that format required, and all other formats optional. Also, if there are multiple formats, the specification should mandate that an application must ALWAYS use the required fingerprint format when displaying fingerprints. It may at the same time display the fingerprint in any other formats, but it must display it in the required format as well. [I.e., no configuration setting to change the preferred format - always display all of them, or at least the required one.] I would hope that the required fingerprint format would be a straightforward one, like the currently defined MD5 format. I wouldn't vote for a specification that mandates a bubble-babble kind of thing; I think the required format should be one that is straightforward and simple to implement. Finally, I don't think there's really any need to define more than one fingerprint format. But if you nevertheless decide to define multiple, please consider the above comments. Regards, denis From owner-ietf-ssh@clinet.fi Fri Feb 2 11:21:43 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13828 for ; Fri, 2 Feb 2001 11:21:42 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id QAA03908 for ietf-ssh-outgoing; Fri, 2 Feb 2001 16:11:30 +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 QAA03862 for ; Fri, 2 Feb 2001 16:11:28 +0200 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by smtp1.clinet.fi (Postfix) with ESMTP id BFF17310 for ; Fri, 2 Feb 2001 15:06:23 +0200 (EET) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07085; Fri, 2 Feb 2001 08:06:20 -0500 (EST) Message-Id: <200102021306.IAA07085@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@clinet.fi From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-griffin-ssh-host-keys-in-dns-00.txt Date: Fri, 02 Feb 2001 08:06:20 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Storing SSH Host Keys in DNS Author(s) : W. Griffin Filename : draft-griffin-ssh-host-keys-in-dns-00.txt Pages : 5 Date : 01-Feb-01 DNS Security Extensions enables the secure distribution of public keys over the Internet. This is a desirable feature for the SSH protocol. This document defines the format for storing SSH host keys in KEY resource records. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-griffin-ssh-host-keys-in-dns-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-griffin-ssh-host-keys-in-dns-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-griffin-ssh-host-keys-in-dns-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010201080651.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-griffin-ssh-host-keys-in-dns-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-griffin-ssh-host-keys-in-dns-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010201080651.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ssh@clinet.fi Fri Feb 2 13:54:58 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21984 for ; Fri, 2 Feb 2001 13:54:58 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA22841 for ietf-ssh-outgoing; Fri, 2 Feb 2001 19:01:41 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA22838 for ; Fri, 2 Feb 2001 19:01:39 +0200 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28250 for ; Fri, 2 Feb 2001 09:01:37 -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 MAA12108 for ; Fri, 2 Feb 2001 12:01:37 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id f12H1a5153886 for ; Fri, 2 Feb 2001 12:01:36 -0500 (EST) Message-Id: <200102021701.f12H1a5153886@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@clinet.fi Subject: draft-griffin-ssh-host-keys-in-dns-00.txt Reply-to: sommerfeld@east.sun.com Date: Fri, 02 Feb 2001 12:01:36 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk I believe that: "Storing SSH Host Keys in DNS" draft-griffin-ssh-host-keys-in-dns-00.txt should be made a working group document. Please send comments on whether or not this makes sense to this list, (as well as technical or other comments on the document itself). - Bill From owner-ietf-ssh@clinet.fi Fri Feb 2 15:13:00 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25828 for ; Fri, 2 Feb 2001 15:12:58 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA27594 for ietf-ssh-outgoing; Fri, 2 Feb 2001 20:18:38 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA27589 for ; Fri, 2 Feb 2001 20:18:37 +0200 Received: from oldviper ([192.168.0.16]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 552; Fri, 2 Feb 2001 11:24:40 -0700 Message-ID: <001101c08d44$8d174960$1000a8c0@oldviper> From: "Jeff P. Van Dyke" To: , References: <200102021701.f12H1a5153886@thunk.east.sun.com> Subject: Re: draft-griffin-ssh-host-keys-in-dns-00.txt Date: Fri, 2 Feb 2001 11:17:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit From: "Bill Sommerfeld" > I believe that: > > "Storing SSH Host Keys in DNS" > draft-griffin-ssh-host-keys-in-dns-00.txt > > should be made a working group document. > > Please send comments on whether or not this makes sense to this list, > (as well as technical or other comments on the document itself). I agree. Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Fri Feb 2 15:24:36 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26313 for ; Fri, 2 Feb 2001 15:24:36 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA28632 for ietf-ssh-outgoing; Fri, 2 Feb 2001 20:34:48 +0200 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA28627 for ; Fri, 2 Feb 2001 20:34:46 +0200 Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f12IYOU22306; Fri, 2 Feb 2001 10:34:24 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f12HZRX03149; Fri, 2 Feb 2001 09:35:27 -0800 Message-Id: <200102021735.f12HZRX03149@zed.isi.edu> Subject: Re: draft-griffin-ssh-host-keys-in-dns-00.txt To: sommerfeld@east.sun.com Date: Fri, 2 Feb 2001 09:35:27 -0800 (PST) Cc: ietf-ssh@clinet.fi, lewis@tislabs.com In-Reply-To: <200102021701.f12H1a5153886@thunk.east.sun.com> from "Bill Sommerfeld" at Feb 02, 2001 12:01:36 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit % % I believe that: % % "Storing SSH Host Keys in DNS" % draft-griffin-ssh-host-keys-in-dns-00.txt % % should be made a working group document. % % Please send comments on whether or not this makes sense to this list, % (as well as technical or other comments on the document itself). % % - Bill If ssh does not pick this up, the DNS people will and they (speaking as a DNS oriented guy) won't really understand this. It would be useful to get Ed Lewis to comment as he has actually implemented this. ... Ed? --bill From owner-ietf-ssh@clinet.fi Fri Feb 2 15:31: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 PAA26672 for ; Fri, 2 Feb 2001 15:31:53 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA29506 for ietf-ssh-outgoing; Fri, 2 Feb 2001 20:48:39 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA29502 for ; Fri, 2 Feb 2001 20:48:38 +0200 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26718; Fri, 2 Feb 2001 10:48: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 NAA06596; Fri, 2 Feb 2001 13:48:34 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id f12ImY5154014; Fri, 2 Feb 2001 13:48:34 -0500 (EST) Message-Id: <200102021848.f12ImY5154014@thunk.east.sun.com> From: Bill Sommerfeld To: Bill Manning cc: sommerfeld@east.sun.com, ietf-ssh@clinet.fi, lewis@tislabs.com Subject: Re: draft-griffin-ssh-host-keys-in-dns-00.txt In-reply-to: Your message of "Fri, 02 Feb 2001 09:35:27 PST." <200102021735.f12HZRX03149@zed.isi.edu> Reply-to: sommerfeld@east.sun.com Date: Fri, 02 Feb 2001 13:48:33 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk If ssh does not pick this up, the DNS people will and they (speaking as a DNS oriented guy) won't really understand this. It would be useful to get Ed Lewis to comment as he has actually implemented this. ... Ed? I had a conversation along those lines with Olafur (for those keeping score at home, he's a co-chair of DNSEXT); we both vigorously agreed that it made more sense here than in DNSEXT. - Bill From owner-ietf-ssh@clinet.fi Fri Feb 2 17:55:42 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03786 for ; Fri, 2 Feb 2001 17:55:41 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA05985 for ietf-ssh-outgoing; Fri, 2 Feb 2001 23:23:50 +0200 Received: from dc.ogud.com (208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com [208.59.114.172]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA05978 for ; Fri, 2 Feb 2001 23:23:48 +0200 Received: from localhost (ogud@localhost) by dc.ogud.com (8.9.3/8.9.3) with ESMTP id QAA27702; Fri, 2 Feb 2001 16:24:15 -0500 (EST) (envelope-from ogud@ogud.com) Date: Fri, 2 Feb 2001 16:24:15 -0500 (EST) From: Olafur Gudmundsson X-Sender: ogud@himnariki.dc.ogud.com To: Bill Sommerfeld cc: Bill Manning , ietf-ssh@clinet.fi, lewis@tislabs.com Subject: Re: draft-griffin-ssh-host-keys-in-dns-00.txt In-Reply-To: <200102021848.f12ImY5154014@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Fri, 2 Feb 2001, Bill Sommerfeld wrote: > If ssh does not pick this up, the DNS people will and they > (speaking as a DNS oriented guy) won't really understand > this. It would be useful to get Ed Lewis to comment as > he has actually implemented this. ... Ed? > > I had a conversation along those lines with Olafur (for those keeping > score at home, he's a co-chair of DNSEXT); we both vigorously agreed > that it made more sense here than in DNSEXT. > > - Bill > Just to concurr Bill and I agreed that SSH people are much better qualified on specifying this but with help from us DNS people. There are no DNS issues associated with this the document mainly reserves a protocol number in DNS key records to use for SSH keys. I would like to ask the SSH WG to put this document on the fast track as it is small but this is important addition to key distribution for SSH. Olafur (co-chair of DNSEXT) From owner-ietf-ssh@clinet.fi Sat Feb 3 18:17: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 SAA14236 for ; Sat, 3 Feb 2001 18:17:34 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA05106 for ietf-ssh-outgoing; Sat, 3 Feb 2001 23:30:48 +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 XAA05100 for ; Sat, 3 Feb 2001 23:30:47 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id E78E1240318F; Sat, 3 Feb 2001 22:30:46 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id WAA16912; Sat, 3 Feb 2001 22:30:46 +0100 (MET) To: sommerfeld@east.sun.com Cc: ietf-ssh@clinet.fi Subject: Re: draft-griffin-ssh-host-keys-in-dns-00.txt References: <200102021701.f12H1a5153886@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 03 Feb 2001 22:30:46 +0100 In-Reply-To: Bill Sommerfeld's message of "Fri, 02 Feb 2001 12:01:36 -0500" Message-ID: Lines: 20 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Bill Sommerfeld writes: > I believe that: > > "Storing SSH Host Keys in DNS" > draft-griffin-ssh-host-keys-in-dns-00.txt > > should be made a working group document. > > Please send comments on whether or not this makes sense to this list, > (as well as technical or other comments on the document itself). I don't know very much about DNS and DNSSEC internals (in particular, I'm not sure how delegation/trust is supposed to flow across the dns tree). But the general idea of storing host keys in DNS makes a lot of sense to me, and I welcome work on this in the wg. /Niels From owner-ietf-ssh@clinet.fi Sat Feb 3 21:56:26 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09575 for ; Sat, 3 Feb 2001 21:56:25 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id DAA16682 for ietf-ssh-outgoing; Sun, 4 Feb 2001 03:22:21 +0200 Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id DAA16678 for ; Sun, 4 Feb 2001 03:22:20 +0200 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id UAA15645; Sat, 3 Feb 2001 20:22:17 -0500 (EST) Date: Sat, 3 Feb 2001 20:22:15 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu Cc: sommerfeld@east.sun.com, ietf-ssh@clinet.fi Subject: Re: draft-griffin-ssh-host-keys-in-dns-00.txt In-Reply-To: Your message of 03 Feb 2001 22:30:46 +0100 Message-ID: Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > Bill Sommerfeld writes: > > > I believe that: > > > > "Storing SSH Host Keys in DNS" > > draft-griffin-ssh-host-keys-in-dns-00.txt > > > > should be made a working group document. > > > > Please send comments on whether or not this makes sense to this list, > > (as well as technical or other comments on the document itself). > > I don't know very much about DNS and DNSSEC internals (in particular, > I'm not sure how delegation/trust is supposed to flow across the dns > tree). > > But the general idea of storing host keys in DNS makes a lot of sense > to me, and I welcome work on this in the wg. > > /Niels > Using DNS to distribute host keys only makes sense if and only if DNSSEC is used at the same time. Otherwise, DNS can be used to spoof the host key for a server. From owner-ietf-ssh@clinet.fi Sat Feb 3 23:03:37 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA10756 for ; Sat, 3 Feb 2001 23:03:37 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id EAA19431 for ietf-ssh-outgoing; Sun, 4 Feb 2001 04:25:22 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id EAA19427 for ; Sun, 4 Feb 2001 04:25:20 +0200 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA21065 for ; Sat, 3 Feb 2001 18:25:19 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.89.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id SAA27920 for ; Sat, 3 Feb 2001 18:25:18 -0800 (PST) Received: from Eng.Sun.COM (dsl-192-32.Eng.Sun.COM [129.146.192.32]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f142PHR877637 for ; Sat, 3 Feb 2001 18:25:18 -0800 (PST) Message-ID: <3A7CBD8D.688BBE54@Eng.Sun.COM> Date: Sat, 03 Feb 2001 18:25:17 -0800 From: Darren J Moffat Organization: Sun Microsystems Inc - Solaris Security Technologies Group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ssh@clinet.fi Subject: Re: draft-griffin-ssh-host-keys-in-dns-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Jeffrey Altman wrote: > Using DNS to distribute host keys only makes sense if and only if > DNSSEC is used at the same time. Otherwise, DNS can be used to spoof > the host key for a server. Agreed. Okay now please forgive my ignorance of DNSSEC and the slight digression to what is probably more of an implementation issue than a protocol issue: Does DNSSEC require/allow using a new API so that the calling program knows that it got the data back from a secure DNS service ? Consider that most implmentations will currently call the platform functions to resolve a hostname, eg gethostbyname()/getaddrinfo() on platforms that have a name service switch the calling application has no way to know which name service the data came from never mind if the DNS lookup was secure. So in this case why should we trust the keys we get back - which if I understand correctly this is what Jeffrey was saying. So maybe what is needed is an implementation note in the draft that says that if app is going to get SSH keys from DNSSEC then it SHOULD use DNSSEC directly to resolv hosts rather than using functions provided by the platform which may hide the details of the name service from the caller. But on the other hand I dislike applications that call into the DNS resolver libaries directly on Solaris because they bypass the valuable caching provided by the name service switch - of course you can always argue that caching an security don't mix very well. -- Darren J Moffat From owner-ietf-ssh@clinet.fi Sun Feb 4 14:23:05 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10964 for ; Sun, 4 Feb 2001 14:23:04 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA26161 for ietf-ssh-outgoing; Sun, 4 Feb 2001 19:34:27 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA26158 for ; Sun, 4 Feb 2001 19:34:27 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id DF7172403181; Sun, 4 Feb 2001 18:34:25 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id SAA26573; Sun, 4 Feb 2001 18:34:25 +0100 (MET) To: Joe Salowey Cc: Tatu Ylonen , ietf-ssh@clinet.fi Subject: Re: Kerberos (Re: minutes from the SECSH working group meeting at the 48th IETF) References: <86EDBD151558D311BB5700508B2E03FC0336F88E@pikachu.wrq.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 04 Feb 2001 18:34:25 +0100 In-Reply-To: Joe Salowey's message of "Tue, 10 Oct 2000 10:38:52 -0700" Message-ID: Lines: 76 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Joe Salowey writes: > In http://www.ietf.org/internet-drafts/draft-salowey-secsh-kerbkeyex-00.txt > I defined a User Auth type "external-keyx" for this purpose. In this > message the client only has to specify a user name. The credentials from > the key exchange are then used to see if this user name is valid. It is > also possible to provide additional credentials (such as an authorization > certificate) in this message. Let's look a little closer at the case where no "additional credentials" are needed (I don't see any case where additional credentials make much sense, but that's a different discussion): byte SSH_MSG_USERAUTH_REQUEST string authorization-ID string service string "external-keyx" boolean FALSE Compare this to a request using the "none" method: byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "none" The difference is so small that I believe the "external-keyx" authentication method is redundant. If the client uses some keyexchange method that provides mutual authentication as a side effect, it can just send a "none" request to login. The server checks that the user name matches the name that was given during keyexchange, and if it does, it lets the user log in right away. This is a cleaner approach than skipping userauth completely (like lsh's current behaviour when srp key exchange is used). To make it fit perfectly in the protocol, the description of the "none" method in the userauth draft should be updated, Old: : 2.3. The "none" Authentication Request : : A client may request a list of authentication methods that may continue : by using the "none" authentication method. : : If no authentication at all is needed for the user, the server MUST : return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return : SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of authentication : methods that can continue. : : This method MUST NOT be listed as supported by the server. New: : 2.3. The "none" Authentication Request : : A client may request a list of authentication methods that may continue : by using the "none" authentication method. : : If no authentication at all is needed for the user (beyond any mutual : authentication that was performed during the earlier key exchange), : the server MUST return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server : MUST return SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of : authentication methods that can continue. : : This method SHOULD NOT be listed as supported by the server, unless : the key exchange provided mutual authentication. Even if we don't consider key exchange methods like kerberos and srp, the MUST NOT in the last paragraph in the description doesn't make much sense to me. If the server provides some anonymous service that doesn't require user authentication, it makes sense to me to include "none" in the list of authentications that can continue. Regards, /Niels From owner-ietf-ssh@clinet.fi Mon Feb 5 02:52:39 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02122 for ; Mon, 5 Feb 2001 02:52:39 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id IAA31357 for ietf-ssh-outgoing; Mon, 5 Feb 2001 08:18:35 +0200 Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id IAA31345 for ; Mon, 5 Feb 2001 08:18:33 +0200 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id WAA09114 for ; Sun, 4 Feb 2001 22:18:30 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id WAA00402 for ietf-ssh@clinet.fi; Sun, 4 Feb 2001 22:18:31 -0800 (PST) Date: Sun, 4 Feb 2001 22:18:30 -0800 From: Wei Dai To: ietf-ssh@clinet.fi Subject: Re: zlib is not GNU Message-ID: <20010204221830.F5848@eskimo.com> References: <20010131174535.G1507@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010131174535.G1507@eskimo.com>; from weidai@eskimo.com on Wed, Jan 31, 2001 at 05:45:35PM -0800 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Wed, Jan 31, 2001 at 05:45:35PM -0800, Wei Dai wrote: > zlib is refered to as "GNU ZLIB (LZ77) compression" in the transport > draft, but I don't think zlib (either the library for the compression > format) has anything to do with GNU (either the organization or the > license). I suggest the word "GNU" be taken out. I take that back. Although the zlib home page doesn't mention GNU, zlib is listed at the gnu.org site as a GNU software package. From owner-ietf-ssh@clinet.fi Mon Feb 5 05:13:20 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02896 for ; Mon, 5 Feb 2001 05:13:19 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id KAA23373 for ietf-ssh-outgoing; Mon, 5 Feb 2001 10:21:36 +0200 Received: from mystery.acr.fi (ip212-226-160-97.adsl.kpnqwest.fi [212.226.160.97]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id KAA23366 for ; Mon, 5 Feb 2001 10:21:34 +0200 Received: from localhost (ylo@localhost) by mystery.acr.fi (8.9.3/8.9.3) with ESMTP id KAA24094; Mon, 5 Feb 2001 10:19:15 +0200 X-Authentication-Warning: mystery.acr.fi: ylo owned process doing -bs Date: Mon, 5 Feb 2001 10:19:15 +0200 (EET) From: Tatu Ylonen X-Sender: ylo@mystery.acr.fi To: Wei Dai cc: ietf-ssh@clinet.fi Subject: Re: zlib is not GNU In-Reply-To: <20010204221830.F5848@eskimo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > On Wed, Jan 31, 2001 at 05:45:35PM -0800, Wei Dai wrote: > > zlib is refered to as "GNU ZLIB (LZ77) compression" in the transport > > draft, but I don't think zlib (either the library for the compression > > format) has anything to do with GNU (either the organization or the > > license). I suggest the word "GNU" be taken out. > > I take that back. Although the zlib home page doesn't mention GNU, zlib is > listed at the gnu.org site as a GNU software package. Looking at the source, it does not mention GNU in any way (at least not in 1.1.3, which is the version I am using). I think we should respect what the authors themselves chose to do, and not use the word GNU there. Attached is the copyright section from the README file: zlib 1.1.3 is a general purpose data compression library. All the code ... Copyright notice: (C) 1995-1998 Jean-loup Gailly and Mark Adler This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution. Jean-loup Gailly Mark Adler jloup@gzip.org madler@alumni.caltech.edu If you use the zlib library in a product, we would appreciate *not* receiving lengthy legal documents to sign. The sources are provided for free but without warranty of any kind. The library has been entirely written by Jean-loup Gailly and Mark Adler; it does not include third-party code. If you redistribute modified sources, we would appreciate that you include in the file ChangeLog history information documenting your changes. From owner-ietf-ssh@clinet.fi Mon Feb 5 10:17:28 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08601 for ; Mon, 5 Feb 2001 10:17:27 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA06550 for ietf-ssh-outgoing; Mon, 5 Feb 2001 15:54:00 +0200 Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA06525 for ; Mon, 5 Feb 2001 15:53:55 +0200 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id IAA27491; Mon, 5 Feb 2001 08:53:41 -0500 (EST) Date: Mon, 5 Feb 2001 8:53:40 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Tatu Ylonen Cc: Wei Dai , ietf-ssh@clinet.fi Subject: Re: zlib is not GNU In-Reply-To: Your message of Mon, 5 Feb 2001 10:19:15 +0200 (EET) Message-ID: Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > > On Wed, Jan 31, 2001 at 05:45:35PM -0800, Wei Dai wrote: > > > zlib is refered to as "GNU ZLIB (LZ77) compression" in the transport > > > draft, but I don't think zlib (either the library for the compression > > > format) has anything to do with GNU (either the organization or the > > > license). I suggest the word "GNU" be taken out. > > > > I take that back. Although the zlib home page doesn't mention GNU, zlib is > > listed at the gnu.org site as a GNU software package. > > Looking at the source, it does not mention GNU in any way (at least not > in 1.1.3, which is the version I am using). I think we > should respect what the authors themselves chose to do, and not use the > word GNU there. I believe that this source has been released under multiple licenses by the authors. Some of them are GNU and some of them are not. I agree that GNU should not be used as part of the description of the ZLIB compression library. From owner-ietf-ssh@clinet.fi Mon Feb 5 12:29: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 MAA12448 for ; Mon, 5 Feb 2001 12:29:59 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA25681 for ietf-ssh-outgoing; Mon, 5 Feb 2001 17:42:56 +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 RAA25677 for ; Mon, 5 Feb 2001 17:42:55 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 97A6E2408232; Mon, 5 Feb 2001 16:42:54 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id QAA29827; Mon, 5 Feb 2001 16:42:54 +0100 (MET) To: jaltman@columbia.edu Cc: Tatu Ylonen , Wei Dai , ietf-ssh@clinet.fi Subject: Re: zlib is not GNU References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 05 Feb 2001 16:42:53 +0100 In-Reply-To: Jeffrey Altman's message of "Mon, 5 Feb 2001 8:53:40 EST" Message-ID: Lines: 15 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Jeffrey Altman writes: > I believe that this source has been released under multiple licenses > by the authors. Some of them are GNU and some of them are not. I > agree that GNU should not be used as part of the description of the > ZLIB compression library. I mailed the zlib authors and rms. It seems the classification on http://www.gnu.org/software is buggy. According to jloup@gzip.org, " zlib should be in section "Other Non-GPL-Covered Free Software". " not in the current section "GNU Software Packages". /Niels From owner-ietf-ssh@clinet.fi Mon Feb 5 14:48:53 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15940 for ; Mon, 5 Feb 2001 14:48:51 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA06750 for ietf-ssh-outgoing; Mon, 5 Feb 2001 19:33:52 +0200 Received: from dr-evil.shagadelic.org (yeah-baby.shagadelic.org [208.176.2.162]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA06744 for ; Mon, 5 Feb 2001 19:33:50 +0200 Received: by dr-evil.shagadelic.org (Postfix, from userid 7518) id 3CF60D203; Mon, 5 Feb 2001 09:33:47 -0800 (PST) Date: Mon, 5 Feb 2001 09:33:47 -0800 From: Jason R Thorpe To: Wei Dai Cc: ietf-ssh@clinet.fi Subject: Re: zlib is not GNU Message-ID: <20010205093347.E24230@dr-evil.shagadelic.org> Reply-To: thorpej@zembu.com Mail-Followup-To: Jason R Thorpe , Wei Dai , ietf-ssh@clinet.fi References: <20010131174535.G1507@eskimo.com> <20010204221830.F5848@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010204221830.F5848@eskimo.com>; from weidai@eskimo.com on Sun, Feb 04, 2001 at 10:18:30PM -0800 Organization: Zembu Labs, Inc. Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Sun, Feb 04, 2001 at 10:18:30PM -0800, Wei Dai wrote: > I take that back. Although the zlib home page doesn't mention GNU, zlib is > listed at the gnu.org site as a GNU software package. If you're worried about zlib's license, it is not GPL'd. Jean-loup Gailly and Mark Adler have been releasing zlib under a non-GPL license for quite some time. Seems to indicate that they're not interested in being associated with the GNU Project. -- -- Jason R. Thorpe From owner-ietf-ssh@clinet.fi Mon Feb 5 15:42: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 PAA17123 for ; Mon, 5 Feb 2001 15:42:55 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA11484 for ietf-ssh-outgoing; Mon, 5 Feb 2001 20:29:02 +0200 Received: from sttlpop4.sttl.uswest.net (sttlpop4.sttl.uswest.net [206.81.192.4]) by mail.clinet.fi (8.9.3/8.9.3) with SMTP id UAA11461 for ; Mon, 5 Feb 2001 20:28:56 +0200 Received: (qmail 22663 invoked by alias); 5 Feb 2001 18:23:22 -0000 Delivered-To: fixup-ietf-ssh@clinet.fi@fixme Received: (qmail 84593 invoked by uid 0); 5 Feb 2001 18:11:05 -0000 Received: from rtp-isp-nat-pool-2.cisco.com (HELO qwest.net) (192.135.249.2) by sttlpop4.sttl.uswest.net with SMTP; 5 Feb 2001 18:11:05 -0000 Message-ID: <3A7EEC28.DD2B2B3B@qwest.net> Date: Mon, 05 Feb 2001 10:08:41 -0800 From: Joseph Salowey X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Niels =?iso-8859-1?Q?M=F6ller?= CC: Joe Salowey , Tatu Ylonen , ietf-ssh@clinet.fi Subject: Re: Kerberos (Re: minutes from the SECSH working group meeting at the 48th IETF) References: <86EDBD151558D311BB5700508B2E03FC0336F88E@pikachu.wrq.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id UAA11484 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA17123 I agree that the additional credentials don't really belong in this message. I think we removed them in the external-keys message in the latest draft. I'm a little uneasy about using the "none" authentication method. When I was thinking about the problem I thought "none" means no authentication, but from your point of view "none" means nothing to do in this phase of user-authentication (except of course authorize that the user name can be accepted). While I think this does make some sense I'm not sure it is cleaner or clearer. I also don't think you need to advertise none since if it is acceptable and sufficient you will not get a list of methods when you send a "none" message, you will receive a success. "none" either succeeds or returns a list of acceptable methods to continue with. Joe "Niels Mцller" wrote: > Joe Salowey writes: > > > In http://www.ietf.org/internet-drafts/draft-salowey-secsh-kerbkeyex-00.txt > > I defined a User Auth type "external-keyx" for this purpose. In this > > message the client only has to specify a user name. The credentials from > > the key exchange are then used to see if this user name is valid. It is > > also possible to provide additional credentials (such as an authorization > > certificate) in this message. > > Let's look a little closer at the case where no "additional > credentials" are needed (I don't see any case where additional > credentials make much sense, but that's a different discussion): > > byte SSH_MSG_USERAUTH_REQUEST > string authorization-ID > string service > string "external-keyx" > boolean FALSE > > Compare this to a request using the "none" method: > > byte SSH_MSG_USERAUTH_REQUEST > string user name > string service name > string "none" > > The difference is so small that I believe the "external-keyx" > authentication method is redundant. If the client uses some > keyexchange method that provides mutual authentication as a side > effect, it can just send a "none" request to login. The server checks > that the user name matches the name that was given during keyexchange, > and if it does, it lets the user log in right away. > > This is a cleaner approach than skipping userauth completely (like > lsh's current behaviour when srp key exchange is used). To make it fit > perfectly in the protocol, the description of the "none" method in the > userauth draft should be updated, > > Old: > > : 2.3. The "none" Authentication Request > : > : A client may request a list of authentication methods that may continue > : by using the "none" authentication method. > : > : If no authentication at all is needed for the user, the server MUST > : return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return > : SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of authentication > : methods that can continue. > : > : This method MUST NOT be listed as supported by the server. > > New: > > : 2.3. The "none" Authentication Request > : > : A client may request a list of authentication methods that may continue > : by using the "none" authentication method. > : > : If no authentication at all is needed for the user (beyond any mutual > : authentication that was performed during the earlier key exchange), > : the server MUST return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server > : MUST return SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of > : authentication methods that can continue. > : > : This method SHOULD NOT be listed as supported by the server, unless > : the key exchange provided mutual authentication. > > Even if we don't consider key exchange methods like kerberos and srp, > the MUST NOT in the last paragraph in the description doesn't make > much sense to me. If the server provides some anonymous service that > doesn't require user authentication, it makes sense to me to include > "none" in the list of authentications that can continue. > > Regards, > /Niels From owner-ietf-ssh@clinet.fi Tue Feb 6 05:26:30 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10652 for ; Tue, 6 Feb 2001 05:26:29 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id KAA25361 for ietf-ssh-outgoing; Tue, 6 Feb 2001 10:36:07 +0200 Received: from mx1.eskimo.com (mx1.eskimo.com [204.122.16.48]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id KAA25339 for ; Tue, 6 Feb 2001 10:36:01 +0200 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id AAA26653 for ; Tue, 6 Feb 2001 00:35:55 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id AAA18349 for ietf-ssh@clinet.fi; Tue, 6 Feb 2001 00:35:59 -0800 (PST) Date: Tue, 6 Feb 2001 00:35:58 -0800 From: Wei Dai To: ietf-ssh@clinet.fi Subject: tcpip-forwarding port binding Message-ID: <20010206003558.D28792@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-ietf-ssh@clinet.fi Precedence: bulk I think we need a way for a client to request that the server find an unused port to bind to, for the purpose of TCP/IP forwarding, and also a way for the server to report back which port it actually bound. How about adding some language such as the following to section 5.1 of the Connection Protocol: If any port is acceptable, 'want reply' should be TRUE and 'port number to bind' should be 0. If such a request is successful, the server should respond with the following message: byte SSH_MSG_REQUEST_SUCCESS uint32 port number assigned 'Port number assigned' specifies the port number that the server assigned to the listening socket. Any comments? Is it too late to make this kind of proposal? Also, why isn't there a way to include an error message in the default SSH_MSG_REQUEST_FAILURE message? Perhaps we should change it (in section 2) to: byte SSH_MSG_REQUEST_FAILURE string error message (ISO-10646 UTF-8) string language tag (as defined in [RFC-1766]) With the protocol the way it is now, there is no way for a user to know why a TCP/IP forwarding request failed. He can't tell if he should try a different port, a different address, or give up. From owner-ietf-ssh@clinet.fi Tue Feb 6 06:53:51 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11153 for ; Tue, 6 Feb 2001 06:53:50 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA17189 for ietf-ssh-outgoing; Tue, 6 Feb 2001 12:15:06 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id MAA17106 for ; Tue, 6 Feb 2001 12:14:46 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 067EE24035C2; Tue, 6 Feb 2001 11:14:46 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id LAA08210; Tue, 6 Feb 2001 11:14:45 +0100 (MET) To: thorpej@zembu.com Cc: Wei Dai , ietf-ssh@clinet.fi Subject: Re: zlib is not GNU References: <20010131174535.G1507@eskimo.com> <20010204221830.F5848@eskimo.com> <20010205093347.E24230@dr-evil.shagadelic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 06 Feb 2001 11:14:45 +0100 In-Reply-To: Jason R Thorpe's message of "Mon, 5 Feb 2001 09:33:47 -0800" Message-ID: Lines: 22 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Jason R Thorpe writes: > If you're worried about zlib's license, it is not GPL'd. Jean-loup Gailly > and Mark Adler have been releasing zlib under a non-GPL license for quite > some time. Using the GPL and "being a part of the GNU project" are quite different things. You can do one without doing the other (although for a program or library to be a part of the GNU project, it ought to at least use a "GPL compatible" license, which zlib indeed does). And I' not worried about the license (it's both free and GPL compatible, which is good enough for me); we're not discussing the zlib license, we're discussing the proper way to refer to zlib. > Seems to indicate that they're not interested in being associated > with the GNU Project. Please note that Mark Adler and Jean-Loup Gailly also wrote gzip, which is definitely a GNU program. /Niels From owner-ietf-ssh@clinet.fi Tue Feb 6 20:54: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 UAA06136 for ; Tue, 6 Feb 2001 20:54:47 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA30085 for ietf-ssh-outgoing; Wed, 7 Feb 2001 02:07:15 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id CAA30081 for ; Wed, 7 Feb 2001 02:07:13 +0200 Received: from king ([192.168.0.17]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 511 for ; Tue, 6 Feb 2001 17:13:28 -0700 Message-ID: <006c01c09099$ebe05ec0$1100a8c0@vandyke.com> From: "David B. Coningham" To: References: <009d01c08d12$ac63e710$0201010a@intergalactic> Subject: Re: server public key fingerprint? Date: Tue, 6 Feb 2001 17:07:11 -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: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "denis bider" To: Sent: Friday, February 02, 2001 5:21 AM Subject: RE: server public key fingerprint? > I think it would be best if the fingerprint specification mandated a single > fingerprint format, not multiple formats; and that the single fingerprint > format be simple to implement. > > In other words - it's OK if you want to define 5 different fingerprint > formats in the specification, as long as you point out a single one that is > THE fingerprint format, and make that format required, and all other formats > optional. > > Also, if there are multiple formats, the specification should mandate that > an application must ALWAYS use the required fingerprint format when > displaying fingerprints. It may at the same time display the fingerprint in > any other formats, but it must display it in the required format as well. > [I.e., no configuration setting to change the preferred format - always > display all of them, or at least the required one.] > > I would hope that the required fingerprint format would be a straightforward > one, like the currently defined MD5 format. I wouldn't vote for a > specification that mandates a bubble-babble kind of thing; I think the > required format should be one that is straightforward and simple to > implement. > > Finally, I don't think there's really any need to define more than one > fingerprint format. But if you nevertheless decide to define multiple, > please consider the above comments. I agree with this almost completely: the specification should definitely mandate that one format be required and always displayed, and I think the hex format presented in the draft should be that required format. The hex format certainly does not introduce any new implementation problems regarding processor and memory limitations. I only think an additional format should be added to the draft if there is a lot of agreement that it meets a need that the hex format does not. I am not completely convinced that the OTP format I mentioned earlier does this, and there certainly does not seem to be a large majority in favor of it yet. --- David B. Coningham dbc-pub@vandyke.com From owner-ietf-ssh@clinet.fi Wed Feb 7 10:24:05 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01612 for ; Wed, 7 Feb 2001 10:24:04 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA14235 for ietf-ssh-outgoing; Wed, 7 Feb 2001 15:16:52 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA14229 for ; Wed, 7 Feb 2001 15:16:50 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 5BB6E240B54E; Wed, 7 Feb 2001 14:16:49 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id OAA27939; Wed, 7 Feb 2001 14:16:49 +0100 (MET) To: "David B. Coningham" Cc: Subject: Re: server public key fingerprint? References: <009d01c08d12$ac63e710$0201010a@intergalactic> <006c01c09099$ebe05ec0$1100a8c0@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 07 Feb 2001 14:16:48 +0100 In-Reply-To: "David B. Coningham"'s message of "Tue, 6 Feb 2001 17:07:11 -0700" Message-ID: Lines: 19 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk "David B. Coningham" writes: > I agree with this almost completely: the specification should definitely > mandate that one format be required and always displayed, and I think > the hex format presented in the draft should be that required format. > The hex format certainly does not introduce any new implementation > problems regarding processor and memory limitations. It would make sense to me to specify one standard fingerprinting method and format (and the one in Markus' draft is good enough for me). The spec (either the dransport spec or a separate spec) can say that if an implementation supports fingerprints at all, then it SHOULD use the specified method and format. I don't think it is appropriate for the spec to require that fingerprints be supported in an implementation's UI. Likewise, support for alternative fingerprinting mechanisms also seems out of scope. /Niels From owner-ietf-ssh@clinet.fi Wed Feb 14 17:59: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 RAA18486 for ; Wed, 14 Feb 2001 17:59:53 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA32184 for ietf-ssh-outgoing; Wed, 14 Feb 2001 23:00:15 +0200 Received: from maximator.cs.stevens-tech.edu (maximator.cs.stevens-tech.edu [155.246.89.203]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA32180 for ; Wed, 14 Feb 2001 23:00:13 +0200 Received: (from tls@localhost) by maximator.cs.stevens-tech.edu (8.11.0/8.10.1) id f1EL09328794; Wed, 14 Feb 2001 16:00:09 -0500 (EST) Date: Wed, 14 Feb 2001 16:00:09 -0500 From: Thor Simon To: ietf-ssh@clinet.fi Subject: Status of trademark claims in SECSH working documents? Message-ID: <20010214160009.A28752@cs.stevens-tech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-ssh@clinet.fi Precedence: bulk The current SECSH working documents contain quite a bit of language identical or substantially similar to the following: > 9. Trademark Issues > > SSH is a registered trademark and Secure Shell is a trademark of SSH > Communications Security Corp. SSH Communications Security Corp permits > the use of these trademarks as the name of this standard and protocol, > and permits their use to describe that a product conforms to this > standard, provided that the following acknowledgement is included where > the trademarks are used: ``SSH is a registered trademark and Secure > Shell is a trademark of SSH Communications Security Corp > (www.ssh.com)''. These trademarks may not be used as part of a product > name or in otherwise confusing manner without prior written permission > of SSH Communications Security Corp. Unfortunately, it appears to me that the text quoted above contains at least one substantial misrepresentation. US registered trademark number 214991, owned by SSH Communications Security Oy, 12 02150 Espoo FINLAND, is for '"ssh", namely the letters in "stylized form"'; in other words, it refers to the *SSH Communications corporate logo*, a particular way to write the lowercase letters "ssh" -- mind you, as far as I can tell, not even "any way to write the lowercase letters", just the particular stylized way that was registered -- and not other use of the letters "SSH" whether lowercase or uppercase. I think the language quoted above raises a number of other ethical issues I'd honestly prefer to avoid flamage about on this list. However, I would like some clarification about the language above and/or confirmation that it will be stricken from the standard before issue, unless there has been some serious misunderstanding and it is actually true. The one ethical concern I _would_ like to raise is the practice of naming a standard and working group in such a manner as to evidently attempt to be able to later bushwack implementors with intellectual property claims, whether valid or specious. But I don't think this list is necessarily the right place to raise that concern, either. I would like it if someone could tell me what *is* the right place within the IETF structure to do that, in private email, please. Thor From owner-ietf-ssh@clinet.fi Wed Feb 14 19:09:06 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19377 for ; Wed, 14 Feb 2001 19:09:05 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id AAA06473 for ietf-ssh-outgoing; Thu, 15 Feb 2001 00:28:59 +0200 Received: from iron-city.cs.stevens-tech.edu (iron-city.cs.stevens-tech.edu [155.246.81.39]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id AAA06470 for ; Thu, 15 Feb 2001 00:28:57 +0200 Received: (from tls@localhost) by iron-city.cs.stevens-tech.edu (8.11.0/8.10.1) id f1EMSrr04925; Wed, 14 Feb 2001 17:28:53 -0500 (EST) Date: Wed, 14 Feb 2001 17:28:53 -0500 From: Thor Simon To: Tatu Ylonen Cc: ietf-ssh@clinet.fi Subject: Re: Status of trademark claims in SECSH working documents? Message-ID: <20010214172853.A4905@cs.stevens-tech.edu> References: <20010214160009.A28752@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 ylo@ssh.com on Wed, Feb 14, 2001 at 11:49:00PM +0200 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Wed, Feb 14, 2001 at 11:49:00PM +0200, Tatu Ylonen wrote: > > Unfortunately, it appears to me that the text quoted above contains at > > least one substantial misrepresentation. US registered trademark number > > 214991, owned by SSH Communications Security Oy, 12 02150 Espoo FINLAND, > > is for '"ssh", namely the letters in "stylized form"'; in other words, > > it refers to the *SSH Communications corporate logo*, a particular way > > to write the lowercase letters "ssh" -- mind you, as far as I can tell, > > not even "any way to write the lowercase letters", just the particular > > stylized way that was registered -- and not other use of the letters > > "SSH" whether lowercase or uppercase. > > This is not true. I've seen the incorrect text on USPTO web site, which > apparedly contains something scanned from a fax in small font. Our > lawyers checked it and the registration was ok as intended. > > Tatu The USPTO records available online show an *abandoned application for* a plain-text mark "SSH" and a *stylized text* mark "ssh". I have confirmed this with legal counsel. Are you saying that the USPTO is in error about the status of your mark? I believe you'd need to take that up with them; as it stands now, as far as I or my attorney are able to ascertain, there is no registered trademark for the text "SSH" in the United States. Furthermore, given the use of the word "SSH" in a generic sense, including use in a generic sense and granting of permission to use in a generic sense *by the registrant of the mark* prior to even the filing date for the abandoned application, it seems highly unlikely to me (note that I am *not* a lawyer and I am not presuming to give *anyone* legal advice, this is my personal speculation) that the USPTO would in fact be willing to register a trademark for the text "SSH". However, that's neither here nor there; the USPTO records show no such registered trademark. Consequently, as I requested in my previous message, I believe that the referenced text should be stricken from all documents in the SECSH working group immediately. There are plenty of other reasons why I believe it should be stricken, but I fear the onset of serious flamage were I to enumerate them. Let's stick to this one for the moment. Thor From owner-ietf-ssh@clinet.fi Wed Feb 14 19:29: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 TAA19650 for ; Wed, 14 Feb 2001 19:29:54 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA08780 for ietf-ssh-outgoing; Thu, 15 Feb 2001 01:07:26 +0200 Received: from iron-city.cs.stevens-tech.edu (iron-city.cs.stevens-tech.edu [155.246.81.39]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id BAA08777 for ; Thu, 15 Feb 2001 01:07:24 +0200 Received: (from tls@localhost) by iron-city.cs.stevens-tech.edu (8.11.0/8.10.1) id f1EN7Ni05025; Wed, 14 Feb 2001 18:07:23 -0500 (EST) Date: Wed, 14 Feb 2001 18:07:22 -0500 From: Thor Simon To: ietf-ssh@clinet.fi Subject: Re: Returned mail: see transcript for details Message-ID: <20010214180722.A4999@cs.stevens-tech.edu> References: <200102142229.f1EMTAq04927@iron-city.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: <200102142229.f1EMTAq04927@iron-city.cs.stevens-tech.edu>; from MAILER-DAEMON@cs.stevens-tech.edu on Wed, Feb 14, 2001 at 05:29:10PM -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk I wrote: > The USPTO records available online show an *abandoned application for* > a plain-text mark "SSH" and a *stylized text* mark "ssh". I have > confirmed this with legal counsel. Are you saying that the USPTO is > in error about the status of your mark? I believe you'd need to take A correction: I cannot find any details on an abandoned application at this time in any USPTO search engine available to me, and my attorney did not, evidently, find such details yesterday. Remarkably, a co-worker *did* manage to pull up such a record from a USPTO web site this morning, but we cannot reproduce those search results. Bizarre. However, it is absolutely, positively the case that the record for the "ssh" mark is a *stylized text* mark. So I'd still like to know just what's going on here -- please, someone persuade me that this isn't just not just an attempt to blackmail an entire working group, but one engaged in upon the basis of nonfactual information snuck into the drafts. Sadly, that is really what it looks like to me. I would like to be mistaken about this. I respect Tatu's work and I do not want to think that he would be responsible for this kind of deception. Please, someone explain to me how and why I am being an idiot. If not, let's get that text removed, please; the parties involved in other aspects of this rather frustrating debacle can clearly handle them outside this forum, but that text doesn't belong in the standards, doubly so if it's just plain false, and that *is* germane here. Thor From owner-ietf-ssh@clinet.fi Wed Feb 14 19:51:15 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19837 for ; Wed, 14 Feb 2001 19:51:15 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA08940 for ietf-ssh-outgoing; Thu, 15 Feb 2001 01:10:15 +0200 Received: from iron-city.cs.stevens-tech.edu (iron-city.cs.stevens-tech.edu [155.246.81.39]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id BAA08937 for ; Thu, 15 Feb 2001 01:10:13 +0200 Received: (from tls@localhost) by iron-city.cs.stevens-tech.edu (8.11.0/8.10.1) id f1ENACm05043 for ietf-ssh@clinet.fi; Wed, 14 Feb 2001 18:10:12 -0500 (EST) Date: Wed, 14 Feb 2001 18:10:12 -0500 From: Thor Simon To: ietf-ssh@clinet.fi Subject: ugh. sorry for mangled Subject in last msg. Message-ID: <20010214181012.A5036@cs.stevens-tech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Sorry -- I just noticed that the Subject: header for my last message in the "please remove incorrect trademark claim from standards" thread probably got mangled. Apologies to the other readers of this list for hosing your nice threaded mailreader views. :-) Thor From owner-ietf-ssh@clinet.fi Wed Feb 14 21:05:21 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20826 for ; Wed, 14 Feb 2001 21:05:19 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA13338 for ietf-ssh-outgoing; Thu, 15 Feb 2001 02:17:40 +0200 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id CAA13335 for ; Thu, 15 Feb 2001 02:17:37 +0200 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA11575; Wed, 14 Feb 2001 16:17:24 -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 TAA25485; Wed, 14 Feb 2001 19:17:23 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.10.2) with ESMTP id f1F0HL921541; Wed, 14 Feb 2001 19:17:21 -0500 (EST) Message-Id: <200102150017.f1F0HL921541@thunk.east.sun.com> From: Bill Sommerfeld To: Thor Simon cc: Tatu Ylonen , ietf-ssh@clinet.fi Subject: Re: Status of trademark claims in SECSH working documents? In-reply-to: Your message of "Wed, 14 Feb 2001 17:28:53 EST." <20010214172853.A4905@cs.stevens-tech.edu> Reply-to: sommerfeld@east.sun.com Date: Wed, 14 Feb 2001 19:17:21 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk There's another problem with the trademark wording: (Quoting from draft-ietf-secsh-architecture-07.txt): 9. Trademark Issues SSH is a registered trademark and Secure Shell is a trademark of SSH Communications Security Corp. SSH Communications Security Corp permits the use of these trademarks as the name of this standard and protocol, and permits their use to describe that a product conforms to this standard, provided that the following acknowledgement is included where the trademarks are used: ``SSH is a registered trademark and Secure Shell is a trademark of SSH Communications Security Corp (www.ssh.com)''. These trademarks may not be used as part of a product name or in otherwise confusing manner without prior written permission of SSH Communications Security Corp. It is not appropriate for the IETF to speak this way about a claimed trademark or claim that another party (SSH Communications Security) has granted certain rights to others. This is in direct conflict with some of what RFC2026 states regarding IPR claims: "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. The current process for publication of IPR notices is to send them to the IESG Secretary for placement on http://www.ietf.org/ipr.html; the process is described on that page. My understanding is that, before these documents have a chance of approval by the IESG, the trademark section must be either removed or altered to be in conformance with RFC2026's policy regarding IPR claims by the IETF. - Bill From owner-ietf-ssh@clinet.fi Wed Feb 14 22:01:28 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22520 for ; Wed, 14 Feb 2001 22:01:27 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id DAA16905 for ietf-ssh-outgoing; Thu, 15 Feb 2001 03:22:44 +0200 Received: from de-neve.cs.stevens-tech.edu (de-neve.cs.stevens-tech.edu [155.246.89.37]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id DAA16900 for ; Thu, 15 Feb 2001 03:22:42 +0200 Received: (from tls@localhost) by de-neve.cs.stevens-tech.edu (8.11.0/8.10.1) id f1F1Mfs03160; Wed, 14 Feb 2001 20:22:41 -0500 (EST) Date: Wed, 14 Feb 2001 20:22:41 -0500 From: Thor Simon To: ietf-ssh@clinet.fi Subject: Re: Status of trademark claims in SECSH working documents? Message-ID: <20010214202241.A3046@cs.stevens-tech.edu> References: <20010214172853.A4905@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 ylo@ssh.com on Thu, Feb 15, 2001 at 02:37:10AM +0200 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Thu, Feb 15, 2001 at 02:37:10AM +0200, Tatu Ylonen wrote: > > > > Unfortunately, it appears to me that the text quoted above contains at > > > > least one substantial misrepresentation. US registered trademark number > > > > 214991, owned by SSH Communications Security Oy, 12 02150 Espoo FINLAND, > > > > is for '"ssh", namely the letters in "stylized form"'; in other words, > > > > it refers to the *SSH Communications corporate logo*, a particular way > > > > to write the lowercase letters "ssh" -- mind you, as far as I can tell, > > > > not even "any way to write the lowercase letters", just the particular > > > > stylized way that was registered -- and not other use of the letters > > > > "SSH" whether lowercase or uppercase. > > > > > > This is not true. I've seen the incorrect text on USPTO web site, which > > > apparedly contains something scanned from a fax in small font. Our > > > lawyers checked it and the registration was ok as intended. > > I may have been inaccurate my statement above. I just discussed this with > our US trademark lawyer, and the US registration really appears to be for > the lowercase word "ssh" (I have apparently received inaccurate > information from our Finnish trademark lawyer). However, our US lawyer > confirmed that use of the name SSH in uppercase is "misleadingly > similar" to the "ssh" mark and is infringing. Unfortunately, your US mark is not a "typed drawing" mark; it is a "Words, letters, and/or numbers in stylized form" mark. It is my understanding, based upon my discussion of the issue with my attorney, that such a mark applies *only* to the specific graphical representation of the mark which was registered; this is the *precise* difference from the "typed drawing" mark the application for which you abandoned. I am further advised by my attorney that such a mark does *not* apply to the uppercase letters "SSH" and certainly does not apply to those letters as a substring of another word. In fact, it doesn't even apply to other *lowercase* renderings of the letters "ssh". Whatever conclusion is reached elsewhere in the IETF about this type of maneuvering, if any, could we please have an end to it in *this* working group? That text does not belong in the documents, for the reasons that I have stated in this and previous contributions and for the solid RFC 2026 reasons that Bill Sommerfeld cited in his most recent message. Thor From owner-ietf-ssh@clinet.fi Thu Feb 15 01:21:01 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28832 for ; Thu, 15 Feb 2001 01:21:01 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id GAA27839 for ietf-ssh-outgoing; Thu, 15 Feb 2001 06:54:33 +0200 Received: from citi.umich.edu (citi.umich.edu [141.211.92.141]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id GAA27835 for ; Thu, 15 Feb 2001 06:54:31 +0200 Received: from citi.umich.edu (ssh-mapper.citi.umich.edu [141.211.92.147]) by citi.umich.edu (Postfix) with ESMTP id 5C6E2207C6; Thu, 15 Feb 2001 04:54:30 +0000 (GMT) Subject: Re: Status of trademark claims in SECSH working documents? From: Niels Provos In-Reply-To: Bill Sommerfeld, Wed, 14 Feb 2001 19:17:21 EST To: sommerfeld@east.sun.com Cc: Thor Simon , Tatu Ylonen , ietf-ssh@clinet.fi Date: Wed, 14 Feb 2001 23:54:30 -0500 Message-Id: <20010215045430.5C6E2207C6@citi.umich.edu> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk In message <200102150017.f1F0HL921541@thunk.east.sun.com>, Bill Sommerfeld writ es: >My understanding is that, before these documents have a chance of >approval by the IESG, the trademark section must be either removed or >altered to be in conformance with RFC2026's policy regarding IPR >claims by the IETF. I agree that the IPR notices is a more appropriate place for the trademark claims of SSH.com. The trademark wording should be removed from the secsh drafts. This might be a valueable lesson for the IETF. Intellectual property issues only hinder the standards process. For the future, the IETF might want to consider standardizing only those drafts that are clear of intellectual property taints. The situation for the secsh working group is especially complicated since now it seems that even the owners of the trademark were mistaken about its scope. I hope that we can resolve this soon, and get the documents back on the standards track. Regards, Niels Provos. From owner-ietf-ssh@clinet.fi Thu Feb 15 11:11:18 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21856 for ; Thu, 15 Feb 2001 11:11:17 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id QAA14335 for ietf-ssh-outgoing; Thu, 15 Feb 2001 16:10:51 +0200 Received: from gnat.inet.org (209-9-249-62.sdsl.cais.net [209.9.249.62]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id QAA14222 for ; Thu, 15 Feb 2001 16:10:05 +0200 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id DC9ED8264F for ; Thu, 15 Feb 2001 09:08:28 -0500 (EST) Message-Id: <5.0.0.25.2.20010215085716.009edc90@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 15 Feb 2001 08:59:52 -0500 To: ietf-ssh@clinet.fi From: RJ Atkinson Subject: Handling IPR claims in SECSH working documents In-Reply-To: <20010215045430.5C6E2207C6@citi.umich.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ssh@clinet.fi Precedence: bulk At 23:54 14/02/01, Niels Provos wrote: >I agree that the IPR notices is a more appropriate place for the >trademark claims of SSH.com. The trademark wording should be removed >from the secsh drafts. IETF practices require that change, as Bill has already noted. Would the authors kindly implement this change right now and resubmit the applicable I-Ds ? I'm sure the Secretariat is happy to handle any incoming IPR notices per the normal IETF procedures for such. This list is NOT the appropriate place to discuss the merits or lack of merits to any given IPR claim, IMHO. Thank you, Ran rja@inet.org From owner-ietf-ssh@clinet.fi Thu Feb 15 22:39:07 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07605 for ; Thu, 15 Feb 2001 22:39:06 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id EAA07202 for ietf-ssh-outgoing; Fri, 16 Feb 2001 04:06:20 +0200 Received: from ratree.psu.ac.th ([192.100.77.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id EAA07188 for ; Fri, 16 Feb 2001 04:06:06 +0200 Received: from brandenburg.cs.mu.OZ.AU (sw11.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id JAA23696; Fri, 16 Feb 2001 09:05:58 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f1FGVIh02894; Thu, 15 Feb 2001 23:31:18 +0700 (ICT) From: Robert Elz To: RJ Atkinson cc: ietf-ssh@clinet.fi Subject: Re: Handling IPR claims in SECSH working documents In-reply-to: Your message of "Thu, 15 Feb 2001 08:59:52 EST." <5.0.0.25.2.20010215085716.009edc90@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Feb 2001 23:31:18 +0700 Message-ID: <2892.982254678@brandenburg.cs.mu.OZ.AU> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Date: Thu, 15 Feb 2001 08:59:52 -0500 From: RJ Atkinson Message-ID: <5.0.0.25.2.20010215085716.009edc90@10.30.15.2> | This list is NOT the appropriate place to discuss the merits or | lack of merits to any given IPR claim, IMHO. I agree with that. However, it may be possible to consider a change of working group (and protocol) name to avoid the issue... For the original unix application, "ssh" was the perfect name, given that it was "rsh" made secure. For a protocol defined by the IETF, while "secure" makes sense as part of the name, "shell" is just plain silly - it isn't even as if a shell (given you know what that means) is what the ssh protocol provides (just take note of all the discussion in the recent past as to whether its file transfer mode should have ascii/binary file type distinctions). I pointed that out back when the WG was being formed (not with any guesses about TM disputes of course) - but for some reason people really wanted the "ssh" label to stick (even though that acronym in the IETF was already taken - leading to "secsh" as the closest reasonable possibility). Maybe we can guess where and why some of that pressure came from now, but that's beside the point. So, maybe this WG should become the "secure remote link" working group or something like that? Then the IETF can completely forget about the TM issues, and implementors can call their implementations anything that they like. kre From owner-ietf-ssh@clinet.fi Fri Feb 16 01:11:21 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA11226 for ; Fri, 16 Feb 2001 01:11:21 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id GAA14262 for ietf-ssh-outgoing; Fri, 16 Feb 2001 06:38:17 +0200 Received: from dr-evil.shagadelic.org (yeah-baby.shagadelic.org [208.176.2.162]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id GAA14258 for ; Fri, 16 Feb 2001 06:38:15 +0200 Received: by dr-evil.shagadelic.org (Postfix, from userid 7518) id 17E54D203; Thu, 15 Feb 2001 20:38:06 -0800 (PST) Date: Thu, 15 Feb 2001 20:38:05 -0800 From: Jason R Thorpe To: Robert Elz Cc: RJ Atkinson , ietf-ssh@clinet.fi Subject: Re: Handling IPR claims in SECSH working documents Message-ID: <20010215203805.V3145@dr-evil.shagadelic.org> Reply-To: thorpej@zembu.com Mail-Followup-To: Jason R Thorpe , Robert Elz , RJ Atkinson , ietf-ssh@clinet.fi References: <5.0.0.25.2.20010215085716.009edc90@10.30.15.2> <2892.982254678@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2892.982254678@brandenburg.cs.mu.OZ.AU>; from kre@munnari.OZ.AU on Thu, Feb 15, 2001 at 11:31:18PM +0700 Organization: Zembu Labs, Inc. Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Thu, Feb 15, 2001 at 11:31:18PM +0700, Robert Elz wrote: > So, maybe this WG should become the "secure remote link" working > group or something like that? Then the IETF can completely > forget about the TM issues, and implementors can call their > implementations anything that they like. "Secure remote link" makes me think of something completely other than what SECSH defines ... more like "secure remote login" (which is essentially what you've done via the user authentication step). -- -- Jason R. Thorpe From owner-ietf-ssh@clinet.fi Fri Feb 16 05:59:10 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 FAA26082 for ; Fri, 16 Feb 2001 05:59:09 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id KAA20031 for ietf-ssh-outgoing; Fri, 16 Feb 2001 10:57:56 +0200 Received: from ratree.psu.ac.th ([192.100.77.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id KAA20000 for ; Fri, 16 Feb 2001 10:57:50 +0200 Received: from brandenburg.cs.mu.OZ.AU ([203.154.130.253]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id PAA21006; Fri, 16 Feb 2001 15:56:59 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f1G8upn00941; Fri, 16 Feb 2001 15:56:58 +0700 (ICT) From: Robert Elz To: thorpej@zembu.com cc: ietf-ssh@clinet.fi Subject: Re: Handling IPR claims in SECSH working documents In-reply-to: Your message of "Thu, 15 Feb 2001 20:38:05 PST." <20010215203805.V3145@dr-evil.shagadelic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Feb 2001 15:56:51 +0700 Message-ID: <939.982313811@brandenburg.cs.mu.OZ.AU> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Date: Thu, 15 Feb 2001 20:38:05 -0800 From: Jason R Thorpe Message-ID: <20010215203805.V3145@dr-evil.shagadelic.org> | "Secure remote link" makes me think of something completely other | than what SECSH defines ... more like "secure remote login" That was what I thought of too, then I wondered if perhaps "remote login" looked just like what telnet provides, and this protocol does more than that, so I kept the acronym and fished around for a new meaning... But what it is called is less relevant to me than that it not be called anything related to shells, which apart from its historical relationship with rsh, it isn't. kre From owner-ietf-ssh@clinet.fi Fri Feb 16 06:06:39 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26137 for ; Fri, 16 Feb 2001 06:06:39 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id LAA25683 for ietf-ssh-outgoing; Fri, 16 Feb 2001 11:21:20 +0200 Received: from levitator.1div0.com (node.061-0.ty.link.si [213.250.43.61]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id LAA25542 for ; Fri, 16 Feb 2001 11:20:50 +0200 Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id KAA15843 for ; Fri, 16 Feb 2001 10:04:06 +0100 Reply-To: From: "denis bider" To: Subject: Renaming SSH-the-standard (Was RE: Handling IPR claims in SECSH working documents) Date: Fri, 16 Feb 2001 10:20:38 +0100 Message-ID: <002101c097f9$ba321870$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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <2892.982254678@brandenburg.cs.mu.OZ.AU> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit > | This list is NOT the appropriate place to discuss the merits or > | lack of merits to any given IPR claim, IMHO. > I agree with that. I think that any discussion on this issue should be open, not conducted in private email. If this list is not appropriate, then another list needs to be created. I haven't seen anyone suggest an existing list to transfer this discussion to. > However, it may be possible to consider a change of working group > (and protocol) name to avoid the issue... > > For the original unix application, "ssh" was the perfect name, > given that it was "rsh" made secure. > > For a protocol defined by the IETF, while "secure" makes sense > as part of the name, "shell" is just plain silly - I agree that "secure shell" is a misleading name. Finding a better name and renaming all specifications to match is an option. But I don't think it will work quickly; maybe it won't work at all. And most definitely, it will offer no instant relief to Tatu and SSH Communications Security. The fact is that, in the minds of people who don't directly do business with SSH Communications Security - which is _most_ people - SSH is synonymous to SSH the protocol, not to SSH the company. I would be inclined to argue that most people who have heard of SSH don't even know that SSH-the-company exists. (I didn't.) Change the name of the standard, and everyone will still refer to the protocol as "SSH" for years to come. The fact is simply that Tatu and ourselves will have to live with the confusion. There is no quick solution. It is my perception - possibly a wrong one, but it is my perception nevertheless - that Tatu has willingly helped create this mess; therefore, I don't think he should be complaining now. If he had a problem with other people using the term 'SSH' to denote the protocol and implementations of the protocol, rather than his company, he should have reacted immediately - years ago. It is my perception that he didn't. Now, everyone is using the term SSH - not to denote the company, but to denote the protocol. This is a reality, and fighting against is like trying to put the genie back into the bottle. 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. But if the acronym we choose is significantly different from "SSH", people won't recognize the new acronym, and will continue to use the old one. The migration to the new acronym will literally take years, and in the mean time, there can only be more mess than there already is. Consider SSL / TLS, for instance. The genie is out of the bottle; the term 'SSH' is with us for the long haul. Renaming the standard to something entirely different will just create more confusion. More confusion is good for none of us. Regards, denis From owner-ietf-ssh@clinet.fi Fri Feb 16 07:16:41 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27123 for ; Fri, 16 Feb 2001 07:16:40 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA08802 for ietf-ssh-outgoing; Fri, 16 Feb 2001 12:32:27 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id MAA08761 for ; Fri, 16 Feb 2001 12:32:19 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id CAB202403192; Fri, 16 Feb 2001 11:32:17 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id LAA05047; Fri, 16 Feb 2001 11:32:17 +0100 (MET) To: Robert Elz Cc: thorpej@zembu.com, ietf-ssh@clinet.fi Subject: Re: Handling IPR claims in SECSH working documents References: <939.982313811@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 16 Feb 2001 11:32:16 +0100 In-Reply-To: Robert Elz's message of "Fri, 16 Feb 2001 15:56:51 +0700" Message-ID: Lines: 12 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Robert Elz writes: > But what it is called is less relevant to me than that it not be > called anything related to shells, which apart from its historical > relationship with rsh, it isn't. Personally, I have no problem with using the word "shell". One reason is that I'd like to remember its history. And another is that the protocol is just what is needed to implement a real command shell with the ability to start remote as well as local processes. /Niels From owner-ietf-ssh@clinet.fi Fri Feb 16 12:29:41 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04576 for ; Fri, 16 Feb 2001 12:29:40 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA01349 for ietf-ssh-outgoing; Fri, 16 Feb 2001 17:20:41 +0200 Received: from gnat.inet.org (209-9-249-62.sdsl.cais.net [209.9.249.62]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA01338 for ; Fri, 16 Feb 2001 17:20:36 +0200 Received: from mosquito.inet.org (unknown [10.30.34.130]) by gnat.inet.org (Postfix) with ESMTP id 417E48264F; Fri, 16 Feb 2001 10:18:45 -0500 (EST) Message-Id: <5.0.0.25.2.20010216100417.009e8e80@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 16 Feb 2001 10:10:03 -0500 To: From: RJ Atkinson Subject: Re: Renaming SSH-the-standard Cc: In-Reply-To: <002101c097f9$ba321870$0201010a@intergalactic> References: <2892.982254678@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ssh@clinet.fi Precedence: bulk At 04:20 16/02/01, denis bider wrote: >> | This list is NOT the appropriate place to discuss the merits or >> | lack of merits to any given IPR claim, IMHO. >> I agree with that. > >I think that any discussion on this issue should be open, not conducted in private email. If this list is not appropriate, then another list needs to be created. I haven't seen anyone suggest an existing list >to transfer this discussion to. Feel free to create such a list yourself. However, it is unreasonable for one to require that other folks expend their resources (personal time, network bandwidth, disk, or CPU) creating such a list, IMHO. It is also unreasonable to clutter up a standards list with a non-technical offtopic discussion such as the merits of any IPR claim, IMHO. :-) >I agree that "secure shell" is a misleading name. I disagree. Secure Shell is quite clear as the protocol provides a secured replacement for the "Remote Shell" protocol. "Secure Shell" is not AFAIK part of the trademark claim, just the string "ssh". In any event, the Working Group is not named "ssh" by IETF. Bill the WG Chair, Perhaps the IETF Secure Shell WG list could be moved now to the ietf.org mail server and renamed in order to be aligned with the official IETF acronym and side-step the swamp. The Secretariat has MailMan setup precisely for this purpose, so its easy to make happen quickly. Ran rja@inet.org From owner-ietf-ssh@clinet.fi Fri Feb 16 12:31:31 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04676 for ; Fri, 16 Feb 2001 12:31:30 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA02473 for ietf-ssh-outgoing; Fri, 16 Feb 2001 17:31:35 +0200 Received: from levitator.1div0.com (node.061-0.ty.link.si [213.250.43.61]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA02469 for ; Fri, 16 Feb 2001 17:31:32 +0200 Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id QAA16486; Fri, 16 Feb 2001 16:14:27 +0100 Reply-To: From: "denis bider" To: "'RJ Atkinson'" Cc: Subject: RE: Renaming SSH-the-standard Date: Fri, 16 Feb 2001 16:30:59 +0100 Message-ID: <002801c0982d$77587510$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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <5.0.0.25.2.20010216100417.009e8e80@10.30.15.2> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit > "Secure Shell" is not AFAIK part of the trademark claim, > just the string "ssh". From an earlier message on the list: : (Quoting from draft-ietf-secsh-architecture-07.txt): : 9. Trademark Issues : SSH is a registered trademark and Secure Shell is a trademark of SSH : Communications Security Corp. > In any event, the Working Group is not named "ssh" by IETF. From www.ietf.org: : : Goals and Milestones: : Feb 97 Submit Internet-Draft on SSH-2.0 protocol : Apr 97 Decide on Transport Layer protocol at Memphis IETF. : Jan 01 Post revised core secsh drafts : Feb 01 Submit core drafts to IESG for publication as proposed standard : Feb 01 Post extensions drafts for review : Feb 01 Start sending extensions drafts to Last Call : : Internet-Drafts: : SSH Connection Protocol (36516 bytes) : SSH Transport Layer Protocol (53476 bytes) : SSH Authentication Protocol (26537 bytes) : SSH Protocol Architecture (27345 bytes) : Generic Message Exchange Authentication For SSH (16022 bytes) : SSH File Transfer Protocol (41987 bytes) : Using GSSAPI authentication for key exchange in Secure Shell (23703 bytes) : SECSH Public Key File Format (6284 bytes) : Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol (14222 bytes) : From owner-ietf-ssh@clinet.fi Fri Feb 16 13:03:31 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05411 for ; Fri, 16 Feb 2001 13:03:30 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA03844 for ietf-ssh-outgoing; Fri, 16 Feb 2001 17:47:01 +0200 Received: from gnat.inet.org (209-9-249-62.sdsl.cais.net [209.9.249.62]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA03830 for ; Fri, 16 Feb 2001 17:46:58 +0200 Received: from mosquito.inet.org (unknown [10.30.34.130]) by gnat.inet.org (Postfix) with ESMTP id 0B6FC8264F; Fri, 16 Feb 2001 10:45:23 -0500 (EST) Message-Id: <5.0.0.25.2.20010216103331.00a28480@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 16 Feb 2001 10:36:47 -0500 To: From: RJ Atkinson Subject: RE: Renaming SSH-the-standard Cc: In-Reply-To: <002801c0982d$77587510$0201010a@intergalactic> References: <5.0.0.25.2.20010216100417.009e8e80@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ssh@clinet.fi Precedence: bulk At 10:30 16/02/01, denis bider wrote: >> In any event, the Working Group is not named "ssh" by IETF. > >>From www.ietf.org: Denis, You've overlooked the main part of the IETF web page. The official name of this WG and its official acronym are each listed there: "Secure Shell (secsh)" 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 ? Ran From owner-ietf-ssh@clinet.fi Fri Feb 16 15:34:53 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08953 for ; Fri, 16 Feb 2001 15:34:52 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA16359 for ietf-ssh-outgoing; Fri, 16 Feb 2001 20:27:31 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA16356 for ; Fri, 16 Feb 2001 20:27:29 +0200 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13010 for ; Fri, 16 Feb 2001 10:27: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 NAA21254 for ; Fri, 16 Feb 2001 13:27:27 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.10.2) with ESMTP id f1GIRQ923087 for ; Fri, 16 Feb 2001 13:27:26 -0500 (EST) Message-Id: <200102161827.f1GIRQ923087@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@clinet.fi Subject: Your working group chair is GRUMPY. Reply-to: sommerfeld@east.sun.com Date: Fri, 16 Feb 2001 13:27:25 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk - At the present time, and until further notice, this is the Secure Shell (secsh) working group, and we're supposed to be working on the SSH protocol. - The abbreviation for this WG is "secsh" because "ssh" was already taken, by the (now completed) Site Security Handbook WG. Had Site Security Handbook gone by a different name, this would have been the Secure Shell (ssh) working group. - Discussions of the validity of various trademarks allegedly owned by various parties are OUT OF SCOPE for the working group; leave it to the trademark lawyers. - The WG Last Call I started in February continues, largely because (for obvious reasons) I haven't had the cycles to sort through, evaluate, and summarize the comments. I would find polite, civil discussion of the technical and process issues already raised to be a refreshing distraction. - There is precedent in the IETF for using standardizing protocols which have names matching a trademark: PGP and Kerberos were both trademarked. There is also precedent for "renaming around the problem" (e.g., S/Key->OTP); there is also evidence that IETF's attempts at renaming a deployed protocol often don't "take" (e.g., SSL->TLS). - 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. - Until we regain consensus on the name of the WG and protocol, the core documents are GOING NOWHERE. - 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. - The observed performance of mail forwarding on clinet.fi has been poor. It may make sense to move the WG's list somewhere else for this reason alone. - I am NOT AMUSED by the trademark dispute between implementors. I'd much rather be (a) writing code for my day job, or (b) getting the core documents ready to submit to the IESG. - Bill From owner-ietf-ssh@clinet.fi Fri Feb 16 15:40:58 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09044 for ; Fri, 16 Feb 2001 15:40:57 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA16886 for ietf-ssh-outgoing; Fri, 16 Feb 2001 20:36:12 +0200 Received: from dr-evil.shagadelic.org (yeah-baby.shagadelic.org [208.176.2.162]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA16883 for ; Fri, 16 Feb 2001 20:36:10 +0200 Received: by dr-evil.shagadelic.org (Postfix, from userid 7518) id C528AD203; Fri, 16 Feb 2001 10:36:06 -0800 (PST) Date: Fri, 16 Feb 2001 10:36:06 -0800 From: Jason R Thorpe To: RJ Atkinson Cc: denis.bider@denisbider.com, ietf-ssh@clinet.fi Subject: Re: Renaming SSH-the-standard Message-ID: <20010216103606.N3145@dr-evil.shagadelic.org> Reply-To: thorpej@zembu.com Mail-Followup-To: Jason R Thorpe , RJ Atkinson , denis.bider@denisbider.com, ietf-ssh@clinet.fi References: <2892.982254678@brandenburg.cs.mu.OZ.AU> <002101c097f9$ba321870$0201010a@intergalactic> <5.0.0.25.2.20010216100417.009e8e80@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.0.0.25.2.20010216100417.009e8e80@10.30.15.2>; from rja@inet.org on Fri, Feb 16, 2001 at 10:10:03AM -0500 Organization: Zembu Labs, Inc. Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Fri, Feb 16, 2001 at 10:10:03AM -0500, RJ Atkinson wrote: > "Secure Shell" is not AFAIK part of the trademark claim, > just the string "ssh". In any event, the Working Group is > not named "ssh" by IETF. No, they are claiming trademark on "Secure Shell" as well (although, it would be interesting to know the time relationship between when the WG started using that name and then the trademark was filed for). -- -- Jason R. Thorpe From owner-ietf-ssh@clinet.fi Fri Feb 16 15:54: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 PAA09549 for ; Fri, 16 Feb 2001 15:54:53 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA17611 for ietf-ssh-outgoing; Fri, 16 Feb 2001 20:46:46 +0200 Received: from levitator.1div0.com (node.061-0.ty.link.si [213.250.43.61]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA17601 for ; Fri, 16 Feb 2001 20:46:44 +0200 Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id TAA16876; Fri, 16 Feb 2001 19:29:46 +0100 Reply-To: From: "denis bider" To: "'RJ Atkinson'" Cc: Subject: RE: Renaming SSH-the-standard Date: Fri, 16 Feb 2001 19:46:13 +0100 Message-ID: <002a01c09848$bd95c3f0$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 5 (Lowest) X-MSMail-Priority: Low X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Low X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <5.0.0.25.2.20010216103331.00a28480@10.30.15.2> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit This particular issue is a bit beside the point. My previous message did not require a reply. However, a slightly challenging reply was posted, so my ego feels that I must provide clarification. >>> In any event, the Working Group is not named "ssh" by IETF. >>From www.ietf.org: > You've overlooked the main part of the IETF web page. No, I didn't overlook that. I never stated it was my opinion that this working group was named anything other than "secsh". I was pointing out that almost all drafts are named "ssh" rather that "secsh". The motivation is that this indicates that people are inclined to call the protocol "ssh" more than anything else. And not just ordinary people at that - the authors of the proposed standard themselves. > Perhaps you're new to our wacky ways of doing things in the IETF ? I've been around for some time. Regards, denis From owner-ietf-ssh@clinet.fi Fri Feb 16 16:15:50 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09873 for ; Fri, 16 Feb 2001 16:15:49 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id VAA19959 for ietf-ssh-outgoing; Fri, 16 Feb 2001 21:21:18 +0200 Message-Id: <200102161921.VAA19959@mail.clinet.fi> Received: from ursa-minor.fac.cs.cmu.edu (URSA-MINOR.FAC.CS.CMU.EDU [128.2.205.178]) by mail.clinet.fi (8.9.3/8.9.3) with SMTP id VAA19955; Fri, 16 Feb 2001 21:21:17 +0200 Received: from URSA-MINOR.FAC.CS.CMU.EDU by ursa-minor.fac.cs.cmu.edu id aa140585; 16 Feb 2001 14:21 EST 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 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > > "A license was granted in 1995 that allows free use of the trademarks" > > This is not accurate, but refers to the following language in > ssh-1.2.12 COPYING file: That's a mischaracterization of the argument: a license was granted in 1995 that allows derivative works to use of the term ssh, when in compliance with the SSH-1.3 protocol. Note the result of the trademark of Linux(R). While you are certainly not in the same position as Della Croce, who attempted to establish a trademark for something with which he had no connection, you are in a similar position as to the prior existance and use of the term within the markets the trademark is active. > Also, this text is from the COPYING file from ssh-1.2.12, dated Nov > 17, 1995. The trademark claims were made in 1996 (ssh-1.2.13 was the > first release claiming them, released on Feb 11, 1996), and this > license provision would not have covered them anyway. Ever since, our > policy has been not to allow unauthorized use of the trademarks. The > trademark claims have been made consistently in every release ever > since. But it clearly delineates that software, not from SSH Corp, has been using the mark since before the trademark was in existance or claimed. Thus, by not preventing these non-SSH Corp products from using the trademark, I think you've given it up. > > "no-one has ever been notified of infringement" > > For example, I notified Van Dyke of the trademark a few years ago when > they used the SSH mark on their web site inappropriately. We > discussed it, they were very co-operative, and immediately added > trademark markings and acknowledgement on their website. Issue > solved. (They were not using it in a product name.) > > Basically, anyone we have ever really encountered in the marketplace > has either been notified or is a licensee of ours. > > > "F-Secure SSH has been using the name for years" > > F-Secure (formerly Data Fellows) is our distributor/VAR, and they are > using the SSH trademark in their product name under a separate written > trademark license agreement. All of the F-Secure SSH products are SSH > Communication Security Corp's products, some verbatim and some with > modifications by F-Secure. But trademark is not claimed, regardless -- note the web pages I previously referenced. > > (reference to FiSSH, TTSSH, Top Gun ssh, etc.) > > These are all non-commercial academic projects made at universities. Irrelevant. They are still "Computer programs and software for preventing unauthorized access to computer networks and for providing secure connections to computer networks." > We have never really encountered any one of these in the marketplace. But you make an SSH for MacOS. Haven't you encountered Nifty Telnet SSH there? Hint: I use Nifty Telnet SSH, and specifically avoid the SSH for MacOS from F-Secure because of it. So you have. > We have tried to notify commercial people who have been using the > trademark inappropriately. OpenSSH was the first non-commercial > implementation to raise to the radar screen. Well, you clearly can't claim lack of knowledge about some of these other products, so can you explain what is required to 'raise to the radar screen'? These other products diluted the trademark, since they fall under the description of the purpose of the trademark as delineated in your trademark registration. > > "why did you notify OpenSSH now" > > The reason OpenSSH was contacted now was that they have only become > more visible during the last months, and I have recently seen a > significant increase in e-mails confusing the meaning of the SSH > trademarks and using them inappropriately. I have also recently > received quite a few e-mails confusing OpenSSH as my product. Sorry, that can be annoying. But then, you misuse the ssh mark as well, since you use it in a form other than "ssh-brand secsh [or whatever]." > > "how about the 'ssh' command name under Unix/Linux?" > > This relates to the proposal I want to make. > > Basically, I am willing to work out a way that will allow anyone to use > the "ssh" command name on Unix/Linux. It appears that there are > ways to do it without exposing our trademarks to unnecessary risk. But are you in a position to offer this? That is, can you enforce it, or is it just a description of what you'd like to happen? > The arrangement I am proposing would be as follows. > > - We (SSH Corp) would allow the use of "ssh" (and sshd, etc) as a > command name on Unix/Linux under the following restrictions: What about under Windows, Plan 9, OS/2.... I'm all for an amicable conclusion. Unfortunately, I also think that the ssh trademark is indefensible and a poor idea. -- Matthew Weigel Research Systems Programmer mcweigel+@cs.cmu.edu From owner-ietf-ssh@clinet.fi Fri Feb 16 17:31: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 RAA10801 for ; Fri, 16 Feb 2001 17:31:53 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA24266 for ietf-ssh-outgoing; Fri, 16 Feb 2001 22:29:05 +0200 Received: from dr-evil.shagadelic.org (yeah-baby.shagadelic.org [208.176.2.162]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id WAA24260 for ; Fri, 16 Feb 2001 22:29:03 +0200 Received: by dr-evil.shagadelic.org (Postfix, from userid 7518) id 7DE0CD203; Fri, 16 Feb 2001 12:28:59 -0800 (PST) Date: Fri, 16 Feb 2001 12:28:59 -0800 From: Jason R Thorpe To: Joel Jaeggli Cc: RJ Atkinson , denis.bider@denisbider.com, ietf-ssh@clinet.fi Subject: Re: Renaming SSH-the-standard Message-ID: <20010216122859.A3145@dr-evil.shagadelic.org> Reply-To: thorpej@zembu.com Mail-Followup-To: Jason R Thorpe , Joel Jaeggli , RJ Atkinson , denis.bider@denisbider.com, ietf-ssh@clinet.fi References: <20010216103606.N3145@dr-evil.shagadelic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from joelja@darkwing.uoregon.edu on Fri, Feb 16, 2001 at 11:23:26AM -0800 Organization: Zembu Labs, Inc. Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Fri, Feb 16, 2001 at 11:23:26AM -0800, Joel Jaeggli wrote: > > No, they are claiming trademark on "Secure Shell" as well (although, > > it would be interesting to know the time relationship between when > > the WG started using that name and then the trademark was filed for). > > the ssh bof was held at the december ietf in san jose in 1997 (ietf 37 I > think)... This would pre-date the filing for the "Secure Shell" trademark, yes? (Which appears to have been on Jan 21, 2000, #75900906). Assuming the term "Secure Shell" was used to refer to the BoF/WG. I went looking for the original posting of draft-ylonen-ssh-protocol-00.txt, but the ietf-announce archives only go back to 1998 (the draft is dated 15 November 1995, and contains no trademark claims for either "SSH" or "Secure Shell", even though those terms are used in the draft). -- -- Jason R. Thorpe From owner-ietf-ssh@clinet.fi Fri Feb 16 18:24:05 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11679 for ; Fri, 16 Feb 2001 18:24:04 -0500 (EST) From: owner-ietf-ssh@clinet.fi Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA27386 for ietf-ssh-outgoing; Fri, 16 Feb 2001 23:19:29 +0200 Received: from localhost.localdomain (IDENT:root@[211.60.74.83]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA27380 for ; Fri, 16 Feb 2001 23:19:26 +0200 Received: from 64.228.37.149 (Toronto-ppp225650.sympatico.ca [64.228.37.149]) by localhost.localdomain (8.9.3/8.9.3) with SMTP id GAA22826; Sat, 17 Feb 2001 06:16:23 +0900 Message-Id: <200102162116.GAA22826@localhost.localdomain> To: Subject: I think you like it 12170 Date: Fri, 16 Feb 2001 15:54:08 -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 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: quoted-printable

Celebs are waiting for you, we invite you to come in. To enter, p= lease CLICK HER= E.

Please click here to be REMOVED<= /a> from our mailing list.
From owner-ietf-ssh@clinet.fi Fri Feb 16 19:35:13 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12307 for ; Fri, 16 Feb 2001 19:35:11 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA00984 for ietf-ssh-outgoing; Sat, 17 Feb 2001 01:06:54 +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 BAA00979 for ; Sat, 17 Feb 2001 01:06:52 +0200 Received: from kado.mindrot.org (CPE-203-45-24-18.vic.bigpond.net.au [203.45.24.18]) by smtp1.clinet.fi (Postfix) with ESMTP id E5CDD217 for ; Sat, 17 Feb 2001 01:06:51 +0200 (EET) Received: from toad.mindrot.org (toad.mindrot.org [203.44.118.252]) by kado.mindrot.org (Postfix) with ESMTP id B76909123; Sat, 17 Feb 2001 02:55:34 +1100 (EST) Received: from mothra.mindrot.org (mothra.mindrot.org [203.44.118.225]) by toad.mindrot.org (Postfix) with ESMTP id 1C7951A1CB; Sat, 17 Feb 2001 10:05:56 +1100 (EST) Received: by mothra.mindrot.org (Postfix, from userid 500) id 08C823C08B; Sat, 17 Feb 2001 10:05:54 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by mothra.mindrot.org (Postfix) with ESMTP id 04C753C08A; Sat, 17 Feb 2001 10:05:54 +1100 (EST) Date: Sat, 17 Feb 2001 10:05:53 +1100 (EST) From: Damien Miller To: RJ Atkinson , Bill Sommerfeld Cc: ietf-ssh@clinet.fi Subject: Re: Renaming SSH-the-standard In-Reply-To: <5.0.0.25.2.20010216100417.009e8e80@10.30.15.2> Message-ID: X-Paranoia: just because you're paranoid doesn't mean they aren't out to get you MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Fri, 16 Feb 2001, RJ Atkinson wrote: > Bill the WG Chair, > Perhaps the IETF Secure Shell WG list could be moved now > to the ietf.org mail server and renamed > in order to be aligned with the official IETF acronym and > side-step the swamp. The Secretariat has MailMan setup > precisely for this purpose, so its easy to make happen quickly. I second this - the less confusion the better (not to mention that the current mailing list is pretty spotty). -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From owner-ietf-ssh@clinet.fi Fri Feb 16 22:23:04 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14832 for ; Fri, 16 Feb 2001 22:23:03 -0500 (EST) From: owner-ietf-ssh@clinet.fi Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id DAA06956 for ietf-ssh-outgoing; Sat, 17 Feb 2001 03:15:21 +0200 Received: from vetapdc.veta.co.kr ([211.234.27.194]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id DAA06949 for ; Sat, 17 Feb 2001 03:15:19 +0200 Received: from ken500_[38.36.71.94] ([38.36.71.94]) by vetapdc.veta.co.kr with Microsoft SMTPSVC(5.0.2195.1600); Sat, 17 Feb 2001 10:12:54 +0900 Received: from by ken500 with ESMTP; Fri, 16 Feb 2001 18:15:07 -0700 Message-ID: <000001061818$000057bb$00006d79@> To: Subject: Want To Go Public? 5680 Date: Fri, 16 Feb 2001 18:14:59 -0700 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-OriginalArrivalTime: 17 Feb 2001 01:12:57.0781 (UTC) FILETIME=[C3645E50:01C0987E] Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: quoted-printable Untitled Document
Do you want to go Public?

 

If you hav= e considered taking your company public, but have found the IPO method to be to= o expensive and time consuming, Wallstreet Partners may be able to help you. T= here is more than one way to take your company public. At Wallstreet Pa= rtners, we help small to midsize companies that want the benefits of being= a public company without the expense and lengthy process of the traditional= IPO. We can assist you with two alternatives to an IPO:

  1. Reverse= Merger - In a reverse merger a private company merges with a "shell" co= rporation. This is a public listed company with no assets or liabilities, c= alled a "shell" because nothing exists of the original company other t= han its corporate shell structure.
  2. Direct = Public Offering (DPO) - A direct public offering DPO under Regulation A or a Reg= ulation D, Rule 504 registered as a SCOR can enable the company to sell = free trading stock on a self- underwritten basis, or through an under= writer on a best efforts basis.

Benefits o= f going public through by these methods, as opposed to an IPO, are the fol= lowing:

  • The = costs are significantly less than the costs required for an initial public= offering (IPO)
  • The = time required is considerably less than for an IPO
  • Addi= tional risk is involved in an IPO in that the IPO may be withdrawn due to an= unstable market condition even after most of the up-front costs have been= expended
  • Whil= e an IPO requires a relatively long and stable earning history, the lack = of an earning history does not normally keep a privately-held company = from completing a reverse merger =FFFFFFB7 The company does not requi= re an underwriter
  • Ther= e is less dilution of ownership control
  • You = can receive a higher valuation for your company

Once a com= pany is taken public, the advantages for raising are:

  • The = market value of a public company is often substantially higher than a private= company with the same structure in the same industry
  • Capi= tal is easier to raise for public companies because the stock has market value= and can be traded
  • The = public trading price of the public company's securities serves as a benchmark f= or the offer price of a subsequent public or private securities offerin= g
  • Acqu= isitions can be made with stock since publicly traded stock is viewed as = currency for mergers and acquisitions

To contact one of our Representatives about taking your company public
CLICK HERE
and respond to the questionnaire. A Representative will review your information and make contact with you about taking your compa= ny public.

 

 

From owner-ietf-ssh@clinet.fi Tue Feb 20 10:13:08 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 KAA13177 for ; Tue, 20 Feb 2001 10:13:07 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA12892 for ietf-ssh-outgoing; Tue, 20 Feb 2001 15:02:42 +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 PAA12817 for ; Tue, 20 Feb 2001 15:02:31 +0200 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 14VCR4-0003JU-00; Tue, 20 Feb 2001 13:02:30 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@clinet.fi Subject: SFTP: password file lookups? Message-Id: Date: Tue, 20 Feb 2001 13:02:30 +0000 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk I'm in the middle of writing an SFTP client at the moment, and it's occurred to me that a couple of functions to look things up in the password file would be handy: - when you get back numeric UIDs from FXP_READDIR, they're unlikely to be terribly meaningful to the user unless they can be translated back into usernames. - if the user issues FXP_SETSTAT to change ownership, they're likely to want to specify a username and have it converted into a user id. - if the user wants to copy something from another user's home directory, they may well want to type `~user' as the pathname. Being able to look up a user's home directory would be handy. Obviously I realise that I could do all this myself by reading /etc/passwd, but that strikes me as utterly the wrong solution because (a) it assumes the server is Unix, and (b) it doesn't cope with NIS. Are there any plans to add these features to the drafts, or is it far too late by now? Cheers, Simon -- Simon Tatham "Selfless? I'm so selfless I don't even know who I am." From owner-ietf-ssh@clinet.fi Tue Feb 20 12:22:40 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17312 for ; Tue, 20 Feb 2001 12:22:39 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id QAA01939 for ietf-ssh-outgoing; Tue, 20 Feb 2001 16:57:03 +0200 Received: from faui02.informatik.uni-erlangen.de (msfriedl@faui02.informatik.uni-erlangen.de [131.188.30.102]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id QAA01936 for ; Tue, 20 Feb 2001 16:57:02 +0200 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id PAA15144; Tue, 20 Feb 2001 15:56:59 +0100 (MET) Date: Tue, 20 Feb 2001 15:56:59 +0100 From: Markus Friedl To: Simon Tatham Cc: ietf-ssh@clinet.fi Subject: Re: SFTP: password file lookups? Message-ID: <20010220155659.B13978@faui02.informatik.uni-erlangen.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from anakin@pobox.com on Tue, Feb 20, 2001 at 01:02:30PM +0000 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Tue, Feb 20, 2001 at 01:02:30PM +0000, Simon Tatham wrote: > - if the user wants to copy something from another user's home > directory, they may well want to type `~user' as the pathname. > Being able to look up a user's home directory would be handy. i don't think the concept of a 'home directory of other users' fits into the sftp-protocol. -markus From owner-ietf-ssh@clinet.fi Tue Feb 20 13:59:37 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20748 for ; Tue, 20 Feb 2001 13:59:36 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA15117 for ietf-ssh-outgoing; Tue, 20 Feb 2001 18:59:09 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA15114 for ; Tue, 20 Feb 2001 18:59:08 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id DD3AF2403188; Tue, 20 Feb 2001 17:59:07 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id RAA26371; Tue, 20 Feb 2001 17:59:07 +0100 (MET) To: Simon Tatham Cc: ietf-ssh@clinet.fi Subject: Re: SFTP: password file lookups? References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 20 Feb 2001 17:59:03 +0100 In-Reply-To: Simon Tatham's message of "Tue, 20 Feb 2001 13:02:30 +0000" Message-ID: Lines: 12 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Simon Tatham writes: > I'm in the middle of writing an SFTP client at the moment, and it's > occurred to me that a couple of functions to look things up in the > password file would be handy: That would make sense to me, either as an extension or as part of the core protocol. One reason to have it in the core protocol is that it is ugly that the longname in SSH_FXP_NAME, which is supposed to be redundant, contains information that is not available anywhere else. /Niels From owner-ietf-ssh@clinet.fi Wed Feb 21 11:54:05 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02576 for ; Wed, 21 Feb 2001 11:54:03 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA16404 for ietf-ssh-outgoing; Wed, 21 Feb 2001 17:00:05 +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 RAA16401 for ; Wed, 21 Feb 2001 17:00:03 +0200 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 14VakM-0007AR-00; Wed, 21 Feb 2001 15:00:02 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham In-Reply-To: To: ietf-ssh@clinet.fi Cc: nisse@lysator.liu.se (Niels Mцller) Subject: Re: SFTP: password file lookups? Message-Id: Date: Wed, 21 Feb 2001 15:00:02 +0000 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > Simon Tatham writes: >> I'm in the middle of writing an SFTP client at the moment, and it's >> occurred to me that a couple of functions to look things up in the >> password file would be handy: nisse@lysator.liu.se (Niels Mцller) wrote: > That would make sense to me, either as an extension or as part of the > core protocol. One reason to have it in the core protocol is that it > is ugly that the longname in SSH_FXP_NAME, which is supposed to be > redundant, contains information that is not available anywhere else. OK, I've now written up a proposal for this which would support everything I'd find useful. It's available at http://www.tartarus.org/~simon/ssh/draft-sftp-userdb-00.txt It defines an SFTP extension, in a namespace I own, so obviously I _could_ just start privately lobbying SSH implementors to add support for it. I thought I'd expose it to the working group's combined wisdom before doing that though :-) (It supports only the user database fields that are actually useful: username, default group, home directory. I considered adding the rest of the Unix password file fields, such as full name and shell, but on balance I thought it would bloat the specification needlessly.) Cheers, Simon -- Simon Tatham "The voices in my head are trying to ignore me. But if I keep talking, I can drive them insane." From owner-ietf-ssh@clinet.fi Wed Feb 21 12:37:21 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03971 for ; Wed, 21 Feb 2001 12:37:20 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA22688 for ietf-ssh-outgoing; Wed, 21 Feb 2001 17:52:41 +0200 Received: from nic.appgate.com (nic.appgate.com [193.12.107.226]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA22676 for ; Wed, 21 Feb 2001 17:52:37 +0200 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id AFC8B3BDBF; Wed, 21 Feb 2001 16:52:37 +0100 (MET) Received: from pelee.firedoor.se (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 81AE66C007; Wed, 21 Feb 2001 16:53:36 +0100 (CET) Received: from appgate.com (pelee.firedoor.se [172.23.2.10]) by pelee.firedoor.se (Postfix) with ESMTP id E8EA0317AF; Wed, 21 Feb 2001 16:52:32 +0100 (MET) Date: Wed, 21 Feb 2001 16:52:46 +0100 (MET) From: Martin Forssen Subject: Re: Comments for draft-ietf-secsh-auth-kbdinteract-01.txt To: ShesMax@ru.hilti.com Cc: ietf-ssh@clinet.fi In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20010221155232.E8EA0317AF@pelee.firedoor.se> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk I am currently applying the suggested changes to the keyboard-interactive draft, so that it may be ready for the March IETF. The following question raises an interesting problem: On 24 Jan, Shesterikov Maxim (sm) wrote: > For a server that uses a separate authentication layer it is desirable > to state in the draft that the order of responses should match with > the order of prompts. It is easy to add text to the draft to this effect, but is that really the best solution. Such a text implies that the server is permitted to have multiple outstanding authentication requests simultaneously, and this can be complicated to handle in the client. Would it not be better just instead forbid the server to have more than one set of prompts (SSH_MSG_USERAUTH_INFO_REQUEST packets) outstanding at any time? Comments? /MaF From owner-ietf-ssh@clinet.fi Wed Feb 21 15:16:15 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08477 for ; Wed, 21 Feb 2001 15:16:14 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA32763 for ietf-ssh-outgoing; Wed, 21 Feb 2001 19:42:39 +0200 Received: from muck.dcs.ed.ac.uk (muck.dcs.ed.ac.uk [129.215.216.15]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA32759 for ; Wed, 21 Feb 2001 19:42:37 +0200 Received: from loki.dcs.ed.ac.uk (root@loki.dcs.ed.ac.uk [129.215.58.88]) by muck.dcs.ed.ac.uk with ESMTP id RAA20289; Wed, 21 Feb 2001 17:42:30 GMT Received: from loki.dcs.ed.ac.uk (IDENT:sxw@localhost [127.0.0.1]) by loki.dcs.ed.ac.uk (8.9.1/8.9.1) with SMTP id RAA08435; Wed, 21 Feb 2001 17:42:30 GMT From: Simon Wilkinson To: Jeffrey Hutzelman Subject: Re: SSH GSSAPI key exchange Date: Wed, 21 Feb 2001 17:41:12 +0000 X-Mailer: KMail [version 1.1.94] Content-Type: text/plain Cc: ietf-ssh@clinet.fi, jsalowey@cisco.com References: In-Reply-To: Organization: Division of Informatics MIME-Version: 1.0 Message-Id: <01022117411205.04292@loki.dcs.ed.ac.uk> Content-Transfer-Encoding: 8bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 8bit On Mon, 19 Feb 2001, Jeffrey Hutzelman wrote: > BTW, I'm interested in knowing a bit more about your implementation... Its based on OpenSSH, and has been tested with the Kerberos GSSAPI mechanism, although the implementation itself should be generic enough to allow any other mechanism to be added (although an equivalent to 'kuserok' would be required in order to make external-keyx work). I have implemented the external-keyx user authentication, but not the 'none' method described for host keys. > - Did you implement the GSSAPI user auth methods described in > ? Not yet, I hadn't encountered this draft until you mentioned it - I'm looking at it now. A further issue with your draft is in the protocol section - the GSSAPI support in MIT Kerberos does the following (which is legal according to the GSSAPI RFC): C: init_sec_context returns CONTINUE_NEEDED with data C->S: sends data (SSH_MSG_GSSAPI_INIT) S: accept_sec_context returns COMPLETE with data According to the draft, the server jumps to step 4, meaning that the client never gets its final data packet, and never completes its context initialisation (the server also never receives e if the SHOULD in step 2 is followed, and so the process fails) To complete the authentication sucessfully, the following steps are required: S->C sends data (SSH_MSG_GSSAPI_CONTINUE) C: init_sec_context returns COMPLETE with no data C->S sends e with no data (SSH_MSG_GSSAPI_INIT, with boolean true) The converse case, where the client returns COMPLETE, with a data packet for the server, is handled correctly by step 2. I've got around this problem in my implementation by amending the protocol as follows: Replace the first line of step 3 with: If the token received from C has non-zero length, then S calls gss_accept_sec_context with the token. If C is zero, and the previous call to gss_accept_sec_context did not return GSS_S_COMPLETE then an error has occured. Otherwise processing continues with step 4 Add the following to the end of step 3: * If the resulting major status code is GSS_S_COMPLETE and the output token has a non-zero length, then the output token is sent to C, and processing continues with step 2 A further concern is of the failure of the GSSAPI key exchange, especially during rekeying. I can't find any mention of what happens following a failed key exchange. However, if connections must be terminated, as opposed to trying again using a different algorithm, then this could cause severe problems for Kerberos users whose local credentials expire during a long running ssh operation. It would be possible to prevent this partially in implementation, by only offering a gss- algorithm if init-sec-context is known to succeed, but this is rather inelegant. Cheers, Simon. From owner-ietf-ssh@clinet.fi Wed Feb 21 15:29:26 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08977 for ; Wed, 21 Feb 2001 15:29:25 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA04188 for ietf-ssh-outgoing; Wed, 21 Feb 2001 20:30:49 +0200 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA04183 for ; Wed, 21 Feb 2001 20:30:47 +0200 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA11021; Wed, 21 Feb 2001 10:31:00 -0800 (PST) Received: from jsolowey-ntl.cisco.com (sjc-vpn-205.cisco.com [10.21.64.205]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAX18232; Wed, 21 Feb 2001 10:30:41 -0800 (PST) Message-Id: <4.3.2.7.2.20010221100156.00b21580@mira-sjc5-6.cisco.com> X-Sender: jsalowey@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 21 Feb 2001 10:27:43 -0800 To: Simon Wilkinson From: Joseph Salowey Subject: Re: SSH GSSAPI key exchange Cc: Jeffrey Hutzelman , ietf-ssh@clinet.fi In-Reply-To: <01022117411205.04292@loki.dcs.ed.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Good catch, Prhaps we should modify things as follows 1. C s At 05:41 PM 2/21/01 +0000, Simon Wilkinson wrote: >On Mon, 19 Feb 2001, Jeffrey Hutzelman wrote: > > BTW, I'm interested in knowing a bit more about your implementation... > >Its based on OpenSSH, and has been tested with the Kerberos GSSAPI mechanism, >although the implementation itself should be generic enough to allow any >other mechanism to be added (although an equivalent to 'kuserok' would be >required in order to make external-keyx work). I have implemented the >external-keyx user authentication, but not the 'none' method described for >host keys. > > > - Did you implement the GSSAPI user auth methods described in > > ? > >Not yet, I hadn't encountered this draft until you mentioned it - I'm looking >at it now. > >A further issue with your draft is in the protocol section - the GSSAPI >support in MIT Kerberos does the following (which is legal according to the >GSSAPI RFC): > >C: init_sec_context returns CONTINUE_NEEDED with data >C->S: sends data (SSH_MSG_GSSAPI_INIT) >S: accept_sec_context returns COMPLETE with data > >According to the draft, the server jumps to step 4, meaning that the client >never gets its final data packet, and never completes its context >initialisation (the server also never receives e if the SHOULD in step 2 is >followed, and so the process fails) > >To complete the authentication sucessfully, the following steps are required: >S->C sends data (SSH_MSG_GSSAPI_CONTINUE) >C: init_sec_context returns COMPLETE with no data >C->S sends e with no data (SSH_MSG_GSSAPI_INIT, with boolean true) > >The converse case, where the client returns COMPLETE, with a data packet for >the server, is handled correctly by step 2. > >I've got around this problem in my implementation by amending the protocol >as follows: > >Replace the first line of step 3 with: > If the token received from C has non-zero length, then S calls > gss_accept_sec_context with the token. If C is zero, and the > previous call to gss_accept_sec_context did not return > GSS_S_COMPLETE then an error has occured. > Otherwise processing continues with step 4 > >Add the following to the end of step 3: >* If the resulting major status code is GSS_S_COMPLETE and the > output token has a non-zero length, then the output token is sent > to C, and processing continues with step 2 > >A further concern is of the failure of the GSSAPI key exchange, especially >during rekeying. I can't find any mention of what happens following a failed >key exchange. However, if connections must be terminated, as opposed to >trying again using a different algorithm, then this could cause severe >problems for Kerberos users whose local credentials expire during a long >running ssh operation. > >It would be possible to prevent this partially in implementation, by only >offering a gss- algorithm if init-sec-context is known to succeed, but this >is rather inelegant. > >Cheers, > >Simon. From owner-ietf-ssh@clinet.fi Wed Feb 21 15:37:58 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09467 for ; Wed, 21 Feb 2001 15:37:56 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA05435 for ietf-ssh-outgoing; Wed, 21 Feb 2001 20:47:40 +0200 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA05431 for ; Wed, 21 Feb 2001 20:47:38 +0200 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id KAA18513; Wed, 21 Feb 2001 10:47:38 -0800 (PST) Received: from jsolowey-ntl.cisco.com (sjc-vpn-205.cisco.com [10.21.64.205]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAX18619; Wed, 21 Feb 2001 10:47:34 -0800 (PST) Message-Id: <4.3.2.7.2.20010221102924.00b20ba0@mira-sjc5-6.cisco.com> X-Sender: jsalowey@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 21 Feb 2001 10:44:37 -0800 To: Simon Wilkinson From: Joseph Salowey Subject: Re: SSH GSSAPI key exchange Cc: Jeffrey Hutzelman , ietf-ssh@clinet.fi In-Reply-To: <01022117411205.04292@loki.dcs.ed.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Good catch, Perhaps we should always send e with the inital token even if the context is not yet complete. I don't think there is a problem sending e if the context does not complete, it might be extra processing for the client, but I' not sure this is a problem. 1 C sends initial context token and e to S even if CONTINUE_NEEDED is returned 2 S calls Accept sec context and stores e if COMPLETE check context for mutual_auth and integrity ready if non zero token send token to C send MIC of H to C if continue needed send token to C 3 C calls init_sec_context with token (if present) if COMPLETE C checks context for mutual_auth and integrity ready verify MIC of H Since e does not have to be integrity protected directly it can be sent with the initial token. This might eliminate an extra round trip. Joe At 05:41 PM 2/21/01 +0000, Simon Wilkinson wrote: >On Mon, 19 Feb 2001, Jeffrey Hutzelman wrote: > > BTW, I'm interested in knowing a bit more about your implementation... > >Its based on OpenSSH, and has been tested with the Kerberos GSSAPI mechanism, >although the implementation itself should be generic enough to allow any >other mechanism to be added (although an equivalent to 'kuserok' would be >required in order to make external-keyx work). I have implemented the >external-keyx user authentication, but not the 'none' method described for >host keys. > > > - Did you implement the GSSAPI user auth methods described in > > ? > >Not yet, I hadn't encountered this draft until you mentioned it - I'm looking >at it now. > >A further issue with your draft is in the protocol section - the GSSAPI >support in MIT Kerberos does the following (which is legal according to the >GSSAPI RFC): > >C: init_sec_context returns CONTINUE_NEEDED with data >C->S: sends data (SSH_MSG_GSSAPI_INIT) >S: accept_sec_context returns COMPLETE with data > >According to the draft, the server jumps to step 4, meaning that the client >never gets its final data packet, and never completes its context >initialisation (the server also never receives e if the SHOULD in step 2 is >followed, and so the process fails) > >To complete the authentication sucessfully, the following steps are required: >S->C sends data (SSH_MSG_GSSAPI_CONTINUE) >C: init_sec_context returns COMPLETE with no data >C->S sends e with no data (SSH_MSG_GSSAPI_INIT, with boolean true) > >The converse case, where the client returns COMPLETE, with a data packet for >the server, is handled correctly by step 2. > >I've got around this problem in my implementation by amending the protocol >as follows: > >Replace the first line of step 3 with: > If the token received from C has non-zero length, then S calls > gss_accept_sec_context with the token. If C is zero, and the > previous call to gss_accept_sec_context did not return > GSS_S_COMPLETE then an error has occured. > Otherwise processing continues with step 4 > >Add the following to the end of step 3: >* If the resulting major status code is GSS_S_COMPLETE and the > output token has a non-zero length, then the output token is sent > to C, and processing continues with step 2 > >A further concern is of the failure of the GSSAPI key exchange, especially >during rekeying. I can't find any mention of what happens following a failed >key exchange. However, if connections must be terminated, as opposed to >trying again using a different algorithm, then this could cause severe >problems for Kerberos users whose local credentials expire during a long >running ssh operation. > >It would be possible to prevent this partially in implementation, by only >offering a gss- algorithm if init-sec-context is known to succeed, but this >is rather inelegant. > >Cheers, > >Simon. From owner-ietf-ssh@clinet.fi Wed Feb 21 16:53:56 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11870 for ; Wed, 21 Feb 2001 16:53:55 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA11257 for ietf-ssh-outgoing; Wed, 21 Feb 2001 22:02:11 +0200 Received: from mariner.rem.cs.cmu.edu (MARINER.REM.CS.CMU.EDU [128.2.81.22]) by mail.clinet.fi (8.9.3/8.9.3) with SMTP id WAA11253 for ; Wed, 21 Feb 2001 22:02:09 +0200 Received: from MARINER.REM.CS.CMU.EDU by mariner.rem.cs.cmu.edu id aa07535; 21 Feb 2001 15:01 EST Date: Wed, 21 Feb 2001 15:01:38 -0500 (EST) From: Jeffrey Hutzelman X-Sender: jhutz@mariner.rem.cs.cmu.edu To: Simon Wilkinson cc: ietf-ssh@clinet.fi, jsalowey@cisco.com Subject: Re: SSH GSSAPI key exchange In-Reply-To: <01022117411205.04292@loki.dcs.ed.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Wed, 21 Feb 2001, Simon Wilkinson wrote: > On Mon, 19 Feb 2001, Jeffrey Hutzelman wrote: > > BTW, I'm interested in knowing a bit more about your implementation... > > Its based on OpenSSH, and has been tested with the Kerberos GSSAPI mechanism, > although the implementation itself should be generic enough to allow any > other mechanism to be added (although an equivalent to 'kuserok' would be > required in order to make external-keyx work). I have implemented the > external-keyx user authentication, but not the 'none' method described for > host keys. Hm. So, a machine still must have an ssh host key, even though it will not be used as part of the GSSAPI key exchange. > A further concern is of the failure of the GSSAPI key exchange, especially > during rekeying. I can't find any mention of what happens following a failed > key exchange. However, if connections must be terminated, as opposed to > trying again using a different algorithm, then this could cause severe > problems for Kerberos users whose local credentials expire during a long > running ssh operation. I'll have to re-read the core ssh drafts, but I believe the only action that can be taken after a failed key exchange is to drop the connection. However, I fail to see how this has an effect on expired user credentials. The key exchange happens only at the start of a connection; if the user's credentials are expired, he must get new ones before establishing a connection. Of course, it is also worth noting that some GSSAPI mechs (particularly public-key based ones) have credentials with much longer expiration times than those typically used in Kerberos. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From owner-ietf-ssh@clinet.fi Wed Feb 21 16:56:16 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11889 for ; Wed, 21 Feb 2001 16:56:15 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id VAA10900 for ietf-ssh-outgoing; Wed, 21 Feb 2001 21:57:33 +0200 Received: from mariner.rem.cs.cmu.edu (MARINER.REM.CS.CMU.EDU [128.2.81.22]) by mail.clinet.fi (8.9.3/8.9.3) with SMTP id VAA10893 for ; Wed, 21 Feb 2001 21:57:31 +0200 Received: from MARINER.REM.CS.CMU.EDU by mariner.rem.cs.cmu.edu id aa07526; 21 Feb 2001 14:56 EST Date: Wed, 21 Feb 2001 14:56:45 -0500 (EST) From: Jeffrey Hutzelman X-Sender: jhutz@mariner.rem.cs.cmu.edu Reply-To: Jeffrey Hutzelman To: Joseph Salowey cc: Simon Wilkinson , ietf-ssh@clinet.fi Subject: Re: SSH GSSAPI key exchange In-Reply-To: <4.3.2.7.2.20010221102924.00b20ba0@mira-sjc5-6.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Wed, 21 Feb 2001, Joseph Salowey wrote: > Good catch, > > Perhaps we should always send e with the inital token even if the context > is not yet complete. I don't think there is a problem sending e if the > context does not complete, it might be extra processing for the client, but > I' not sure this is a problem. I don't think there's any problem with sending e before the context is established. In fact, I was initially going to write the spec that way, but doing it last seemed to make both the protocol and the text cleaner. Sending it first does seem to save a half round trip, but the way I read the GSSAPI spec, _every_ call to gss_init_sec_context results in a token that must be sent to the server. It would seem now that this is not true; it's possible for the acceptor to send the last message. Let's assume, then, that either initiator or acceptor can be the last to send, and will return COMPLETE iff it is not expecting a reply. Then I think we should do the following: - Change the wording of step 2 such that the client MUST send e with the first message sent to the server (formerly, we said the client SHOULD send it with the last message, but MAY send it in some other message instead. Now, the client doesn't know if it is sending the last message). - Change the wording of step 2 such that is is an error if the call to gss_init_sec_context does not produce a token. If there is a final token, we'll handle it later. - Change the wording of step 3 such that a final token may be sent to the client. - Insert step 4a, in which the client calls gss_init_sec_context to process the server's final token, if there is one. This call is like the one in step 2, except that it is an error for the call to return a token or any status other than GSS_S_COMPLETE. This step is performed only if no previous call to gss_init_sec_context had a status of GSS_S_COMPLETE. - Adjust the message flow description to match the changes, including a change in the definition of SSH_MSG_GSSAPI_COMPLETE to include an optional final token. - We should make it clear that it is an error for the server to send SSH_MSG_GSSAPI_COMPLETE without a final token if the client is still expecting one. For safety, it should also be an error for the server to send SSH_MSG_GSSAPI_CONTINUE or SSH_MSG_GSSAPI_COMPLETE with a final token if the client has already seen a GSS_S_COMPLETE status. So, we have the client and server trading messages as follows: - client calls gss_init_sec_context, with the server's last token if any. This must result in a token, which is sent to the server in a message of type SSH_MSG_GSSAPI_INIT. - server calls gss_accept_sec_context. If the result status is GSS_S_CONTINUE_NEEDED, there must be a token, which is sent to the client in an SSH_MSG_GSSAPI_CONTINUE message. If the result status is GSS_S_COMPLETE, then an SSH_MSG_GSSAPI_COMPLETE message is sent, containing 'f', a MIC of the exchange hash, and a final token if there is one. - On receiving SSH_MSG_GSSAPI_CONTINUE, the client goes to the top, calling gss_init_sec_context again. It is an error for this to happen if the previous call to gss_init_sec_context resulted in a GSS_S_COMPLETE status. - On receiving SSH_MSG_GSSAPI_COMPLETE, the client makes one last call to gss_init_sec_context iff the server provides a final token. It is an error for a final token to be present if the previous call resulted in a GSS_S_COMPLETE status, or for a final token to be absent if the previous call resulted in GSS_S_CONTINUE_NEEDED. I think this addresses the problem of the server sending the last message, as well as preventing the extra round trip that Joe was concerned about. -- Jeff From owner-ietf-ssh@clinet.fi Wed Feb 21 17:26:39 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12524 for ; Wed, 21 Feb 2001 17:26:38 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA14384 for ietf-ssh-outgoing; Wed, 21 Feb 2001 22:44:18 +0200 Received: from muck.dcs.ed.ac.uk (muck.dcs.ed.ac.uk [129.215.216.15]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id WAA14379 for ; Wed, 21 Feb 2001 22:44:15 +0200 Received: from loki.dcs.ed.ac.uk (root@loki.dcs.ed.ac.uk [129.215.58.88]) by muck.dcs.ed.ac.uk with ESMTP id UAA10167; Wed, 21 Feb 2001 20:44:14 GMT Received: from loki.dcs.ed.ac.uk (IDENT:sxw@localhost [127.0.0.1]) by loki.dcs.ed.ac.uk (8.9.1/8.9.1) with SMTP id UAA13269; Wed, 21 Feb 2001 20:44:13 GMT From: Simon Wilkinson To: Jeffrey Hutzelman Subject: Re: SSH GSSAPI key exchange Date: Wed, 21 Feb 2001 20:42:55 +0000 X-Mailer: KMail [version 1.1.94] Content-Type: text/plain Cc: ietf-ssh@clinet.fi References: In-Reply-To: Organization: Division of Informatics MIME-Version: 1.0 Message-Id: <01022120425506.04292@loki.dcs.ed.ac.uk> Content-Transfer-Encoding: 8bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 8bit On Wed, 21 Feb 2001, Jeffrey Hutzelman wrote: > However, I fail to see how this has an effect on expired user credentials. > The key exchange happens only at the start of a connection; My concern was when a server requests that new keys be established for the connection, which according to the core drafts should take place hourly. If the users credentials have expired between connection establishment, and rekeying, then I think, from my reading of the drafts, that their existing connection would be dropped. Cheers, Simon. From owner-ietf-ssh@clinet.fi Wed Feb 21 18:12:12 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13587 for ; Wed, 21 Feb 2001 18:12:11 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA16035 for ietf-ssh-outgoing; Wed, 21 Feb 2001 23:06:48 +0200 Received: from muck.dcs.ed.ac.uk (muck.dcs.ed.ac.uk [129.215.216.15]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA16031 for ; Wed, 21 Feb 2001 23:06:47 +0200 Received: from canna.dcs.ed.ac.uk (sxw@canna.dcs.ed.ac.uk [129.215.216.106]) by muck.dcs.ed.ac.uk with ESMTP id VAA11478; Wed, 21 Feb 2001 21:06:46 GMT Received: (from sxw@localhost) by canna.dcs.ed.ac.uk (8.8.8+Sun/8.8.8) id VAA15082; Wed, 21 Feb 2001 21:06:45 GMT Date: Wed, 21 Feb 2001 21:06:45 GMT Message-Id: <200102212106.VAA15082@canna.dcs.ed.ac.uk> From: Simon Wilkinson Subject: Re: SSH GSSAPI key exchange To: Jeffrey Hutzelman , Joseph Salowey In-Reply-To: Jeffrey Hutzelman's message of Wed, 21 Feb 2001 14:56:45 -0500 (EST) Cc: ietf-ssh@clinet.fi Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > the way I read the GSSAPI spec, _every_ call to gss_init_sec_context > results in a token that must be sent to the server. RFC2743 says that gss_init_sec_context "ordinarily emits an output token", RFC2744 (the C bindings) says "may return an output token ... If no token need be sent, gss_init_sec_context will indicate this by setting the length field ... to zero", and "Portable applications should ... use the token length ... to determine whether a token needs to be sent". The sample code in RFC2744 certainly assumes that an output token may or may not be present at either end of the connection. > Let's assume, then, that either initiator or acceptor can be the last to > send, and will return COMPLETE iff it is not expecting a reply. Then I > think we should do the following: This appears to work in all of the situations I can think of. Just to get my head round it, I've tried implementing this, and it works correctly in the Kerberos case. Cheers, Simon. From owner-ietf-ssh@clinet.fi Thu Feb 22 03:18:34 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05977 for ; Thu, 22 Feb 2001 03:18:33 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id IAA22635 for ietf-ssh-outgoing; Thu, 22 Feb 2001 08:52:47 +0200 Received: from tolstoi.ru.hilti.com ([195.239.59.130]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id IAA22628 for ; Thu, 22 Feb 2001 08:52:46 +0200 Received: by tolstoi.ru.hilti.com with Internet Mail Service (5.5.2653.19) id <1CKRFACS>; Thu, 22 Feb 2001 09:59:50 +0300 Message-ID: From: "Shesterikov Maxim (sm)" To: Martin Forssen Cc: ietf-ssh@clinet.fi Subject: RE: Comments for draft-ietf-secsh-auth-kbdinteract-01.txt Date: Thu, 22 Feb 2001 09:59:43 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ssh@clinet.fi Precedence: bulk >Such a text implies that the server is permitted to >have multiple outstanding authentication requests simultaneously, and >this can be complicated to handle in the client. Would it not be better >just instead forbid the server to have more than one set of prompts >(SSH_MSG_USERAUTH_INFO_REQUEST packets) outstanding at any time? >Comments? I agree. Maxim From owner-ietf-ssh@clinet.fi Fri Feb 23 19:56:10 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 TAA27952 for ; Fri, 23 Feb 2001 19:56:09 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA22992 for ietf-ssh-outgoing; Sat, 24 Feb 2001 01:24:38 +0200 Received: from orchard.arlington.ma.us (orchard.hamachi.org [4.255.0.98]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id BAA22988 for ; Sat, 24 Feb 2001 01:24:37 +0200 Received: by orchard.arlington.ma.us (Postfix, from userid 587) id 97B472A3E; Fri, 23 Feb 2001 18:24:20 -0500 (EST) Received: from orchard.arlington.ma.us (localhost [127.0.0.1]) by orchard.arlington.ma.us (Postfix) with ESMTP id 869021FD8 for ; Fri, 23 Feb 2001 18:24:20 -0500 (EST) To: ietf-ssh@clinet.fi Subject: testing .. one .. two .. three.. Reply-To: sommerfeld@orchard.arlington.ma.us Date: Fri, 23 Feb 2001 18:24:15 -0500 From: Bill Sommerfeld Message-Id: <20010223232420.97B472A3E@orchard.arlington.ma.us> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Sorry for the noise; please delete this. Some mail I sent earlier from a different address hasn't gone through. Let's see if this does any better. - Bill From owner-ietf-ssh@clinet.fi Sat Feb 24 08:53:34 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19581 for ; Sat, 24 Feb 2001 08:53:33 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id OAA29536 for ietf-ssh-outgoing; Sat, 24 Feb 2001 14:08:53 +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 OAA29533 for ; Sat, 24 Feb 2001 14:08:52 +0200 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 14WdVL-0005bc-00; Sat, 24 Feb 2001 12:08:51 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@clinet.fi Subject: SFTP: clarification Message-Id: Date: Sat, 24 Feb 2001 12:08:51 +0000 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Hi, ssh.com's and OpenSSH's SFTP servers seem to have a difference of opinion over the semantics of FXP_REALPATH. I read the spec carefully but couldn't see anything that explicitly stated who was right. ssh.com is willing to return a canonical pathname for a nonexistent file. It returns the string that _would_ be the file's canonical name if it were to be created. Hence, I can call FXP_REALPATH just before creating a remote file, and get back the canonical pathname of the file I'm about to create. OpenSSH, by contrast, will only return a canonical pathname for a file that actually exists. Which of these is the right behaviour, or are they both right? Could the SFTP draft be clarified on this point please? Cheers, Simon -- Simon Tatham "My heart bleeds. (That's how it works.)" -- Gareth Taylor From owner-ietf-ssh@clinet.fi Sun Feb 25 22:13:05 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15677 for ; Sun, 25 Feb 2001 22:13:04 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id AAA04940 for ietf-ssh-outgoing; Mon, 26 Feb 2001 00:25:25 +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 AAA04936 for ; Mon, 26 Feb 2001 00:25:24 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id A582482F528; Sun, 25 Feb 2001 23:25:17 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id XAA28081; Sun, 25 Feb 2001 23:25:17 +0100 (MET) To: Simon Tatham Cc: ietf-ssh@clinet.fi Subject: Re: SFTP: clarification References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 25 Feb 2001 23:25:16 +0100 In-Reply-To: Simon Tatham's message of "Sat, 24 Feb 2001 12:08:51 +0000" Message-ID: Lines: 10 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Simon Tatham writes: > Which of these is the right behaviour, or are they both right? Could > the SFTP draft be clarified on this point please? I would also like to see some motivation for the FXP_REALPATH feature. Why does anybody need that? /Niels From owner-ietf-ssh@clinet.fi Mon Feb 26 00:32:49 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17821 for ; Mon, 26 Feb 2001 00:32:48 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id FAA01070 for ietf-ssh-outgoing; Mon, 26 Feb 2001 05:53:55 +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 FAA01066 for ; Mon, 26 Feb 2001 05:53:55 +0200 Received: from kado.mindrot.org (CPE-203-45-24-18.vic.bigpond.net.au [203.45.24.18]) by smtp1.clinet.fi (Postfix) with ESMTP id 264E7221 for ; Mon, 26 Feb 2001 05:53:38 +0200 (EET) Received: from toad.mindrot.org (toad.mindrot.org [203.44.118.252]) by kado.mindrot.org (Postfix) with ESMTP id 2B2609002; Mon, 26 Feb 2001 04:36:37 +1100 (EST) Received: from mothra.mindrot.org (mothra.mindrot.org [203.44.118.225]) by toad.mindrot.org (Postfix) with ESMTP id 19DC11A1E6; Mon, 26 Feb 2001 14:53:33 +1100 (EST) Received: by mothra.mindrot.org (Postfix, from userid 500) id 76F4A3C08B; Mon, 26 Feb 2001 14:53:31 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by mothra.mindrot.org (Postfix) with ESMTP id 705983C08A; Mon, 26 Feb 2001 14:53:31 +1100 (EST) Date: Mon, 26 Feb 2001 14:53:31 +1100 (EST) From: Damien Miller To: =?X-UNKNOWN?Q?Niels_M=F6ller?= Cc: Simon Tatham , ietf-ssh@clinet.fi Subject: Re: SFTP: clarification In-Reply-To: Message-ID: X-Paranoia: just because you're paranoid doesn't mean they aren't out to get you MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.clinet.fi id FAA01067 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id FAA01070 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA17821 On 25 Feb 2001, Niels Mцller wrote: > Simon Tatham writes: > > > Which of these is the right behaviour, or are they both right? Could > > the SFTP draft be clarified on this point please? > > I would also like to see some motivation for the FXP_REALPATH feature. > Why does anybody need that? It makes it a fair bit easier to write a client, especially since the server lacks the concept of a current working directory. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From owner-ietf-ssh@clinet.fi Mon Feb 26 06:20: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 GAA03980 for ; Mon, 26 Feb 2001 06:20:53 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id LAA22063 for ietf-ssh-outgoing; Mon, 26 Feb 2001 11:44:24 +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 LAA22049 for ; Mon, 26 Feb 2001 11:44:21 +0200 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 14XKCa-00074D-00; Mon, 26 Feb 2001 09:44:20 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham In-Reply-To: To: nisse@lysator.liu.se (Niels Mцller) Cc: ietf-ssh@clinet.fi Subject: Re: SFTP: clarification Message-Id: Date: Mon, 26 Feb 2001 09:44:20 +0000 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk nisse@lysator.liu.se (Niels Mцller) wrote: > I would also like to see some motivation for the FXP_REALPATH feature. > Why does anybody need that? It allows you to implement a current working directory in the form Unix users expect it. That is, typing `pwd' always gives you the same result if you're in the same directory. Without FXP_REALPATH, there would be a visual distinction between my home directory as specified by `.', and my home directory as specified by `cd /home/simon'. Typing `cd ..' from each would leave you in `..' and `/home' respectively. A naive user who's used to `..' being pwd-relative isn't going to be soothed by the idea that there simply isn't a pwd in the SFTP wire protocol; they will expect the client to synthesise a plausible pwd _for_ them. Moreover, there's a subtle change in behaviour given the existence of symlinks to directories. Consider /usr/doc -> /usr/share/doc, for example. Without FXP_REALPATH, I type `cd /usr/doc' and then `cd ..' and end up in /usr; but I type `cd /usr/share/doc' and then `cd ..' and end up in /usr/share. With FXP_REALPATH, I end up in the _same_ place no matter which I do - which is the behaviour traditional Unix provides. (Aside: bash well-meaningly tries to obscure this behaviour, by keeping its own notion of your pwd which doesn't dereference symlinks, so `cd /usr/doc' followed by `cd ..' leaves you in /usr; but this illusion is imperfect and therefore arguably more confusing than its absence, because it's not shared by anything other than the shell: so once you've done `cd /usr/doc', `ls ..' will list /usr/share even though `cd ..' lands you in /usr!) Cheers, Simon -- Simon Tatham "What a caterpillar calls the end of the world, a human calls a butterfly." From owner-ietf-ssh@clinet.fi Mon Feb 26 06:26:48 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04049 for ; Mon, 26 Feb 2001 06:26:48 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id LAA24443 for ietf-ssh-outgoing; Mon, 26 Feb 2001 11:54:34 +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 LAA24412 for ; Mon, 26 Feb 2001 11:54:30 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id E341D82F521; Mon, 26 Feb 2001 10:54:28 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id KAA16943; Mon, 26 Feb 2001 10:54:28 +0100 (MET) To: Simon Tatham Cc: ietf-ssh@clinet.fi Subject: Re: SFTP: clarification References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 From: nisse@lysator.liu.se (Niels Mцller) Date: 26 Feb 2001 10:54:27 +0100 In-Reply-To: Simon Tatham's message of "Mon, 26 Feb 2001 09:44:20 +0000" Message-ID: Lines: 16 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 LAA24443 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA04049 Simon Tatham writes: > nisse@lysator.liu.se (Niels Mцller) wrote: > > > I would also like to see some motivation for the FXP_REALPATH feature. > > Why does anybody need that? > > It allows you to implement a current working directory in the form > Unix users expect it. That is, typing `pwd' always gives you the > same result if you're in the same directory. Ok, that makes some sense. Having the client's pwd command return "" for the home directory would definitely confuse users. Thanks for the explanation. /Niels From owner-ietf-ssh@clinet.fi Mon Feb 26 13:21:30 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19911 for ; Mon, 26 Feb 2001 13:21:29 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA05554 for ietf-ssh-outgoing; Mon, 26 Feb 2001 18:19:15 +0200 Received: from dr-evil.shagadelic.org (yeah-baby.shagadelic.org [208.176.2.162]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA05548 for ; Mon, 26 Feb 2001 18:19:12 +0200 Received: by dr-evil.shagadelic.org (Postfix, from userid 7518) id 21AD3D203; Mon, 26 Feb 2001 08:19:08 -0800 (PST) Date: Mon, 26 Feb 2001 08:19:08 -0800 From: Jason R Thorpe To: Simon Tatham Cc: =?iso-8859-1?Q?Niels_M=F6ller?= , ietf-ssh@clinet.fi Subject: Re: SFTP: clarification Message-ID: <20010226081908.F3786@dr-evil.shagadelic.org> Reply-To: thorpej@zembu.com Mail-Followup-To: Jason R Thorpe , Simon Tatham , =?iso-8859-1?Q?Niels_M=F6ller?= , ietf-ssh@clinet.fi References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from anakin@pobox.com on Mon, Feb 26, 2001 at 09:44:20AM +0000 Organization: Zembu Labs, Inc. Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Mon, Feb 26, 2001 at 09:44:20AM +0000, Simon Tatham wrote: > (Aside: bash well-meaningly tries to obscure this behaviour, by > keeping its own notion of your pwd which doesn't dereference > symlinks, so `cd /usr/doc' followed by `cd ..' leaves you in /usr; > but this illusion is imperfect and therefore arguably more confusing > than its absence, because it's not shared by anything other than the > shell: so once you've done `cd /usr/doc', `ls ..' will list > /usr/share even though `cd ..' lands you in /usr!) That shell behavior is not specific to bash -- in fact, I seem to recall that it is required by POSIX. -- -- Jason R. Thorpe From owner-ietf-ssh@clinet.fi Mon Feb 26 13:28:02 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20139 for ; Mon, 26 Feb 2001 13:28:01 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA06846 for ietf-ssh-outgoing; Mon, 26 Feb 2001 18:31:49 +0200 Received: from smtp.netreach.net (fatuka.netreach.net [207.29.195.121]) by mail.clinet.fi (8.9.3/8.9.3) with SMTP id SAA06841 for ; Mon, 26 Feb 2001 18:31:48 +0200 Received: (qmail 6906 invoked by uid 102); 26 Feb 2001 16:32:29 -0000 Received: from static-cc.netreach.net (HELO delbert) (207.29.201.235) by smtp.netreach.net with SMTP; 26 Feb 2001 16:32:29 -0000 Message-Id: <4.2.0.58.20010226112837.00a562d0@mail2.netreach.net> X-Sender: programs@corecom.com@mail2.netreach.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 26 Feb 2001 11:31:12 -0500 To: ietf-ssh@clinet.fi From: TISC Programs Subject: The Internet Security Conference 2001 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ssh@clinet.fi Precedence: bulk The Fifth Internet Security Conference will be held June 4-8, 2001 at the Century Plaza Hotel and Tower, 2025 Avenue of the Stars, Century City Los Angeles, CA 90067-4696. TISC is an educational forum for security professionals and practitioners. TISC Workshops on network security principles, Windows 2000 security, firewall practices, incident response, security systems for the Internet, attack trends and countermeasures, VPNs, and hacking are presented by leading experts in the security community. In addition, over 50 security experts will offer technical advice and present invited papers during the TISC Security Symposium. Topics include Anti-Hacking, IDS, VPNs, Authentication and PKI, web security and privacy, network forensics, LINUX security, wireless security, malware, web threats, and more. For example, see http://www.tisc2001.com/symposium.html#S39, an invited paper entitled "Choosing the Best Solution for Your Network Security: Secure Shell, IPsec or TLS" View the complete agenda at http://www.tisc2001.com/agenda.html We hope to see you in Los Angeles! The TISC 2001 Program Committee www.tisc2001.com From owner-ietf-ssh@clinet.fi Mon Feb 26 13:46:09 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 NAA20953 for ; Mon, 26 Feb 2001 13:46:08 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA09236 for ietf-ssh-outgoing; Mon, 26 Feb 2001 18:59:09 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA09199 for ; Mon, 26 Feb 2001 18:58:45 +0200 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11343 for ; Mon, 26 Feb 2001 08:58:44 -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 LAA28137 for ; Mon, 26 Feb 2001 11:58:43 -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 f1QGwf201067 for ; Mon, 26 Feb 2001 11:58:41 -0500 (EST) Message-Id: <200102261658.f1QGwf201067@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@clinet.fi Subject: testing.. Reply-to: sommerfeld@east.sun.com Date: Mon, 26 Feb 2001 11:58:40 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk [testing, again..] From owner-ietf-ssh@clinet.fi Mon Feb 26 14:08:28 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21928 for ; Mon, 26 Feb 2001 14:08:27 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA09100 for ietf-ssh-outgoing; Mon, 26 Feb 2001 18:57:34 +0200 Received: from noc.untraceable.net (noc.untraceable.net [166.84.189.65]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA09097 for ; Mon, 26 Feb 2001 18:57:32 +0200 Received: (from andrew@localhost) by noc.untraceable.net (8.12.0.Beta3/8.12.0.Beta3/bonk!) id f1QGvVJc023661; Mon, 26 Feb 2001 11:57:31 -0500 (EST) Date: Mon, 26 Feb 2001 11:57:31 -0500 From: Andrew Brown To: Simon Tatham Cc: =?iso-8859-1?Q?Niels_M=F6ller?= , ietf-ssh@clinet.fi Subject: Re: SFTP: clarification Message-ID: <20010226115730.A23308@noc.untraceable.net> Reply-To: Andrew Brown References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from anakin@pobox.com on Mon, Feb 26, 2001 at 09:44:20AM +0000 X-Hi-To-All-My-Friends-In-Domestic-Surveillance: hi there, sports fans :) Sender: owner-ietf-ssh@clinet.fi Precedence: bulk >(Aside: bash well-meaningly tries to obscure this behaviour, by >keeping its own notion of your pwd which doesn't dereference >symlinks, so `cd /usr/doc' followed by `cd ..' leaves you in /usr; >but this illusion is imperfect and therefore arguably more confusing >than its absence, because it's not shared by anything other than the >shell: so once you've done `cd /usr/doc', `ls ..' will list >/usr/share even though `cd ..' lands you in /usr!) tcsh can also do this, with the distinction that if you have this feature turned on, after a "cd /usr/doc", then command "ls .." will be executed as "ls /usr". it's still not perfect though. -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth." From owner-ietf-ssh@clinet.fi Tue Feb 27 11:00:36 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14080 for ; Tue, 27 Feb 2001 11:00:35 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA01926 for ietf-ssh-outgoing; Tue, 27 Feb 2001 15:52:27 +0200 Received: from folly.informatik.uni-erlangen.de (muedi4-145-253-166-076.arcor-ip.net [145.253.166.76]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA01855 for ; Tue, 27 Feb 2001 15:52:08 +0200 Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id B49F7F6C; Tue, 27 Feb 2001 14:19:32 +0100 (CET) Date: Tue, 27 Feb 2001 14:19:32 +0100 From: Markus Friedl To: Simon Tatham Cc: =?iso-8859-1?Q?Niels_M=F6ller?= , ietf-ssh@clinet.fi Subject: Re: SFTP: clarification Message-ID: <20010227141932.A21832@folly> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from anakin@pobox.com on Mon, Feb 26, 2001 at 09:44:20AM +0000 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Mon, Feb 26, 2001 at 09:44:20AM +0000, Simon Tatham wrote: > (Aside: bash well-meaningly tries to obscure this behaviour, by > keeping its own notion of your pwd which doesn't dereference > symlinks, so `cd /usr/doc' followed by `cd ..' leaves you in /usr; > but this illusion is imperfect and therefore arguably more confusing > than its absence, because it's not shared by anything other than the > shell: so once you've done `cd /usr/doc', `ls ..' will list > /usr/share even though `cd ..' lands you in /usr!) oh yes, it's bad that chdir("..") and cd .. are not the same. this has been introduced with some ksh version. see http://plan9.bell-labs.com/sys/doc/lexnames.{html,ps,pdf} for related information. From owner-ietf-ssh@clinet.fi Tue Feb 27 12:48:17 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 MAA20224 for ; Tue, 27 Feb 2001 12:48:16 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA20430 for ietf-ssh-outgoing; Tue, 27 Feb 2001 17:48:09 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA20422 for ; Tue, 27 Feb 2001 17:48:07 +0200 Received: from joseph ([192.168.0.1]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 521; Tue, 27 Feb 2001 08:55:05 -0700 Message-ID: <00ab01c0a0d5$480e5170$140210ac@Galbraith.Local> From: "Joseph Galbraith" To: "Simon Wilkinson" , Cc: , References: <01022715362909.04425@loki.dcs.ed.ac.uk> Subject: Re: SSH_MSG_USERAUTH_GSSAPI_HASH in draft-galb-secsh-gssapi Date: Tue, 27 Feb 2001 08:52:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit > draft-galb-secsh-gssapi-00.txt uses a user authentication exchange packet to > provide additional trust in the server's host key, by sending the client a > GSSAPI MIC of the host key after a GSSAPI context has been established. > However, I believe that this does not provide any additional protection > against man in the middle attacks, as claimed. > > The draft has no clear requirement that the client receives this packet > before continuing with authentication, so allowing a man in the middle > attacker to simply remove that packet from the exchange that it is proxying > between the client and the server. I think that in order to receive the > required protection, clients must not accept a success message unless the > hash packet has been successfully received and verified. Could this be stated > more clearly in the document? Yes, this is much clearer in my working version of the draft, and I have just clarified it further to specify that if the client doesn't receive the packet, it is a protocol error. Thanks for pointing this out. We have been remiss getting this draft out; we will be publishing a revision before the Friday deadline though, containing the results of the discussion last working group meeting. - Joseph From owner-ietf-ssh@clinet.fi Tue Feb 27 12:49:31 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20257 for ; Tue, 27 Feb 2001 12:49:30 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA18940 for ietf-ssh-outgoing; Tue, 27 Feb 2001 17:36:35 +0200 Received: from rhenium (rhenium.btinternet.com [194.73.73.93]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA18928 for ; Tue, 27 Feb 2001 17:36:32 +0200 Received: from [213.1.132.165] (helo=loki.dcs.ed.ac.uk) by rhenium with smtp (Exim 3.03 #83) id 14XmAx-0007S8-00; Tue, 27 Feb 2001 15:36:31 +0000 From: Simon Wilkinson To: ietf-ssh@clinet.fi Subject: SSH_MSG_USERAUTH_GSSAPI_HASH in draft-galb-secsh-gssapi Date: Tue, 27 Feb 2001 15:36:29 +0000 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="iso-8859-1" Organization: Division of Informatics Cc: galb@vandyke.com, jpv@vandyke.com, welch@mcs.anl.gov MIME-Version: 1.0 Message-Id: <01022715362909.04425@loki.dcs.ed.ac.uk> Content-Transfer-Encoding: 8bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 8bit draft-galb-secsh-gssapi-00.txt uses a user authentication exchange packet to provide additional trust in the server's host key, by sending the client a GSSAPI MIC of the host key after a GSSAPI context has been established. However, I believe that this does not provide any additional protection against man in the middle attacks, as claimed. The draft has no clear requirement that the client receives this packet before continuing with authentication, so allowing a man in the middle attacker to simply remove that packet from the exchange that it is proxying between the client and the server. I think that in order to receive the required protection, clients must not accept a success message unless the hash packet has been successfully received and verified. Could this be stated more clearly in the document? Cheers, Simon. From owner-ietf-ssh@clinet.fi Tue Feb 27 14:10:11 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24438 for ; Tue, 27 Feb 2001 14:10:10 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA27031 for ietf-ssh-outgoing; Tue, 27 Feb 2001 18:53:48 +0200 Received: from sultan.cceb.upenn.edu (SULTAN.CCEB.UPENN.EDU [165.123.126.23]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA27027 for ; Tue, 27 Feb 2001 18:53:46 +0200 Received: from cceb.upenn.edu ([165.123.126.136]) by sultan.cceb.upenn.edu (Netscape Messaging Server 4.15) with ESMTP id G9FDLK00.KQ8 for ; Tue, 27 Feb 2001 11:53:44 -0500 Message-ID: <3A9BDB98.85049FA1@cceb.upenn.edu> Date: Tue, 27 Feb 2001 11:53:44 -0500 From: "Govind Vinjamuri" X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ssh@clinet.fi Subject: starting ssh Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit does anyone know what this mean. # /etc/init.d/sshd start "Warning: PasswordAutentication configuration keyword is deprecated. Use allowedAuthentications. "Warning: PubkeyAuthentication COnfiguration keyword is deprecated. use AllowedAuthentications. "starting sshd" does not sound too good. Is there a solution for this. Thanks for you help. -- Govind Vinjamuri From owner-ietf-ssh@clinet.fi Tue Feb 27 15:42:40 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28845 for ; Tue, 27 Feb 2001 15:42:39 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA04197 for ietf-ssh-outgoing; Tue, 27 Feb 2001 20:47:50 +0200 Received: from faui02.informatik.uni-erlangen.de (msfriedl@faui02.informatik.uni-erlangen.de [131.188.30.102]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA04193 for ; Tue, 27 Feb 2001 20:47:48 +0200 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id TAA28142; Tue, 27 Feb 2001 19:47:46 +0100 (MET) Date: Tue, 27 Feb 2001 19:47:46 +0100 From: Markus Friedl To: Govind Vinjamuri Cc: ietf-ssh@clinet.fi Subject: Re: starting ssh Message-ID: <20010227194746.A26820@faui02.informatik.uni-erlangen.de> References: <3A9BDB98.85049FA1@cceb.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <3A9BDB98.85049FA1@cceb.upenn.edu>; from gvinjamu@cceb.upenn.edu on Tue, Feb 27, 2001 at 11:53:44AM -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Tue, Feb 27, 2001 at 11:53:44AM -0500, Govind Vinjamuri wrote: > does anyone know what this mean. > > # /etc/init.d/sshd start > "Warning: PasswordAutentication configuration keyword is deprecated. Use > allowedAuthentications. > "Warning: PubkeyAuthentication COnfiguration keyword is deprecated. use > AllowedAuthentications. it means that you should not use PubkeyAuthentication or PasswordAutentication, but the AllowedAuthentications option in sshd2_config. From owner-ietf-ssh@clinet.fi Wed Feb 28 02:11:31 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28922 for ; Wed, 28 Feb 2001 02:11:30 -0500 (EST) From: owner-ietf-ssh@clinet.fi Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id HAA11296 for ietf-ssh-outgoing; Wed, 28 Feb 2001 07:21:01 +0200 Message-Id: <200102280521.HAA11296@mail.clinet.fi> Received: from chat.ru ([195.209.134.2]) by mail.clinet.fi (8.9.3/8.9.3) with SMTP id HAA11247; Wed, 28 Feb 2001 07:20:25 +0200 To: Subject: в отдел снабжения Date: Ср, 28 фев 2001 04:46:55 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk По Вашему запросу сообщаем, что у нас Вы можете купить картриджи для Вашей офисной техники прямо из своего офиса. Гарантированное качество, низкие цены, бесплатная доставка в течение 3-5 часов, индивидуальное обслуживание гарантируем. Если Вы хотите сохранить свое время, деньги и получить от покупки удовольствие - загляните к нам! Мы всегда ждем Вас по адресу: http://www.sanda.ru Приносим свои извинения, если это письмо попало к Вам случайно. From ietf-ssh-owner@netbsd.org Wed Feb 28 18:17: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 SAA01054 for ; Wed, 28 Feb 2001 18:17:40 -0500 (EST) Received: (qmail 1371 invoked by uid 605); 28 Feb 2001 23:11:47 -0000 Date: 28 Feb 2001 23:11:45 -0000 Message-ID: <20010228231145.1360.qmail@mail.netbsd.org> To: secsh-archive@ietf.org From: majordomo@netbsd.org Subject: Welcome to ietf-ssh Reply-To: majordomo@netbsd.org -- Welcome to the ietf-ssh mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe ietf-ssh or from another account, besides secsh-archive@odin.ietf.org: unsubscribe ietf-ssh secsh-archive@odin.ietf.org If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. Here's the general information for the list you've subscribed to, in case you don't already have it: This mailing list hosts the IETF Secure Shell working group, founded to produce an IETF standard based on the popular "SSH" protocol. See http://www.ietf.org/html.charters/secsh-charter.html for more information regarding the working group and the current status of its documents. If you are unfamiliar with the IETF, you should review http://www.ietf.org/overview.html for an overview of the IETF and its standards process. Participation from any interested party is welcome. New subscribers are encouraged to review the recent archives of the list. [This list was formerly hosted at ietf-ssh@clinet.fi, but has been moved here due to reliability problems with the old host.] From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Feb 28 18:23: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 SAA01237 for ; Wed, 28 Feb 2001 18:23:51 -0500 (EST) Received: (qmail 5880 invoked by uid 605); 28 Feb 2001 23:23:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5873 invoked from network); 28 Feb 2001 23:23:38 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 28 Feb 2001 23:23:38 -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 PAA28882; Wed, 28 Feb 2001 15:23: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 SAA09252; Wed, 28 Feb 2001 18:23:15 -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 f1SNNCj04094; Wed, 28 Feb 2001 18:23:12 -0500 (EST) Message-Id: <200102282323.f1SNNCj04094@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@clinet.fi, ietf-ssh@netbsd.org Subject: This list has moved. Reply-to: sommerfeld@east.sun.com Date: Wed, 28 Feb 2001 18:23:11 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list As a few of you have remarked, ietf-ssh@clinet.fi hasn't been working well lately. I've seen evidence that several fairly important messages (both from myself and from several other folks) have not made it through to the two places I'm subscribed or to the archive. Tatu Ylonen informs me that the folks he knew at clinet.fi (which he described as a "local ISP") are no longer there, so it's time to move the list. When I mentioned these difficulties in another forum, I recieved an immediate offer to host it at netbsd.org. The new list is ; it will be administered via majordomo (just like the current list). I'm currently set up as the moderator for that list. List policy: There has been substantial discussion over on the POISED list recently regarding mailing list policy, so a few words are appropriate here.. The new list is currently configured to be unmoderated and to allow open access (i.e., non-subscribers may post) since there seems to be rough consensus that subscriber-only lists discourage participation from folks (like IESG/IAB members) who may have something to contribute but don't have the time to subscribe to every WG's list. That said, there are a few (system-wide) filters in place on the netbsd.org mail server which catch certain messages and send them to the moderator instead of the list members. These include patterns to weed out common user errors (e.g., subscribe/unsubscribe requests), as well as excessively long messages (over 100000 bytes), barfmail, and words and phrases that have historically been used by spammers and mail viruses. As moderator, I'll look over all the bounces and approve messages which were bounced inappropriately -- i.e., if there's a message about using ssh for remote management of t*ner c*rtridges, I'll let it through ;-) It is my intent to encourage open contribution to this WG from any interested party. There are, to my knowledge, no filters in place which would automatically exclude posts by any WG participant or implementor. If you feel that filters are being applied inappropriately, please let me know ASAP; most likely it's an oversight or error which can be quickly corrected. Likewise, please let me know ASAP if you see other operational problems with this list. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Feb 28 19:10: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 TAA02646 for ; Wed, 28 Feb 2001 19:10:31 -0500 (EST) Received: (qmail 15980 invoked by uid 605); 1 Mar 2001 00:10:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15973 invoked from network); 1 Mar 2001 00:10:15 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 1 Mar 2001 00:10:15 -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 QAA02994 for ; Wed, 28 Feb 2001 16:10: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 TAA22613 for ; Wed, 28 Feb 2001 19:10:14 -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 f210AAj04165 for ; Wed, 28 Feb 2001 19:10:10 -0500 (EST) Message-Id: <200103010010.f210AAj04165@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: (off topic) list archive technology? Reply-to: sommerfeld@east.sun.com Date: Wed, 28 Feb 2001 19:10:10 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list I got a comment from an implementor that public access to the list archives could be improved. Any suggestions for which package to use? Any volunteers to host the archive? - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Feb 28 19:21: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 TAA02938 for ; Wed, 28 Feb 2001 19:21:39 -0500 (EST) Received: (qmail 18038 invoked by uid 605); 1 Mar 2001 00:21:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18030 invoked from network); 1 Mar 2001 00:21:26 -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; 1 Mar 2001 00:21:26 -0000 Received: from toad.mindrot.org (toad.mindrot.org [203.44.118.252]) by kado.mindrot.org (Postfix) with ESMTP id 59CD0900A for ; Thu, 1 Mar 2001 00:08:21 +1100 (EST) Received: from mothra.mindrot.org (mothra.mindrot.org [203.44.118.225]) by toad.mindrot.org (Postfix) with ESMTP id 575931A1DF for ; Thu, 1 Mar 2001 11:21:24 +1100 (EST) Received: by mothra.mindrot.org (Postfix, from userid 500) id 7C49D96E2A; Thu, 1 Mar 2001 11:21:23 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by mothra.mindrot.org (Postfix) with ESMTP id 7BB4D96E29 for ; Thu, 1 Mar 2001 11:21:23 +1100 (EST) Date: Thu, 1 Mar 2001 11:21:23 +1100 (EST) From: Damien Miller To: Subject: resend: symlinks in filexfer 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 Hopefully this will reach the new list intact. I tried sending it about eight times to the old list without success: How are symlinks to be handled in the filexfer draft? Whether a directory entry is a symlink may be determined by SSH_FXP_LSTAT, but I can't see any way to discover where a symlink points. SSH_FXP_REALPATH will return the target of the link, but in canonical form - thus messing up relative links. There also seems to be no way to create a link at the server end. I would propose the following new packets to add the above capabilities, but I don't know whether it would be better to include hardlinks as well. -------- #define SSH_FXP_READLINK 19 #define SSH_FXP_SYMLINK 20 The SSH_FXP_READLINK request may be used to read the target of a symbolic link. It would have a data part as follows: uint32 id string path where `id' is the request identifier and `path' specifies the path name of the symlink to be read. The server will respond with a SSH_FXP_NAME packet containing only one name and a dummy attributes value. The name in the returned packet contains the target of the link. If an error occurs, the server may respond with SSH_FXP_STATUS. -------- The SSH_FXP_SYMLINK request will create a symbolic link on the server. It is of the following format uint32 id string linkpath string targetpath where `id' is the request identifier, `linkpath' specifies the path name of the symlink to be created and 'targetpath' specifies the target of the symlink. The server shall respond with a SSH_FXP_STATUS indicating either success (SSH_FX_OK) or an error condition. -------- -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From owner-ietf-ssh@clinet.fi Wed Feb 28 20:03:24 2001 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04132 for ; Wed, 28 Feb 2001 20:03:23 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA09598 for ietf-ssh-outgoing; Thu, 1 Mar 2001 01:23:58 +0200 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id BAB09544 for ; Thu, 1 Mar 2001 01:23:18 +0200 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA28882; Wed, 28 Feb 2001 15:23: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 SAA09252; Wed, 28 Feb 2001 18:23:15 -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 f1SNNCj04094; Wed, 28 Feb 2001 18:23:12 -0500 (EST) Message-Id: <200102282323.f1SNNCj04094@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@clinet.fi, ietf-ssh@netbsd.org Subject: This list has moved. Reply-to: sommerfeld@east.sun.com Date: Wed, 28 Feb 2001 18:23:11 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk As a few of you have remarked, ietf-ssh@clinet.fi hasn't been working well lately. I've seen evidence that several fairly important messages (both from myself and from several other folks) have not made it through to the two places I'm subscribed or to the archive. Tatu Ylonen informs me that the folks he knew at clinet.fi (which he described as a "local ISP") are no longer there, so it's time to move the list. When I mentioned these difficulties in another forum, I recieved an immediate offer to host it at netbsd.org. The new list is ; it will be administered via majordomo (just like the current list). I'm currently set up as the moderator for that list. List policy: There has been substantial discussion over on the POISED list recently regarding mailing list policy, so a few words are appropriate here.. The new list is currently configured to be unmoderated and to allow open access (i.e., non-subscribers may post) since there seems to be rough consensus that subscriber-only lists discourage participation from folks (like IESG/IAB members) who may have something to contribute but don't have the time to subscribe to every WG's list. That said, there are a few (system-wide) filters in place on the netbsd.org mail server which catch certain messages and send them to the moderator instead of the list members. These include patterns to weed out common user errors (e.g., subscribe/unsubscribe requests), as well as excessively long messages (over 100000 bytes), barfmail, and words and phrases that have historically been used by spammers and mail viruses. As moderator, I'll look over all the bounces and approve messages which were bounced inappropriately -- i.e., if there's a message about using ssh for remote management of t*ner c*rtridges, I'll let it through ;-) It is my intent to encourage open contribution to this WG from any interested party. There are, to my knowledge, no filters in place which would automatically exclude posts by any WG participant or implementor. If you feel that filters are being applied inappropriately, please let me know ASAP; most likely it's an oversight or error which can be quickly corrected. Likewise, please let me know ASAP if you see other operational problems with this list. - Bill