From owner-ietf-ssh@clinet.fi Thu Jul 20 14:59:22 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29282 for ; Thu, 20 Jul 2000 14:59:21 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id VAA03245; Thu, 20 Jul 2000 21:58:50 +0300 Date: Thu, 20 Jul 2000 21:58:50 +0300 Message-Id: <200007201858.VAA03245@mail.clinet.fi> To: secsh-archive@ietf.org From: Majordomo@clinet.fi Subject: Welcome to ietf-ssh Reply-To: Majordomo@clinet.fi -- 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. #### No info available for ietf-ssh. From Majordomo-Owner@clinet.fi Thu Jul 20 15:31:07 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29281 for ; Thu, 20 Jul 2000 14:59:20 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id VAA03243; Thu, 20 Jul 2000 21:58:50 +0300 Date: Thu, 20 Jul 2000 21:58:50 +0300 Message-Id: <200007201858.VAA03243@mail.clinet.fi> To: secsh-archive@ietf.org From: Majordomo@clinet.fi Subject: Majordomo results Reply-To: Majordomo@clinet.fi -- >>>> subscribe ietf-ssh Succeeded. From owner-ietf-ssh@clinet.fi Sat Jul 22 21:33:36 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04886 for ; Sat, 22 Jul 2000 21:33:36 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA22460 for ietf-ssh-outgoing; Sun, 23 Jul 2000 02:22:08 +0300 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id CAA22455 for ; Sun, 23 Jul 2000 02:22:07 +0300 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id CAA25531; Sun, 23 Jul 2000 02:20:11 +0300 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <14714.11307.410023.751051@asgard.tky.hut.fi> Date: Sun, 23 Jul 2000 02:20:11 +0300 (EEST) To: sommerfeld@east.sun.com Cc: ietf-ssh@clinet.fi, ylo@ssh.fi Subject: secsh meeting in pittsburgh: call for agenda items. In-Reply-To: <200007201747.e6KHlfJ117017@thunk.east.sun.com> References: <87aefc23qq.fsf@snark.piermont.com> <200007201747.e6KHlfJ117017@thunk.east.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 8bit Bill Sommerfeld, on July 20. 2000, wrote: : Now would be a good time for folks to do a careful review of the four : existing drafts: : : draft-ietf-secsh-architecture-05.txt : draft-ietf-secsh-transport-07.txt : draft-ietf-secsh-userauth-07.txt : draft-ietf-secsh-connect-07.txt : : Please send comments to this list. As Markus Friedl, Niels Möller and I have already commented on this list, I will be removing the unnecessary ``length'' fields from the certificate and public key encoding. It will also be removed from the encoded signature. This is because the signatures and public keys are encoded as strings in all the messages they are used. This change will only affect the transport draft. Regards, -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Sun Jul 23 00:34:18 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03143 for ; Sun, 23 Jul 2000 00:34:18 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id FAA31173 for ietf-ssh-outgoing; Sun, 23 Jul 2000 05:31:05 +0300 Received: from texcel.net (w092.z208037077.nyc-ny.dsl.cnc.net [208.37.77.92]) by mail.clinet.fi (8.9.3/8.9.3) with SMTP id FAA31166; Sun, 23 Jul 2000 05:31:03 +0300 From: Subject: FREE Computer Support & Consulting for your Business - to remove send a blank reply Date: Sat, 22 Jul 2000 22:30:40 Message-Id: <468.393071.186231@texcel.net> Reply-To: remove@texcel.net Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Networking and Computer Solutions - TEXCEL provides Computer Solutions and Networking Services for small to mid-sized businesses. From owner-ietf-ssh@clinet.fi Sun Jul 23 19:43:57 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18149 for ; Sun, 23 Jul 2000 19:43:57 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id AAA20889 for ietf-ssh-outgoing; Mon, 24 Jul 2000 00:40:20 +0300 Received: from inner.net (avarice.inner.net [199.33.248.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id AAA20886 for ; Mon, 24 Jul 2000 00:40:17 +0300 Received: from mosquito ([216.52.8.30]) by inner.net (8.7.6/8.9.3) with ESMTP id VAA19577; Sun, 23 Jul 2000 21:36:48 GMT Message-Id: <4.2.0.58.20000723173237.0097b100@avarice.inner.net> X-Sender: rja@avarice.inner.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 23 Jul 2000 17:35:49 -0400 To: Sami Lehtinen From: RJ Atkinson Subject: Re: secsh meeting in pittsburgh: call for agenda items. Cc: ietf-ssh@clinet.fi, ylo@ssh.fi In-Reply-To: <14714.11307.410023.751051@asgard.tky.hut.fi> References: <200007201747.e6KHlfJ117017@thunk.east.sun.com> <87aefc23qq.fsf@snark.piermont.com> <200007201747.e6KHlfJ117017@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 8bit At 19:20 22/07/00 , Sami Lehtinen wrote: >As Markus Friedl, Niels Möller and I have already commented on this >list, I will be removing the unnecessary ``length'' fields from the >certificate and public key encoding. It will also be removed from the >encoded signature. This is because the signatures and public keys are >encoded as strings in all the messages they are used. > >This change will only affect the transport draft. Ought this not receive broader WG discussion before being made ? At least in theory this is an open IETF standard, rather than the private specification of SSH Communications Security... :-) Ran rja@inet.org From owner-ietf-ssh@clinet.fi Mon Jul 24 12:35:27 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15685 for ; Mon, 24 Jul 2000 12:35:26 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA16051 for ietf-ssh-outgoing; Mon, 24 Jul 2000 17:01:34 +0300 Received: from ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA16047 for ; Mon, 24 Jul 2000 17:01:33 +0300 Received: from torni.hel.fi.ssh.com (torni.hel.fi.ssh.com [10.1.0.43]) by ssh.com (8.9.3/8.9.3/SSH-1.16) with ESMTP id RAA17276 for ; Mon, 24 Jul 2000 17:01:33 +0300 (EEST) Received: (from sshlist@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.17) id RAA23039 for ietf-ssh@clinet.fi; Mon, 24 Jul 2000 17:01:33 +0300 (EET DST) Received: (from ylo@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.17) id AAA16672; Mon, 24 Jul 2000 00:40:13 +0300 (EET DST) Date: Mon, 24 Jul 2000 00:40:13 +0300 (EET DST) Message-Id: <200007232140.AAA16672@torni.hel.fi.ssh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tatu Ylonen To: sommerfeld@east.sun.com Cc: Sami Lehtinen , ietf-ssh@clinet.fi Subject: secsh meeting in pittsburgh: call for agenda items. In-Reply-To: <14714.11307.410023.751051@asgard.tky.hut.fi> References: <87aefc23qq.fsf@snark.piermont.com> <200007201747.e6KHlfJ117017@thunk.east.sun.com> <14714.11307.410023.751051@asgard.tky.hut.fi> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security, Finland Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit I'm writing a draft on Kerberos V5 support in SSH2, and would like to have a short presentation/discussion on that at the meeting. The general idea is very simple: Two new authentication methods, "kerberos" and "kerberos-tgt", plus allowing the user name passed in the authentication protocol to be in the form "@", in addition to just user name. The "kerberos" method passes a "host" ticket, whereas the "kerberos-tgt" passes a ticket granting ticket. The only method-specific field in the authentication packets is a string containing the ticket. If "user@realm" syntax is used for the user name, it should be mapped to a local name. The "password" method should also check for kerberos passwords. If successfully authenticating using either "kerberos-tgt" or "password" (using kerberos passwords), the ticket granting ticket should be stored in the user's credentials cache (as if kinit had been done for the user). I should have the draft ready in a couple of days (or maybe even later today), and I will send it to this list before the IETF. Tatu -- SSH Communications Security http://www.ssh.com/ SSH IPSEC Toolkit http://www.ipsec.com/ SSH(R) Secure Shell(TM) http://www.ssh.com/ssh From owner-ietf-ssh@clinet.fi Mon Jul 24 13:07:53 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26273 for ; Mon, 24 Jul 2000 13:07:52 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA21293 for ietf-ssh-outgoing; Mon, 24 Jul 2000 17:49:46 +0300 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA21290 for ; Mon, 24 Jul 2000 17:49:45 +0300 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id RAA27000; Mon, 24 Jul 2000 17:47:48 +0300 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14716.22292.55071.340992@asgard.tky.hut.fi> Date: Mon, 24 Jul 2000 17:47:48 +0300 (EEST) To: Tatu Ylonen Cc: RJ Atkinson , ietf-ssh@clinet.fi Subject: Re: secsh meeting in pittsburgh: call for agenda items. In-Reply-To: <200007232156.AAA18723@torni.hel.fi.ssh.com> References: <200007201747.e6KHlfJ117017@thunk.east.sun.com> <87aefc23qq.fsf@snark.piermont.com> <14714.11307.410023.751051@asgard.tky.hut.fi> <4.2.0.58.20000723173237.0097b100@avarice.inner.net> <200007232156.AAA18723@torni.hel.fi.ssh.com> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Tatu Ylonen, on July 24. 2000, wrote: [length field in signatures and certificate/public key encoding] : > Ought this not receive broader WG discussion before being made ? : > : > At least in theory this is an open IETF standard, rather than : > the private specification of SSH Communications Security... :-) : : Markus is working on OpenSSH, and Niels is doing the GNU LSH : implementation. Neither of them works for SSH Communications : Security. In any case, this *is* the secsh WG mailing list... :-) Also, the change has already been discussed here at length. If you (RJ) have differing views, please post them to the list. -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Mon Jul 24 13:08:43 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26571 for ; Mon, 24 Jul 2000 13:08:42 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA21009 for ietf-ssh-outgoing; Mon, 24 Jul 2000 17:45:41 +0300 Received: from inner.net (avarice.inner.net [199.33.248.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA21004 for ; Mon, 24 Jul 2000 17:45:37 +0300 Received: from mosquito ([216.52.8.30]) by inner.net (8.7.6/8.9.3) with ESMTP id OAA20144; Mon, 24 Jul 2000 14:42:02 GMT Message-Id: <4.2.0.58.20000724103533.0096f550@avarice.inner.net> X-Sender: rja@avarice.inner.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 24 Jul 2000 10:41:29 -0400 To: RJ Atkinson From: RJ Atkinson Subject: Re: secsh meeting in pittsburgh: call for agenda items. Cc: Sami Lehtinen , ietf-ssh@clinet.fi, ylo@ssh.fi In-Reply-To: <4.2.0.58.20000723173237.0097b100@avarice.inner.net> References: <14714.11307.410023.751051@asgard.tky.hut.fi> <200007201747.e6KHlfJ117017@thunk.east.sun.com> <87aefc23qq.fsf@snark.piermont.com> <200007201747.e6KHlfJ117017@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 8bit >At 19:20 22/07/00 , Sami Lehtinen wrote: > > >As Markus Friedl, Niels Möller and I have already commented on this > >list, I will be removing the unnecessary ``length'' fields from the > >certificate and public key encoding. It will also be removed from the > >encoded signature. This is because the signatures and public keys are > >encoded as strings in all the messages they are used. > > > >This change will only affect the transport draft. I'll try again and maybe be more clear. Various folks (including my employer and its myriad customers) have already SHIPPED and DEPLOYED SSHv2, therefore changing the protocol on the wire is highly undesirable at this point in time. If we are merely sending data that isn't needed, but is not actually incorrect or harmful, we probably ought not be changing the spec (and thereby removing what interoperability exists at present). There are more than 3 implementers at this point, so ALL changes ought to go through a normal IETF "propose to the mailing list", "list discusses proposal", then "document is changed if and only if there is clear consensus to make the change" process. Generally speaking, the goal at this point ought to be to AVOID changing the protocol, though updating documents to reflect the as-built, as-shipped, as-deployed protocol would obviously be useful and a good thing. If there is a specific flaw in the currently specified protocol, then that ought to be outlined before the WG (as a whole, not one or two individuals) so the group collective can figure out how to proceed. All IMHO. Ran rja@inet.org From owner-ietf-ssh@clinet.fi Mon Jul 24 13:16:52 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28895 for ; Mon, 24 Jul 2000 13:16:51 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA22626 for ietf-ssh-outgoing; Mon, 24 Jul 2000 18:06:12 +0300 Received: from inner.net (avarice.inner.net [199.33.248.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA22621 for ; Mon, 24 Jul 2000 18:06:10 +0300 Received: from mosquito ([216.52.8.30]) by inner.net (8.7.6/8.9.3) with ESMTP id PAA20220; Mon, 24 Jul 2000 15:02:36 GMT Message-Id: <4.2.0.58.20000724105942.00973bf0@avarice.inner.net> X-Sender: rja@avarice.inner.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 24 Jul 2000 11:02:01 -0400 To: Sami Lehtinen From: RJ Atkinson Subject: Re: secsh meeting in pittsburgh: call for agenda items. Cc: ietf-ssh@clinet.fi In-Reply-To: <14716.22292.55071.340992@asgard.tky.hut.fi> References: <200007232156.AAA18723@torni.hel.fi.ssh.com> <200007201747.e6KHlfJ117017@thunk.east.sun.com> <87aefc23qq.fsf@snark.piermont.com> <14714.11307.410023.751051@asgard.tky.hut.fi> <4.2.0.58.20000723173237.0097b100@avarice.inner.net> <200007232156.AAA18723@torni.hel.fi.ssh.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ssh@clinet.fi Precedence: bulk At 10:47 24/07/00 , Sami Lehtinen wrote: >Also, the change has already been discussed here at length. If you >(RJ) have differing views, please post them to the list. I'll assume that those emails didn't reach me due to some SMTP weirdness. Any road, I haven't seen them. I've forgotten where the list archive lives, maybe someone can throw me a clue privately ? :-) I do object to changing the protocol on the wire because it adversely impacts what interoperability exists at present. I have commit access to an SSHv2 implementation that has already shipped and is in daily (hourly ?) use by customers. Ran rja@inet.org From owner-ietf-ssh@clinet.fi Mon Jul 24 13:34:30 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04904 for ; Mon, 24 Jul 2000 13:34:29 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA23894 for ietf-ssh-outgoing; Mon, 24 Jul 2000 18:22:29 +0300 Received: from inner.net (avarice.inner.net [199.33.248.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA23891 for ; Mon, 24 Jul 2000 18:22:27 +0300 Received: from mosquito ([216.52.8.30]) by inner.net (8.7.6/8.9.3) with ESMTP id PAA20258; Mon, 24 Jul 2000 15:18:57 GMT Message-Id: <4.2.0.58.20000724111450.009e7c30@avarice.inner.net> X-Sender: rja@avarice.inner.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 24 Jul 2000 11:18:25 -0400 To: Sami Lehtinen From: RJ Atkinson Subject: Re: secsh meeting in pittsburgh: call for agenda items. Cc: ietf-ssh@clinet.fi In-Reply-To: <14716.22962.521316.19481@asgard.tky.hut.fi> References: <4.2.0.58.20000724103533.0096f550@avarice.inner.net> <14714.11307.410023.751051@asgard.tky.hut.fi> <200007201747.e6KHlfJ117017@thunk.east.sun.com> <87aefc23qq.fsf@snark.piermont.com> <4.2.0.58.20000724103533.0096f550@avarice.inner.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ssh@clinet.fi Precedence: bulk At 10:58 24/07/00 , Sami Lehtinen wrote: >Okay, let's see. LSH and OpenSSH and our SSH implementation (from >v.2.2.0) follow the more "logical" style, ie. the length field is >omitted. > >That means, if the draft isn't changed, atleast 3 implementors will >have to change their implementation. I'll rescind the objection if this is merely changing the document to reflect the majority of the running code (as the above seems to indicate). This was not clear in earlier comments that I have seen. Given that I'm not receiving all of the notes from the list and my other correspondents aren't indicating that they are having trouble reaching me, maybe we could migrate the list over to ietf.org ? This would also have the side-effect of making the list auto-archived with the archive accessible via web from www.ietf.org. Reactions ? Ran rja@inet.org From owner-ietf-ssh@clinet.fi Mon Jul 24 13:53:54 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10533 for ; Mon, 24 Jul 2000 13:53:53 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA25141 for ietf-ssh-outgoing; Mon, 24 Jul 2000 18:39:24 +0300 Received: from naughty.monkey.org (IDENT:smtp@naughty.monkey.org [63.77.239.20]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA25136 for ; Mon, 24 Jul 2000 18:39:22 +0300 Received: by naughty.monkey.org (Postfix, from userid 1001) id C5633108686; Mon, 24 Jul 2000 11:39:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by naughty.monkey.org (Postfix) with ESMTP id C2300107740; Mon, 24 Jul 2000 11:39:20 -0400 (EDT) Date: Mon, 24 Jul 2000 11:39:20 -0400 (EDT) From: Dug Song To: Tatu Ylonen Cc: sommerfeld@east.sun.com, Sami Lehtinen , ietf-ssh@clinet.fi Subject: Re: secsh meeting in pittsburgh: call for agenda items. In-Reply-To: <200007232140.AAA16672@torni.hel.fi.ssh.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Mon, 24 Jul 2000, Tatu Ylonen wrote: > I'm writing a draft on Kerberos V5 support in SSH2, and would like to > have a short presentation/discussion on that at the meeting. quick question - has any consideration been given to GSS as an authentication mechanism for SSH2? this is how krb5 support is actually implemented in FTP (via SASL), RPC (via RPCSEC_GSS), etc. the Globus folks have a GSS patch for ssh-1.2.27, if you're interested in how this might work: ftp://ftp.ncsa.uiuc.edu/aces/gssapi-ssh/ -d. --- http://www.monkey.org/~dugsong/ From owner-ietf-ssh@clinet.fi Mon Jul 24 14:56:09 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28609 for ; Mon, 24 Jul 2000 14:56:08 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA28899 for ietf-ssh-outgoing; Mon, 24 Jul 2000 19:26:14 +0300 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 TAA28887 for ; Mon, 24 Jul 2000 19:26:13 +0300 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21537; Mon, 24 Jul 2000 09:25:55 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA18003; Mon, 24 Jul 2000 12:23:07 -0400 (EDT) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6OGMjS100462; Mon, 24 Jul 2000 12:22:45 -0400 (EDT) Message-Id: <200007241622.e6OGMjS100462@thunk.east.sun.com> From: Bill Sommerfeld To: Sami Lehtinen cc: "Richard E. Silverman" , SECSH Discussion List Subject: Re: "ssh-rsa" public-key type In-reply-to: Your message of "Sat, 17 Jun 2000 02:36:45 +0300." <14666.47629.645249.255747@asgard.tky.hut.fi> Reply-to: sommerfeld@east.sun.com Date: Mon, 24 Jul 2000 12:22:45 -0400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > "ssh-rsa" is supposed to be added to the draft as soon as the patent > expires. There's no particular reason to do this; certainly the patent issues have not stopped other wg's from publishing specs for how to use RSA encryption/signatures. As far as I'm concerned, the time to add this to the draft is right now. Even if you're concerned about patent issues, given the built-in time delays in the last-calls, IESG queue, and RFC Editor queue, etc., etc. if we were to start the WG last-call on the documents right now, there's no way they'd be published as RFC's until after the patent expiration. If the final spec differs from existing practice, we may need to change the name of the "ssh-rsa" to avoid interoperability problems with existing implementations. Other opinions? - Bill From owner-ietf-ssh@clinet.fi Mon Jul 24 17:16:51 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09612 for ; Mon, 24 Jul 2000 17:16:50 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id VAA07213 for ietf-ssh-outgoing; Mon, 24 Jul 2000 21:51:35 +0300 Received: from ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id VAA07210 for ; Mon, 24 Jul 2000 21:51:34 +0300 Received: from torni.hel.fi.ssh.com (torni.hel.fi.ssh.com [10.1.0.43]) by ssh.com (8.9.3/8.9.3/SSH-1.16) with ESMTP id VAA27419 for ; Mon, 24 Jul 2000 21:51:34 +0300 (EEST) Received: (from sshlist@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.17) id VAA28582 for ietf-ssh@clinet.fi; Mon, 24 Jul 2000 21:51:34 +0300 (EET DST) Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id RAA27009; Mon, 24 Jul 2000 17:58:58 +0300 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14716.22962.521316.19481@asgard.tky.hut.fi> Date: Mon, 24 Jul 2000 17:58:58 +0300 (EEST) To: RJ Atkinson Cc: ietf-ssh@clinet.fi, ylo@ssh.com Subject: Re: secsh meeting in pittsburgh: call for agenda items. In-Reply-To: <4.2.0.58.20000724103533.0096f550@avarice.inner.net> References: <14714.11307.410023.751051@asgard.tky.hut.fi> <200007201747.e6KHlfJ117017@thunk.east.sun.com> <87aefc23qq.fsf@snark.piermont.com> <4.2.0.58.20000724103533.0096f550@avarice.inner.net> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit RJ Atkinson, on July 24. 2000, wrote: : Various folks (including my employer and its myriad : customers) have already SHIPPED and DEPLOYED SSHv2, therefore : changing the protocol on the wire is highly undesirable at : this point in time. If we are merely sending data that isn't : needed, but is not actually incorrect or harmful, we probably : ought not be changing the spec (and thereby removing what : interoperability exists at present). : : There are more than 3 implementers at this point, : so ALL changes ought to go through a normal IETF "propose to : the mailing list", "list discusses proposal", then "document : is changed if and only if there is clear consensus to make : the change" process. These have already been established, though I don't know whether you have access to those messages. The change hasn't yet been made, as the responsible person for this change (=me) was in vacation. : Generally speaking, the goal at this point ought to be : to AVOID changing the protocol, though updating documents to : reflect the as-built, as-shipped, as-deployed protocol would : obviously be useful and a good thing. If there is a specific : flaw in the currently specified protocol, then that ought to : be outlined before the WG (as a whole, not one or two individuals) : so the group collective can figure out how to proceed. Okay, let's see. LSH and OpenSSH and our SSH implementation (from v.2.2.0) follow the more "logical" style, ie. the length field is omitted. That means, if the draft isn't changed, atleast 3 implementors will have to change their implementation. -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Mon Jul 24 17:20:40 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10510 for ; Mon, 24 Jul 2000 17:20:40 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id VAA07886 for ietf-ssh-outgoing; Mon, 24 Jul 2000 21:58:01 +0300 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 VAA07881 for ; Mon, 24 Jul 2000 21:57:59 +0300 Received: from citi.umich.edu (ssh-mapper.citi.umich.edu [141.211.92.147]) by citi.umich.edu (Postfix) with ESMTP id B1DE3207C1; Mon, 24 Jul 2000 14:57:52 -0400 (EDT) Subject: Re: secsh meeting in pittsburgh: call for agenda items. From: Niels Provos In-Reply-To: Bill Sommerfeld, Thu, 20 Jul 2000 13:47:41 EDT To: sommerfeld@east.sun.com Cc: ietf-ssh@clinet.fi Date: Mon, 24 Jul 2000 14:57:52 -0400 Message-Id: <20000724185752.B1DE3207C1@citi.umich.edu> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk In message <200007201747.e6KHlfJ117017@thunk.east.sun.com>, Bill Sommerfeld wri tes: >We need an agenda for the meeting, so I'll shortly be going through >back traffic to this mailing list looking for any open issues/problems Markus Friedl, Bill Simpson and I authored a draft on "Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol" It is available as draft-provos-secsh-dh-group-exchange-00.txt, and we would like the working group to consider it. Regards, Niels Provos. From owner-ietf-ssh@clinet.fi Mon Jul 24 17:26:35 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12122 for ; Mon, 24 Jul 2000 17:26:34 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id VAA07377 for ietf-ssh-outgoing; Mon, 24 Jul 2000 21:52:24 +0300 Received: from ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id VAA07371 for ; Mon, 24 Jul 2000 21:52:23 +0300 Received: from torni.hel.fi.ssh.com (torni.hel.fi.ssh.com [10.1.0.43]) by ssh.com (8.9.3/8.9.3/SSH-1.16) with ESMTP id VAA27428 for ; Mon, 24 Jul 2000 21:52:23 +0300 (EEST) Received: (from sshlist@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.17) id VAA28463 for ietf-ssh@clinet.fi; Mon, 24 Jul 2000 21:52:23 +0300 (EET DST) Received: from anl.gov (apollo.ctd.anl.gov [146.137.96.39]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA24787; Mon, 24 Jul 2000 13:07:28 -0500 (CDT) Message-ID: <397C85D1.EA497FF3@anl.gov> Date: Mon, 24 Jul 2000 13:07:13 -0500 From: "Douglas E. Engert" Reply-To: deengert@anl.gov Organization: Argonne National Laboratory X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tatu Ylonen CC: sommerfeld@east.sun.com, Sami Lehtinen , ietf-ssh@clinet.fi Subject: Re: secsh meeting in pittsburgh: call for agenda items. References: <87aefc23qq.fsf@snark.piermont.com> <200007201747.e6KHlfJ117017@thunk.east.sun.com> <14714.11307.410023.751051@asgard.tky.hut.fi> <200007232140.AAA16672@torni.hel.fi.ssh.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Tatu Ylonen wrote: > > I'm writing a draft on Kerberos V5 support in SSH2, and would like to > have a short presentation/discussion on that at the meeting. Have you also considered a GSSAPI authenticaiton, rather then Kerberos directly? (We talked breifly at the RSA conference last spring on this.) Would you also like to say a few words at the new Kerberos WG on Wednesday 1530? Let me know if you would. > > The general idea is very simple: > > Two new authentication methods, "kerberos" and "kerberos-tgt", plus > allowing the user name passed in the authentication protocol to be in > the form "@", in addition to just user name. > > The "kerberos" method passes a "host" ticket, whereas the > "kerberos-tgt" passes a ticket granting ticket. The only > method-specific field in the authentication packets is a string > containing the ticket. > > If "user@realm" syntax is used for the user name, it should be mapped > to a local name. > > The "password" method should also check for kerberos passwords. > > If successfully authenticating using either "kerberos-tgt" or > "password" (using kerberos passwords), the ticket granting ticket > should be stored in the user's credentials cache (as if kinit had been > done for the user). > > I should have the draft ready in a couple of days (or maybe even later > today), and I will send it to this list before the IETF. > > Tatu > > -- > SSH Communications Security http://www.ssh.com/ > SSH IPSEC Toolkit http://www.ipsec.com/ > SSH(R) Secure Shell(TM) http://www.ssh.com/ssh > > Jeffrey Altman * Sr.Software Designer > The Kermit Project * Columbia University > 612 West 115th St * New York, NY * 10025 * USA > http://www.kermit-project.org/ * kermit-support@kermit-project.org -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From owner-ietf-ssh@clinet.fi Mon Jul 24 18:12:13 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24610 for ; Mon, 24 Jul 2000 18:12:10 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA11797 for ietf-ssh-outgoing; Mon, 24 Jul 2000 23:02:40 +0300 Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA11794 for ; Mon, 24 Jul 2000 23:02:39 +0300 Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA13041; Mon, 24 Jul 2000 13:02:36 -0700 (PDT) Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA13006 for ; Mon, 24 Jul 2000 13:02:35 -0700 (PDT) Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by qualcomm.com with ESMTP id NAA08170 for ; Mon, 24 Jul 2000 13:03:09 -0700 (PDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id VAA07886 for ietf-ssh-outgoing; Mon, 24 Jul 2000 21:58:01 +0300 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 VAA07881 for ; Mon, 24 Jul 2000 21:57:59 +0300 Received: from citi.umich.edu (ssh-mapper.citi.umich.edu [141.211.92.147]) by citi.umich.edu (Postfix) with ESMTP id B1DE3207C1; Mon, 24 Jul 2000 14:57:52 -0400 (EDT) Subject: Re: secsh meeting in pittsburgh: call for agenda items. From: Niels Provos In-Reply-To: Bill Sommerfeld, Thu, 20 Jul 2000 13:47:41 EDT To: sommerfeld@east.sun.com Cc: ietf-ssh@clinet.fi Date: Mon, 24 Jul 2000 14:57:52 -0400 Message-Id: <20000724185752.B1DE3207C1@citi.umich.edu> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk In message <200007201747.e6KHlfJ117017@thunk.east.sun.com>, Bill Sommerfeld wri tes: >We need an agenda for the meeting, so I'll shortly be going through >back traffic to this mailing list looking for any open issues/problems Markus Friedl, Bill Simpson and I authored a draft on "Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol" It is available as draft-provos-secsh-dh-group-exchange-00.txt, and we would like the working group to consider it. Regards, Niels Provos. From owner-ietf-ssh@clinet.fi Mon Jul 24 20:45:15 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24361 for ; Mon, 24 Jul 2000 20:45:14 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA19327 for ietf-ssh-outgoing; Tue, 25 Jul 2000 01:36:21 +0300 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 BAA19324 for ; Tue, 25 Jul 2000 01:36:19 +0300 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA23324 for ; Mon, 24 Jul 2000 15:36:17 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA23719 for ; Mon, 24 Jul 2000 18:36:16 -0400 (EDT) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6OMZsS100807 for ; Mon, 24 Jul 2000 18:35:54 -0400 (EDT) Message-Id: <200007242235.e6OMZsS100807@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@clinet.fi Subject: multiple implementations.. In-reply-to: Your message of "Mon, 24 Jul 2000 10:41:29 EDT." <4.2.0.58.20000724103533.0096f550@avarice.inner.net> Reply-to: sommerfeld@east.sun.com Date: Mon, 24 Jul 2000 18:35:54 -0400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk {working group chair hat on}: while this isn't the case for the change which sparked this (there appears to be consensus that the proposed change to delete the duplicate length field is appropriate), I'll underline what Ran just said: There are more than 3 implementers at this point, so ALL changes ought to go through a normal IETF "propose to the mailing list", "list discusses proposal", then "document is changed if and only if there is clear consensus to make the change" process. I am personally aware of several other sshv2 implementations besides the 3 everyone knows about (SSH, Inc, LSH, and openssh). I'm sure there are others; it would be useful to hear from other SSHv2 protocol implementors if they have something to say.. - Bill From owner-ietf-ssh@clinet.fi Mon Jul 24 20:46:26 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24754 for ; Mon, 24 Jul 2000 20:46:25 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA19417 for ietf-ssh-outgoing; Tue, 25 Jul 2000 01:38:50 +0300 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 BAA19414 for ; Tue, 25 Jul 2000 01:38:49 +0300 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA24347; Mon, 24 Jul 2000 15:38:41 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA24120; Mon, 24 Jul 2000 18:38:40 -0400 (EDT) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6OMcIS100825; Mon, 24 Jul 2000 18:38:18 -0400 (EDT) Message-Id: <200007242238.e6OMcIS100825@thunk.east.sun.com> From: Bill Sommerfeld To: Tatu Ylonen cc: sommerfeld@east.sun.com, Sami Lehtinen , ietf-ssh@clinet.fi Subject: Re: secsh meeting in pittsburgh: call for agenda items. In-reply-to: Your message of "Mon, 24 Jul 2000 00:40:13 +0300." <200007232140.AAA16672@torni.hel.fi.ssh.com> Reply-to: sommerfeld@east.sun.com Date: Mon, 24 Jul 2000 18:38:18 -0400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > I should have the draft ready in a couple of days (or maybe even later > today), and I will send it to this list before the IETF. Since we're already past the internet-drafts deadline for this meeting, there's no need to go to extreme lengths to rush this out the door before the pittsburgh meeting.. - Bill From owner-ietf-ssh@clinet.fi Tue Jul 25 01:15:01 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13649 for ; Tue, 25 Jul 2000 01:15:01 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id GAA30914 for ietf-ssh-outgoing; Tue, 25 Jul 2000 06:13:24 +0300 Received: from taka.swcp.com (taka.swcp.com [198.59.115.12]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id GAA30910 for ; Tue, 25 Jul 2000 06:13:22 +0300 Received: from viper2 (dpm4-04.swcp.com [204.134.5.197]) by taka.swcp.com (8.10.0.Beta12/8.10.0.Beta12) with SMTP id e6P3J7H06950 for ; Mon, 24 Jul 2000 21:19:07 -0600 (MDT) Message-ID: <000401bff5e8$a4261440$0201a8c0@vandyke.com> From: "Jeff P. Van Dyke" To: References: <200007201747.e6KHlfJ117017@thunk.east.sun.com> Subject: Re: secsh meeting in pittsburgh: call for agenda items. Date: Mon, 24 Jul 2000 21:29:58 -0600 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.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Bill Sommerfeld, on July 20. 2000, wrote: > Now would be a good time for folks to do a careful review of the four > existing drafts: > > draft-ietf-secsh-architecture-05.txt > draft-ietf-secsh-transport-07.txt > draft-ietf-secsh-userauth-07.txt > draft-ietf-secsh-connect-07.txt draft-ietf-secsh-connect-07.txt currently includes a reference to SSH-AGENT: 4.4. Authentication Agent Forwarding It is RECOMMENDED that authentication agent forwarding is allowed even when either or both parties do not support the SSH authentication agent protocol [SSH-AGENT]. Does this document exist? Is so, where can I download a copy? If not, what are the current plans to address this? Thank you. Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Tue Jul 25 01:59:59 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08158 for ; Tue, 25 Jul 2000 01:59:59 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id GAA32303 for ietf-ssh-outgoing; Tue, 25 Jul 2000 06:51:44 +0300 Received: from taka.swcp.com (taka.swcp.com [198.59.115.12]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id GAA32300 for ; Tue, 25 Jul 2000 06:51:43 +0300 Received: from viper2 (dpm4-04.swcp.com [204.134.5.197]) by taka.swcp.com (8.10.0.Beta12/8.10.0.Beta12) with SMTP id e6P3vSH13234 for ; Mon, 24 Jul 2000 21:57:28 -0600 (MDT) Message-ID: <009001bff5ed$ff93bdf0$0201a8c0@vandyke.com> From: "Jeff P. Van Dyke" To: References: <200007241622.e6OGMjS100462@thunk.east.sun.com> Subject: Re: "ssh-rsa" public-key type Date: Mon, 24 Jul 2000 22:08:19 -0600 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.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit > > "ssh-rsa" is supposed to be added to the draft as soon as the patent > > expires. > > There's no particular reason to do this; certainly the patent issues > have not stopped other wg's from publishing specs for how to use RSA > encryption/signatures. > > As far as I'm concerned, the time to add this to the draft is right > now. > > Even if you're concerned about patent issues, given the built-in time > delays in the last-calls, IESG queue, and RFC Editor queue, etc., etc. > if we were to start the WG last-call on the documents right now, > there's no way they'd be published as RFC's until after the patent > expiration. > > If the final spec differs from existing practice, we may need to > change the name of the "ssh-rsa" to avoid interoperability problems > with existing implementations. > > Other opinions? I would like to see "ssh-rsa" added to the next revision of the draft. Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Tue Jul 25 05:55:35 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13928 for ; Tue, 25 Jul 2000 05:55:34 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id IAA04987 for ietf-ssh-outgoing; Tue, 25 Jul 2000 08:23:53 +0300 Received: from nimbus.anzio.com (IDENT:ras@nimbus.anzio.com [204.201.253.34]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id IAA04981 for ; Tue, 25 Jul 2000 08:23:51 +0300 Received: from localhost (ras@localhost) by nimbus.anzio.com (8.8.7/8.8.7) with ESMTP id WAA01562 for ; Mon, 24 Jul 2000 22:22:06 -0700 Date: Mon, 24 Jul 2000 22:22:05 -0700 (PDT) From: Bob Rasmussen To: ietf-ssh@clinet.fi Subject: Getting started with SSH Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Greetings, Since I'm about to dive headlong into SSH, I wonder if some of you folks could answer a couple of basic questions: 1. Is the SSH protocol 1 published anywhere, online or onpaper? 2. Where is information about this meeting in Pittsburg? 3. Would anyone care to summarize the status of trademark, patent, copyright, etc. issues re. version 1; version 2? Thanks in advance. -- Regards, ....Bob Rasmussen, President, Rasmussen Software, Inc. personal e-mail: ras@anzio.com company e-mail: rsi@anzio.com voice: (US) 503-624-0360 (9:00-6:00 Pacific Time) fax: (US) 503-624-0760 web: http://www.anzio.com From owner-ietf-ssh@clinet.fi Tue Jul 25 13:46:22 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10221 for ; Tue, 25 Jul 2000 13:46:21 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA13109 for ietf-ssh-outgoing; Tue, 25 Jul 2000 18:19:41 +0300 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 SAA13104 for ; Tue, 25 Jul 2000 18:19:36 +0300 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA12184 for ; Tue, 25 Jul 2000 08:19:25 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA13453; Tue, 25 Jul 2000 11:19:21 -0400 (EDT) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6PFIxS101060; Tue, 25 Jul 2000 11:18:59 -0400 (EDT) Message-Id: <200007251518.e6PFIxS101060@thunk.east.sun.com> From: Bill Sommerfeld To: "Jeff P. Van Dyke" cc: ietf-ssh@clinet.fi Subject: authentication agent forwarding. In-reply-to: Your message of "Mon, 24 Jul 2000 21:29:58 MDT." <000401bff5e8$a4261440$0201a8c0@vandyke.com> Reply-to: sommerfeld@east.sun.com Date: Tue, 25 Jul 2000 11:18:58 -0400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > draft-ietf-secsh-connect-07.txt currently includes a reference to > SSH-AGENT: > > 4.4. Authentication Agent Forwarding > > It is RECOMMENDED that authentication agent forwarding is allowed even > when either or both parties do not support the SSH authentication agent > protocol [SSH-AGENT]. Good catch. There's also a reference to agent forwarding in the architecture draft. From a process standpoint, we cannot have unresolved external references in the document.. this reference needs to be resolved, or the refererences removed from the documents, before they can be advanced into the standards track. My personal opinion is that there should be a fifth draft to describe the SSHv2 authentication agent forwarding protocol, plus external references to the SSHv1 agent protocol. > If not, what are the current plans to address this? The document editors will need to answer this. - Bill From owner-ietf-ssh@clinet.fi Tue Jul 25 17:32:14 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13583 for ; Tue, 25 Jul 2000 17:32:13 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA26193 for ietf-ssh-outgoing; Tue, 25 Jul 2000 22:08:11 +0300 Received: from mail.imep.ru (mail.imep.ru [195.222.181.67]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id WAA26190 for ; Tue, 25 Jul 2000 22:08:09 +0300 Received: from dial-up-user6.imep.ru ([195.222.181.6] helo=8r37d5ek) by mail.imep.ru with smtp (Exim 3.03 #2) id 13GyqS-000FOG-00 for ietf-ssh@clinet.fi; Tue, 25 Jul 2000 11:09:40 +0400 From: "baza@hello.to" To: ietf-ssh@clinet.fi Subject: BUSINESS PRESENTATION (don't delete) X-Mailer: baza@hey.to Reply-To: baza@hello.to Date: Tue, 25 Jul 2000 11:10:32 +0300 Mime-Version: 1.0 Content-Type: text/plain; charset=Windows-1251 Message-Id: Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Óâàæàåìûå ãîñïîäà, ïðåäëàãàåì Âàøåìó âíèìàíèþ Áàçû Äàííûõ â ò.÷. - ÃÈÁÄÄ -2000 (àâòîâëàäåëüöû,òðàíñïîðò â óãîíå); - ÎÂÈÐ; - Ôèçè÷åñêèå ëèöà; - Ïîõèùåííûå ïàñïîðòà; - Áàíêè ÐÔ; - ×ÀÑÒÍÀß ÑÎÁÑÒÂÅÍÍÎÑÒÜ ã. Ìîñêâû (êâàðòèðîñúåìùèêè, èñòîðè êâàðòèð); - ÌÎÑÊÎÂÑÊÀß ÍÅÄÂÈÆÈÌÎÑÒÜ (ñîáñòâåííèêè è àðåíäàòîðû íåæèëûõ ïîìåùåíèé); - Ýëåêòðîííûå àäðåñà êîììåð÷åñêèõ ôèðì Ìîñêâû; - Òåëåôîííûé Ñïðàâî÷íèê Ìîñêâû (â ò.÷. ÑÎÒÎÂÛÅ); - Ðåãèñòðàöèîííà Ïàëàòà (Ìîñêâà, îáëàñòü, äð.ãîðîäà; - Ïðîèçâîäèòåëè òîâàðîâ è óñëóã Ðîññèè è ÑÍÃ... Best regards http://www.geocities.com/b2000_bg/index.html From owner-ietf-ssh@clinet.fi Tue Jul 25 18:09:23 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23849 for ; Tue, 25 Jul 2000 18:09:23 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA27622 for ietf-ssh-outgoing; Tue, 25 Jul 2000 22:36:38 +0300 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id WAA27619 for ; Tue, 25 Jul 2000 22:36:34 +0300 Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id OAA25809; Tue, 25 Jul 2000 14:36:19 -0500 (CDT) Message-Id: <200007251936.OAA25809@gungnir.fnal.gov> To: Tatu Ylonen Cc: sommerfeld@east.sun.com, Sami Lehtinen , ietf-ssh@clinet.fi From: "Matt Crawford" Subject: Re: secsh meeting in pittsburgh: call for agenda items. In-reply-to: Your message of Mon, 24 Jul 2000 00:40:13 +0300. <200007232140.AAA16672@torni.hel.fi.ssh.com> Date: Tue, 25 Jul 2000 14:36:18 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > The "kerberos" method passes a "host" ticket, whereas the > "kerberos-tgt" passes a ticket granting ticket. The only > method-specific field in the authentication packets is a string > containing the ticket. OK, I'm stumped. How does the ssh server check the validity of a TGT? By getting a host ticket for itself from the KDC? Then it must have a sverice principal. And if it has that, why not just require the client to get the host-specific service ticket first? It already had to do a TGS exchange with the KDC in order to "forward" the TGT. It looks like you're encouraging the client to pass its credential to a server it can't have authenticated (by Kerberos) yet. > If successfully authenticating using either "kerberos-tgt" or > "password" (using kerberos passwords), the ticket granting ticket > should be stored in the user's credentials cache (as if kinit had been > done for the user). Can't you provide a way for the client to *optionally* forward its TGT after mutual client-server authentication has been done? Matt Crawford (Now I'll have to look at the ietf-ssh archive to see if this has already been answered.) From owner-ietf-ssh@clinet.fi Tue Jul 25 19:19:18 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18122 for ; Tue, 25 Jul 2000 19:19:17 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA31746 for ietf-ssh-outgoing; Tue, 25 Jul 2000 23:50:33 +0300 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 XAA31734 for ; Tue, 25 Jul 2000 23:50:31 +0300 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA29912 for ; Tue, 25 Jul 2000 13:50:29 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA01027 for ; Tue, 25 Jul 2000 16:50:28 -0400 (EDT) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6PKo6S103405 for ; Tue, 25 Jul 2000 16:50:06 -0400 (EDT) Message-Id: <200007252050.e6PKo6S103405@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@clinet.fi Subject: we now have a mail archive. Reply-to: sommerfeld@east.sun.com Date: Tue, 25 Jul 2000 16:50:06 -0400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk This WG has been without a mailing list archive for a while; this has now been corrected. Posts to this list sent on or after 21 July 2000 are now archived in files within: ftp://ftp.ietf.org/ietf-mail-archive/secsh/ If anyone has been privately archiving the list, I'd appreciate it if you can make your archive available so that we can fill in the history of the group. Thanks. - Bill From owner-ietf-ssh@clinet.fi Tue Jul 25 21:17:43 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16663 for ; Tue, 25 Jul 2000 21:17:42 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA05439 for ietf-ssh-outgoing; Wed, 26 Jul 2000 01:54:33 +0300 Received: from folly.informatik.uni-erlangen.de (muedi6-212-144-216-028.arcor-ip.net [212.144.216.28]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id BAA05432 for ; Wed, 26 Jul 2000 01:54:20 +0300 Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 0283314C9; Wed, 26 Jul 2000 00:49:58 +0200 (CEST) Date: Wed, 26 Jul 2000 00:49:58 +0200 From: Markus Friedl To: RJ Atkinson Cc: Sami Lehtinen , ietf-ssh@clinet.fi Subject: Re: secsh meeting in pittsburgh: call for agenda items. Message-ID: <20000726004958.E25606@folly.informatik.uni-erlangen.de> References: <200007232156.AAA18723@torni.hel.fi.ssh.com> <200007201747.e6KHlfJ117017@thunk.east.sun.com> <87aefc23qq.fsf@snark.piermont.com> <14714.11307.410023.751051@asgard.tky.hut.fi> <4.2.0.58.20000723173237.0097b100@avarice.inner.net> <200007232156.AAA18723@torni.hel.fi.ssh.com> <14716.22292.55071.340992@asgard.tky.hut.fi> <4.2.0.58.20000724105942.00973bf0@avarice.inner.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="z6Eq5LdranGa6ru8" Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0.1i In-Reply-To: <4.2.0.58.20000724105942.00973bf0@avarice.inner.net>; from rja@inet.org on Mon, Jul 24, 2000 at 11:02:01AM -0400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk --z6Eq5LdranGa6ru8 Content-Type: text/plain; charset=us-ascii On Mon, Jul 24, 2000 at 11:02:01AM -0400, RJ Atkinson wrote: > I do object to changing the protocol on the wire because > it adversely impacts what interoperability exists at present. i don't consider this a 'change of the protocol on the wire'. the current draft is just ambiguous and inconsistent, see my previous e-mail. -markus --z6Eq5LdranGa6ru8 Content-Type: message/rfc822 Date: Mon, 22 May 2000 00:13:41 +0200 From: Markus Friedl To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: ietf-ssh@clinet.fi, psst@net.lut.ac.uk, Sami Lehtinen , niels@openbsd.org, deraadt@openbsd.org Subject: Re: ssh-dss signatures Message-ID: <20000522001341.A360@folly.informatik.uni-erlangen.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Mutt 1.0.1i In-Reply-To: ; from nisse@lysator.liu.se on Sun, May 21, 2000 at 10:26:35PM +0200 Content-Transfer-Encoding: 8bit Hello, On Sun, May 21, 2000 at 10:26:35PM +0200, Niels Möller wrote: > Sami Lehtinen notified me of a bug in LSH's implementation of ssh-dss > signatures. As I would like to have my interpretation of the spec > confirmed, and as I suspect that also openssh may have the same > problem (as it manages to interoperate with LSH), I'm writing to the > WG list. > > The transport draft, draft-ietf-secsh-transport-07.txt, defines an > ssh-dss signature as > > uint32 length > string "ssh-dss" > string dss_signature_blob The first field is omitted by OpenSSH as well as by SecureCRT and from my experiments with other implementations of SSH2 it seems that ssh-2.1.0 and ssh-2.0.13 both omit everything but dss_signature_blob not even the size of the dss_signature_blob is included. IMHO, the redundant field uint32 length seems inconsistent with the overall design of all other parts of the SSH2 specification so I would strongly support the change of the signature specification to string "ssh-dss" string dss_signature_blob Moreover, from reading the drafts now again it seems to me that the above mentioned (redundant) uint32 length is identical to the uint32 length field from the "string signature of H". Similar to this is the definition for "ssh-dss" from the same transport draft: uint32 length string "ssh-dss" mpint p mpint q mpint g mpint y In all implementations that I could test (ssh-2.1.0, ssh-2.0.13, lsh, SecureCRT, OpenSSH) the specified (redundant) length field is _never_ sent across the wire. e.g., in SSH_MSG_KEXDH_REPLY length field from the string string K_S, the host key is again identical to the length field from the "ssh-dss" definition. > The problem is the first field, which LSH omits. The signature is used > for instance inside the SSH_MSG_KEXDH_REPLY message, > > byte SSH_MSG_KEXDH_REPLY > string server public host key and certificates (K_S) > mpint f > string signature of H > > In LSH, this message looks something like this: > > SSH_MSG_KEXDH_REPLY (byte) > length of host key (uint32) > host key data (byte array) > length of f > digits of f > * length of signature (i.e. all below) > 7 (length of "ssh-dss") > "ssh-dss" (7 bytes) > length of signature blob (usually 40, and always even) > r digits (usually 20 bytes) > s digits (usually 20 bytes, but always the same length as for r) This is the same encoding OpenSSH generates and expects. SecureCRT expects the same format and it seems consistent with there overall design (there is never a explicit length field, only 'string'-type data has length fileds). And again: I would strongly favour the removal of the redundant length fields from the drafts since: 1) They are not usefull at all. Why should n bytes of data be encoded as: uint32 n+4 uint32 n n bytes data 2) There is no public implementation of the drafts that includes the redundant length field so 3) Requiring the length field breaks all public implementations of the drafts. This would hurt the acceptance of SSH2 much, since it adds yet another layer of incompatibility. > The extra length field is totally redundant here (and I believe it is > equally redundant in all other places where an ssh-dss signature is > used). I'm about to add it in LSH now, in order to comply with the > draft, but I would also like the WG to give some consideration to > removing the redundant length field in the definition of the ssh-dss > signature. As I said before, I see no reason why the length field is in the drafts and I even think it refers to the length field from the string encoding. -markus --z6Eq5LdranGa6ru8-- From owner-ietf-ssh@clinet.fi Tue Jul 25 21:39:45 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25034 for ; Tue, 25 Jul 2000 21:39:45 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA06865 for ietf-ssh-outgoing; Wed, 26 Jul 2000 02:19:49 +0300 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 CAA06862 for ; Wed, 26 Jul 2000 02:19:47 +0300 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA00684 for ; Tue, 25 Jul 2000 16:19:43 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA24340; Tue, 25 Jul 2000 19:19:36 -0400 (EDT) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6PNJDS103611; Tue, 25 Jul 2000 19:19:13 -0400 (EDT) Message-Id: <200007252319.e6PNJDS103611@thunk.east.sun.com> From: Bill Sommerfeld To: Niels Provos cc: sommerfeld@east.sun.com, ietf-ssh@clinet.fi Subject: Re: secsh meeting in pittsburgh: call for agenda items. In-reply-to: Your message of "Mon, 24 Jul 2000 14:57:52 EDT." <20000724185752.B1DE3207C1@citi.umich.edu> Reply-to: sommerfeld@east.sun.com Date: Tue, 25 Jul 2000 19:19:13 -0400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > Markus Friedl, Bill Simpson and I authored a draft on > > "Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol" > > It is available as draft-provos-secsh-dh-group-exchange-00.txt, and > we would like the working group to consider it. The document starts with the statement: This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026, except that the right to produce derivative works is not granted. Given that derivative works may not be produced, this document cannot form the basis of a potential standards track document, and it would thus not be appropriate to devote meeting time to discussing it. If there is other interest in this area, I can set aside some time for general discussion of DH parameter negotiation within the SSHv2 protocol, but unless you and your co-authors agree to change this clause in your document, someone else will have to write a new draft which is not derived from yours. - Bill From owner-ietf-ssh@clinet.fi Wed Jul 26 12:53:15 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19825 for ; Wed, 26 Jul 2000 12:53:15 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA01963 for ietf-ssh-outgoing; Wed, 26 Jul 2000 17:18:40 +0300 Received: from ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA01957 for ; Wed, 26 Jul 2000 17:18:40 +0300 Received: from torni.hel.fi.ssh.com (torni.hel.fi.ssh.com [10.1.0.43]) by ssh.com (8.9.3/8.9.3/SSH-1.16) with ESMTP id RAA12386 for ; Wed, 26 Jul 2000 17:18:40 +0300 (EEST) Received: (from sshlist@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.17) id RAA29872 for ietf-ssh@clinet.fi; Wed, 26 Jul 2000 17:18:39 +0300 (EET DST) Received: (from jhm@localhost) by picard.cistron.nl (8.9.3/8.9.3/Debian 8.9.3-6) id SAA01511 for ietf-ssh@clinet.fi; Tue, 25 Jul 2000 18:48:43 +0200 Date: Tue, 25 Jul 2000 18:48:43 +0200 From: "J.H.M. Dassen (Ray)" To: ietf-ssh@clinet.fi Subject: Re: Getting started with SSH Message-ID: <20000725184843.A647@cistron.nl> Mail-Followup-To: ietf-ssh@clinet.fi References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from ras@anzio.com on Mon, Jul 24, 2000 at 10:22:05PM -0700 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Mon, Jul 24, 2000 at 22:22:05 -0700, Bob Rasmussen wrote: > Since I'm about to dive headlong into SSH, I wonder if some of you folks > could answer a couple of basic questions: > > 1. Is the SSH protocol 1 published anywhere, online or onpaper? The SSH1 source, e.g. OpenSSH's, includes a draft protocol in nroff format. > 3. Would anyone care to summarize the status of trademark, patent, > copyright, etc. issues re. version 1; version 2? Please distinguish between the protocol and the implementation. Depending on your location, there may be patent issues regarding the RSA and IDEA algorithms used by SSH1. (RSA is primarily a problem in the US; IDEA primarily in Europe). The SSH2 protocol has been designed so as not to require use of patented algorithms (IIRC, it requires Diffie-Helman rather than RSA and an unencumbered block cipher (3DES?) rather than IDEA). The copyright status varies per implementation: neither SSH1 nor SSH2 are free software (in the Debian/GNU/OpenSource sense). OpenSSH is a free software implementation of the SSH1 protocol for Un*x systems that has recently been modified to handle the SSH2 protocol as well. lsh is a free software implementation of the SSH2 protocol for Un*x systems. PuTTY is a free software implementation of the SSH1 protocol for MS-Windows systems. There are several other implementations; I'm unfamiliar with their licensing terms. HTH, Ray -- UNFAIR Term applied to advantages enjoyed by other people which we tried to cheat them out of and didn't manage. See also DISHONESTY, SNEAKY, UNDERHAND and JUST LUCKY I GUESS. - The Hipcrime Vocab by Chad C. Mulligan From owner-ietf-ssh@clinet.fi Wed Jul 26 19:57:45 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28857 for ; Wed, 26 Jul 2000 19:57:44 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id AAA28331 for ietf-ssh-outgoing; Thu, 27 Jul 2000 00:24:56 +0300 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 AAA28325 for ; Thu, 27 Jul 2000 00:24:54 +0300 Received: from citi.umich.edu (ssh-mapper.citi.umich.edu [141.211.92.147]) by citi.umich.edu (Postfix) with ESMTP id 4D3CF207C1; Wed, 26 Jul 2000 17:24:53 -0400 (EDT) Subject: Re: secsh meeting in pittsburgh: call for agenda items. From: Niels Provos In-Reply-To: Bill Sommerfeld, Tue, 25 Jul 2000 19:19:13 EDT To: sommerfeld@east.sun.com Cc: ietf-ssh@clinet.fi, William Allen Simpson Date: Wed, 26 Jul 2000 17:24:53 -0400 Message-Id: <20000726212453.4D3CF207C1@citi.umich.edu> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Hi Bill, In message <200007252319.e6PNJDS103611@thunk.east.sun.com>, Bill Sommerfeld wri tes: >The document starts with the statement: > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026, except that the right to > produce derivative works is not granted. >Given that derivative works may not be produced, this document cannot >form the basis of a potential standards track document, and it would >thus not be appropriate to devote meeting time to discussing it. This is the mandated language by the POISED working group and the IESG. The only thing that it prevents you from doing is assigning it to another author without the permission of the original authors of the draft. When published as a standards track RFC, the standards track copyright applies, which is according to RFC 2026: "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. [...] This is just to prevent problems that have happened in the past where original author attributions have been removed from drafts. So, please allocate some time for general discussion of this draft for the WG meeting. Greetings, Niels. From owner-ietf-ssh@clinet.fi Wed Jul 26 19:57:48 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28881 for ; Wed, 26 Jul 2000 19:57:47 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id AAA29597 for ietf-ssh-outgoing; Thu, 27 Jul 2000 00:51:36 +0300 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 AAA29590 for ; Thu, 27 Jul 2000 00:51:33 +0300 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA04255 for ; Wed, 26 Jul 2000 14:51:30 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA14292; Wed, 26 Jul 2000 17:51:26 -0400 (EDT) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6QLp3S104373; Wed, 26 Jul 2000 17:51:03 -0400 (EDT) Message-Id: <200007262151.e6QLp3S104373@thunk.east.sun.com> From: Bill Sommerfeld To: Niels Provos cc: sommerfeld@east.sun.com, ietf-ssh@clinet.fi, William Allen Simpson , jis@MIT.EDU Subject: Re: secsh meeting in pittsburgh: call for agenda items. In-reply-to: Your message of "Wed, 26 Jul 2000 17:24:53 EDT." <20000726212453.4D3CF207C1@citi.umich.edu> Reply-to: sommerfeld@east.sun.com Date: Wed, 26 Jul 2000 17:51:03 -0400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > In message <200007252319.e6PNJDS103611@thunk.east.sun.com>, Bill Sommerfeld wri > tes: > >The document starts with the statement: > > > > This document is an Internet-Draft and is in full conformance with > > all provisions of Section 10 of RFC2026, except that the right to > > produce derivative works is not granted. > > >Given that derivative works may not be produced, this document cannot > >form the basis of a potential standards track document, and it would > >thus not be appropriate to devote meeting time to discussing it. > This is the mandated language by the POISED working group and the > IESG. The IESG member I spoke to (Jeff Schiller, CC'ed above) disagreed. He stated quite clearly in a phone conversation that drafts which do not grant the right to produce derivative works are not acceptable as potential standards track documents. The text which is needed for standards-track candidates is: This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 > The only thing that it prevents you from doing is assigning it to > another author without the permission of the original authors of the > draft. Working group documents eventually become the product of the working group as a whole. In order to avoid wasting the work of the rest of the contributors to the WG, we need the ability to reassign a draft to a new document editor should an original document editor become uncooperative or unresponsive. > So, please allocate some time for general discussion of this draft for > the WG meeting. I am willing to allocate time to discuss the general concept of DH parameter negotiation within SSHv2; however, your document in its present form is not acceptable as input to this working group. Agenda time will not be allocated in Pittsburgh to discuss this draft. If you wish to appeal this ruling, you should follow the appeals procedure documented in section 6.5 of RFC2026. Do not expect the answer to change. - Bill From owner-ietf-ssh@clinet.fi Thu Jul 27 01:09:48 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23285 for ; Thu, 27 Jul 2000 01:09:47 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id GAA09782 for ietf-ssh-outgoing; Thu, 27 Jul 2000 06:01:06 +0300 Received: from snark.piermont.com (snark.piermont.com [206.1.51.10]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id GAA09779 for ; Thu, 27 Jul 2000 06:01:04 +0300 Received: by snark.piermont.com (Postfix, from userid 1000) id 859FB1E00A4; Wed, 26 Jul 2000 23:01:02 -0400 (EDT) From: "Perry E. Metzger" To: Niels Provos Cc: sommerfeld@east.sun.com, ietf-ssh@clinet.fi Subject: Re: secsh meeting in pittsburgh: call for agenda items. References: <20000724185752.B1DE3207C1@citi.umich.edu> Date: 26 Jul 2000 23:01:02 -0400 In-Reply-To: Niels Provos's message of "Mon, 24 Jul 2000 14:57:52 -0400" Message-ID: <873dkwp98x.fsf@snark.piermont.com> Lines: 24 X-Mailer: Gnus v5.7/Emacs 20.6 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Niels Provos writes: > "Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol" > > It is available as draft-provos-secsh-dh-group-exchange-00.txt, and > we would like the working group to consider it. When I was chair, I rejected having this be a real working group document because of the intellectual property clauses associated with it. It really isn't possible to consider a document with the "no derivative works" clause for standardization. I had thought I re-mentioned the issue to you at Usenix, although I'm so exhausted these days my memory on such things is rather fallible. In any case, I would strongly urge that if you want it to be considered, you remove the "no derivative works" clause. It isn't my call any more, but I suspect that consensus in the IETF is still that such documents can be published but can never be made into real standards. -- Perry E. Metzger perry@wasabisystems.com -- Quality NetBSD Sales, Support & Service. http://www.wasabisystems.com/ From owner-ietf-ssh@clinet.fi Thu Jul 27 13:52:05 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13367 for ; Thu, 27 Jul 2000 13:52:05 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA20006 for ietf-ssh-outgoing; Thu, 27 Jul 2000 18:12:09 +0300 Received: from mail.mindbright.se (IDENT:root@mindbright5.cityoffice.se [195.17.71.134]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA20003 for ; Thu, 27 Jul 2000 18:12:07 +0300 Received: from hal.mindbright.se (IDENT:root@hal.mindbright.se [192.168.1.1]) by mail.mindbright.se (8.9.2/8.8.5) with ESMTP id RAA12677; Thu, 27 Jul 2000 17:29:11 +0200 (MEST) Received: from hal.mindbright.se (IDENT:mats@hal.mindbright.se [192.168.1.1]) by hal.mindbright.se (8.9.3/8.9.3) with ESMTP id RAA17225; Thu, 27 Jul 2000 17:11:07 +0100 Date: Thu, 27 Jul 2000 17:11:07 +0100 (IST) From: "Andersson, Mats" To: Bill Sommerfeld cc: ietf-ssh@clinet.fi Subject: Re: multiple implementations.. In-Reply-To: <200007242235.e6OMZsS100807@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 Hi, I'm the author of the MindTerm ssh1 client. I have implemented the sshv2 protocol also, currently only client side (interoperates with OpenSSH and SSH Inc's sshd). Server side will be implemented later on, the development have been stalled for over 2 months due to heavy workload. The change proposed (signature) is (IMHO) a good one and should be made "final", as someone else noted it's only an ambiguity in the draft that would be "closed" (besides beeing trivial/logical anyway :-). Generally, it's not very hard to change the implementation for basic stuff like this, after all it IS a draft still. As long as the standard becomes clean, shouldn't that be the main concern? While I'm at it, it would be fun (useful?) if the connection-draft gave RECOMMENDED values for (initial) window-sizes and max-packet-sizes for different channel types since I believe throughput performance (on high speed links) can vary some depending on client's and server's "mix" of values. This is of course quite a speculative thing to recommend, however, the usual implementation would be ontop of the secsh-transport ontop of TCP. Speed of the link is of course a factor, but that's why it's called INITIAL window size I guess, it's probably not constant... One other thing which could be fun to standardize is the ssh-dss key-formats since it is in everybody's interest(?) to be able to use keys inbetween implementations (I know this is kind of an implementation issue, but interoperability-wise it's a nice thing to standardize since most implementations will probably use "ssh-dss" keys primarily, at least to start with, or in a "basic" configuration). Of course there is also the sftp file-transfer protocol which I gather that Tatu(?) is writing up a draft on. If sftp is to be standardized, could there be something that could be improved in the process? Just my $.02... Cheers, /Mats On Mon, 24 Jul 2000, Bill Sommerfeld wrote: > while this isn't the case for the change which sparked this (there > appears to be consensus that the proposed change to delete the > duplicate length field is appropriate), I'll underline what Ran just > said: > > There are more than 3 implementers at this point, > so ALL changes ought to go through a normal IETF "propose to > the mailing list", "list discusses proposal", then "document > is changed if and only if there is clear consensus to make > the change" process. > > I am personally aware of several other sshv2 implementations besides > the 3 everyone knows about (SSH, Inc, LSH, and openssh). I'm sure > there are others; it would be useful to hear from other SSHv2 protocol > implementors if they have something to say.. > > - Bill > From owner-ietf-ssh@clinet.fi Thu Jul 27 13:54:16 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13638 for ; Thu, 27 Jul 2000 13:54:15 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA21370 for ietf-ssh-outgoing; Thu, 27 Jul 2000 18:33:18 +0300 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 SAA21366 for ; Thu, 27 Jul 2000 18:33:17 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id E8DA02400A78; Thu, 27 Jul 2000 17:33:20 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id RAA24628; Thu, 27 Jul 2000 17:33:16 +0200 (MET DST) To: sommerfeld@east.sun.com Cc: "Jeff P. Van Dyke" , ietf-ssh@clinet.fi Subject: Re: authentication agent forwarding. References: <200007251518.e6PFIxS101060@thunk.east.sun.com> From: nisse@lysator.liu.se (Niels Möller) Date: 27 Jul 2000 17:33:16 +0200 In-Reply-To: Bill Sommerfeld's message of "Tue, 25 Jul 2000 11:18:58 -0400" Message-ID: Lines: 22 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Bill Sommerfeld writes: > My personal opinion is that there should be a fifth draft to describe > the SSHv2 authentication agent forwarding protocol, plus external > references to the SSHv1 agent protocol. When talking about agent forwarding, one thing that I really would like to see, is to add the final host (and service) to the data being signed, and perhaps also some more information about the forwarding path. The goal for such changes is to let the machine hosting the agent cooperate with the target machine, to make sure that the forwarding path does not pass through untrusted machines. One should also note that the details of agent forwarding is deeply intertwined with publickey userauth protocol. Improvements to the forwarding mechanism will likely require a new "publickey-2" or "publickey-forwarded" userauth mechanism. (I haven't read any official documentation of the agent protocol, only a description from someone who reverse engineered it). /Niels From owner-ietf-ssh@clinet.fi Thu Jul 27 19:26:24 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02016 for ; Thu, 27 Jul 2000 19:26:23 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id AAA09112 for ietf-ssh-outgoing; Fri, 28 Jul 2000 00:06:15 +0300 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 AAA09108 for ; Fri, 28 Jul 2000 00:06:13 +0300 Received: from viper ([192.168.0.16]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 597; Thu, 27 Jul 2000 15:19:29 -0600 Message-ID: <003801bff80e$7d2a2d90$1000a8c0@viper> From: "Jeff P. Van Dyke" To: "Andersson, Mats" , "Bill Sommerfeld" Cc: References: Subject: Re: multiple implementations.. Date: Thu, 27 Jul 2000 15:06:05 -0600 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.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit > One other thing which could be fun to standardize is the ssh-dss > key-formats since it is in everybody's interest(?) to be able to use keys > inbetween implementations (I know this is kind of an implementation issue, > but interoperability-wise it's a nice thing to standardize since most > implementations will probably use "ssh-dss" keys primarily, at least to > start with, or in a "basic" configuration). > > Of course there is also the sftp file-transfer protocol which I gather > that Tatu(?) is writing up a draft on. If sftp is to be standardized, > could there be something that could be improved in the process? I think both of these issues are very important. I would be very interested in discussing how to move forward on both these issues - either during the meeting or during some informal BOF Tuesday or Wednesday evening. Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Fri Jul 28 16:50:24 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13186 for ; Fri, 28 Jul 2000 16:50:23 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id VAA08710 for ietf-ssh-outgoing; Fri, 28 Jul 2000 21:20:53 +0300 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 VAA08697 for ; Fri, 28 Jul 2000 21:20:51 +0300 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05382 for ; Fri, 28 Jul 2000 11:20:49 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA26416 for ; Fri, 28 Jul 2000 14:18:46 -0400 (EDT) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6SIINS105775 for ; Fri, 28 Jul 2000 14:18:23 -0400 (EDT) Message-Id: <200007281818.e6SIINS105775@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@clinet.fi Subject: list archives.. Reply-to: sommerfeld@east.sun.com Date: Fri, 28 Jul 2000 14:18:23 -0400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Thanks to Markus Friedl and Tero Kivinen, I now have two different mailing list archives for this list/working group, which should both be complete. (i.e., if you have an archive and haven't sent it yet, you don't need to). I've sent a query to Steve Coya about dropping them in place on the ietf FTP server. I expect that this will likely be dealt with after the dust settles from next weeks meeting... - Bill From owner-ietf-ssh@clinet.fi Sat Jul 29 02:33:35 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23788 for ; Sat, 29 Jul 2000 02:33:34 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id HAA30900 for ietf-ssh-outgoing; Sat, 29 Jul 2000 07:25:49 +0300 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 HAA30893 for ; Sat, 29 Jul 2000 07:25:48 +0300 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA07996 for ; Fri, 28 Jul 2000 21:25:45 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA19734 for ; Fri, 28 Jul 2000 23:15:02 -0400 (EDT) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6T3EdS108592 for ; Fri, 28 Jul 2000 23:14:39 -0400 (EDT) Message-Id: <200007290314.e6T3EdS108592@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@clinet.fi Subject: draft agenda for secsh WG meeting next week, Reply-to: sommerfeld@east.sun.com Date: Fri, 28 Jul 2000 23:14:38 -0400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Send comments to me.. WEDNESDAY, August 2, 2000 1300-1500 Afternoon Sessions I South Rm 10 SEC secsh Secure Shell WG Draft Agenda: current status of the working group. - 5 minutes current status of our drafts. - 5 minutes open issues - 30 minutes What do we need to work on before we can advance the current drafts onto the standards track? - correct length/public key encodings - ssh-agent loose ends - ??? kerberos in ssh - 30 minutes presentation (Tatu Ylonen) discussion kerberos v5 or GSSapi? other future work - 15 minutes What other ssh-related work do we want to consider for standardization? WG charter refresh - 10 minutes We've accomplished a bunch of our milestones. Charter hasn't been touched for 3+ years. What should we change, if anything? [random padding] - 25 minutes ---- From owner-ietf-ssh@clinet.fi Mon Jul 31 17:07:29 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16114 for ; Mon, 31 Jul 2000 17:07:28 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id VAA27912 for ietf-ssh-outgoing; Mon, 31 Jul 2000 21:19:58 +0300 Received: from ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id VAA27906 for ; Mon, 31 Jul 2000 21:19:58 +0300 Received: from torni.hel.fi.ssh.com (torni.hel.fi.ssh.com [10.1.0.43]) by ssh.com (8.9.3/8.9.3/SSH-1.16) with ESMTP id VAA23735 for ; Mon, 31 Jul 2000 21:19:54 +0300 (EEST) Received: (from sshlist@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.17) id VAA18450 for ietf-ssh@clinet.fi; Mon, 31 Jul 2000 21:19:54 +0300 (EET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id SAA07561; Mon, 31 Jul 2000 18:52:53 +0200 (MET DST) To: sommerfeld@east.sun.com Cc: ietf-ssh@clinet.fi Subject: Re: secsh meeting in pittsburgh: call for agenda items. References: <200007201747.e6KHlfJ117017@thunk.east.sun.com> From: nisse@lysator.liu.se (Niels Möller) Date: 31 Jul 2000 18:52:53 +0200 In-Reply-To: Bill Sommerfeld's message of "Thu, 20 Jul 2000 13:47:41 -0400" Message-ID: Lines: 371 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Bill Sommerfeld writes: > Now would be a good time for folks to do a careful review of the four > existing drafts: > > draft-ietf-secsh-architecture-05.txt > draft-ietf-secsh-transport-07.txt > draft-ietf-secsh-userauth-07.txt > draft-ietf-secsh-connect-07.txt I have reread the first two documents, and tried to recall problems and ambiguities that I have encountered, or remember from the list. Sections are marked as "minor" or "important". I hope to get to the other two documents later. Comments on the protocol drafts. 2000-07-31 draft-ietf-secsh-architecture-05.txt : 3.1. Host Keys : : Each server host MUST have a host key. Hosts MAY have multiple host : keys using multiple different algorithms. Multiple hosts MAY share the : same host key. Every host MUST have at least one key using each REQUIRED : public key algorithm (currently DSS [FIPS-186]). (minor) In some situations, it is desirable to authenticate the host using some secret shared between the host and a particular user. : 3.6. Localization and Character Set Support : : ... : : The client and server user names are inherently constrained by what the : server is prepared to accept. They might, however, occasionally be : displayed in logs, reports, etc. They MUST be encoded using ISO 10646 : UTF-8, but other encodings may be required in some cases. It is up to : the server to decide how to map user names to accepted user names. : Straight bit-wise binary comparison is RECOMMENDED. (important, but not urgent) This is too sloppy. Implementations should be required to respect unicode character equivalence. Say I have an account on a system that allows non-ascii characters in user names. Assume I'm known to the system under the name "möller", which has at least two different but equivalent representations in unicode (and therefore also in utf-8). As a user, I usually have no control over which of the representations my local system and software uses, and if I have to configure my local system to use the same (most likely undocumented) conventions as the remote system, I lose. There may be some option to choose between utf-8 and iso-8859-x, but I've never seen any user-level options for choosing between different canonicalization conventions for utf-8. A simple way to solve the problem is to require a particular unicode/utf-8 canonicalization when usernames are sent across the wire. I expect the WG for internationilized domain names to have similar considerations. : 4.1. Encoding of Network Addresses : : Network addresses are encoded as strings. DNS names MUST NOT be used, as : DNS is an insecure protocol. (important) DNS names should not be ruled out. For instance, when setting up a TCP/IP tunnel, it might be useful (and perhaps even increase security) to pass a dns name and let the server resolve it to an IP-address. So I would prefer if support for DNS names was optional rather than disallowed. : If an address contains a colon (':', ascii 58), it is interpreted as an : IPv6 address. The encoding of IPv6 addresses is described in [RFC-1884]. : IPv4 addresses are expressed in the standard dot-separated decimal : format (e.g. 127.0.0.1). "dot-separated decimal" is too vague. It will be interpreted as "anything that inet_addr() or inet_aton() accepts", which is not standardized. I would propose something like this: 1. If an address contains a ':' character, it is interpreted as an IPv6 address (it seems unnecessary to allow the shorthand ::-forms, but that's a minor point). 2. Otherwise, view it as a sequence of components separated by dots. There must be at least one component, and no empty ones (and no leading no trailing dots. Or do we want to allow a trailing dot?). 3. If the rightmost component starts with a decimal digit, the address is interpreted as an IPv4 address, and it must consist of exactly 4 components, each a number in the range 0-255, with no redundant leading zeroes. 4. Finally, if the rightmost, final component starts with a non-digit, the address is a symbolic DNS name, to be resolved to a numeric address when needed. If the name does not include a trailing dot, the systems DNS search path may be used. draft-ietf-secsh-transport-07.txt : 3.3.1. Old Client, New Server : : Server implementations MAY support a configurable "compatibility" flag : that enables compatibility with old versions. When this flag is on, the : server SHOULD identify its protocol version as "1.99". Clients using : protocol 2.0 MUST be able to identify this as identical to "2.0". In : this mode the server SHOULD NOT send carriage return character (ascii : 13) after the version identification string. (minor) Clients have been observed to *send* the protocol version number "1.99". I can't see any reason for this; if there is one, it should be mentioned here. : 4.1. Maximum Packet Length : : All implementations MUST be able to process packets with uncompressed : payload length of 32768 bytes or less and total packet size of 35000 : bytes or less (including length, padding length, payload, padding, and : MAC). Implementations SHOULD support longer packets, where they might : be needed e.g. if an implementation wants to send a very large number of : certificates. Such packets MAY be sent if the version string indicates : that the other party is able to process them. However, implementations : SHOULD check that the packet length is reasonable for the implementation : to avoid denial-of-service and/or buffer overflow attacks. (minor) Is there any rationale for the choice of the fudge factor 35000 - 32768? E.g. I have tried to look for the worst case expansion when compressing a packet with zlib, but I haven't found any precise numbers (the zlib docs says that the worst case for an _entire_ file is 12 bytes + 0.1%, but it's not clear to my how to apply that to individual blocks compressed with partial (Z_SYNC_FLUSH) syncing). : 4.3. Encryption ... : The "arcfour" is the Arcfour stream cipher with 128 bit keys. The : Arcfour cipher is believed to be compatible with the RC4 cipher : [Schneier]. RC4 is a registered trademark of RSA Data Security Inc. (minor) I have heard cryptographers say that the first few bytes of the arcfour keystream are weak (correlated to the first bytes of the key or somesuch), and that one should always throw away the first few 10-100 bytes output by arcfour. Is that something that should be done when using arcfour for ssh? : 4.6. Public Key Algorithms : : This protocol has been designed to be able to operate with almost any : public key format, encoding, and algorithm (signature and/or : encryption). : : There are several aspects that define a public key type: : : o Key format: how is the key encoded and how are certificates : represented. The key blobs in this protocol MAY contain certificates : in addition to keys. : : o Signature and/or encryption algorithms. Some key types may not : support both signing and encryption. Key usage may also be : restricted by policy statements in e.g. certificates. In this case, : different key types SHOULD be defined for the different policy : alternatives. : : o Encoding of signatures and/or encrypted data. This includes but is : not limited to padding, byte order, and data formats. (important) The way I want to read this, there is a unique mapping from key type to triples . I.e. when I advertise a key type, I *know* which algorithms I have to support in order to live up to my advertising. However, that's not the case for the defined key types, : The following public key and/or certificate formats are currently : defined: : : ssh-dss REQUIRED sign Simple DSS : x509v3 RECOMMENDED sign X.509 certificates : spki OPTIONAL sign SPKI certificates : pgp OPTIONAL sign OpenPGP certificates Say that a server has a dss hostkey, that it can offer as either a ssh-dss key or as a x509 certificate chain. I'm running a client that supports x509 (but only the most common rsa-based certificates) and ssh-dss. If both programs lists x509 as their preferred public key algorithm, it will be chosen, but communication will fail, even though there is a ssh-dss hostkey that both parties can deal with. I don't know the right way to solve this. Perhaps one needs to define more keytypes, x509v3-dsa (implementation can deal with both rsa and dsa) and spki-rsa. Here, rsa is the usual algorithm for use with x509, while dsa is the usual one for spki. This is mostly a problem for hostkeys, where communication fails when the client can't deal with the hostkey. For user authentication, the client can just try another key or key type. : The resulting signature is encoded as: : : uint32 length : string "ssh-dss" : string dss_signature_blob The redundant length fields in this and other representations has already been discussed on the list. For the record, I would prefer that they are removed. : 5.1. Algorithm Negotiation : ... Each side MAY guess which algorithm the other side is using, : and MAY send an initial key exchange packet according to the algorithm : if appropriate for the preferred method. If all algorithms were guessed ^^^ : right, the optimistically sent packet MUST be handled as the first key : exchange packet. ... (important) I feel the description of the "guessing" mechanism is too vague. In particular, the meaning of "all" seems unclear. : Key exchange begins by each side sending the following packet: : : byte SSH_MSG_KEXINIT : byte[16] cookie (random bytes) : string kex_algorithms : string server_host_key_algorithms ... : The first algorithm in each list MUST be the preferred (guessed) : algorithm. Each string MUST contain at least one algorithm name. : : cookie : The cookie MUST be a random value generated by the sender. Its : purpose is to make it impossible for either side to fully : determine the keys and the session identifier. : : kex_algorithms : Key exchange algorithms were defined above. The first algorithm : MUST be the preferred (and guessed) algorithm. If both sides make : the same guess, that algorithm MUST used. Otherwise, the : following algorithm MUST be used to choose a key exchange method: : iterate over client's kex algorithms, one at a time. Choose the : first algorithm that satisfies the following conditions: This seems inadequate. Consider the preference lists (where "foo" stands for some key exchange method that requires an encryption-capable host key): Server: kex_algorithms: "foo,diffie-hellman-group1-sha1" server_host_key_algorithms: "ssh-dss,rsa-encrypt" Client: kex_algorithms "foo,diffie-hellman-group1-sha1" server_host_key_algorithms: "ssh-dss,elgamal-encrypt" Here, the "guess" foo is correct, but it will cause communication to fail. Both parties preferences are reasonable, and they do have enough in common that they ought to figure out that they need to use diffie-hellman and ssh-dss. : first_kex_packet_follows : Indicates whether a guessed key exchange packet follows. If a : guessed packet will be sent, this MUST be true. If no guessed : packet will be sent, this MUST be false. : : After receiving the SSH_MSG_KEXINIT packet from the other side, : each party will know whether their guess was right. If the other : party's guess was wrong, and this field was true, the next packet : MUST be silently ignored, and both sides MUST then act as : determined by the negotiated key exchange method. If the guess : was right, key exchange MUST continue using the guessed packet. It needs to be clearly defined what it means that the guess was right. I can think of several interpretations: 1. The first element of the server's kex_algorithms list equals the first element of the client's kex_algorithms list. This has the problem described above, and additional problems if the first_kex_packet feature is used, and the contents of that packet depends in any way on the host key algorithm. 2. The first elements of the server's kex_algorithms and server_host_key_algorithms lists equal the respective first elements of the client's lists. This seems more reasonable, but it still needs some extra conditions to deal with the example above. 3. The first elements of "all" the server's lists equal the respective first elements of the client's list. This is what the first paragraph says, but it seems like a unneccessarily strict criterion. I don't see much use to have the guessing mechanism depend on a correct guess for the bulk encryption algorithms, and even less use of it depending on a correct guess for the compression algorithms. 4. Interpret "all" algorithms to mean the kex_algorithms, server_host_key_algorithms, encryption_algorithms and mac_algorithms (but not compression_algorithms or languages). : 5.2. Output from Key Exchange : : The key exchange produces two values: a shared secret K, and an exchange : hash H. Encryption and authentication keys are derived from these. The : exchange hash H from the first key exchange is additionally used as the : session identifier, which is a unique identifier for this connection. (minor) I would like a line or two specifying whether or not the exchange hash should be treated as secret information (when designing and analysing user authentication mechanisms, it helps to be able to assume one or the other). : If the key length in longer than the output of the HASH, the key is : extended by computing HASH of the concatenation of K and H and the : entire key so far, and appending the resulting bytes (as many as HASH : generates) to the key. This process is repeated until enough key : material is available; the key is taken from the beginning of this : value. In other words, : : K1 = HASH(K || H || X || session_id) (X is e.g. "A") : K2 = HASH(K || H || K1) : K3 = HASH(K || H || K1 || K2) : ... : key = K1 || K2 || K3 || ... (minor) As was pointed out on the list and coderpunks recently, this key stretching mechanism loses entropy if the amount of entropy that enters the system (in the form of K) is larger than the internal state of HASH. : 8. Service Request : : After the key exchange, the client requests a service. The service is : identified by a name. The format of names and procedures for defining : new names are defined in [SSH-ARCH]. : : Currently, the following names have been reserved: : : ssh-userauth : ssh-connection : : Similar local naming policy is applied to the service names that is : applied to the algorithm names; a local service should use the : servicename@domain syntax. : byte SSH_MSG_SERVICE_REQUEST : string service name : : If the server rejects the service request, it SHOULD send an appropriate : SSH_MSG_DISCONNECT message and MUST disconnect. : : When the service starts, it may have access to the session identifier : generated during the key exchange. : : If the server supports the service (and permits the client to use it), : it MUST respond with : : byte SSH_MSG_SERVICE_ACCEPT : string service name (minor) The service name part of this message seems redundant. It would make sense (but still be redundant) if the client were expected to send more than one SSH_MSG_SERVICE_REQUEST, which the server responded to in turn (similar to the handling of SSH_MSG_USERAUTH_REQUEST messages). But the spec requires the server to reply with a SSH_MSG_SERVICE_ACCEPT at most once, and never give the client a second chance if a service request is rejected. /Niels