From owner-ietf-ssh@clinet.fi Mon Oct 2 21:03:06 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16486 for ; Mon, 2 Oct 2000 21:03:05 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA31356 for ietf-ssh-outgoing; Tue, 3 Oct 2000 01:57:41 +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 BAA31351 for ; Tue, 3 Oct 2000 01:57:39 +0300 Received: from viper2 ([192.168.0.38]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 570; Mon, 2 Oct 2000 16:58:38 -0600 Message-ID: <002701c02cc4$bf26ff30$0201a8c0@vandyke.com> From: "Jeff P. Van Dyke" To: Cc: References: <200009012350.e81NoJT108944@thunk.east.sun.com> Subject: Are we still on track for last call? (was Re: minutes from the SECSH working group meeting at the 48th IETF) Date: Mon, 2 Oct 2000 17:01:46 -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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit > Schedule > > Sep 00 Finalization of core drafts > Oct 00 Last calls > Oct 00 Submit core drafts to IESG > Oct 00 Determine schedule for extensions > Nov 00 Submit extension drafts for discussion > Dec 00 Meet in SD > Sep 01 Submit core drafts for publication as draft standard Can we expect a revised set of core drafts to be published soon? Are last calls on the core drafts still a possibility for October? Thanks. Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Tue Oct 3 07:11:28 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05828 for ; Tue, 3 Oct 2000 07:11:27 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id LAA03529 for ietf-ssh-outgoing; Tue, 3 Oct 2000 11:48:27 +0300 Received: from mail.mindbright.se (IDENT:postfix@mindterm.appgate.com [193.12.107.237]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id LAA03523 for ; Tue, 3 Oct 2000 11:48:25 +0300 Received: by mail.mindbright.se (Postfix, from userid 1001) id D0CAE1FF01; Tue, 3 Oct 2000 10:49:09 +0200 (MEST) Received: from localhost (localhost [127.0.0.1]) by mail.mindbright.se (Postfix) with ESMTP id CA1431F101; Tue, 3 Oct 2000 10:49:09 +0200 (MEST) Date: Tue, 3 Oct 2000 10:49:09 +0200 (MEST) From: Mats Andersson X-Sender: mats@mindterm.appgate.com To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: ietf-ssh@clinet.fi Subject: Re: New bulk encryption algorithms In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.clinet.fi id LAA03525 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id LAA03529 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA05828 Hi, On 11 Sep 2000, Niels Mцller wrote: > I'm about to add support for serpent and rijndael to LSH. I'm using > the names "rijndael-cbc" and "serpent-cbc". Both use 256 bit keys, and Since rijndael is proposed for AES wouldn't it be nice to have rijndael-cbc as RECOMMENDED in the drafts? Cheers, /Mats From owner-ietf-ssh@clinet.fi Tue Oct 3 07:41:49 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06632 for ; Tue, 3 Oct 2000 07:41:49 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA14217 for ietf-ssh-outgoing; Tue, 3 Oct 2000 12:35:16 +0300 Received: from kanto.cc.jyu.fi (mjos@kanto.cc.jyu.fi [130.234.1.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id MAA14211 for ; Tue, 3 Oct 2000 12:35:14 +0300 Received: from localhost (mjos@localhost) by kanto.cc.jyu.fi (8.9.3/8.9.3/antispam3) with ESMTP id MAA19033 for ; Tue, 3 Oct 2000 12:35:11 +0300 (EET DST) Date: Tue, 3 Oct 2000 12:35:11 +0300 (EET DST) From: Markku-Juhani Saarinen To: ietf-ssh@clinet.fi Subject: Re: New bulk encryption algorithms Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id MAA14217 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA06632 Mats Andersson wrote: > Since rijndael is proposed for AES wouldn't it be nice to have > Rijndael-cbc as RECOMMENDED in the drafts? I'd rather see "AES" than "Rijndael" in the drafts. (most of us prefer to use the word "DES" rather than the original name "Lucifer" after all.. ) Note that the speed of AES varies according to the key size. Going from 128 bits to 256 bits slows AES down by about 40%. For this reason I'd like to propose names for the various standard key sizes: "aes128-cbc" (663 Mbit / sec @ 1 GHz P3) "aes192-cbc" (448 Mbit / sec @ 1 GHz P3) "aes256-cbc" (384 Mbit / sec @ 1 GHz P3) The block size is 128 bits in all cases. The timings are based on the paper "Fast Implementations of AES Candidates" by Aoki and Lipmaa (presented in the AES 3 conference). - mj Markku-Juhani O. Saarinen University of Jyvдskylд, Finland From owner-ietf-ssh@clinet.fi Tue Oct 3 09:56:25 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11521 for ; Tue, 3 Oct 2000 09:56:25 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA18029 for ietf-ssh-outgoing; Tue, 3 Oct 2000 15:01:46 +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 PAA18011 for ; Tue, 3 Oct 2000 15:01:43 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 14CCC2409FE5; Tue, 3 Oct 2000 14:01:42 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id OAA02312; Tue, 3 Oct 2000 14:01:41 +0200 (MET DST) To: Markku-Juhani Saarinen Cc: ietf-ssh@clinet.fi Subject: Re: New bulk encryption algorithms References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 03 Oct 2000 14:01:41 +0200 In-Reply-To: Markku-Juhani Saarinen's message of "Tue, 3 Oct 2000 12:35:11 +0300 (EET DST)" Message-ID: Lines: 23 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Markku-Juhani Saarinen writes: > I'd rather see "AES" than "Rijndael" in the drafts. (most of us prefer to > use the word "DES" rather than the original name "Lucifer" after all.. ) That depends a little on what becomes the usual way to refer to the cipher. I don't really know, but if you think that "aes" is what people will be calling the cipher in a year or two, it makes sense to call it it aes rather than rijndael. > Note that the speed of AES varies according to the key size. Going from > 128 bits to 256 bits slows AES down by about 40%. > > For this reason I'd like to propose names for the various standard key > sizes: > > "aes128-cbc" (663 Mbit / sec @ 1 GHz P3) > "aes192-cbc" (448 Mbit / sec @ 1 GHz P3) > "aes256-cbc" (384 Mbit / sec @ 1 GHz P3) Sounds reasonable. /Niels From owner-ietf-ssh@clinet.fi Tue Oct 3 11:42:20 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14495 for ; Tue, 3 Oct 2000 11:42:19 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id QAA09853 for ietf-ssh-outgoing; Tue, 3 Oct 2000 16:46: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 QAA09844 for ; Tue, 3 Oct 2000 16:46:52 +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 GAA14908; Tue, 3 Oct 2000 06:46:44 -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 JAA26709; Tue, 3 Oct 2000 09:46:23 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e93Djml122401; Tue, 3 Oct 2000 09:45:48 -0400 (EDT) Message-Id: <200010031345.e93Djml122401@thunk.east.sun.com> From: Bill Sommerfeld To: Markku-Juhani Saarinen cc: ietf-ssh@clinet.fi Subject: Re: New bulk encryption algorithms In-reply-to: Your message of "Tue, 03 Oct 2000 12:35:11 +0300." Reply-to: sommerfeld@east.sun.com Date: Tue, 03 Oct 2000 09:45:48 -0400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > > Since rijndael is proposed for AES wouldn't it be nice to have > > Rijndael-cbc as RECOMMENDED in the drafts? > > I'd rather see "AES" than "Rijndael" in the drafts. This makes sense. It's shorter and easier to type.. > Note that the speed of AES varies according to the key size. Going > from 128 bits to 256 bits slows AES down by about 40%. For this > reason I'd like to propose names for the various standard key sizes: > "aes128-cbc" (663 Mbit / sec @ 1 GHz P3) > "aes192-cbc" (448 Mbit / sec @ 1 GHz P3) > "aes256-cbc" (384 Mbit / sec @ 1 GHz P3) Given how secsh parameter negotiation works, this makes sense. - Bill From owner-ietf-ssh@clinet.fi Tue Oct 3 11:55:53 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14828 for ; Tue, 3 Oct 2000 11:55:53 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id QAA12013 for ietf-ssh-outgoing; Tue, 3 Oct 2000 16:56:30 +0300 Received: from nic.appgate.com (nic.appgate.com [193.12.107.226]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id QAA12006 for ; Tue, 3 Oct 2000 16:56:28 +0300 Received: from pelee.firedoor.se (pelee.firedoor.se [172.23.2.10]) by nic.appgate.com (Postfix) with ESMTP id 9A4793BE07; Tue, 3 Oct 2000 15:56:28 +0200 (MET DST) Received: from appgate.com (maunaloa.firedoor.se [172.23.2.56]) by pelee.firedoor.se (Postfix) with ESMTP id 61E2C317AA; Tue, 3 Oct 2000 15:56:23 +0200 (MEST) Date: Tue, 3 Oct 2000 15:56:20 +0200 (MEST) From: Martin Forssen Subject: Re: New bulk encryption algorithms To: nisse@lysator.liu.se Cc: mjos@cc.jyu.fi, ietf-ssh@clinet.fi In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=iso-8859-1 Message-Id: <20001003135623.61E2C317AA@pelee.firedoor.se> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id QAA12013 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA14828 On 3 Oct, Niels Mцller wrote: > Markku-Juhani Saarinen writes: >> I'd rather see "AES" than "Rijndael" in the drafts. (most of us prefer to >> use the word "DES" rather than the original name "Lucifer" after all.. ) > > That depends a little on what becomes the usual way to refer to the > cipher. I don't really know, but if you think that "aes" is what > people will be calling the cipher in a year or two, it makes sense to > call it it aes rather than rijndael. Please keep in mind that NIST has only proposed that Rijndael should be the new AES. The actual certification will take some time yet (maybe years). So we can not be 100% that Rijndael will become the AES, there is still a possibility (although very a very faint one) that some other algorithm will be chosen as AES. Therefore I think it is a bad idea to use "aes" when we mean "rijndael", at least at the protocol level. Also I am not sure the analogy with Lucifer/DES holds since Lucifer was another cipher. There is a thread on exactly this topic in sci.crypt at the moment. >> Note that the speed of AES varies according to the key size. Going from >> 128 bits to 256 bits slows AES down by about 40%. >> >> For this reason I'd like to propose names for the various standard key >> sizes: >> >> "aes128-cbc" (663 Mbit / sec @ 1 GHz P3) >> "aes192-cbc" (448 Mbit / sec @ 1 GHz P3) >> "aes256-cbc" (384 Mbit / sec @ 1 GHz P3) > > Sounds reasonable. Yes it does (with changing "aes" to "rijndael" of course:-) /MaF From owner-ietf-ssh@clinet.fi Tue Oct 3 12:03:10 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15023 for ; Tue, 3 Oct 2000 12:03:09 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA13624 for ietf-ssh-outgoing; Tue, 3 Oct 2000 17:07:33 +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 RAA13616 for ; Tue, 3 Oct 2000 17:07:31 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id BA1EF2401B4E; Tue, 3 Oct 2000 16:07:30 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id QAA13830; Tue, 3 Oct 2000 16:07:30 +0200 (MET DST) To: Martin Forssen Cc: mjos@cc.jyu.fi, ietf-ssh@clinet.fi Subject: Re: New bulk encryption algorithms References: <20001003135623.61E2C317AA@pelee.firedoor.se> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 03 Oct 2000 16:07:30 +0200 In-Reply-To: Martin Forssen's message of "Tue, 3 Oct 2000 15:56:20 +0200 (MEST)" Message-ID: Lines: 16 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Martin Forssen writes: > Please keep in mind that NIST has only proposed that Rijndael should be > the new AES. The actual certification will take some time yet (maybe > years). So we can not be 100% that Rijndael will become the AES, there > is still a possibility (although very a very faint one) that some other > algorithm will be chosen as AES. Therefore I think it is a bad idea to > use "aes" when we mean "rijndael", at least at the protocol level. Good point. It makes sense to use "rijndael" to refer to the cipher that was input to the AES process, and "aes" for whatever comes out at the other end. One possible thing that might happen before the AES process is over is NIST tweaking the number of rounds, I guess. If no tweaking happens, "aes" and "rijndael" will turn out to be synonyms. /Niels From owner-ietf-ssh@clinet.fi Tue Oct 3 17:55:24 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24003 for ; Tue, 3 Oct 2000 17:55:23 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA18830 for ietf-ssh-outgoing; Tue, 3 Oct 2000 23:02:25 +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 XAA18822 for ; Tue, 3 Oct 2000 23:02:23 +0300 Received: from sage ([192.168.0.38]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 343 for ; Tue, 3 Oct 2000 14:03:25 -0600 Message-ID: <029a01c02d75$c2410b00$0500a8c0@sage> From: "Joseph Galbraith" To: Subject: key re-exchange with compression enabled Date: Tue, 3 Oct 2000 14:08:54 -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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit I believe draft-ietf-secsh-transport-07 is ambiguous with regards to how the hash H is computed during key re-exchange when compression is on. Here is a quote from Section 6 (pg, 14): The hash H is computed as the HASH hash of the concatenation of the following: string V_C, the client's version string (CR and NL excluded) string V_S, the server's version string (CR and NL excluded) string I_C, the payload of the client's SSH_MSG_KEXINIT string I_S, the payload of the server's SSH_MSG_KEXINIT string K_S, the host key mpint e, exchange value sent by the client mpint f, exchange value sent by the server mpint K, the shared secret In the case of the initial key exchange, compression is always off, and there is no confusion. However, if a key re-exchange is in progress and compression was negotiated by the prior key exchange, then the current wording would seem to imply that the compressed payload should be used in the hash. It appears that current implementations (or at least SSH Communications 2.3.0) use the uncompressed packet payload. I believe I_C and I_S should be clarified to read as follows: string I_C, the uncompressed payload of the client's SSH_MSG_KEXINIT string I_S, the uncompressed payload of the server's SSH_MSG_KEXINIT Thanks, Joseph Galbraith galb-list@vandyke.com From owner-ietf-ssh@clinet.fi Tue Oct 3 19:13:05 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24633 for ; Tue, 3 Oct 2000 19:13:04 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id AAA26228 for ietf-ssh-outgoing; Wed, 4 Oct 2000 00:28:10 +0300 Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id AAA26224 for ; Wed, 4 Oct 2000 00:28:08 +0300 Received: from mosquito.extremenetworks.com ([10.0.8.141]) by sol.extremenetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id T8951J9A; Tue, 3 Oct 2000 14:26:41 -0700 Message-Id: <4.3.2.7.2.20001003171650.00b074b0@sc-sol-04.extremenetworks.com> X-Sender: rja@sc-sol-04.extremenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 03 Oct 2000 17:22:07 -0400 To: Martin Forssen From: RJ Atkinson Subject: Re: New bulk encryption algorithms Cc: ietf-ssh@clinet.fi In-Reply-To: <20001003135623.61E2C317AA@pelee.firedoor.se> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ssh@clinet.fi Precedence: bulk At 09:56 03/10/00, Martin Forssen wrote: >Please keep in mind that NIST has only proposed that Rijndael should be >the new AES. The actual certification will take some time yet (maybe >years). So we can not be 100% that Rijndael will become the AES, there >is still a possibility (although very a very faint one) that some other >algorithm will be chosen as AES. Therefore I think it is a bad idea to >use "aes" when we mean "rijndael", at least at the protocol level. Disagree. It definitely won't take years. The decision is made and the only thing is to publish a formal FIPS for AES. The formal process for the AES FIPS document to be approved only involves: (1) NIST publishes draft FIPS for AES in the US Federal Register (2) legal comment period occurs (which is N weeks, not years) (3) The full FIPS gets approved I'll be surprised if AES FIPS isn't fully completed by the end of the Minneapolis IETF. In any event, IANA has already allocated an IPsec magic number for AES (and also numbers for SHA-2), see the URL below: http://www.isi.edu/in-notes/iana/assignments/ipsec-registry Ran rja@inet.org From owner-ietf-ssh@clinet.fi Tue Oct 3 20:53:58 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25323 for ; Tue, 3 Oct 2000 20:53:57 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA01524 for ietf-ssh-outgoing; Wed, 4 Oct 2000 02:12:52 +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 CAA01517 for ; Wed, 4 Oct 2000 02:12:51 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id D2D26240A470; Wed, 4 Oct 2000 00:13:52 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id AAA02290; Wed, 4 Oct 2000 00:13:52 +0200 (MET DST) To: "Joseph Galbraith" Cc: Subject: Re: key re-exchange with compression enabled References: <029a01c02d75$c2410b00$0500a8c0@sage> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 04 Oct 2000 00:13:52 +0200 In-Reply-To: "Joseph Galbraith"'s message of "Tue, 3 Oct 2000 14:08:54 -0600" Message-ID: Lines: 84 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk "Joseph Galbraith" writes: > The hash H is computed as the HASH hash of the > concatenation of the following: > > string V_C, the client's version string (CR and NL excluded) > string V_S, the server's version string (CR and NL excluded) > string I_C, the payload of the client's SSH_MSG_KEXINIT > string I_S, the payload of the server's SSH_MSG_KEXINIT > string K_S, the host key > mpint e, exchange value sent by the client > mpint f, exchange value sent by the server > mpint K, the shared secret > > In the case of the initial key exchange, compression > is always off, and there is no confusion. > > However, if a key re-exchange is in progress and > compression was negotiated by the prior key exchange, > then the current wording would seem to imply that the > compressed payload should be used in the hash. > > It appears that current implementations (or at least SSH > Communications 2.3.0) use the uncompressed packet payload. That's the natural way to do it, I guess. I deal with both decrypting and inflating of incoming packets before I look inside them. The encrypted and compressed data is thrown away before I even look at the message type and contents. Similarly on the way out, I generate cleartext uncompressed packets and put them on the transmission queue. The code that compresses the packets doesn't care about the message type or contents, and compressed data is thrown away as soon as it is encrypted or passed to write() by the next handler on the queue. > I believe I_C and I_S should be clarified to read > as follows: > > string I_C, the uncompressed payload of the client's SSH_MSG_KEXINIT > string I_S, the uncompressed payload of the server's SSH_MSG_KEXINIT If the processing described above is not obvious, the spec could need some clarification. But instead of clarifying every use of the word "payload", I think it would be a good idea to use the word "payload" _exclusively_ for the cleartext uncompressed packets, and some other word when talking about possibly encrypted and/or compressed data that appears closer to the wire. E.g. replace : Each packet is of the following format. : : uint32 packet_length : byte padding_length : byte[n1] payload; n1 = packet_length - padding_length - 1 : byte[n2] random padding; n2 = padding_length : byte[m] mac (message authentication code); m = mac_length : : [...] : : payload : The useful contents of the packet. If compression has been : negotiated, this field is compressed. Initially, compression MUST : be "none". with : Each packet is of the following format. : : uint32 packet_length : byte padding_length : byte[n1] contents; n1 = packet_length - padding_length - 1 : byte[n2] random padding; n2 = padding_length : byte[m] mac (message authentication code); m = mac_length : : [...] : : contents : The useful contents of the packet. If compression has been : negotiated, decompression of the contents yields the : packet payload; otherwise, the payload and the contents are the : same. Initially, compression MUST : be "none". Regards, /Niels From owner-ietf-ssh@clinet.fi Wed Oct 4 06:19:02 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14351 for ; Wed, 4 Oct 2000 06:19:01 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id JAA17964 for ietf-ssh-outgoing; Wed, 4 Oct 2000 09:59:05 +0300 Received: from nic.appgate.com (nic.appgate.com [193.12.107.226]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id JAA17961 for ; Wed, 4 Oct 2000 09:59:04 +0300 Received: from pelee.firedoor.se (pelee.firedoor.se [172.23.2.10]) by nic.appgate.com (Postfix) with ESMTP id 07BA03BE07; Wed, 4 Oct 2000 08:59:04 +0200 (MET DST) Received: from appgate.com (maunaloa.firedoor.se [172.23.2.56]) by pelee.firedoor.se (Postfix) with ESMTP id B6AA4317AA; Wed, 4 Oct 2000 08:58:59 +0200 (MEST) Date: Wed, 4 Oct 2000 08:58:56 +0200 (MEST) From: Martin Forssen Subject: Re: New bulk encryption algorithms To: rja@extremenetworks.com Cc: ietf-ssh@clinet.fi In-Reply-To: <4.3.2.7.2.20001003171650.00b074b0@sc-sol-04.extremenetworks.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20001004065859.B6AA4317AA@pelee.firedoor.se> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On 3 Oct, RJ Atkinson wrote: > At 09:56 03/10/00, Martin Forssen wrote: >>Please keep in mind that NIST has only proposed that Rijndael should be >>the new AES. The actual certification will take some time yet (maybe >>years). So we can not be 100% that Rijndael will become the AES, there >>is still a possibility (although very a very faint one) that some other >>algorithm will be chosen as AES. Therefore I think it is a bad idea to >>use "aes" when we mean "rijndael", at least at the protocol level. > > Disagree. It definitely won't take years. The decision is made Ok, I stand corrected. It seems as they expect it to be final somewhere around April-June 2001 (http://csrc.nist.gov/encryption/aes/round2/aesfact.html item #9). > and the only thing is to publish a formal FIPS for AES. The formal > process for the AES FIPS document to be approved only involves: > (1) NIST publishes draft FIPS for AES in the US Federal Register > (2) legal comment period occurs (which is N weeks, not years) > (3) The full FIPS gets approved I think you forgot one step here: (2.5) NIST makes apropriate changes to the draft (See above url item #8) So as far as I understand it there is nothing which guarantees that the cipher we today know as Rijndael is going to meet the conformance testing criteriaof the official AES. NIST may still make changes to the draft. So IMHO this leaves us two choices, either we define the name rijndael and are the able to start using it now, or we define the name as aes and wait until it is official. Perhaps I just have a vivid imagination but I can see potential problems if people now implement what they think is AES and nist then tweaks the algorithm so we have incompatible versions of the "same" algorithm. So to summarize: I do not see any real advantages of calling it aes, but I see one drawback in that we may get implementations which do not conform to the official AES when that is released. /MaF From owner-ietf-ssh@clinet.fi Wed Oct 4 07:28:25 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15609 for ; Wed, 4 Oct 2000 07:28:24 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA30359 for ietf-ssh-outgoing; Wed, 4 Oct 2000 12:45:25 +0300 Received: from kanto.cc.jyu.fi (kanto.cc.jyu.fi [130.234.1.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id MAA30348 for ; Wed, 4 Oct 2000 12:45:23 +0300 Received: from localhost (mjos@localhost) by kanto.cc.jyu.fi (8.9.3/8.9.3/antispam3) with ESMTP id MAA27191 for ; Wed, 4 Oct 2000 12:45:22 +0300 (EET DST) Date: Wed, 4 Oct 2000 12:45:22 +0300 (EET DST) From: Markku-Juhani Saarinen To: ietf-ssh@clinet.fi Subject: Forwarded mail.... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id MAA30359 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA15609 Ok, perhaps it is better to use "rijndael" for now.. But what's the concensus on the key length issue ? "rijndael128-cbc" recommended ? "rijndael192-cbc" recommended ? "rijndael256-cbc" recommended ? By the way, secsh will not have have > 2^80 security against certain key derivation attacks before the adoptation of SHA-2. > Also I am not sure the analogy with Lucifer/DES holds since Lucifer was > another cipher. There is a thread on exactly this topic in sci.crypt at > the moment. Actually my understanding is that many IBM block ciphers prior to DES were called "Lucifer", as was IBM's submission to NBS in 1974. At least two variants of Lucifer are discussed in Biham's and Shamir's '93 book on differential cryptanalysis. This algorithm was heavily modified (with the help of NSA) during the 3-year selection process and was ultimately selected as the DES in 1977. Cheers, - mj Markku-Juhani O. Saarinen University of Jyvдskylд, Finland From owner-ietf-ssh@clinet.fi Wed Oct 4 09:20:44 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19061 for ; Wed, 4 Oct 2000 09:20:43 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id OAA27085 for ietf-ssh-outgoing; Wed, 4 Oct 2000 14:40:10 +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 OAA27078 for ; Wed, 4 Oct 2000 14:40:10 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 55C742407DD1; Wed, 4 Oct 2000 13:40:09 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id NAA22778; Wed, 4 Oct 2000 13:40:08 +0200 (MET DST) To: Markku-Juhani Saarinen Cc: ietf-ssh@clinet.fi Subject: Re: Forwarded mail.... References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 04 Oct 2000 13:40:08 +0200 In-Reply-To: Markku-Juhani Saarinen's message of "Wed, 4 Oct 2000 12:45:22 +0300 (EET DST)" Message-ID: Lines: 26 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Markku-Juhani Saarinen writes: > Ok, perhaps it is better to use "rijndael" for now.. But what's > the concensus on the key length issue ? > > "rijndael128-cbc" recommended ? > "rijndael192-cbc" recommended ? > "rijndael256-cbc" recommended ? Hmm. My first reaction was that I would rather use "rijdael-256-cbc" etc, analogous to "hmac-md5-96". But on the other hand, you're naming is more consistent with "cast128-cbc". Using consistent naming conventions isn't crucial for interoperability or some such, but it makes the spec look a lot cleaner. I don't have any strong opinion on whether or not the algorithms should be recommended. To me, it seems reasonable to make "rijndael256-cbc" RECOMMENDED (analogous to the recommended "twofish-cbc", which also uses 256 bit keys), and make the shorter-key variants OPTIONAL. (And BTW, when talking about algorithm names, I'd like to remind you that "hmac-sha-96" ought to be changed to "hmac-sha1-96"). Regards, /Niels From owner-ietf-ssh@clinet.fi Wed Oct 4 13:41:15 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27117 for ; Wed, 4 Oct 2000 13:41:15 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA05920 for ietf-ssh-outgoing; Wed, 4 Oct 2000 18:25:52 +0300 Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA05916 for ; Wed, 4 Oct 2000 18:25:50 +0300 Received: from mosquito.extremenetworks.com ([10.0.8.92]) by sol.extremenetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id T8951QTY; Wed, 4 Oct 2000 08:24:22 -0700 Message-Id: <4.3.2.7.2.20001004105802.00abbca0@sc-sol-04.extremenetworks.com> X-Sender: rja@sc-sol-04.extremenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Oct 2000 11:19:47 -0400 To: Martin Forssen From: RJ Atkinson Subject: Re: New bulk encryption algorithms Cc: ietf-ssh@clinet.fi In-Reply-To: <20001004065859.B6AA4317AA@pelee.firedoor.se> References: <4.3.2.7.2.20001003171650.00b074b0@sc-sol-04.extremenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ssh@clinet.fi Precedence: bulk At 02:58 04/10/00, you wrote: >> and the only thing is to publish a formal FIPS for AES. The formal >> process for the AES FIPS document to be approved only involves: >> (1) NIST publishes draft FIPS for AES in the US Federal Register >> (2) legal comment period occurs (which is N weeks, not years) >> (3) The full FIPS gets approved > >I think you forgot one step here: > (2.5) NIST makes apropriate changes to the draft > (See above url item #8) Changes to draft will definitely NOT include changing the algorithm chosen. It might involve changes to which US Government agencies are required to use it, what modes a US Government agency must deploy, or to what set of conformance testing procedures have to be gone through. Please recall that the document NIST is producing is a (US) Federal Information Processing Standard (FIPS), which levies requirements ONLY upon US Government agencies (sometimes FIPS are not mandatory for US Dept of Defence). This is not an ANSI, ISO, or ITU document or standard, where meaningful technical changes might happen before final publication. >So as far as I understand it there is nothing which guarantees that the >cipher we today know as Rijndael is going to meet the conformance >testing criteriaof the official AES. NIST may still make changes to the >draft. I believe there is no risk to us that the AES algorithm will change, based on past experience with the FIPS process, public statements by NIST folks about AES, and conversations with folks at NIST/Gaithersburg, MD. If the Security ADs disagreed with my analysis, they wouldn't have asked IANA to allocate an IPsec magic number for AES. The ADs did so yesterday and IANA allocated the magic number within a couple of hours. Regards, Ran rja@inet.org From owner-ietf-ssh@clinet.fi Wed Oct 4 20:45:31 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05498 for ; Wed, 4 Oct 2000 20:45:30 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA22986 for ietf-ssh-outgoing; Thu, 5 Oct 2000 01:49:37 +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 BAA22975 for ; Thu, 5 Oct 2000 01:49:34 +0300 Received: from sage ([192.168.0.38]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 474 for ; Wed, 4 Oct 2000 16:50:38 -0600 Message-ID: <021401c02e56$486b4a70$0500a8c0@sage> From: "Joseph Galbraith" To: Subject: Guessed key exchange packets Date: Wed, 4 Oct 2000 16:56:07 -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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit I'm a little confused about when a guessed key exchange packet should be retransmitted. Quote from section 5 of draft-ietf-secsh-transport-07.txt: Key exchange begins by each side sending lists of supported algorithms. Each side has a preferred algorithm in each category, and it is assumed that most implementations at any given time will use the same preferred algorithm. 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. However, if the guess was wrong, and a packet was optimistically sent by one or both parties, such packets MUST be ignored (even if the error in the guess would not affect the contents of the initial packet(s)), and the appropriate side MUST send the correct initial packet. ... The first algorithm in each list MUST be the preferred (guessed) algorithm. Each string MUST contain at least one algorithm name. I am unclear as to when I should ignore a guessed key exchange packet. The SSH Communications clients are the only ones I know of that guess packets... and I can't find any situation where they retransmit. The way I first read this paragraph, the guessed packet should be retransmitted if the first algorithm of each list isn't the same for the client and server (for all algorithms negotiated in the KEX_INIT packet.) Then I read it again, and it seemed like maybe it would only be retransmitted if the first algorithm in the guesser's list wasn't chosen... Can anyone clarify what the appropriate behavior is when I receive a guessed packet? In particular, when should I expect/require a retransmission? Thanks, Joseph Galbraith galb-list@vandyke.com From owner-ietf-ssh@clinet.fi Thu Oct 5 07:25:03 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA25823 for ; Thu, 5 Oct 2000 07:25:02 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA22843 for ietf-ssh-outgoing; Thu, 5 Oct 2000 12:37:07 +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 MAA22826 for ; Thu, 5 Oct 2000 12:37:03 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 2F63F2401B41; Thu, 5 Oct 2000 11:37:02 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id LAA09929; Thu, 5 Oct 2000 11:37:01 +0200 (MET DST) To: "Joseph Galbraith" Cc: Subject: Re: Guessed key exchange packets References: <021401c02e56$486b4a70$0500a8c0@sage> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 05 Oct 2000 11:37:01 +0200 In-Reply-To: "Joseph Galbraith"'s message of "Wed, 4 Oct 2000 16:56:07 -0600" Message-ID: Lines: 64 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk "Joseph Galbraith" writes: > I'm a little confused about when a guessed key exchange > packet should be retransmitted. The guessed packet MUST be discarded iff the guess was "wrong". The problem is criteria for determining whether or not a guess is considered correct or wrong. The interpretations I can come up with, for defining "correct", are: : 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). : (from ). Also consider this example (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" which demonstrates that it is not good enough that the first elements of the respective preference lists match. > Then I read it again, and it seemed like maybe it would only be > retransmitted if the first algorithm in the guesser's list wasn't > chosen... That's a new interpretation to me. I don't read the spec that way. > Can anyone clarify what the appropriate behavior is when I receive > a guessed packet? I agree that this has to be clarified. /Niels From owner-ietf-ssh@clinet.fi Fri Oct 6 12:02:51 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07128 for ; Fri, 6 Oct 2000 12:02:49 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA18915 for ietf-ssh-outgoing; Fri, 6 Oct 2000 17:25:56 +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 RAA18912 for ; Fri, 6 Oct 2000 17:25:56 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 368EF2401703; Fri, 6 Oct 2000 16:25:55 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id QAA29713; Fri, 6 Oct 2000 16:25:54 +0200 (MET DST) To: sommerfeld@east.sun.com Cc: ietf-ssh@clinet.fi, minutes@ietf.org Subject: utf-8 usernames (Re: minutes from the SECSH working group meeting at the 48th IETF) References: <200009012350.e81NoJT108944@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 06 Oct 2000 16:25:54 +0200 In-Reply-To: Bill Sommerfeld's message of "Fri, 01 Sep 2000 19:50:19 -0400" Message-ID: Lines: 29 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Bill Sommerfeld writes: > Minutes of the secsh working group > Wednesday, August 2, 2000 > il8n of usernames > > A comment to the list was made that multiple representations could happen, do > we need canonicalization. > > Niels Moller suggested waiting for il8n strategy from the DNS people and using > that. One approach is to adopt draft-duerst-i18n-norm-04.txt, saying that usernames and passwords MUST be encoded in utf8, "Early Uniform Normalization according to Unicode Normalization Form C, Canonical Composition (NFC)". > Tero: I think canonicalization should be done at server, since it > knows internal format it wants to use. This makes sense (as I admitted on the list earlier). However, using the rules of draft-duerst-i18n-norm-04.txt may well make the job easier for most internal representations a server might want to use, and reduce the amount unicode-knowledge reqiured by the server. For instance, I think we get rid of all "strange" canonical equivalents to ascii, like "(1)". /Niels From owner-ietf-ssh@clinet.fi Fri Oct 6 12:03:00 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07142 for ; Fri, 6 Oct 2000 12:02:58 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA16745 for ietf-ssh-outgoing; Fri, 6 Oct 2000 17:09:06 +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 RAA16735 for ; Fri, 6 Oct 2000 17:09:03 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 888E42401703; Fri, 6 Oct 2000 16:09:01 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id QAA06764; Fri, 6 Oct 2000 16:09:01 +0200 (MET DST) To: sommerfeld@east.sun.com Cc: ietf-ssh@clinet.fi, minutes@ietf.org Subject: Signal numbering (was Re: minutes from the SECSH working group meeting at the 48th IETF) References: <200009012350.e81NoJT108944@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 06 Oct 2000 16:09:00 +0200 In-Reply-To: Bill Sommerfeld's message of "Fri, 01 Sep 2000 19:50:19 -0400" Message-ID: Lines: 67 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk I'm rereading the minutes, and have a few more comments (which I'll send in separate messages). Bill Sommerfeld writes: > Minutes of the secsh working group > Wednesday, August 2, 2000 > draft-ietf-secsh-connect-07.txt > signal encoding > - extend format, include optional string with > signal name w/o SIG prefix. > SIGBUS -> "BUS" As far as I can tell, there's no standard whatsoever assigning numerical signal numbers to signals. (Some) symbolic signal names are defined by posix. In practice, numbers 1-15 seems to be the same everywhere, while higher numbers mean different things on different systems. I don't know te motivation for adding an optional signal name, but it doesn't solve the problem. In lsh, I use the concept of "network signal numbers" which are a somewhat arbitrary numbering that local numbers are translated to and from when transmitted in the protocol (in the "exit-signal" and "signal" SSH_MSG_CHANNEL_REQUEST:s). I use the following numbering { network number, local number } { 1, SIGHUP }, { 2, SIGINT }, { 3, SIGQUIT }, { 4, SIGILL }, { 5, SIGTRAP }, { 6, SIGABRT }, /* IOT is the mnemonic for the PDP-11 instruction used by the abort() function */ { 7, SIGEMT }, { 8, SIGFPE }, { 9, SIGKILL }, { 10, SIGBUS }, { 11, SIGSEGV }, { 12, SIGSYS }, { 13, SIGPIPE }, { 14, SIGALRM }, { 15, SIGTERM }, /* Signals beyond 15 does not have the same meaning everywhere */ { 16, SIGURG }, { 17, SIGSTOP }, { 18, SIGTSTP }, { 19, SIGCONT }, { 20, SIGCHLD }, { 21, SIGTTIN }, { 22, SIGTTOU }, { 23, SIGIO }, { 23, SIGPOLL }, /* SysV name for SIGIO */ { 24, SIGXCPU }, { 25, SIGXFSZ }, { 26, SIGVTALRM }, { 27, SIGPROF }, { 28, SIGWINCH }, { 29, SIGLOST }, { 30, SIGUSR1 }, { 31, SIGUSR2 } /Niels From owner-ietf-ssh@clinet.fi Fri Oct 6 12:11:36 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07277 for ; Fri, 6 Oct 2000 12:11:34 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA17855 for ietf-ssh-outgoing; Fri, 6 Oct 2000 17:17:40 +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 RAA17849 for ; Fri, 6 Oct 2000 17:17:39 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 739C42401703; Fri, 6 Oct 2000 16:17:38 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id QAA18408; Fri, 6 Oct 2000 16:17:38 +0200 (MET DST) To: sommerfeld@east.sun.com Cc: ietf-ssh@clinet.fi, minutes@ietf.org Subject: Kerberos (Re: minutes from the SECSH working group meeting at the 48th IETF) References: <200009012350.e81NoJT108944@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 06 Oct 2000 16:17:37 +0200 In-Reply-To: Bill Sommerfeld's message of "Fri, 01 Sep 2000 19:50:19 -0400" Message-ID: Lines: 26 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Bill Sommerfeld writes: > Minutes of the secsh working group > Wednesday, August 2, 2000 > Kerberos Authentication (Tatu Ylonen) Is Tatu's proposal available anywhere? I'm looking into kerberos support, and my current thinking is that if kerberos is used to provide mutual authentication (and not simply as a different password verification mechanism), it should be done as a keyexchange method, not a userauth method. So kerberos is an example of a keyexchange method that authenticates both user and host (other examples are SRP and similar protocols). I think it makes sense to use this class of keyexchange methods, and then skip the user authentication on success. I.e. the client can send a SSH_MSG_SERVICE_REQUEST asking for "ssh-connection", and the server will associate the userid established during key exchange with any created sessions, processes etc. Comments? Are there any security problems here that I have overlooked? I imagine that the keyexchange has to include some steps to bind the exchange hash to the negotiated key. /Niels From owner-ietf-ssh@clinet.fi Fri Oct 6 12:13:39 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07346 for ; Fri, 6 Oct 2000 12:13:38 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA19044 for ietf-ssh-outgoing; Fri, 6 Oct 2000 17:27:34 +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 RAA19040 for ; Fri, 6 Oct 2000 17:27:33 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id A13C22401F44; Fri, 6 Oct 2000 16:27:32 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id QAA01999; Fri, 6 Oct 2000 16:27:32 +0200 (MET DST) To: sommerfeld@east.sun.com Cc: ietf-ssh@clinet.fi, minutes@ietf.org Subject: SRP-like protocols (Re: minutes from the SECSH working group meeting at the 48th IETF) References: <200009012350.e81NoJT108944@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 06 Oct 2000 16:27:31 +0200 In-Reply-To: Bill Sommerfeld's message of "Fri, 01 Sep 2000 19:50:19 -0400" Message-ID: Lines: 14 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Bill Sommerfeld writes: > Minutes of the secsh working group > Wednesday, August 2, 2000 > Improvided password auth > > EKE/SPEKE/SRP interest which ties the password a bit better into the > crypto and less succeptible to dictionaries. A volunteer exists > to write a draft on this. Are you referring to my draft on SRP here, or have I missed something? /Niels From owner-ietf-ssh@clinet.fi Fri Oct 6 14:26:16 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10081 for ; Fri, 6 Oct 2000 14:26:15 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA32337 for ietf-ssh-outgoing; Fri, 6 Oct 2000 19:44:11 +0300 Received: from smaug.wrq.com (smaug.wrq.com [150.215.17.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA32332 for ; Fri, 6 Oct 2000 19:44:09 +0300 Received: from abra.wrq.com (abra.wrq.com [150.215.8.10]) by smaug.wrq.com (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id JAA10075; Fri, 6 Oct 2000 09:43:47 -0700 (PDT) Received: by abra.wrq.com with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Oct 2000 09:43:46 -0700 Message-ID: <86EDBD151558D311BB5700508B2E03FC0336F886@pikachu.wrq.com> From: Joe Salowey To: "'nisse@lysator.liu.se'" , sommerfeld@east.sun.com Cc: ietf-ssh@clinet.fi Subject: RE: Kerberos Date: Fri, 6 Oct 2000 09:43:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ssh@clinet.fi Precedence: bulk I recently submitted a draft on using Kerberos as a key exchange method for SSH. The approach I took is different than what Tatu proposed. I proposed two different methods, one which used Kerberos to authenticate the Diffie-Hellman key exchange and one in which Kerberos was used for the entire key exchange. The advantage of this type of approach is that it uses existing Kerberos infra-structure to do the exchange, without the need for extra keys. This method could be used to initially distribute host public keys as well. I also defined a user authentication method that uses that uses information from the key exchange for authentication. I'd like to get some feedback so I can refine (or refute ) the draft. I've already had some discussions with people about using GSSAPI instead of straight Kerberos. The draft is at http://www.ietf.org/internet-drafts/draft-salowey-secsh-kerbkeyex-00.txt Abstract This memo describes two methods for using Kerberos [KRB5] for authentication and key exchange in the Secure Shell protocol. The first method uses Kerberos as a means to authenticate the Diffie-Hellman exchange described in [SSH-TRANSPORT]. The second method uses Kerberos for authentication and key-exchange. This memo also defines a new user authentication method which allows an authorization name and optional credentials to build upon the underlying authenticated key exchange. Thanks, Joe From owner-ietf-ssh@clinet.fi Mon Oct 9 09:41:19 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03966 for ; Mon, 9 Oct 2000 09:41:18 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id OAA12290 for ietf-ssh-outgoing; Mon, 9 Oct 2000 14:28:37 +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 OAA12071 for ; Mon, 9 Oct 2000 14:27:48 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id C105A240171E; Mon, 9 Oct 2000 13:27:47 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id NAA00470; Mon, 9 Oct 2000 13:27:47 +0200 (MET DST) To: Tatu Ylonen Cc: sommerfeld@east.sun.com, ietf-ssh@clinet.fi Subject: Re: Kerberos (Re: minutes from the SECSH working group meeting at the 48th IETF) References: <200009012350.e81NoJT108944@thunk.east.sun.com> <200010090557.IAA26871@torni.hel.fi.ssh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 09 Oct 2000 13:27:47 +0200 In-Reply-To: Tatu Ylonen's message of "Mon, 9 Oct 2000 08:57:55 +0300 (EET DST)" Message-ID: Lines: 64 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk I wrote: > > So kerberos is an example of a keyexchange method that authenticates > > both user and host (other examples are SRP and similar protocols). I > > think it makes sense to use this class of keyexchange methods, and > > then skip the user authentication on success. I.e. the client can send > > a SSH_MSG_SERVICE_REQUEST asking for "ssh-connection", and the server > > will associate the userid established during key exchange with any > > created sessions, processes etc. Comments? Tatu Ylonen writes: > The protocol is designed so that host authentication and user > authentication are different steps. I'm very aware of that. > It is not entirely trivial (and certainly not clean) to modify it so > that both host authentication and user authentication take place > using the same external protocol. I think it is both easy and reasonably clean to skip the userauth step under some circumstances. What makes me feel a little uneasy about it is authentication of the keyexchange messages; if there is no hostkey distributed by a pki or some out-of-band means, the exchange hash has to be authenticated using the newly negotiated sessino key, which seems a little circular. > I am personally not sure if it is worth the trouble to complicate > the protocol. How badly are such authentication mechanisms needed? It is a big improvement in situations where you have a kerberos infrastructure, but no good means to distribute hostkeys securely. And similarly in any scenario where SRP makes sense. Another approach to mutual kerberos authentication (which I consider a lot less clean than skipping the userauth step) is to perform the usual dh-based keyexchange, using a hostkey that there is not much trust in, then perform mutual kerberos authetnication as part of the userauth protocol, and finally mix the kerberos and the dh session keys in some way. > (The same issue comes up with Kerberos mutual authentication.) The examples I care about are kerberos mutual authentication, and SRP. A potential problem with kerberos is the size of the session keys. I'm no kerberos expert, but I'm been told that it is common that you only get a "des-ticket", i.e. a single 56 bit session key. In this situation, perhaps it would make sense to use some EKE-like techniques, first doing kerberos mutual authentication, next use the kerberos session key as a shared secret for an EKE-like exchange. E.g. encrypting the dh values using the kerberos key, or deriving the generator from the kerberos key, or some such. The goal of that approach would be to base authentication on the short kerberos key (so that an attacker would have to crack it in more or less real time to impersonate either party), and still get forward secrecy so that the real session keys are secret a few hours or days later when the short kerberos key is cracked. Does that make sense, or is kerberos with des-tickets too poor to make anything work securely? /Niels From owner-ietf-ssh@clinet.fi Tue Oct 10 06:55:05 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA00982 for ; Tue, 10 Oct 2000 06:55:04 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id LAA24726 for ietf-ssh-outgoing; Tue, 10 Oct 2000 11:57:43 +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 LAA24710 for ; Tue, 10 Oct 2000 11:57:41 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 4D6712401B3D; Tue, 10 Oct 2000 10:57:40 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id KAA21415; Tue, 10 Oct 2000 10:57:39 +0200 (MET DST) To: Tatu Ylonen Cc: sommerfeld@east.sun.com, ietf-ssh@clinet.fi Subject: Re: Kerberos (Re: minutes from the SECSH working group meeting at the 48th IETF) References: <200009012350.e81NoJT108944@thunk.east.sun.com> <200010090557.IAA26871@torni.hel.fi.ssh.com> <200010100543.IAA05817@torni.hel.fi.ssh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 10 Oct 2000 10:57:36 +0200 In-Reply-To: Tatu Ylonen's message of "Tue, 10 Oct 2000 08:43:48 +0300 (EET DST)" Message-ID: Lines: 29 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Tatu Ylonen writes: > One possible way to "cleanly" skip userauth is to allow the requested > service name to be ssh-conn also in the transport layer service > request. That's exactly what I'm thinking of. > (I still think it is kind of kludgy - it needs to pass user > information from the transport protocol to the connection protocol. > However, I cannot think of a cleaner solution without major changes in > the protocols.) In lsh, I have one object that is responsible for a connection, which handles all packet-type dispatch as well as other connection-related information that doesn't fit naturally anywhere else. I store a user-pointer in that object, and the function initializing the ssh-connection service checks that the user pointer is non-NULL, but it doesn't care if a value was installed by the key exchange mechanism or by the userauth protocol. > For SRP an ad-hoc mechanism would probably need to be designed. (I > am not familiar with the details of the SRP protocol though.) I've tried to do that in draft-nisse-secsh-srp-00.txt, but it needs careful review. Regards, /Niels From owner-ietf-ssh@clinet.fi Tue Oct 10 14:23:42 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09767 for ; Tue, 10 Oct 2000 14:23:41 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA11696 for ietf-ssh-outgoing; Tue, 10 Oct 2000 19:24:21 +0300 Received: from raeburn.org (r93aag001418.sbo-smr.ma.cable.rcn.com [209.6.180.209]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA11691 for ; Tue, 10 Oct 2000 19:24:18 +0300 Received: (from raeburn@localhost) by raeburn.org (8.8.8/8.6.9) id MAA27875; Tue, 10 Oct 2000 12:24:10 -0400 (EDT) X-Authentication-Warning: raeburn.org: raeburn set sender to raeburn@raeburn.org using -f To: nisse@lysator.liu.se (Niels Mцller) Cc: ietf-ssh@clinet.fi Subject: Re: Kerberos (Re: minutes from the SECSH working group meeting at the 48th IETF) References: <200009012350.e81NoJT108944@thunk.east.sun.com> <200010090557.IAA26871@torni.hel.fi.ssh.com> From: Ken Raeburn Date: 10 Oct 2000 12:24:09 -0400 In-Reply-To: nisse@lysator.liu.se's message of "09 Oct 2000 13:27:47 +0200" Message-ID: Lines: 50 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from quoted-printable to 8bit by mail.clinet.fi id TAA11694 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id TAA11696 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA09767 nisse@lysator.liu.se (Niels Mцller) writes: > A potential problem with kerberos is the size of the session keys. I'm > no kerberos expert, but I'm been told that it is common that you only > get a "des-ticket", i.e. a single 56 bit session key. In this Currently common, but should become much less so in the near future. MIT and Heimdal have support for triple-DES keys (168 bits), and there's a good chance we'll put in AES sometime soon too. It is definitely not the intent of Kerberos to provide weak protection; it's merely that we need time to get existing installations to upgrade. (And you could take the view that if someone is still using single-DES Kerberos to authenticate a connection to the host, then they've expressed a lack of interest in strong protection, or they'd have upgraded. That's often how I look at it.) In the long run, using the Kerberos-supplied session key should be adequate. And you can explicitly request a triple-DES or AES key from a KDC if it's supported by that installation. Speaking just for myself, I'm not worried about the level of protection afforded by Kerberos with triple-DES, and pretty much any machine I care a lot about is protected that way. > situation, perhaps it would make sense to use some EKE-like > techniques, first doing kerberos mutual authentication, next use the > kerberos session key as a shared secret for an EKE-like exchange. E.g. > encrypting the dh values using the kerberos key, or deriving the > generator from the kerberos key, or some such. > The goal of that approach would be to base authentication on the short > kerberos key (so that an attacker would have to crack it in more or > less real time to impersonate either party), and still get forward > secrecy so that the real session keys are secret a few hours or > days later when the short kerberos key is cracked. Does that make > sense, or is kerberos with des-tickets too poor to make anything work > securely? If cracking the DES key doesn't help the attacker crack the session key because the key exchange routine is strong enough, why factor the DES key into the session key generation at all (except perhaps as an *additional* source of pseudo-randomness)? Also, in most such configurations the server's host key is likely to be single-DES too, so that'd be the key to go after. Once that's cracked, the attacker can get in as any user with a new connection. It's still difficult to do without significant resources, but this is the reason for the push to triple-DES and AES. Ken From owner-ietf-ssh@clinet.fi Tue Oct 10 15:17:54 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11328 for ; Tue, 10 Oct 2000 15:17:53 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA18828 for ietf-ssh-outgoing; Tue, 10 Oct 2000 20:39:13 +0300 Received: from smaug.wrq.com (smaug.wrq.com [150.215.17.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA18825 for ; Tue, 10 Oct 2000 20:39:11 +0300 Received: from abra.wrq.com (abra.wrq.com [150.215.8.10]) by smaug.wrq.com (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id KAA10788; Tue, 10 Oct 2000 10:38:58 -0700 (PDT) Received: by abra.wrq.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Oct 2000 10:38:58 -0700 Message-ID: <86EDBD151558D311BB5700508B2E03FC0336F88E@pikachu.wrq.com> From: Joe Salowey To: "'nisse@lysator.liu.se'" , Tatu Ylonen Cc: ietf-ssh@clinet.fi Subject: RE: Kerberos (Re: minutes from the SECSH working group meeting at the 48th IETF) Date: Tue, 10 Oct 2000 10:38:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Another possibility is to specify a new User authentication method that uses the external key exchange. In http://www.ietf.org/internet-drafts/draft-salowey-secsh-kerbkeyex-00.txt I defined a User Auth type "external-keyx" for this purpose. In this message the client only has to specify a user name. The credentials from the key exchange are then used to see if this user name is valid. It is also possible to provide additional credentials (such as an authorization certificate) in this message. Joe > -----Original Message----- > From: nisse@lysator.liu.se [mailto:nisse@lysator.liu.se] > Sent: Tuesday, October 10, 2000 1:58 AM > To: Tatu Ylonen > Cc: sommerfeld@east.sun.com; ietf-ssh@clinet.fi > Subject: Re: Kerberos (Re: minutes from the SECSH working > group meeting > at the 48th IETF) > > > Tatu Ylonen writes: > > > One possible way to "cleanly" skip userauth is to allow the > requested > > service name to be ssh-conn also in the transport layer service > > request. > > That's exactly what I'm thinking of. > > > (I still think it is kind of kludgy - it needs to pass user > > information from the transport protocol to the connection protocol. > > However, I cannot think of a cleaner solution without major > changes in > > the protocols.) > > In lsh, I have one object that is responsible for a connection, which > handles all packet-type dispatch as well as other connection-related > information that doesn't fit naturally anywhere else. I store a > user-pointer in that object, and the function initializing the > ssh-connection service checks that the user pointer is non-NULL, but > it doesn't care if a value was installed by the key exchange mechanism > or by the userauth protocol. > > > For SRP an ad-hoc mechanism would probably need to be designed. (I > > am not familiar with the details of the SRP protocol though.) > > I've tried to do that in draft-nisse-secsh-srp-00.txt, but it needs > careful review. > > Regards, > /Niels > From owner-ietf-ssh@clinet.fi Tue Oct 10 16:39:33 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12919 for ; Tue, 10 Oct 2000 16:39:32 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id VAA24393 for ietf-ssh-outgoing; Tue, 10 Oct 2000 21:40:30 +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 VAA24389 for ; Tue, 10 Oct 2000 21:40:29 +0300 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id VAA10720; Tue, 10 Oct 2000 21:38:08 +0300 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Message-ID: <14819.25103.861652.268558@asgard.tky.hut.fi> Date: Tue, 10 Oct 2000 21:38:07 +0300 (EEST) To: nisse@lysator.liu.se (Niels Mцller) Cc: ietf-ssh@clinet.fi Subject: Revising the document In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id VAA24393 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA12919 Niels Mцller, on September 27. 2000, wrote: : I'd like to know who, if any, is working as document editor for : revising the current drafts? Ho. -- [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 Tue Oct 10 18:34:57 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14726 for ; Tue, 10 Oct 2000 18:34:56 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA02893 for ietf-ssh-outgoing; Tue, 10 Oct 2000 23:52:56 +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 XAA02890 for ; Tue, 10 Oct 2000 23:52:56 +0300 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id XAA10783; Tue, 10 Oct 2000 23:50:29 +0300 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14819.33045.121267.929575@asgard.tky.hut.fi> Date: Tue, 10 Oct 2000 23:50:29 +0300 (EEST) To: RJ Atkinson Cc: Martin Forssen , Bill Sommerfeld , Tero Kivinen , ietf-ssh@clinet.fi Subject: Re: New bulk encryption algorithms In-Reply-To: <4.3.2.7.2.20001004105802.00abbca0@sc-sol-04.extremenetworks.com> References: <4.3.2.7.2.20001003171650.00b074b0@sc-sol-04.extremenetworks.com> <4.3.2.7.2.20001004105802.00abbca0@sc-sol-04.extremenetworks.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 AES or Rijndael? There have been opinions about this for both sides, but no real consensus. As I'm currently trying to finish these, I'd like to know which should it be. Personally, I'd like AES, but because it isn't officially official yet, there just might be changes. OTOH, there have been opinions Rijndael will become AES without changes, and that's the impression I got after threading through the NIST pages. And it would be a shame if we were to use the "rijndael" name long after it has been declared AES. So, what's it going to be? -- [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 Tue Oct 10 20:50:36 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16256 for ; Tue, 10 Oct 2000 20:50:35 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA12897 for ietf-ssh-outgoing; Wed, 11 Oct 2000 02:11:33 +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 CAA12892 for ; Wed, 11 Oct 2000 02:11:31 +0300 Received: from viper2 ([192.168.0.38]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 347; Tue, 10 Oct 2000 17:12:45 -0600 Message-ID: <003a01c03310$0d18b430$0201a8c0@vandyke.com> From: "Jeff P. Van Dyke" To: "Markus Friedl" Cc: References: <200009012350.e81NoJT108944@thunk.east.sun.com> <002901c01d27$2a94f8b0$0201a8c0@vandyke.com> <20000913130149.A1228@faui02.informatik.uni-erlangen.de> Subject: Support for rename in sftp protocol? (was Re: minutes from the SECSH working group meeting at the 48th IETF) Date: Tue, 10 Oct 2000 17:15:37 -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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit What versions of the sftp server support RENAME, packet type 18? Is OpenSSH the only server supporting this? Thanks. Jeff P. Van Dyke jpv@vandyke.com ----- Original Message ----- From: "Markus Friedl" To: "Jeff P. Van Dyke" Cc: Sent: Wednesday, September 13, 2000 5:01 AM Subject: Re: minutes from the SECSH working group meeting at the 48th IETF > On Tue, Sep 12, 2000 at 08:05:57PM -0600, Jeff P. Van Dyke wrote: > > > File transfer > > > > > > Current sftp draft is not in any state. sftp protocol needs to be > > > documented, reviewed by the working group. file listing format should > > > take a look at what the FTP WG did for directory listings. > > > > I'd very much like to see some progress on getting sftp documented. > > here are my notes on the SFTP protocol. -m > From owner-ietf-ssh@clinet.fi Tue Oct 10 22:24:56 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17840 for ; Tue, 10 Oct 2000 22:24:56 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id DAA18842 for ietf-ssh-outgoing; Wed, 11 Oct 2000 03:49:10 +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 DAA18839 for ; Wed, 11 Oct 2000 03:49:09 +0300 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id DAA14000; Wed, 11 Oct 2000 03:46:43 +0300 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14819.47219.606996.794591@asgard.tky.hut.fi> Date: Wed, 11 Oct 2000 03:46:43 +0300 (EEST) To: "Jeff P. Van Dyke" Cc: "Markus Friedl" , Subject: Support for rename in sftp protocol? (was Re: minutes from the SECSH working group meeting at the 48th IETF) In-Reply-To: <003a01c03310$0d18b430$0201a8c0@vandyke.com> References: <200009012350.e81NoJT108944@thunk.east.sun.com> <002901c01d27$2a94f8b0$0201a8c0@vandyke.com> <20000913130149.A1228@faui02.informatik.uni-erlangen.de> <003a01c03310$0d18b430$0201a8c0@vandyke.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 Jeff P. Van Dyke, on October 10. 2000, wrote: : What versions of the sftp server support RENAME, packet type 18? : : Is OpenSSH the only server supporting this? ssh-2.2.0 and up from SSH Communications Security. -- [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 Tue Oct 10 22:40:46 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18967 for ; Tue, 10 Oct 2000 22:40:45 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id EAA19424 for ietf-ssh-outgoing; Wed, 11 Oct 2000 04:00:19 +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 EAA19416 for ; Wed, 11 Oct 2000 04:00:17 +0300 Received: from viper2 ([192.168.0.38]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 566; Tue, 10 Oct 2000 19:01:36 -0600 Message-ID: <000901c0331f$41abba30$0201a8c0@vandyke.com> From: "Jeff P. Van Dyke" To: "Sami Lehtinen" , References: <4.3.2.7.2.20001003171650.00b074b0@sc-sol-04.extremenetworks.com><4.3.2.7.2.20001004105802.00abbca0@sc-sol-04.extremenetworks.com> <14819.33045.121267.929575@asgard.tky.hut.fi> Subject: Re: New bulk encryption algorithms Date: Tue, 10 Oct 2000 19:04:46 -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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit From: "Sami Lehtinen" > AES or Rijndael? > > There have been opinions about this for both sides, but no real > consensus. As I'm currently trying to finish these, I'd like to know > which should it be. Personally, I'd like AES, but because it isn't > officially official yet, there just might be changes. OTOH, there have > been opinions Rijndael will become AES without changes, and that's the > impression I got after threading through the NIST pages. And it would > be a shame if we were to use the "rijndael" name long after it has > been declared AES. > > So, what's it going to be? After reading the NIST pages... I would prefer we use AES in the draft. Something like: "aes128-cbc" "aes192-cbc" "aes256-cbc" Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Wed Oct 11 06:37:42 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05801 for ; Wed, 11 Oct 2000 06:37:42 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id LAA24110 for ietf-ssh-outgoing; Wed, 11 Oct 2000 11:42:53 +0300 Received: from mail.mindbright.se (IDENT:postfix@mindterm.appgate.com [193.12.107.237]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id LAA24016 for ; Wed, 11 Oct 2000 11:42:27 +0300 Received: by mail.mindbright.se (Postfix, from userid 1001) id 62E071FF01; Wed, 11 Oct 2000 10:43:19 +0200 (MEST) Received: from localhost (localhost [127.0.0.1]) by mail.mindbright.se (Postfix) with ESMTP id 5C5C71F101; Wed, 11 Oct 2000 10:43:19 +0200 (MEST) Date: Wed, 11 Oct 2000 10:43:19 +0200 (MEST) From: Mats Andersson X-Sender: mats@mindterm.appgate.com To: Sami Lehtinen Cc: ietf-ssh@clinet.fi Subject: Re: Revising the document In-Reply-To: <14819.25103.861652.268558@asgard.tky.hut.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.clinet.fi id LAA24060 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id LAA24110 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA05801 Hi, Some small questions about the drafts: 1) In the connection draft nothing is explicitly said about whether GLOBAL_REQUESTS can be sent to the peer without waiting for response. Though since nothing identifies the response I guess it is implicit that one HAVE to wait. Maybe this should be stated explicitly? 2) When requesting remote forwarding it would be convenient to be able to specify a port number 0 to indicate any port and have the response include the bound port. 3) I might have missed something but I think that some of the disconnect reasons in the transport draft might need some definition/clarification (e.g. SSH_DISCONNECT_CONNECTION_LOST, who lost which connection?). Another example is I guess that now the SSH_DISCONNECT_KEY_EXCHANGE_FAILED should be sent when host authentication fails? Hence the SSH_DISCONNECT_RESERVED for the "deprecated" SSH_DISCONNECT_HOST_AUTHENTICATION_FAILED? 4) The drafts ("combined" transport/connection) doesn't say anything about when the transport is taken down (if ever implicitly?). E.g. openssh disconnects the transport layer when the "last" session channel has exited. My interpretation is that the transport layer must be explicitly killed by the client when it doesn't need it any more (or for some reason, e.g. "idle timeout", by the server). Is this (should this be) defined? Cheers, /Mats On Tue, 10 Oct 2000, Sami Lehtinen wrote: > Niels Mцller, on September 27. 2000, wrote: > : I'd like to know who, if any, is working as document editor for > : revising the current drafts? > > Ho. > > -- > [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] > [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] > [SSH Communications Security Corp http://www.ssh.com/] > From owner-ietf-ssh@clinet.fi Wed Oct 11 07:34:13 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06977 for ; Wed, 11 Oct 2000 07:34:12 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA03831 for ietf-ssh-outgoing; Wed, 11 Oct 2000 12:37:46 +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 MAA03776 for ; Wed, 11 Oct 2000 12:37:32 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 5BBB02409FFD; Wed, 11 Oct 2000 11:37:28 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id LAA14998; Wed, 11 Oct 2000 11:37:28 +0200 (MET DST) To: Sami Lehtinen Cc: RJ Atkinson , Martin Forssen , Bill Sommerfeld , Tero Kivinen , ietf-ssh@clinet.fi Subject: Re: New bulk encryption algorithms References: <4.3.2.7.2.20001003171650.00b074b0@sc-sol-04.extremenetworks.com> <4.3.2.7.2.20001004105802.00abbca0@sc-sol-04.extremenetworks.com> <14819.33045.121267.929575@asgard.tky.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 11 Oct 2000 11:37:27 +0200 In-Reply-To: Sami Lehtinen's message of "Tue, 10 Oct 2000 23:50:29 +0300 (EEST)" Message-ID: Lines: 19 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Sami Lehtinen writes: > There have been opinions about this for both sides, but no real > consensus. As I'm currently trying to finish these, I'd like to know > which should it be. Personally, I'd like AES, but because it isn't > officially official yet, there just might be changes. "aes256-cbc" is fine with me, provided that we all agree that *if* the final "aes" turns out to be different from today's "rijndael" (say, two more rounds or something like that), we'll all update our implementations and just accept the temporary interoperability problems that causes. I.e. it should be clear that the specs that exist today (i.e. the rijndael aes proposal documents) are not a canonical definition of "aes". I'm considering also using "rijndael-cbc@lysator.liu.se" as a local alias for the time being. /Niels From owner-ietf-ssh@clinet.fi Wed Oct 11 09:42:18 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10591 for ; Wed, 11 Oct 2000 09:42:18 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id OAA03294 for ietf-ssh-outgoing; Wed, 11 Oct 2000 14:55:10 +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 OAA03285 for ; Wed, 11 Oct 2000 14:55:09 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id B14D0240A014; Wed, 11 Oct 2000 13:55:06 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id NAA08536; Wed, 11 Oct 2000 13:55:06 +0200 (MET DST) To: Mats Andersson Cc: Sami Lehtinen , ietf-ssh@clinet.fi Subject: Re: Revising the document References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 11 Oct 2000 13:55:06 +0200 In-Reply-To: Mats Andersson's message of "Wed, 11 Oct 2000 10:43:19 +0200 (MEST)" Message-ID: Lines: 52 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Mats Andersson writes: > 1) In the connection draft nothing is explicitly said about whether > GLOBAL_REQUESTS can be sent to the peer without waiting for response. > Though since nothing identifies the response I guess it is implicit that > one HAVE to wait. Maybe this should be stated explicitly? The important thing is that replies to GLOBAL_REQUEST:s that have want_reply = 1 are sent in the right order. There should be no problem with having several requests pending. It requires some extra bookkeping to queue replies if one supports some kind of global request which one can't reply to immediately. > 2) When requesting remote forwarding it would be convenient to be able to > specify a port number 0 to indicate any port and have the response include > the bound port. Could be useful, but I think I'd prefer a new requst type for doing that. If this is addressed, it may also be useful to be able to bind other kind of sockets, like AF_LOCAL sockets and UDP sockets. > 3) I might have missed something but I think that some of the disconnect > reasons in the transport draft might need some definition/clarification > (e.g. SSH_DISCONNECT_CONNECTION_LOST, who lost which connection?). Another > example is I guess that now the SSH_DISCONNECT_KEY_EXCHANGE_FAILED should > be sent when host authentication fails? Hence the SSH_DISCONNECT_RESERVED > for the "deprecated" SSH_DISCONNECT_HOST_AUTHENTICATION_FAILED? I agree, I think it's very unclear what the intended meaning of the different disconnect reason codes are. > 4) The drafts ("combined" transport/connection) doesn't say anything about > when the transport is taken down (if ever implicitly?). E.g. openssh > disconnects the transport layer when the "last" session channel has > exited. My interpretation is that the transport layer must be explicitly > killed by the client when it doesn't need it any more (or for some reason, > e.g. "idle timeout", by the server). Is this (should this be) defined? I think this is mostly an application issue, not a protocol issue. I believe a server should usually never initiate take down of the transport layer (even if it could be considered in situations were there is some limit on the number of simultaneous connections and some connection appears idle). It should usually be left to the client to decide when to take down the connection and the transport protocol. There's one thing though: The spec should probably spell out that it is considered a protocol failure if the connection dies without a SSH_MSG_DISCONNECT message being sent or received. (According to the spec, one will never have both sent and received a SSH_MSG_DISCONNECT). /Niels From owner-ietf-ssh@clinet.fi Wed Oct 11 12:58:12 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15192 for ; Wed, 11 Oct 2000 12:58:12 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA05691 for ietf-ssh-outgoing; Wed, 11 Oct 2000 18:09:36 +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 SAA05672 for ; Wed, 11 Oct 2000 18:09:32 +0300 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id SAA14926; Wed, 11 Oct 2000 18:07:04 +0300 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Message-ID: <14820.33303.801971.810149@asgard.tky.hut.fi> Date: Wed, 11 Oct 2000 18:07:03 +0300 (EEST) To: Markus Friedl Cc: =?iso-8859-1?Q?Niels_M=F6ller?= , ietf-ssh@clinet.fi, openssh@openssh.com Subject: Re: Revising the document In-Reply-To: <20001011151103.A14796@folly> References: <14819.25103.861652.268558@asgard.tky.hut.fi> <20001011151103.A14796@folly> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id SAA05691 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA15192 Markus Friedl, on October 11. 2000, wrote: : On Tue, Oct 10, 2000 at 09:38:07PM +0300, Sami Lehtinen wrote: : > Niels Mцller, on September 27. 2000, wrote: : > : I'd like to know who, if any, is working as document editor for : > : revising the current drafts? : > : > Ho. : : So are you changing the specification for the MAC/hmac? Yes. It will be along the lines of "key length used MUST be the same as the digest length" or some such. That is, of course, unless someone else has a better idea? -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Thu Oct 12 16:32:11 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05394 for ; Thu, 12 Oct 2000 16:32:09 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id VAA27695 for ietf-ssh-outgoing; Thu, 12 Oct 2000 21:36:34 +0300 Received: from mail.mindbright.se (IDENT:postfix@mindterm.appgate.com [193.12.107.237]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id VAA27692 for ; Thu, 12 Oct 2000 21:36:34 +0300 Received: by mail.mindbright.se (Postfix, from userid 1001) id E33771FF01; Thu, 12 Oct 2000 20:37:26 +0200 (MEST) Received: from localhost (localhost [127.0.0.1]) by mail.mindbright.se (Postfix) with ESMTP id DC0801F101; Thu, 12 Oct 2000 20:37:26 +0200 (MEST) Date: Thu, 12 Oct 2000 20:37:26 +0200 (MEST) From: Mats Andersson X-Sender: mats@mindterm.appgate.com To: Tatu Ylonen Cc: =?iso-8859-1?Q?Niels_M=F6ller?= , Sami Lehtinen , ietf-ssh@clinet.fi Subject: Re: Revising the document In-Reply-To: <200010111717.UAA32374@torni.hel.fi.ssh.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.clinet.fi id VAA27693 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id VAA27695 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA05394 Hi, On Wed, 11 Oct 2000, Tatu Ylonen wrote: > transport layer connection can be closed at any time. In particular, > it was not intended to be a transport layer error to close the socket > (it may be an error for the higher layer protocols). Fair enough. Though I see no point in NOT having an orderly/well defined disconnect procedure in a transport protocol. > SSH_MSG_DISCONNECT was intended to signal errors. It should not be > sent on successful termination. So, the transport layer considers it an error when the application disconects it? (i.e. SSH_DISCONNECT_BY_APPLICATION). Some of the disconnect reasons are obvious but some are not well defined IMHO. > It is basically a client policy issue when to close the transport > layer connection. Agreed, that's why I asked since openssh seems to take another stance. > example if port forwarding is enabled, it may make perfect sense to > keep the transport layer connection open for a long time even when Exactly. On 11 Oct 2000, Niels Mцller wrote: > The important thing is that replies to GLOBAL_REQUEST:s that have > want_reply = 1 are sent in the right order. There should be no problem > with having several requests pending. I know, that's what my code does. Though it could (should?) be explicitly stated (since this might not be obvious for an implementor?). Note that it's stated explicitly for channel-requests: ... The client is allowed to send further messages without waiting for the response to the request. ... Cheers, /Mats From owner-ietf-ssh@clinet.fi Thu Oct 12 18:54:39 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07302 for ; Thu, 12 Oct 2000 18:54:39 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id AAA10087 for ietf-ssh-outgoing; Fri, 13 Oct 2000 00:18:38 +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 AAA10079 for ; Fri, 13 Oct 2000 00:18:32 +0300 Received: from mosquito.inet.org ([216.52.8.30]) by inner.net (8.7.6/8.9.3) with ESMTP id VAA19762 for ; Thu, 12 Oct 2000 21:09:20 GMT Message-Id: <4.3.2.7.2.20001012170959.00b3bc50@avarice.inner.net> X-Sender: rja@avarice.inner.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Oct 2000 17:12:12 -0400 To: ietf-ssh@clinet.fi From: RJ Atkinson Subject: new hashes to go with AES Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ssh@clinet.fi Precedence: bulk NIST has new specs for 3 new SHA-2 hashes with length of 256, 384, and 512 bits. These were created for use with the new AES. NIST also reports that they will formally allocate ISO OIDs for AES and these new hashes, probably next week, which is further indication that NIST does not believe that any change in any of these algorithms is possible at this time. It would seem clever to allocate algorithm IDs in the drafts at this point, IMHO. Ran rja@inet.org From owner-ietf-ssh@clinet.fi Sun Oct 15 17:24:11 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10599 for ; Sun, 15 Oct 2000 17:24:10 -0400 (EDT) From: owner-ietf-ssh@clinet.fi Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA27073 for ietf-ssh-outgoing; Sun, 15 Oct 2000 22:15:18 +0300 Received: from smtp.clinet.fi (smtp.clinet.fi [194.100.0.12]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id WAA27069; Sun, 15 Oct 2000 22:15:17 +0300 Received: from unknown (ppp98-69.dialup.mtu-net.ru [212.188.98.69]) by smtp.clinet.fi (8.9.3/8.9.3) with SMTP id WAA60143; Sun, 15 Oct 2000 22:01:51 +0300 (EEST) Message-Id: <200010151901.WAA60143@smtp.clinet.fi> Date: Вс, 15 окт 2000 19:40:46 Subject: Интересное предложение Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Уважаемые господа ! Крупная компьютернея компания расширяет круг своих партнеров. Мы предлагаем поставки компьютеров и комплектующих. Почему выгодно работать с нами. 1. Низкие цены. Мы готовы дать Вам цены ниже чем те по которым Вы работаете с вашими поставщиками. 2. Мы без проблем можем организовать отправку грузов к Вам. 3. Гибкая система работы ( Нал, Безнал, и другие услуги) 4. Быстрая заменная гарантия. 5. Большой ассортимент товара. ( Более 3000 наименований ) 6. Большой склад. 7. Оперативность выполнения заказов. Свежий прайс-лист вы можете получить направив запрос по эл. почте. Если у Вас есть желание с нами поработать то пишите es_comp@mail.ru escomputer@mtu-net.ru или звоните +7(095) 747-7231 , 268-4633 Наш адрес: Москва, Стромынcкий пер. 7/23. п. 4 P.S. Прозьба данное письмо массовой рассылкой не считать, так как это конкретное коммерческое предложение. From owner-ietf-ssh@clinet.fi Mon Oct 16 23:14:10 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20860 for ; Mon, 16 Oct 2000 23:14:09 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id EAA12380 for ietf-ssh-outgoing; Tue, 17 Oct 2000 04:24:45 +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 EAA12377 for ; Tue, 17 Oct 2000 04:24:44 +0300 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id EAA19904; Tue, 17 Oct 2000 04:22:08 +0300 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14827.43456.303774.624863@asgard.tky.hut.fi> Date: Tue, 17 Oct 2000 04:22:08 +0300 (EEST) To: IETF-Secsh List Subject: New drafts (TODO) 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 Here's the minutes and some other things I bundled with it. The items marked with "%" are basically done. There are still issues open, though. I compiled them to the end. Please find the items, and my comments, below. Open issues/proposed resolutions: draft-ietf-secsh-architecture-05.txt % dangling reference to ssh-agent draft - rip out until agent draft exists. % anti-dns language in section 4.1 - rip out section 4.1; dead code. draft-ietf-secsh-transport-07.txt % eliminating redundant length fields - just do it. % add ssh-rsa key type - just do it. [done basically according to the spec I sent to the list earlier.] % arcfour - add cautionary text % key stretching clamps entropy to hash size - ok as is given current threat models, but document as such [cautionary text is in essence what Niels said here earlier] % packet size fuzz factor - document 35000 as arbitrary value larger than uncompressed size % secrecy of exchange hash - document that its best to keep it secret % dangling references to pkix, spki - both are now rfcs; correct references. % hmac-sha-96 => hmax-sha1-96 % HMAC key and digest length clarification [again, as Neils proposed] % aes and serpent algorithms [it's AES] draft-ietf-secsh-userauth-07.txt any certificate implementation experience? - none yet, but that's ok for now. draft-ietf-secsh-connect-07.txt % signal encoding - extend format, include optional string with signal name w/o SIG prefix. SIGBUS -> "BUS" [this is done as discussed in the WG meeting. Neils commented on this, but no one commented back. More thoughts on this?] % need references to X11, POSIX drafts - just add them. % ssh agent forwarding dangling references - remove for now until agent draft appears. Still open: draft-ietf-secsh-architecture-05.txt iana considerations section ok? - waiting for answer from AD draft-ietf-secsh-transport-07.txt optimistic algorithm negotiation - discuss on list. Should concatenated string encoding specify length of each string? (transport, section 6) - [chair couldn't find context; will take to list] DH parameter selection clarification - [chair couldn't find context; will take to list] Comments, please. Especially for the issues still open. -- [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 Tue Oct 17 01:13:04 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23354 for ; Tue, 17 Oct 2000 01:13:04 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id GAA25950 for ietf-ssh-outgoing; Tue, 17 Oct 2000 06:34:43 +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 GAA25946 for ; Tue, 17 Oct 2000 06:34:41 +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 UAA13522; Mon, 16 Oct 2000 20:34:36 -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 XAA11921; Mon, 16 Oct 2000 23:34:35 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e9H3Y1l153520; Mon, 16 Oct 2000 23:34:01 -0400 (EDT) Message-Id: <200010170334.e9H3Y1l153520@thunk.east.sun.com> From: Bill Sommerfeld To: Sami Lehtinen cc: IETF-Secsh List Subject: Re: New drafts (TODO) In-reply-to: Your message of "Tue, 17 Oct 2000 04:22:08 +0300." <14827.43456.303774.624863@asgard.tky.hut.fi> Reply-to: sommerfeld@east.sun.com Date: Mon, 16 Oct 2000 23:34:00 -0400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > Still open: > draft-ietf-secsh-architecture-05.txt > iana considerations section ok? > - waiting for answer from AD I just ping'ed the AD's. - Bill From owner-ietf-ssh@clinet.fi Wed Oct 18 12:36:52 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27269 for ; Wed, 18 Oct 2000 12:36:51 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA10572 for ietf-ssh-outgoing; Wed, 18 Oct 2000 17:41:47 +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 RAA10568 for ; Wed, 18 Oct 2000 17:41:45 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 46CA12401B4A; Wed, 18 Oct 2000 16:41:45 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id QAA12563; Wed, 18 Oct 2000 16:41:44 +0200 (MET DST) To: Sami Lehtinen Cc: IETF-Secsh List Subject: Signals (Re: New drafts (TODO)) References: <14827.43456.303774.624863@asgard.tky.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 18 Oct 2000 16:41:44 +0200 In-Reply-To: Sami Lehtinen's message of "Tue, 17 Oct 2000 04:22:08 +0300 (EEST)" Message-ID: Lines: 41 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Sami Lehtinen writes: > % signal encoding > - extend format, include optional string with > signal name w/o SIG prefix. > SIGBUS -> "BUS" > [this is done as discussed in the WG meeting. Neils commented on this, > but no one commented back. More thoughts on this?] Could someone explain the rational for the proposal? In general, I think that it is nice to include both a machine-friendly field (signal names, error codes, etc) and human-friendly ones in the same message. But is the optional name intended to be machine-friendly (in which case the old numeric field is redundant and should be obsoleted) or human-friendly (in which case the "machine-friendly" field is still broken, see below)? The problem with the current spec on signals is that the signal number field, which is intended to be machine-friendly, is broken. This is because the numbers assigned even to standard signals is implementation specific. When changing the signal encoding, the primary goal must be to fix the supposedly "machine-friendly" field; when that is done we can consider adding a human-readable field as well. As far as I can see, the change above doesn't solve the problem, and it doesn't add much value. So I would prefer that we either (1) leave the spec as is on this point, (2) or implement a change that does solve the problem. Alternative solutions could be to define "network signal numbers" as I have proposed earlier, or replace the signal number with a symbolic name. The latter approach has the advantage that non-standard signals could be encodeed as "name@domain", using the same extension mechanism as in the rest of the protocols, while the former approach offers some backwards compatibility. /Niels From owner-ietf-ssh@clinet.fi Wed Oct 18 12:39:30 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27652 for ; Wed, 18 Oct 2000 12:39:29 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA11771 for ietf-ssh-outgoing; Wed, 18 Oct 2000 17:51:10 +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 RAA11768 for ; Wed, 18 Oct 2000 17:51:08 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 6FBF024012D8; Wed, 18 Oct 2000 16:51:07 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id QAA24684; Wed, 18 Oct 2000 16:51:07 +0200 (MET DST) To: Sami Lehtinen Cc: IETF-Secsh List Subject: Optimistic algorithm negotiation (Re: New drafts (TODO)) References: <14827.43456.303774.624863@asgard.tky.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 18 Oct 2000 16:51:06 +0200 In-Reply-To: Sami Lehtinen's message of "Tue, 17 Oct 2000 04:22:08 +0300 (EEST)" Message-ID: Lines: 39 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Sami Lehtinen writes: > draft-ietf-secsh-transport-07.txt > optimistic algorithm negotiation - discuss on list. I think this is the single biggest problem in the current set of spec (the second is that all specified algorithm names should specify what algorithms are involved, but the definitions of names like "spki" and "openpgp" fail to do that). For optimistic algorithm negotiation, I think the ones who want this feature and have implemented it should be able to clearify exactly how it is supposed to work. In particular, we need an algorithm that takes two SSH_MSG_KEXINIT packets as input, and determines whether or not any guesses in those messages should be considered "successful". Without this, I think we should consider dropping that feature (i.e. we specify that the first_kex_packet_follows field should always be false in this version of the protocol, and leave the definition of the behaviour when that field is true for the next version of the protocol, or something like that). BTW, what is our current schedule? From the IETF 48 minutes : Schedule : : Sep 00 Finalization of core drafts : Oct 00 Last calls : Oct 00 Submit core drafts to IESG : Oct 00 Determine schedule for extensions : Nov 00 Submit extension drafts for discussion : Dec 00 Meet in SD : Sep 01 Submit core drafts for publication as draft standard we're trying to have the core drafts finished this month. But the milestones at http://www.ietf.org/html.charters/secsh-charter.html are not updated. /Niels From owner-ietf-ssh@clinet.fi Wed Oct 18 19:24:43 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17884 for ; Wed, 18 Oct 2000 19:24:42 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id AAA19513 for ietf-ssh-outgoing; Thu, 19 Oct 2000 00:42:42 +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 AAA19508 for ; Thu, 19 Oct 2000 00:42:40 +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 OAA11340; Wed, 18 Oct 2000 14:42:33 -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 RAA03276; Wed, 18 Oct 2000 17:42:32 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e9ILful155540; Wed, 18 Oct 2000 17:41:56 -0400 (EDT) Message-Id: <200010182141.e9ILful155540@thunk.east.sun.com> From: Bill Sommerfeld To: nisse@lysator.liu.se (Niels M ller) cc: Sami Lehtinen , IETF-Secsh List Subject: Re: Signals (Re: New drafts (TODO)) In-reply-to: Your message of "18 Oct 2000 16:41:44 +0200." Reply-to: sommerfeld@east.sun.com Date: Wed, 18 Oct 2000 17:41:56 -0400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > > % signal encoding > > - extend format, include optional string with > > signal name w/o SIG prefix. > > SIGBUS -> "BUS" > > [this is done as discussed in the WG meeting. Neils commented on this, > > but no one commented back. More thoughts on this?] > > Could someone explain the rational for the proposal? It's an attempt to avoid the need to create a canonical signal numbering space. > In general, I think that it is nice to include both a > machine-friendly field (signal names, error codes, etc) and > human-friendly ones in the same message. The string name is not intended to be human-friendly. > But is the optional name intended to be machine-friendly (in which > case the old numeric field is redundant and should be obsoleted) This was the intent; the old numeric field is left in place in the encoding so as to not cause an interoperability problem with existing implementations. - Bill From owner-ietf-ssh@clinet.fi Thu Oct 19 06:50:45 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA28241 for ; Thu, 19 Oct 2000 06:50:44 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id LAA27088 for ietf-ssh-outgoing; Thu, 19 Oct 2000 11:42:56 +0300 Received: from faui02.informatik.uni-erlangen.de (msfriedl@faui02.informatik.uni-erlangen.de [131.188.30.102]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id LAA27080 for ; Thu, 19 Oct 2000 11:42:54 +0300 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id KAA05968; Thu, 19 Oct 2000 10:42:46 +0200 (MET DST) Date: Thu, 19 Oct 2000 10:42:46 +0200 From: Markus Friedl To: Bill Sommerfeld Cc: nisse@lysator.liu.se, Sami Lehtinen , IETF-Secsh List Subject: Re: Signals (Re: New drafts (TODO)) Message-ID: <20001019104246.A3219@faui02.informatik.uni-erlangen.de> References: <200010182141.e9ILful155540@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <200010182141.e9ILful155540@thunk.east.sun.com>; from sommerfeld@east.sun.com on Wed, Oct 18, 2000 at 05:41:56PM -0400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Wed, Oct 18, 2000 at 05:41:56PM -0400, Bill Sommerfeld wrote: > > Could someone explain the rational for the proposal? > > It's an attempt to avoid the need to create a canonical signal > numbering space. this is a very good idea. but i think the signal numbers should be dropped. > [...] > > This was the intent; the old numeric field is left in place in the > encoding so as to not cause an interoperability problem with existing > implementations. i don't think this is necessary: secsh should not be bloated by this kind of legacy applications, so the new message should look like this: uint32 recipient channel string "signal" boolean FALSE strings signal type if you are talking to old implementations you can tell from the message size that the signal is encoded with a "uint32" instead of a string, but having a signal number without a defined mapping of signal to number is pointless. a part from this, adding a string to the signal message would break old implementations if they are checking the size of the message, so you have to deal with backward compatibility in some different way (e.g. using the version strings, like many implementations currenly do). so either define a mapping of signals to numbers or switch to the usage if strings only. -markus From owner-ietf-ssh@clinet.fi Thu Oct 19 06:55:44 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA28829 for ; Thu, 19 Oct 2000 06:55:43 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id LAA31222 for ietf-ssh-outgoing; Thu, 19 Oct 2000 11:59:22 +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 LAA31209 for ; Thu, 19 Oct 2000 11:59:20 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 53AF724012CC; Thu, 19 Oct 2000 10:59:19 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id KAA23571; Thu, 19 Oct 2000 10:59:18 +0200 (MET DST) To: Markus Friedl Cc: Bill Sommerfeld , Sami Lehtinen , IETF-Secsh List Subject: Re: Signals (Re: New drafts (TODO)) References: <200010182141.e9ILful155540@thunk.east.sun.com> <20001019104246.A3219@faui02.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 19 Oct 2000 10:59:18 +0200 In-Reply-To: Markus Friedl's message of "Thu, 19 Oct 2000 10:42:46 +0200" Message-ID: Lines: 34 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Markus Friedl writes: > so either define a mapping of signals to numbers or switch to > the usage if strings only. I agree. The only reason to include both a (broken) number and a string is to make it easier for an implementations to interoperate both with implementations that follow the spec and those that follow old drafts (i.e. all implementations that exist today). However, as Markus points out, 1. We still don't get complete backwards compatibility, as current implementations should consider extra junk in messages as protocol errors, and 2. The level of backwards compatibility that can be achieved that way can just as well be done by looking at the packet length. Actually, there's one subtlety with (2): Signal number 0 (encoded according to the current drafts) and the signal name "" (encoded according to an improved spec using strings) will look exacltly the same. But I don't think that is a problem: Both 0 and "" of questionable usefulness, and if handled at all both should be treated as some kind of "unspecified signal", and it doesn't matter if the sending part thought it was sending a zero or an empty string. lsh actually uses signal number 0, namely for signals that can't be mapped to its "network signal numbers". If we go for strings, should we specify a list of "standard" signals and require extension syntax (signal@domain) for signals not in that list? /Niels From owner-ietf-ssh@clinet.fi Thu Oct 19 15:01:42 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18664 for ; Thu, 19 Oct 2000 15:01:40 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA24640 for ietf-ssh-outgoing; Thu, 19 Oct 2000 20:07:36 +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 UAA24628 for ; Thu, 19 Oct 2000 20:07:34 +0300 Received: from sage ([192.168.0.38]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 551; Thu, 19 Oct 2000 11:09:06 -0600 Message-ID: <004b01c039f0$06a0a720$0500a8c0@sage> From: "Joseph Galbraith" To: "Markus Friedl" , "Bill Sommerfeld" Cc: , "Sami Lehtinen" , "IETF-Secsh List" References: <200010182141.e9ILful155540@thunk.east.sun.com> <20001019104246.A3219@faui02.informatik.uni-erlangen.de> Subject: Re: Signals (Re: New drafts (TODO)) Date: Thu, 19 Oct 2000 11:14:22 -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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, October 19, 2000 2:42 AM, Markus Friedl wrote: > On Wed, Oct 18, 2000 at 05:41:56PM -0400, Bill Sommerfeld wrote: > > > Could someone explain the rational for the proposal? > > > > It's an attempt to avoid the need to create a canonical signal > > numbering space. > > this is a very good idea. but i think the signal numbers > should be dropped. > > > [...] > > > > This was the intent; the old numeric field is left in place in the > > encoding so as to not cause an interoperability problem with existing > > implementations. > > i don't think this is necessary: secsh should not be bloated > by this kind of legacy applications, so the new message should > look like this: > > uint32 recipient channel > string "signal" > boolean FALSE > strings signal type > > if you are talking to old implementations you can tell > from the message size that the signal is encoded with a "uint32" > instead of a string, but having a signal number without a > defined mapping of signal to number is pointless. > > a part from this, adding a string to the signal message would > break old implementations if they are checking the size of > the message, so you have to deal with backward compatibility in > some different way (e.g. using the version strings, like many > implementations currenly do). I'd prefer to see us change the name of the request if we change it's format at this late date. This avoids all compatibility problems with the least amount of fuss. Old implementations should either ignore of fail the new request (based on the boolean flag.) New implementations seeking compatibility with old implementations can send the new request, and if that fails, send the old request, or just always send both. But, the point is, I don't have to burden my implementation with nasty cruft to detect whether the packet is one format or another... I just add an additional request type, which is pretty clean. So I would suggest we remove "signal" from the draft and replace it with "named-signal" or "signal2" ... does anyone have a better name? Thanks, Joseph Galbraith galb-list@vandyke.com From owner-ietf-ssh@clinet.fi Thu Oct 19 17:34:29 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12656 for ; Thu, 19 Oct 2000 17:34:28 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA05356 for ietf-ssh-outgoing; Thu, 19 Oct 2000 22:19:50 +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 WAA05353 for ; Thu, 19 Oct 2000 22:19:49 +0300 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id WAA21748; Thu, 19 Oct 2000 22:17:04 +0300 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14831.18607.884406.570962@asgard.tky.hut.fi> Date: Thu, 19 Oct 2000 22:17:03 +0300 (EEST) To: "Joseph Galbraith" Cc: "Markus Friedl" , "Bill Sommerfeld" , , "IETF-Secsh List" Subject: Re: Signals (Re: New drafts (TODO)) In-Reply-To: <004b01c039f0$06a0a720$0500a8c0@sage> References: <200010182141.e9ILful155540@thunk.east.sun.com> <20001019104246.A3219@faui02.informatik.uni-erlangen.de> <004b01c039f0$06a0a720$0500a8c0@sage> 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 Joseph Galbraith, on October 19. 2000, wrote: : I'd prefer to see us change the name of the request if we : change it's format at this late date. : : This avoids all compatibility problems with the least : amount of fuss. : : Old implementations should either ignore of fail the new : request (based on the boolean flag.) [...] : So I would suggest we remove "signal" from the draft : and replace it with "named-signal" or "signal2" ... : does anyone have a better name? Somehow I don't like this. Yes, it may be clean in the implementation, but inventing new names in place of the old doesn't sound nice, IMHO. And remember, there is also "exit-signal". Should that be "named-exit-signal" or "exit-signal2" in the new draft? I think we should keep the old messages (and change the format), and deal with the incompatibilities. Because no matter what we do with the drafts at this point will lead to incompatibility with the old drafts (and implementations). -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Fri Oct 20 05:55:17 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09272 for ; Fri, 20 Oct 2000 05:55:16 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id KAA15326 for ietf-ssh-outgoing; Fri, 20 Oct 2000 10:38:58 +0300 Received: from nic.appgate.com (nic.appgate.com [193.12.107.226]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id KAA15317 for ; Fri, 20 Oct 2000 10:38:56 +0300 Received: from pelee.firedoor.se (pelee.firedoor.se [172.23.2.10]) by nic.appgate.com (Postfix) with ESMTP id 82AA93BD06 for ; Fri, 20 Oct 2000 09:38:56 +0200 (MET DST) Received: from appgate.com (maunaloa.firedoor.se [172.23.2.56]) by pelee.firedoor.se (Postfix) with ESMTP id 49CF231772 for ; Fri, 20 Oct 2000 09:38:53 +0200 (MEST) Date: Fri, 20 Oct 2000 09:38:50 +0200 (MEST) From: Martin Forssen Subject: New keyboard-interactive draft available To: ietf-ssh@clinet.fi MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20001020073853.49CF231772@pelee.firedoor.se> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk I have finally updated the old and since long expired draft on the keyboard-interactive authentication method draft. The new version is available at the following location: http://www.appgate.com/~maf/secsh-auth-kbdinteract-01.txt There has been no changes to the actual protocol but clarifying text has been added at various places and the examples have been corrected. I have contacted the work group chair and he has promised to look into making this official once he finds the time. /MaF From owner-ietf-ssh@clinet.fi Fri Oct 20 15:51:52 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08191 for ; Fri, 20 Oct 2000 15:51:51 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA13376 for ietf-ssh-outgoing; Fri, 20 Oct 2000 20:15:59 +0300 Message-Id: <200010201715.UAA13376@mail.clinet.fi> Received: from psismtp2.psi.airtel.es (back.airtel.net [212.73.32.158]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA13372 for ; Fri, 20 Oct 2000 20:15:57 +0300 Date: Fri, 20 Oct 2000 20:15:57 +0300 Received: from lider09 ([212.73.54.24]) by psismtp2.psi.airtel.es (ESMTP service) with SMTP id G2QNG200.Z7C; Fri, 20 Oct 2000 19:04:50 +0200 From: OfertaЎЎ To: Oferta Nokia 3210 X-Priority: 1 Reply-To: info@grupolidertel.com X-Mailer: MultiMailer (3.1.0) Subject: Nokia 3210 2 x 3995 ptsЎЎ T10 al mismo precioЎЎЎЎЎ Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by mail.clinet.fi id UAA13373 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id UAA13376 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA08191 Oferta impresionante en www.grupolidertel.com dos nokia 3210 o dos ericson t10 por 3995 ptsЎЎЎ ademas si eres cliente de otro operador 32.000 pts en llamdas y alta gratis podras llamar entre esos dos telefonos cualquier dia a cualquier hora por 10 pts min. o si lo prefieres dos alcatel club gratis. si eres cliente de otro operador 32.000 pts en llamdas y alta gratis podras llamar entre esos dos telefonos cualquier dia a cualquier hora por 10 pts min. y una semana de estancia gratis y sin sorteo valorada en 70.000 pts en canarias, baleares o costa mediterranea. www.grupolidertel.com Este envio no es spam, esta vd incluido en una lista de distribucion de la que puede ser removido definitivamente mandando un e mail con asunto borrar y este debe estar en blanco, recibira una confirmacion de que ha sido eliminado. From owner-ietf-ssh@clinet.fi Fri Oct 20 21:13:46 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27621 for ; Fri, 20 Oct 2000 21:13:45 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA02691 for ietf-ssh-outgoing; Sat, 21 Oct 2000 02:20:05 +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 CAA02688 for ; Sat, 21 Oct 2000 02:20:05 +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 CAA16805 for ; Sat, 21 Oct 2000 02:20:04 +0300 (EEST) Received: (from sshlist@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.17) id CAA11316 for ietf-ssh@clinet.fi; Sat, 21 Oct 2000 02:20:03 +0300 (EET DST) Received: from dns.hokuto.ed.jp (dns.hokuto.ed.jp [210.233.0.34]) by mail.clinet.fi (8.9.3/8.9.3) with SMTP id IAA16486 for ; Fri, 20 Oct 2000 08:05:55 +0300 Message-ID: <001701c03a33$4eb1eb80$7344efc3@user> From: "DirectPost" To: ietf-ssh@clinet.fi Subject: =?koi8-r?B?987JzcHOycAg0tXLz9fPxMnUxczFyiDP1MTFzM/XINDSz8TB1iwgzQ==?= =?koi8-r?B?wdLLxdTPzM/Hz9csICDNxc7FxNbF0s/XINDPINLFy8zBzcUh?= Date: Fri, 20 Oct 2000 05:16:00 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C03A54.D5898FC0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C03A54.D5898FC0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable =F7=C1=CD =D0=D2=C5=C4=CC=C1=C7=C1=C5=D4=D3=D1 = =D0=D2=C9=CF=C2=D2=C5=D3=D4=C9 =D5=CE=C9=CB=C1=CC=D8=CE=D9=CA = =D0=D2=CF=C7=D2=C1=CD=CD=CE=D9=CA =CB=CF=CD=D0=CC=C5=CB=D3, = =CB=CF=D4=CF=D2=D9=CA =D0=CF=DA=D7=CF=CC=C9=D4 =C4=CF=CE=C5=D3=D4=C9 = =F7=C1=DB=D5 =D2=C5=CB=CC=C1=CD=CE=D5=C0 =C9=CE=C6=CF=D2=CD=C1=C3=C9=C0 = =C9=CC=C9 =CB=CF=CD=CD=C5=D2=DE=C5=D3=CB=CF=C5 = =D0=D2=C5=C4=CC=CF=D6=C5=CE=C9=C5 =C4=CF = =CD=CE=CF=C7=CF=D4=D9=D3=D1=DE=CE=CF=CA =C1=D5=C4=C9=D4=CF=D2=C9=C9 = =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=C5=CA = =DC=CC=C5=CB=D4=D2=CF=CE=CE=CF=CA =D0=CF=DE=D4=D9.=20 =F0=D2=CF=C7=D2=C1=CD=CD=CE=D9=CA =CB=CF=CD=D0=CC=C5=CB=D3 = =D3=CF=D3=D4=CF=C9=D4 =C9=DA =C2=C1=DA=D9 =C1=C4=D2=C5=D3=CF=D7 =C9 = =D0=C5=D2=D3=CF=CE=C1=CC=D8=CE=CF=C7=CF =D0=CF=DE=D4=CF=D7=CF=C7=CF = =D3=C5=D2=D7=C5=D2=C1 =D5=D3=D4=C1=CE=C1=D7=CC=C9=D7=C1=C5=CD=CF=C7=CF = =CE=C1 =F7=C1=DB =CB=CF=CD=D0=D8=C0=D4=C5=D2, =C1 =D4=C1=CB=D6=C5, = =D5=CE=C9=CB=C1=CC=D8=CE=CF=CA =D0=D2=CF=C7=D2=C1=CD=CD=D9 =C4=CC=D1 = =D3=C2=CF=D2=C1 e-mail =C1=C4=D2=C5=D3=CF=D7 = =C9=CE=D4=C5=D2=C5=D3=D5=C0=DD=C5=CA =F7=C1=D3 =D4=C5=CD=C1=D4=C9=CB=C9 = =D7 =D3=C5=D4=C9.=20 =F0=D2=C5=C4=CC=C1=C7=C1=C5=CD=C1=D1 =D7 =CB=CF=CD=D0=CC=C5=CB=D4=C5 = =C2=C1=DA=C1 =D3=CF=C4=C5=D2=D6=C9=D4 =C2=CF=CC=C5=C5 200 =D4=D9=D3 = =C1=C4=D2=C5=D3=CF=D7 =DC=CC=C5=CB=D4=D2=CF=CE=CE=CF=CA =D0=CF=DE=D4=D9 = =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=C5=CA = =D2=CF=D3=D3=C9=CA=D3=CB=CF=C7=CF =D3=C5=C7=CD=C5=CE=D4=C1 = =C9=CE=D4=C5=D2=CE=C5=D4. =F7=CF-=D0=C5=D2=D7=D9=C8, =DC=D4=CF = =D0=D2=C1=CB=D4=C9=DE=C5=D3=CB=C9 =D7=D3=C5 = =CF=C6=C9=C3=C9=C1=CC=D8=CE=D9=C5 e-mail =C1=C4=D2=C5=D3=C1 = =D0=D2=C5=C4=D0=D2=C9=D1=D4=C9=CA =C9 =D5=DE=D2=C5=D6=C4=C5=CE=C9=CA = =F2=CF=D3=D3=C9=CA=D3=CB=CF=CA =E6=C5=C4=C5=D2=C1=C3=C9=C9 = (=C1=C4=D2=C5=D3=C1 =C9=CD=D0=CF=D2=D4=C9=D2=CF=D7=C1=CE=D9 =C9=DA = =C2=CF=CC=D8=DB=C9=CE=D3=D4=D7=C1 =CB=CF=CD=CD=C5=D2=DE=C5=D3=CB=C9=C8 = =C2=C1=DA =C4=C1=CE=CE=D9=C8), =D7=CF-=D7=D4=CF=D2=D9=C8, =DC=D4=CF = =C1=C4=D2=C5=D3=C1 =DE=C1=D3=D4=CE=D9=C8 =CC=C9=C3 = =D0=D2=CF=D1=D7=CC=D1=C0=DD=C9=C8 =C1=CB=D4=C9=D7=CE=CF=D3=D4=D8 =D7 = =D3=C5=D4=C9, =D3=D2=C5=C4=C9 =CB=CF=D4=CF=D2=D9=C8 = =D2=D5=CB=CF=D7=CF=C4=C9=D4=C5=CC=C9 =D0=D2=C5=C4=D0=D2=C9=D1=D4=C9=CA, = =D0=D2=C5=C4=D0=D2=C9=CE=C9=CD=C1=D4=C5=CC=C9, =D0=CF=CC=C9=D4=C9=CB=C9, = =CC=C0=C4=C9 =C9=D3=CB=D5=D3=D3=D4=D7=C1. =E2=C1=DA=C1 =CE=C5 = =D3=D4=D2=D5=CB=D4=D5=D2=C9=D2=CF=D7=C1=CE=C1 =D0=CF = =CF=D4=D2=C1=D3=CC=D1=CD =D0=D2=CF=C9=DA=D7=CF=C4=D3=D4=D7=C1 =C9 = =D2=C5=C7=C9=CF=CE=C1=CD, =CE=CF =CF=D3=D5=DD=C5=D3=D4=D7=CC=D1=D1 = =D2=C1=D3=D3=D9=CC=CB=D5 =D0=CF =D7=D3=C5=CA =C2=C1=DA=C5 - =F7=D9 = =CF=C8=D7=C1=D4=D9=D7=C1=C5=D4=C5 =D0=D2=C1=CB=D4=C9=DE=C5=D3=CB=C9 = =D7=D3=C5 =D3=C5=CB=D4=CF=D2=C1 =D2=D9=CE=CB=C1 =C9 =D3=C6=C5=D2=D9 = =C9=CE=D4=C5=D2=C5=D3=CF=D7. =EB=C1=D6=C4=CF=C5 = =CF=D4=D0=D2=C1=D7=CC=D1=C5=CD=CF=C5 =D0=C9=D3=D8=CD=CF = =D3=CF=C4=C5=D2=D6=C9=D4 =D7 =DA=C1=C7=CF=CC=CF=D7=CB=C5 =C1=C4=D2=C5=D3 = =CB=CF=CE=CB=D2=C5=D4=CE=CF=C7=CF =D0=CF=CC=D5=DE=C1=D4=C5=CC=D1, = =D0=CF=DC=D4=CF=CD=D5 =F7=C1=DB=C1 =D2=C1=D3=D3=D9=CC=CB=C1 =CE=C5 = =C2=D5=C4=C5=D4 =D3=DE=C9=D4=C1=D4=D8=D3=D1 =F3=D0=C1=CD=CF=CD!=20 =F4=C1=CB=C9=CD =CF=C2=D2=C1=DA=CF=CD, =CB=C1=CB = =D0=CF=CB=C1=DA=D9=D7=C1=C5=D4 =D0=D2=C1=CB=D4=C9=CB=C1, = =DC=C6=C6=C5=CB=D4=C9=D7=CE=CF=D3=D4=D8 =D4=C1=CB=CF=CA = =D2=C5=CB=CC=C1=CD=CE=D9 =C9=DA-=DA=C1 =DB=C9=D2=CF=D4=D9 = =CF=C8=D7=C1=D4=C1 =C1=D5=C4=C9=D4=CF=D2=C9=CA =D3=D2=C1=D7=CE=C9=CD=C1 = =D3 =D2=C5=CB=CC=C1=CD=CE=D9=CD=C9 =D2=CF=CC=C9=CB=C1=CD=C9 =CE=C1 = =C3=C5=CE=D4=D2=C1=CC=D8=CE=CF=CD =D4=C5=CC=C5=D7=C9=C4=C5=CE=C9=C9! =20 =E1 =D3=D4=CF=C9=D4 =CE=C1=DB =D0=D2=CF=C7=D2=C1=CD=CD=CE=D9=CA = =CB=CF=CD=D0=CC=C5=CB=D3 =D7=D3=C5=C7=CF 3500 =D2=D5=C2=CC=C5=CA. =FA=C1 = =DC=D4=C9 =C4=C5=CE=D8=C7=C9 =F7=D9 =D0=CF=CC=D5=DE=C1=C5=D4=C5 = =D5=CE=C9=CB=C1=CC=D8=CE=D5=C0 =D0=D2=CF=C7=D2=C1=CD=CD=D5 = =CF=D3=D5=DD=C5=D3=D4=D7=CC=D1=C0=DD=D5=C0 =D2=C1=D3=D3=D9=CC=CB=D5 = (=D7=C1=DB =D3=CF=C2=D3=D4=D7=C5=CE=CE=D9=CA =D0=CF=DE=D4=CF=D7=D9=CA = =D3=C5=D2=D7=C5=D2!!!), =C2=C1=DA=D5 =C4=C1=CE=CE=D9=C8 e-mail = =C1=C4=D2=C5=D3=CF=D7 =D3=CF=C4=C5=D2=D6=C1=DD=D5=C0 =C1=C4=D2=C5=D3=C1 = =D0=D2=C1=CB=D4=C9=DE=C5=D3=CB=C9 =F7=D3=C5=C8 = =D0=D2=C5=C4=D0=D2=C9=D1=D4=C9=CA, =C1 =D4=C1=CB=D6=C5 = =DE=C1=D3=D4=CE=D9=C8 =CC=C9=C3, =D3=D2=C5=C4=C9 =CB=CF=D4=CF=D2=D9=C8 = =D2=D5=CB=CF=D7=CF=C4=C9=D4=C5=CC=C9 =D0=D2=C5=C4=D0=D2=C9=D1=D4=C9=CA, = =D0=D2=C5=C4=D0=D2=C9=CE=C9=CD=C1=D4=C5=CC=C9 , = =D0=CF=CC=C9=D4=C9=CB=C9, =D4=C1=CB=D6=C5 =D0=D2=CF=C7=D2=C1=CD=CD=D5 = =C4=CC=D1 =D3=C1=CD=CF=D3=D4=CF=D1=D4=C5=CC=D8=CE=CF=C7=CF = =D3=C2=CF=D2=C1 =C1=C4=D2=C5=D3=CF=D7 =D7 =D3=C5=D4=C9 =D0=CF = =CB=CC=C0=DE=C5=D7=D9=CD =D3=CC=CF=D7=C1=CD! =F7=D9=C2=CF=D2 =DA=C1 =F7=C1=CD=C9! =E5=D3=CC=C9 =F7=C1=D3 =DA=C1=C9=CE=D4=C5=D2=C5=D3=CF=D7=C1=CC=CF = =CE=C1=DB=C5 =D0=D2=C5=C4=CC=CF=D6=C5=CE=C9=C5 = =F5=E2=E5=E4=E9=F4=E5=EC=F8=EE=E1=F1 =F0=F2=EF=F3=F8=E2=E1 =D3=D7=CF=C9 = =DA=C1=CB=C1=DA=D9 =CE=C1=D0=D2=C1=D7=CC=D1=D4=D8 = =CF=C4=CE=CF=D7=D2=C5=CD=C5=CE=CE=CF =CE=C1 =C4=D7=C1 = =C1=C4=D2=C5=D3=C1: =E5=D3=CC=C9 =D7 =D0=C9=D3=D8=CD=C5 =F7=D9 = =D5=CB=C1=D6=C9=D4=C5 =D3=D7=CF=CA =D4=C5=CC=C5=C6=CF=CE - =CE=C1=DB = =CD=C5=CE=C5=C4=D6=C5=D2 =D3=D7=D1=D6=C5=D4=D3=D1 =D3 =F7=C1=CD=C9. directpost@rambler.ru directpost@x707.net=20 =E9=CC=C9 ICQ 95210206 =F3=D0=C1=D3=C9=C2=CF =DA=C1 =D7=CE=C9=CD=C1=CE=C9=C5! = =F0=D2=CF=D3=C9=CD =D0=D2=CF=DD=C5=CE=C9=D1 =DA=C1 = =CE=C5=CF=D6=C9=C4=C1=CE=CE=CF=C5 =D7=D4=CF=D2=D6=C5=CE=C9=C5. ------=_NextPart_000_0014_01C03A54.D5898FC0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
=F7=C1=CD = =D0=D2=C5=C4=CC=C1=C7=C1=C5=D4=D3=D1 =D0=D2=C9=CF=C2=D2=C5=D3=D4=C9 = =D5=CE=C9=CB=C1=CC=D8=CE=D9=CA=20 =D0=D2=CF=C7=D2=C1=CD=CD=CE=D9=CA =CB=CF=CD=D0=CC=C5=CB=D3,  =CB=CF=D4=CF=D2=D9=CA=20 =D0=CF=DA=D7=CF=CC=C9=D4 =C4=CF=CE=C5=D3=D4=C9 =F7=C1=DB=D5 = =D2=C5=CB=CC=C1=CD=CE=D5=C0 =C9=CE=C6=CF=D2=CD=C1=C3=C9=C0 =C9=CC=C9 = =CB=CF=CD=CD=C5=D2=DE=C5=D3=CB=CF=C5 =D0=D2=C5=C4=CC=CF=D6=C5=CE=C9=C5 = =C4=CF=20 =CD=CE=CF=C7=CF=D4=D9=D3=D1=DE=CE=CF=CA  =C1=D5=C4=C9=D4=CF=D2=C9=C9=20 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=C5=CA = =DC=CC=C5=CB=D4=D2=CF=CE=CE=CF=CA =D0=CF=DE=D4=D9.=20

=F0=D2=CF=C7=D2=C1=CD=CD=CE=D9=CA = =CB=CF=CD=D0=CC=C5=CB=D3 =D3=CF=D3=D4=CF=C9=D4 =C9=DA =C2=C1=DA=D9 = =C1=C4=D2=C5=D3=CF=D7 =C9 =D0=C5=D2=D3=CF=CE=C1=CC=D8=CE=CF=C7=CF=20 =D0=CF=DE=D4=CF=D7=CF=C7=CF =D3=C5=D2=D7=C5=D2=C1 = =D5=D3=D4=C1=CE=C1=D7=CC=C9=D7=C1=C5=CD=CF=C7=CF =CE=C1 =F7=C1=DB = =CB=CF=CD=D0=D8=C0=D4=C5=D2, =C1 =D4=C1=CB=D6=C5, = =D5=CE=C9=CB=C1=CC=D8=CE=CF=CA=20 =D0=D2=CF=C7=D2=C1=CD=CD=D9 =C4=CC=D1 =D3=C2=CF=D2=C1 e-mail =C1=C4=D2=C5=D3=CF=D7 = =C9=CE=D4=C5=D2=C5=D3=D5=C0=DD=C5=CA =F7=C1=D3 =D4=C5=CD=C1=D4=C9=CB=C9 = =D7=20 =D3=C5=D4=C9.

=F0=D2=C5=C4=CC=C1=C7=C1=C5=CD=C1=D1 =D7 =CB=CF=CD=D0=CC=C5=CB=D4=C5 = =C2=C1=DA=C1 =D3=CF=C4=C5=D2=D6=C9=D4 =C2=CF=CC=C5=C5 200 =D4=D9=D3 = =C1=C4=D2=C5=D3=CF=D7 =DC=CC=C5=CB=D4=D2=CF=CE=CE=CF=CA=20 =D0=CF=DE=D4=D9 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=C5=CA = =D2=CF=D3=D3=C9=CA=D3=CB=CF=C7=CF =D3=C5=C7=CD=C5=CE=D4=C1 = =C9=CE=D4=C5=D2=CE=C5=D4. =F7=CF-=D0=C5=D2=D7=D9=C8, =DC=D4=CF = =D0=D2=C1=CB=D4=C9=DE=C5=D3=CB=C9=20 =D7=D3=C5 =CF=C6=C9=C3=C9=C1=CC=D8=CE=D9=C5 e-mail =C1=C4=D2=C5=D3=C1 = =D0=D2=C5=C4=D0=D2=C9=D1=D4=C9=CA =C9 =D5=DE=D2=C5=D6=C4=C5=CE=C9=CA = =F2=CF=D3=D3=C9=CA=D3=CB=CF=CA =E6=C5=C4=C5=D2=C1=C3=C9=C9=20 (=C1=C4=D2=C5=D3=C1 =C9=CD=D0=CF=D2=D4=C9=D2=CF=D7=C1=CE=D9 =C9=DA = =C2=CF=CC=D8=DB=C9=CE=D3=D4=D7=C1 =CB=CF=CD=CD=C5=D2=DE=C5=D3=CB=C9=C8 = =C2=C1=DA =C4=C1=CE=CE=D9=C8), =D7=CF-=D7=D4=CF=D2=D9=C8, =DC=D4=CF=20 =C1=C4=D2=C5=D3=C1 =DE=C1=D3=D4=CE=D9=C8 =CC=C9=C3 = =D0=D2=CF=D1=D7=CC=D1=C0=DD=C9=C8 =C1=CB=D4=C9=D7=CE=CF=D3=D4=D8 =D7 = =D3=C5=D4=C9, =D3=D2=C5=C4=C9 =CB=CF=D4=CF=D2=D9=C8 = =D2=D5=CB=CF=D7=CF=C4=C9=D4=C5=CC=C9=20 =D0=D2=C5=C4=D0=D2=C9=D1=D4=C9=CA, = =D0=D2=C5=C4=D0=D2=C9=CE=C9=CD=C1=D4=C5=CC=C9, =D0=CF=CC=C9=D4=C9=CB=C9, = =CC=C0=C4=C9 =C9=D3=CB=D5=D3=D3=D4=D7=C1. =E2=C1=DA=C1 =CE=C5=20 =D3=D4=D2=D5=CB=D4=D5=D2=C9=D2=CF=D7=C1=CE=C1  =D0=CF = =CF=D4=D2=C1=D3=CC=D1=CD=20 =D0=D2=CF=C9=DA=D7=CF=C4=D3=D4=D7=C1 =C9 =D2=C5=C7=C9=CF=CE=C1=CD, = =CE=CF =CF=D3=D5=DD=C5=D3=D4=D7=CC=D1=D1 =D2=C1=D3=D3=D9=CC=CB=D5 = =D0=CF =D7=D3=C5=CA =C2=C1=DA=C5 - =F7=D9=20 =CF=C8=D7=C1=D4=D9=D7=C1=C5=D4=C5 =D0=D2=C1=CB=D4=C9=DE=C5=D3=CB=C9 = =D7=D3=C5 =D3=C5=CB=D4=CF=D2=C1 =D2=D9=CE=CB=C1 =C9 =D3=C6=C5=D2=D9 = =C9=CE=D4=C5=D2=C5=D3=CF=D7.  =EB=C1=D6=C4=CF=C5 = =CF=D4=D0=D2=C1=D7=CC=D1=C5=CD=CF=C5 =D0=C9=D3=D8=CD=CF = =D3=CF=C4=C5=D2=D6=C9=D4 =D7=20 =DA=C1=C7=CF=CC=CF=D7=CB=C5 =C1=C4=D2=C5=D3 = =CB=CF=CE=CB=D2=C5=D4=CE=CF=C7=CF =D0=CF=CC=D5=DE=C1=D4=C5=CC=D1, = =D0=CF=DC=D4=CF=CD=D5 =F7=C1=DB=C1 =D2=C1=D3=D3=D9=CC=CB=C1 =CE=C5 = =C2=D5=C4=C5=D4 =D3=DE=C9=D4=C1=D4=D8=D3=D1=20 =F3=D0=C1=CD=CF=CD!

  =F4=C1=CB=C9=CD = =CF=C2=D2=C1=DA=CF=CD, =CB=C1=CB=20 =D0=CF=CB=C1=DA=D9=D7=C1=C5=D4 =D0=D2=C1=CB=D4=C9=CB=C1, = =DC=C6=C6=C5=CB=D4=C9=D7=CE=CF=D3=D4=D8 =D4=C1=CB=CF=CA = =D2=C5=CB=CC=C1=CD=CE=D9 =C9=DA-=DA=C1 =DB=C9=D2=CF=D4=D9 = =CF=C8=D7=C1=D4=C1 =C1=D5=C4=C9=D4=CF=D2=C9=CA=20 =D3=D2=C1=D7=CE=C9=CD=C1 =D3 =D2=C5=CB=CC=C1=CD=CE=D9=CD=C9 = =D2=CF=CC=C9=CB=C1=CD=C9 =CE=C1 =C3=C5=CE=D4=D2=C1=CC=D8=CE=CF=CD = =D4=C5=CC=C5=D7=C9=C4=C5=CE=C9=C9! 

=E1 =D3=D4=CF=C9=D4 =CE=C1=DB =D0=D2=CF=C7=D2=C1=CD=CD=CE=D9=CA = =CB=CF=CD=D0=CC=C5=CB=D3 =D7=D3=C5=C7=CF 3500 =D2=D5=C2=CC=C5=CA. =FA=C1 = =DC=D4=C9 =C4=C5=CE=D8=C7=C9 =F7=D9=20 =D0=CF=CC=D5=DE=C1=C5=D4=C5 =D5=CE=C9=CB=C1=CC=D8=CE=D5=C0 = =D0=D2=CF=C7=D2=C1=CD=CD=D5 =CF=D3=D5=DD=C5=D3=D4=D7=CC=D1=C0=DD=D5=C0 = =D2=C1=D3=D3=D9=CC=CB=D5 (=D7=C1=DB =D3=CF=C2=D3=D4=D7=C5=CE=CE=D9=CA = =D0=CF=DE=D4=CF=D7=D9=CA =D3=C5=D2=D7=C5=D2!!!), =C2=C1=DA=D5 = =C4=C1=CE=CE=D9=C8 e-mail =C1=C4=D2=C5=D3=CF=D7 = =D3=CF=C4=C5=D2=D6=C1=DD=D5=C0 =C1=C4=D2=C5=D3=C1=20 =D0=D2=C1=CB=D4=C9=DE=C5=D3=CB=C9 =F7=D3=C5=C8 = =D0=D2=C5=C4=D0=D2=C9=D1=D4=C9=CA, =C1 =D4=C1=CB=D6=C5 = =DE=C1=D3=D4=CE=D9=C8 =CC=C9=C3, =D3=D2=C5=C4=C9 =CB=CF=D4=CF=D2=D9=C8 = =D2=D5=CB=CF=D7=CF=C4=C9=D4=C5=CC=C9=20 =D0=D2=C5=C4=D0=D2=C9=D1=D4=C9=CA, = =D0=D2=C5=C4=D0=D2=C9=CE=C9=CD=C1=D4=C5=CC=C9 , = =D0=CF=CC=C9=D4=C9=CB=C9, =D4=C1=CB=D6=C5 =D0=D2=CF=C7=D2=C1=CD=CD=D5 = =C4=CC=D1 =D3=C1=CD=CF=D3=D4=CF=D1=D4=C5=CC=D8=CE=CF=C7=CF=20 =D3=C2=CF=D2=C1 =C1=C4=D2=C5=D3=CF=D7 =D7 =D3=C5=D4=C9 =D0=CF = =CB=CC=C0=DE=C5=D7=D9=CD =D3=CC=CF=D7=C1=CD!

=F7=D9=C2=CF=D2 =DA=C1 =F7=C1=CD=C9!

=E5=D3=CC=C9 =F7=C1=D3 = =DA=C1=C9=CE=D4=C5=D2=C5=D3=CF=D7=C1=CC=CF =CE=C1=DB=C5 = =D0=D2=C5=C4=CC=CF=D6=C5=CE=C9=C5 =F5=E2=E5=E4=E9=F4=E5=EC=F8=EE=E1=F1 = =F0=F2=EF=F3=F8=E2=E1=20 =D3=D7=CF=C9 =DA=C1=CB=C1=DA=D9 =CE=C1=D0=D2=C1=D7=CC=D1=D4=D8 = =CF=C4=CE=CF=D7=D2=C5=CD=C5=CE=CE=CF =CE=C1 =C4=D7=C1 = =C1=C4=D2=C5=D3=C1: =E5=D3=CC=C9 =D7 =D0=C9=D3=D8=CD=C5 =F7=D9 = =D5=CB=C1=D6=C9=D4=C5 =D3=D7=CF=CA=20 =D4=C5=CC=C5=C6=CF=CE - =CE=C1=DB =CD=C5=CE=C5=C4=D6=C5=D2 = =D3=D7=D1=D6=C5=D4=D3=D1 =D3 =F7=C1=CD=C9.

directpost@rambler.ru

directpost@x707.net

 =E9=CC=C9=20 ICQ=20 95210206

=F3=D0=C1=D3=C9=C2=CF =DA=C1 = =D7=CE=C9=CD=C1=CE=C9=C5! =F0=D2=CF=D3=C9=CD =D0=D2=CF=DD=C5=CE=C9=D1 = =DA=C1 =CE=C5=CF=D6=C9=C4=C1=CE=CE=CF=C5=20 =D7=D4=CF=D2=D6=C5=CE=C9=C5.

------=_NextPart_000_0014_01C03A54.D5898FC0-- From owner-ietf-ssh@clinet.fi Sat Oct 21 16:26:11 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20686 for ; Sat, 21 Oct 2000 16:26:10 -0400 (EDT) From: owner-ietf-ssh@clinet.fi Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id VAA26235 for ietf-ssh-outgoing; Sat, 21 Oct 2000 21:43:55 +0300 Message-Id: <200010211843.VAA26235@mail.clinet.fi> Received: from unknown (p24.relline.ru [195.146.70.88]) by mail.clinet.fi (8.9.3/8.9.3) with SMTP id VAA26196; Sat, 21 Oct 2000 21:43:21 +0300 Date: Сб, 21 окт 2000 19:08:45 Subject: Интересное предложение Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Уважаемые господа ! Крупная компьютерная компания расширяет круг своих партнеров. Мы предлагаем поставки компьютеров и комплектующих, а так же русофикацию и снатие SP-LOCK сотовых телефонов. Почему выгодно работать с нами. 1. Низкие цены. Мы готовы дать Вам цены ниже чем те по которым Вы работаете с вашими поставщиками. 2. Мы без проблем можем организовать отправку грузов к Вам. 3. Гибкая система работы ( Нал, Безнал, и другие услуги) 4. Быстрая заменная гарантия. 5. Большой ассортимент товара. ( Более 3000 наименований ) 6. Большой склад. 7. Оперативность выполнения заказов. Свежий прайс-лист вы можете получить направив запрос по эл. почте. Если у Вас есть желание с нами поработать то пишите escompx@mail.ru escomputer@mtu.ru escomp@chat.ru или звоните +7(095) 747-7231 , 268-4633 Наш адрес: Москва, Стромынкий пер. 7/23. п. 4 P.S. Прозьба данное письмо массовой рассылкой не считать, так как это конкретное коммерческое предложение. From owner-ietf-ssh@clinet.fi Wed Oct 25 10:47:03 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16878 for ; Wed, 25 Oct 2000 10:47:01 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA02898 for ietf-ssh-outgoing; Wed, 25 Oct 2000 15:30:50 +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 PAA02894 for ; Wed, 25 Oct 2000 15:30:49 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id C776E24012CC; Wed, 25 Oct 2000 14:30:35 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id OAA15226; Wed, 25 Oct 2000 14:30:35 +0200 (MET DST) To: Tero Kivinen Cc: Sami Lehtinen , "Joseph Galbraith" , "Markus Friedl" , "Bill Sommerfeld" , "IETF-Secsh List" Subject: Re: Signals (Re: New drafts (TODO)) References: <200010182141.e9ILful155540@thunk.east.sun.com> <20001019104246.A3219@faui02.informatik.uni-erlangen.de> <004b01c039f0$06a0a720$0500a8c0@sage> <14831.18607.884406.570962@asgard.tky.hut.fi> <14838.51411.891974.967487@hutcs.cs.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 25 Oct 2000 14:30:34 +0200 In-Reply-To: Tero Kivinen's message of "Wed, 25 Oct 2000 15:00:11 +0300 (EET DST)" Message-ID: Lines: 44 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Tero Kivinen writes: > Sami Lehtinen writes: > > I think we should keep the old messages (and change the format), and > > deal with the incompatibilities. Because no matter what we do with the > > drafts at this point will lead to incompatibility with the old drafts > > (and implementations). > > I agree. Has anybody really implementing the "signal" request? I mean > in addition to just ignore it if you see one? The "exit-signal" is > propably implemented, but it is not used that much (the case where the > the other end exited because of the it dumped core because if SIGBUS, > should not happen that often :-), and think we can just change the > format and be done with it. I agree too. (And I haven't implemented "signal"). > I would say we just change the number to string and define that it can > have "standard" signal names (listed in the draft), or it can have > signal@hosttype.hostname.domain type of signals. I think the latter part is overspecification. It's better to say that the string should either be a "standard" signal name (listed), or a signal@domain for locally defined or extended signals. If you want to encode the system type into the domain, you could say that you intend to use some *particular* domains for that, for instance by naming signals like "THAW@sparc-sun-solaris2-7.hosttype-by-config-guess.hut.fi" "name@`config.guess |sed s/./-/`.hosttype-by-config-guess.hut.fi" But it seems very unnecessary to me to mandate that structure on *all* domains that might be used. That's contrary to the idea of using hierarchical domain names as namespaces, as it attaches a meaning to the *first* component of the domain, independent of the latter components which represents parents in the dns tree. If I want to support some signals that exists on several systems but under different names, I'd like to use a clean "@domain" namespace for assigning machine-independent names to those signals. A required hosttype component will be in the way. /Niels From owner-ietf-ssh@clinet.fi Wed Oct 25 13:11:59 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11474 for ; Wed, 25 Oct 2000 13:11:57 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA30029 for ietf-ssh-outgoing; Wed, 25 Oct 2000 18:02:03 +0300 Received: from folly.informatik.uni-erlangen.de (muedi4-145-253-166-092.arcor-ip.net [145.253.166.92]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA30022 for ; Wed, 25 Oct 2000 18:01:59 +0300 Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id A2B4811AB; Wed, 25 Oct 2000 17:01:51 +0200 (CEST) Date: Wed, 25 Oct 2000 17:01:51 +0200 From: Markus Friedl To: Tero Kivinen Cc: =?iso-8859-1?Q?Niels_M=F6ller?= , Sami Lehtinen , Joseph Galbraith , Bill Sommerfeld , IETF-Secsh List Subject: Re: Signals (Re: New drafts (TODO)) Message-ID: <20001025170151.B11373@folly> References: <200010182141.e9ILful155540@thunk.east.sun.com> <20001019104246.A3219@faui02.informatik.uni-erlangen.de> <004b01c039f0$06a0a720$0500a8c0@sage> <14831.18607.884406.570962@asgard.tky.hut.fi> <14838.51411.891974.967487@hutcs.cs.hut.fi> <14838.58278.655124.808875@hutcs.cs.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <14838.58278.655124.808875@hutcs.cs.hut.fi>; from kivinen@mail.niksula.cs.hut.fi on Wed, Oct 25, 2000 at 05:01:03PM +0300 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Wed, Oct 25, 2000 at 05:01:03PM +0300, Tero Kivinen wrote: > Anyways this is not a very important issue, and I think we can just > ignore this whole issue as obscure feature not really needed... so, why not drop signals from the spec? if it's not really needed it should not be in the protocol. -markus From owner-ietf-ssh@clinet.fi Wed Oct 25 13:34:14 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14334 for ; Wed, 25 Oct 2000 13:34:13 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA02208 for ietf-ssh-outgoing; Wed, 25 Oct 2000 18:40:25 +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 SAA02200 for ; Wed, 25 Oct 2000 18:40:24 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 6C32D2401F7A; Wed, 25 Oct 2000 17:40:22 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id RAA19110; Wed, 25 Oct 2000 17:40:22 +0200 (MET DST) To: Markus Friedl Cc: Tero Kivinen , Sami Lehtinen , Joseph Galbraith , Bill Sommerfeld , IETF-Secsh List Subject: Re: Signals (Re: New drafts (TODO)) References: <200010182141.e9ILful155540@thunk.east.sun.com> <20001019104246.A3219@faui02.informatik.uni-erlangen.de> <004b01c039f0$06a0a720$0500a8c0@sage> <14831.18607.884406.570962@asgard.tky.hut.fi> <14838.51411.891974.967487@hutcs.cs.hut.fi> <14838.58278.655124.808875@hutcs.cs.hut.fi> <20001025170151.B11373@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 25 Oct 2000 17:40:21 +0200 In-Reply-To: Markus Friedl's message of "Wed, 25 Oct 2000 17:01:51 +0200" Message-ID: Lines: 18 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Markus Friedl writes: > so, why not drop signals from the spec? > > if it's not really needed it should not be in the protocol. I think something like exit-signal is needed; clients should have some way to find out how a remote process died. This is particularly important if you run a program with more than two valid exit codes (otherwise one could just send an exit-status with any non-zero status code if a process crashes). So the alternative to keeping exit-signal is to add something to exit-status message to distinguish normal and abnormal process termination. I think fixing the signal encoding is a smaller change than extending the exit-status message. /Niels From owner-ietf-ssh@clinet.fi Wed Oct 25 13:46:59 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15920 for ; Wed, 25 Oct 2000 13:46:57 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA00797 for ietf-ssh-outgoing; Wed, 25 Oct 2000 18:31:13 +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 SAA00789 for ; Wed, 25 Oct 2000 18:31:12 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 9D4B124012D8; Wed, 25 Oct 2000 17:31:10 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id RAA05560; Wed, 25 Oct 2000 17:31:10 +0200 (MET DST) To: Tero Kivinen Cc: Sami Lehtinen , "Joseph Galbraith" , "Markus Friedl" , "Bill Sommerfeld" , "IETF-Secsh List" Subject: Re: Signals (Re: New drafts (TODO)) References: <200010182141.e9ILful155540@thunk.east.sun.com> <20001019104246.A3219@faui02.informatik.uni-erlangen.de> <004b01c039f0$06a0a720$0500a8c0@sage> <14831.18607.884406.570962@asgard.tky.hut.fi> <14838.51411.891974.967487@hutcs.cs.hut.fi> <14838.58278.655124.808875@hutcs.cs.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 25 Oct 2000 17:31:10 +0200 In-Reply-To: Tero Kivinen's message of "Wed, 25 Oct 2000 17:01:03 +0300 (EET DST)" Message-ID: Lines: 70 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Tero Kivinen writes: > > "THAW@sparc-sun-solaris2-7.hosttype-by-config-guess.hut.fi" > > "name@`config.guess |sed s/./-/`.hosttype-by-config-guess.hut.fi" > > > > But it seems very unnecessary to me to mandate that structure on *all* > > domains that might be used. > > I think my previous email I said SHOULD. If I accidently said MUST, > then that was my error... I think even a SHOULD is too strong. > > That's contrary to the idea of using hierarchical domain names as > > namespaces, as it attaches a meaning to the *first* component of > > the domain, independent of the latter components which represents > > parents in the dns tree. > > Not really. The idea is that two implementations can map also the > unstandard signal names between themself on the same architecture. > Lets say the implementation 1 uses the *.foo.com domain for all its > privately own information. The implementation 2 uses the *.zappa.net > domain. If they want to use the same encoding, they should either agree on a common namespace to use, or keep a list of domains known to use that encoding. I'm objecting to the idea that one should try to interpret names under an unknown domain. I.e. if one doesn't know the "foo.com" domain, one shouldn't try to guess what names like "foo@some-random-string.foo.com means. I want to be able to assign names under @my.domain any way I see fit, without having to having to worry that some other implementation that doesn't know anything about what conventions I use may try to guess. If I implement a signal "kill@foo.my.domain", which performs something useful for some ssh server under some circumstances, I want my clients to be able to send that signal safely, knowing that any server that haven't implemented that feature will safely ignore it. > > If I want to support some signals that exists on several systems but > > under different names, I'd like to use a clean "@domain" namespace for > > assigning machine-independent names to those signals. A required > > hosttype component will be in the way. > > You can do it, but that is going to be hard. The signal names are not > related to the implementations, they are related to the architecture > where the implementation is executed. Somebody might compile the > implementation on environment that you have never heard of and there > might be new signal TEMP (temperature alert) that is mapped to number > 42. I wouldn't call the signal "TEMP@my.domain", I'd rather use "temperature-alert@my.domain". And similarly for temporarily-suspended, time-memory-integral-limit-exceeded, etc. Names for nonstandard signals will have to be more verbose. > Anyways this is not a very important issue, and I think we can just > ignore this whole issue as obscure feature not really needed... I would prefer that the spec not recommend applying the encoding conventions you propose to random domains. It's fine to mention one or a few domains that does use the encoding. And if people want to do this (I agree that it could be useful), the spec could spell out the encoding details so that it will really interoperate. But for now I think it would be fine to just say that we use the same namespace mechanism for non-standard signal names as for all other names in the protocols. /Niels From owner-ietf-ssh@clinet.fi Wed Oct 25 23:41:34 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA02867 for ; Wed, 25 Oct 2000 23:41:33 -0400 (EDT) From: owner-ietf-ssh@clinet.fi Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id EAA17357 for ietf-ssh-outgoing; Thu, 26 Oct 2000 04:51:21 +0300 Received: from smtp.clinet.fi (smtp.clinet.fi [194.100.0.12]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id EAA17314; Thu, 26 Oct 2000 04:50:49 +0300 Received: from unknown (ip-1899.dialup.cl.spb.ru [212.46.202.169] (may be forged)) by smtp.clinet.fi (8.9.3/8.9.3) with SMTP id EAA88316; Thu, 26 Oct 2000 04:35:40 +0300 (EEST) Message-Id: <200010260135.EAA88316@smtp.clinet.fi> Subject: Direktoru FIRM предложение is S-Petersburga , marketing- reklama- basa danix - spravozniki (Sewero- Sapadnij region) Date: Чт, 26 окт 2000 02:27:13 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Предлагаем Вашему вниманию информационные каталоги охватывающие все сферы бизнеса и коммерции по всем регионам России. Представим Ваши интересы в Северо- Западном регионе и Санкт- Петербурге - распространим о Вас информацию в короткие сроки с помощью факсовой рассылки, рассылки электронной почтой, размещением в эффективных рекламно- информационных изданиях. 1.Имеются в наличии каталог Оптовая торговля- Оптовые поставщики. 2.База данных - Кто что покупает. 3.Справочник - Производители товаров и услуг. 4.Телефонные и коммерческие справочники по различным отраслям и регионам, городам России и СНГ. Предлагаем размещение информации о Вашем предприятии в каталоге Оптовая торговля- Оптовые поставщики на 2001 год. Это реклама, которая будет работать на Вас в регионах.Вопросы можно направлять по E-mail: bisinform@rambler.ru или tel/fax (812)532-7038. по почте: 195265, С-Петербург, а/я 88, ООО"БизнесИнформ". PS: по техническим причинам мы не сможем принять сообщение направленное просто обратно на ответить отправителю на исходящий электронный ящик. Dla tex y kogo no Cirilic Rasprostranim o Bac informaziu po vcem regionam Rossij + Cevero-Sapadnij region + S-Petersburg v korotkie croki metodom fax-rassilki, E-mail rassilki, razmestim o Bac informaziu v spravosnikax.- Optovaj torgovla Optovie postavsiki. Predlogaem dla priobretenia katalogi, spravosniki, basi danix, po vcem otrasljm i regionam Rossij + SNG + goroda + S-Petersburg. dla otveta tolko E-mail: bisinform@rambler.ru ili tel/fax (812)532-7038. adres: 195265, Rossia, S-Petersburg, ab.88, BisnesInform. Direktoru FIRM предложение is S-Petersburga , marketing- reklama- basa danix - spravozniki (Sewero- Sapadnij region) From owner-ietf-ssh@clinet.fi Thu Oct 26 12:12:20 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14333 for ; Thu, 26 Oct 2000 12:12:18 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id QAA19372 for ietf-ssh-outgoing; Thu, 26 Oct 2000 16:47:35 +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 QAA19361 for ; Thu, 26 Oct 2000 16:47:33 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 20F4A24079F6; Thu, 26 Oct 2000 15:47:31 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id PAA08999; Thu, 26 Oct 2000 15:47:30 +0200 (MET DST) To: Tero Kivinen Cc: Sami Lehtinen , "Joseph Galbraith" , "Markus Friedl" , "Bill Sommerfeld" , "IETF-Secsh List" Subject: Re: Signals (Re: New drafts (TODO)) References: <200010182141.e9ILful155540@thunk.east.sun.com> <20001019104246.A3219@faui02.informatik.uni-erlangen.de> <004b01c039f0$06a0a720$0500a8c0@sage> <14831.18607.884406.570962@asgard.tky.hut.fi> <14838.51411.891974.967487@hutcs.cs.hut.fi> <14838.58278.655124.808875@hutcs.cs.hut.fi> <14840.4367.999115.578109@hutcs.cs.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 26 Oct 2000 15:47:30 +0200 In-Reply-To: Tero Kivinen's message of "Thu, 26 Oct 2000 14:19:26 +0300 (EET DST)" Message-ID: Lines: 22 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Tero Kivinen writes: > > I want to be able to assign names under @my.domain any way I see fit, > > without having to having to worry that some other implementation that > > doesn't know anything about what conventions I use may try to guess. > > You can do that. SHOULD does not prevent you doing that. It just says > that there might be reason to do it otherwise. I can't do that if we recommend that the other implementations try to guess the meaning of names in random namespaces, including mine. > So we create @xxx.config.guess domain that will be used for those > systems that automatically detect unknown signals at the configure > time, and the xxx is going to be the output of the config.guess for > the system. That's fine with me. You also have to specify the details (like what to do when config.guess outputs a name with characters like '.' that are not allowed in a dns label). /Niels From owner-ietf-ssh@clinet.fi Mon Oct 30 02:10:20 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA23804 for ; Mon, 30 Oct 2000 02:10:19 -0500 (EST) From: owner-ietf-ssh@clinet.fi Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id HAA18154 for ietf-ssh-outgoing; Mon, 30 Oct 2000 07:17:13 +0200 Date: Mon, 30 Oct 2000 07:17:13 +0200 Message-Id: <200010300517.HAA18154@mail.clinet.fi> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk From owner-ietf-ssh@clinet.fi Tue Oct 31 16:10:02 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11696 for ; Tue, 31 Oct 2000 16:09:56 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id VAA20533 for ietf-ssh-outgoing; Tue, 31 Oct 2000 21:10:54 +0200 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 VAA20530 for ; Tue, 31 Oct 2000 21:10:53 +0200 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 VAA02679 for ; Tue, 31 Oct 2000 21:10:52 +0200 (EET) Received: (from sshlist@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.17) id VAA21695 for ietf-ssh@clinet.fi; Tue, 31 Oct 2000 21:10:52 +0200 (EET) Received: from dingle.lightspeed.net (HELO kevin2k) ([209.165.3.9]) (envelope-sender ) by mail007.mail.onemain.com (qmail-ldap-1.03) with SMTP for ; 31 Oct 2000 02:05:43 -0000 Message-ID: <000201c042df$14509720$013c100a@kevin2k> From: "Kevin Sanders" To: Subject: subscribe Date: Mon, 30 Oct 2000 13:23:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit subscribe From owner-ietf-ssh@clinet.fi Tue Oct 31 22:02:06 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA06273 for ; Tue, 31 Oct 2000 22:02:05 -0500 (EST) From: owner-ietf-ssh@clinet.fi Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id DAA12790 for ietf-ssh-outgoing; Wed, 1 Nov 2000 03:12:59 +0200 Date: Wed, 1 Nov 2000 03:12:59 +0200 Message-Id: <200011010112.DAA12790@mail.clinet.fi> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk