From owner-ietf-ssh@clinet.fi Fri Dec 1 02:51: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 CAA23772 for ; Fri, 1 Dec 2000 02:51:16 -0500 (EST) From: owner-ietf-ssh@clinet.fi Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id IAA27301 for ietf-ssh-outgoing; Fri, 1 Dec 2000 08:12:31 +0200 Received: from gromit.pmc.com.pl (root@gromit.pmc.com.pl [195.116.99.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id IAA27289 for ; Fri, 1 Dec 2000 08:12:29 +0200 Received: from KP1xoHrR8 (1Cust8.tnt2.modesto.ca.da.uu.net [63.28.59.8]) by gromit.pmc.com.pl (8.8.7/8.8.7) with SMTP id IAA12881; Fri, 1 Dec 2000 08:06:44 +0100 Message-Id: <200012010706.IAA12881@gromit.pmc.com.pl> DATE: 30 Nov 00 10:12:21 PM Reply-to: wecandazzleu@soon.com TO: wecandazzleu@soon.com SUBJECT: New Policy for Domain Names Protect Your Name Sender: owner-ietf-ssh@clinet.fi Precedence: bulk New Top Level Domains to come out early next year! .BIZ, .INFO & .PRO – Approved for general use Domain Policy Overview: July 16, 2000 - Yokohama, Japan -ICANN (Internet Corporation for Assigned Names and Numbers) announced that it adopted a policy that will introduce new global top-level domains (TLDs). July 17, 2000 – Companies around the world begin the application process. Oct 2, 2000 – Application process for new TLD’s is finalized. Oct 3, 2000 – Marina del Rey, California - ICANN announces that the application process has been completed. The new domain extensions will be awarded to registries in December 2000. Nov 16, 2000 - Marina del Rey, California – ICANN announces approved new gTLDs. Included in these new gTLDs are .Biz, .Info, & .Pro for general use (like .com, .net & .org) In anticipation of high demand, you can pre-register for rapid submission for these names prior to their official public opening via a centralized pre-registration database. For further information about the pre-registration process please visit: http://www.preregnames.com/ sent by cybernet--to be removed go to helloremove@umpire.com 209-669-0176 From owner-ietf-ssh@clinet.fi Sun Dec 3 08: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 IAA20683 for ; Sun, 3 Dec 2000 08:34:13 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id NAA15015 for ietf-ssh-outgoing; Sun, 3 Dec 2000 13:44:04 +0200 Received: from folly.informatik.uni-erlangen.de (muedi6-212-144-216-145.arcor-ip.net [212.144.216.145]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id NAA15008 for ; Sun, 3 Dec 2000 13:44:02 +0200 Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 23FD01414; Sun, 3 Dec 2000 12:43:52 +0100 (CET) Date: Sun, 3 Dec 2000 12:43:52 +0100 From: Markus Friedl To: Bill Sommerfeld Cc: ietf-ssh@clinet.fi Subject: Re: agenda items.. Message-ID: <20001203124352.A8644@folly> References: <200011302111.eAULB5a104779@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011302111.eAULB5a104779@thunk.east.sun.com>; from sommerfeld@east.sun.com on Thu, Nov 30, 2000 at 04:11:05PM -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Thu, Nov 30, 2000 at 04:11:05PM -0500, Bill Sommerfeld wrote: > I expect that we'll spend most of the time discussing the core drafts. i just read the drafts, in draft-ietf-secsh-connect-08.txt 4.10. Returning Exit Status [...] Additional signal names MAY be sent in the format "sig-name@xyz", where `sig-name' and `xyz' may be anything a particular implementor wants (except the `@' sign). However, it is suggested that if a `configure' script is used, the non-standard signal names it finds be encoded as "SIG@xyz.config.guess", where `SIG' is the signal name without the "SIG" prefix, and `xyz' be the host type, as determined by `config.guess'. should the standard speculate about details of specific implementations of certain configure scripts? why talk about 'config.guess'? why not remove this? -markus From owner-ietf-ssh@clinet.fi Sun Dec 3 12:48: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 MAA05147 for ; Sun, 3 Dec 2000 12:48:03 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA31479 for ietf-ssh-outgoing; Sun, 3 Dec 2000 18:06:08 +0200 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA31475 for ; Sun, 3 Dec 2000 18:06:07 +0200 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id SAA14203; Sun, 3 Dec 2000 18:06:28 +0200 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14890.28547.508748.927677@asgard.tky.hut.fi> Date: Sun, 3 Dec 2000 18:06:27 +0200 (EET) To: Markus Friedl Cc: Bill Sommerfeld , ietf-ssh@clinet.fi Subject: Re: agenda items.. In-Reply-To: <20001203124352.A8644@folly> References: <200011302111.eAULB5a104779@thunk.east.sun.com> <20001203124352.A8644@folly> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Markus Friedl, on December 3. 2000, wrote: : On Thu, Nov 30, 2000 at 04:11:05PM -0500, Bill Sommerfeld wrote: : > I expect that we'll spend most of the time discussing the core drafts. : : i just read the drafts, in draft-ietf-secsh-connect-08.txt : : 4.10. Returning Exit Status : : [...] : : Additional signal names MAY be sent in the format "sig-name@xyz", where : `sig-name' and `xyz' may be anything a particular implementor wants : (except the `@' sign). However, it is suggested that if a `configure' : script is used, the non-standard signal names it finds be encoded as : "SIG@xyz.config.guess", where `SIG' is the signal name without the "SIG" : prefix, and `xyz' be the host type, as determined by `config.guess'. : : : should the standard speculate about details of specific implementations : of certain configure scripts? why talk about 'config.guess'? why not : remove this? It is a suggestion. It is not even a SHOULD. Tero and Niels had a dialogue about signals on this list, and nobody commented (for or against) on that. I decided to put the results of that dialogue to good use. The `config.guess' is part of the autoconf package, and it is supposed to be used by configure scripts. AFAIK, it is not going anywhere. -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Sun Dec 3 13:51:21 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 NAA24217 for ; Sun, 3 Dec 2000 13:51:19 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA02946 for ietf-ssh-outgoing; Sun, 3 Dec 2000 19:05:33 +0200 Received: from Mail6.mgfairfax.rr.com (fe6.southeast.rr.com [24.93.67.53]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA02941 for ; Sun, 3 Dec 2000 19:05:29 +0200 Received: from mosquito.inet.org ([24.168.212.166]) by Mail6.mgfairfax.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Sun, 3 Dec 2000 12:04:55 -0500 Message-Id: <5.0.0.25.2.20001203115402.00a4b840@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sun, 03 Dec 2000 11:57:45 -0500 To: Markus Friedl From: RJ Atkinson Subject: Re: agenda items.. Cc: ietf-ssh@clinet.fi In-Reply-To: <20001203124352.A8644@folly> References: <200011302111.eAULB5a104779@thunk.east.sun.com> <200011302111.eAULB5a104779@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Markus, Implementation notes are legitimate for an RFC. If consensus wer that they are distracting in the main body, they could always be moved to an Appendix or some such. For my part, I find that RFCs with more implementation hints tend to have more interoperability than those with fewer hints. On the specific topic below, it would be nice if a clear and precise mapping of POSIX.1 signals with the SSH signals would get documented, by the way. At 06:43 03/12/00, Markus Friedl wrote: >On Thu, Nov 30, 2000 at 04:11:05PM -0500, Bill Sommerfeld wrote: >> I expect that we'll spend most of the time discussing the core drafts. > >i just read the drafts, in draft-ietf-secsh-connect-08.txt > > 4.10. Returning Exit Status > > [...] > > Additional signal names MAY be sent in the format "sig-name@xyz", where > `sig-name' and `xyz' may be anything a particular implementor wants > (except the `@' sign). However, it is suggested that if a `configure' > script is used, the non-standard signal names it finds be encoded as > "SIG@xyz.config.guess", where `SIG' is the signal name without the "SIG" > prefix, and `xyz' be the host type, as determined by `config.guess'. > > >should the standard speculate about details of specific implementations of certain configure scripts? It is certainly legitimate to do so in an IETF RFC. >why talk about 'config.guess'? why not remove this? More implementation hints are better. Though perhaps an implementation hint should be more clearly marked as not normative. Ran From owner-ietf-ssh@clinet.fi Sun Dec 3 14:58: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 OAA14427 for ; Sun, 3 Dec 2000 14:58:28 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA07308 for ietf-ssh-outgoing; Sun, 3 Dec 2000 20:13:23 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA07304 for ; Sun, 3 Dec 2000 20:13:22 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 7457B2402812; Sun, 3 Dec 2000 19:13:21 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id TAA25590; Sun, 3 Dec 2000 19:13:21 +0100 (MET) To: sommerfeld@east.sun.com Cc: ietf-ssh@clinet.fi Subject: Re: agenda items.. References: <200011302111.eAULB5a104779@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 03 Dec 2000 19:13:20 +0100 In-Reply-To: Bill Sommerfeld's message of "Thu, 30 Nov 2000 16:11:05 -0500" Message-ID: Lines: 42 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Bill Sommerfeld writes: > Folks who have something they want on the agenda should send requests > to me. Thanks. I'm afraid I'll not be able to attend. But I think the most serious problem with the current (transport) draft is the unclear specification of the "algorithm guess" feature. The first paragraph of section 5 says that "all" algorithms have to be gussed right, or an implementation MUST ignore any optimistically sent key exchange packet (which seems bogus, as the algorithms for bulk encryption or compression are clearly irrelevant to key exchange) while section 5.1, describing the kex_algorithms field, seems to imply that a guess is considered successful iff the advertised key-exchange methods match (which also seems bad, as encryption/signature capabilities of the hostkey algorithms also have to be taken into account). I hope you can sort that out (or else, the first version spec should probably discourage use of that feature). The second most serious problem is that the algorithm names openpgp, x509v3 and spki are defined, even though those definitions doesn't match the requirements (section 4.6) on a public-key algorithm name (more precisely, an algorithm name, by itself, should provide information about the algorithms used (rsa/dsa etc), key usage). Both "x509v3" and "spki" are ambiguous (I'm not sure about openpgp, but I suspect that is just as bad): they only provide information about the *encoding* of keys and certificates. (What is *needed* from an algorithm name is actually different for host keys and user keys, but unless the spec spell out that distinction, the most harsh requirements (that apply primarily for host keys) must be applied to all public-key algorithm names). This second problem is in some ways more fundamental, but perhaps less urgent to solve as not many use the other formats (lsh uses spki formats, but with no real certificate support yet. Nobody else uses spki formats for secsh as far as I know) /Niels From owner-ietf-ssh@clinet.fi Sun Dec 3 16:20: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 QAA08743 for ; Sun, 3 Dec 2000 16:20:48 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id VAA13131 for ietf-ssh-outgoing; Sun, 3 Dec 2000 21:39:22 +0200 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id VAA13128 for ; Sun, 3 Dec 2000 21:39:21 +0200 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id VAA14408; Sun, 3 Dec 2000 21:39:36 +0200 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14890.41336.288119.366888@asgard.tky.hut.fi> Date: Sun, 3 Dec 2000 21:39:36 +0200 (EET) To: RJ Atkinson Cc: Markus Friedl , ietf-ssh@clinet.fi Subject: Re: agenda items.. In-Reply-To: <5.0.0.25.2.20001203115402.00a4b840@10.30.15.2> References: <200011302111.eAULB5a104779@thunk.east.sun.com> <5.0.0.25.2.20001203115402.00a4b840@10.30.15.2> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit RJ Atkinson, on December 3. 2000, wrote: : On the specific topic below, it would be nice if : a clear and precise mapping of POSIX.1 signals with the : SSH signals would get documented, by the way. The signal names documented in "exit-signal" (and used in the same way in "signal") are the POSIX.1 signals, without the "SIG" prefix. Was this what you meant? -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Mon Dec 4 17:53:23 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 RAA06153 for ; Mon, 4 Dec 2000 17:53:22 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA15014 for ietf-ssh-outgoing; Mon, 4 Dec 2000 22:58:46 +0200 Received: from director.ci.baltimore.md.us ([141.157.34.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id WAA15010 for ; Mon, 4 Dec 2000 22:58:44 +0200 Received: by director with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Dec 2000 15:53:49 -0500 Message-ID: <9A59B7C83CEDD311A17700508B95086250D03A@finance> From: "Gupta, Rakesh" To: "'ietf-ssh@clinet.fi'" Subject: Automatic authentication Date: Mon, 4 Dec 2000 15:54:09 -0500 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 Hello, One of our team members is trying to remotely copy files from another machine using the ssh2 shell. The copying works fine but it requires entering a password manually. We would like to automate this process so the users do not have to enter the password. We would prefer if we do not have to save the username or password in any file or any shell variable. Thanks Rakesh DBA From owner-ietf-ssh@clinet.fi Mon Dec 4 21:45: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 VAA10619 for ; Mon, 4 Dec 2000 21:45:24 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id DAA31331 for ietf-ssh-outgoing; Tue, 5 Dec 2000 03:08:32 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id DAA31324 for ; Tue, 5 Dec 2000 03:08:30 +0200 Received: from merlin ([127.0.0.1]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 580; Mon, 4 Dec 2000 18:12:03 -0700 Message-ID: <015701c05e57$910937c0$2800a8c0@merlin> From: "Joseph Galbraith" To: , =?iso-8859-1?Q?Niels_M=F6ller?= Cc: References: <200011302111.eAULB5a104779@thunk.east.sun.com> Subject: Re: agenda items.. Date: Mon, 4 Dec 2000 18:06:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit > > Folks who have something they want on the agenda should send requests > > to me. Thanks. > > I'm afraid I'll not be able to attend. > > But I think the most serious problem with the current (transport) > draft is the unclear specification of the "algorithm guess" feature. > > The first paragraph of section 5 says that "all" algorithms have to be > gussed right, or an implementation MUST ignore any optimistically sent > key exchange packet (which seems bogus, as the algorithms for bulk > encryption or compression are clearly irrelevant to key exchange) > while section 5.1, describing the kex_algorithms field, seems to imply > that a guess is considered successful iff the advertised key-exchange > methods match (which also seems bad, as encryption/signature > capabilities of the hostkey algorithms also have to be taken into > account). > > I hope you can sort that out (or else, the first version spec should > probably discourage use of that feature). I too would like to sorted this out; this seems one of the biggest remaining holes in the draft. I'm not sure anyone outside of the SSH Communications people is actually using this feature... Perhaps the SSH Communications people could comment on when their software actually retransmits the first key exchange packet, and that would give us a starting point for clarifying this language? > The second most serious problem is that the algorithm names openpgp, > x509v3 and spki are defined, even though those definitions doesn't > match the requirements (section 4.6) on a public-key algorithm name > (more precisely, an algorithm name, by itself, should provide > information about the algorithms used (rsa/dsa etc), key usage). Both > "x509v3" and "spki" are ambiguous (I'm not sure about openpgp, but I > suspect that is just as bad): they only provide information about the > *encoding* of keys and certificates. (What is *needed* from an > algorithm name is actually different for host keys and user keys, but > unless the spec spell out that distinction, the most harsh > requirements (that apply primarily for host keys) must be applied to > all public-key algorithm names). > > This second problem is in some ways more fundamental, but perhaps less > urgent to solve as not many use the other formats (lsh uses spki > formats, but with no real certificate support yet. Nobody else uses > spki formats for secsh as far as I know) Again, I am very eager to see this problem resolved. Do we just need to change the names... for example, x509v3-dsa and x509v3-rsa? Has there been a solution to this problem proposed on the list? Joseph From owner-ietf-ssh@clinet.fi Tue Dec 5 12:51: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 MAA22322 for ; Tue, 5 Dec 2000 12:51:18 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA21780 for ietf-ssh-outgoing; Tue, 5 Dec 2000 17:47:19 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA21776 for ; Tue, 5 Dec 2000 17:47:18 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 9841E2402C4F; Tue, 5 Dec 2000 16:47:16 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id QAA05679; Tue, 5 Dec 2000 16:47:15 +0100 (MET) To: "Joseph Galbraith" Cc: , Subject: Re: agenda items.. References: <200011302111.eAULB5a104779@thunk.east.sun.com> <015701c05e57$910937c0$2800a8c0@merlin> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 05 Dec 2000 16:47:14 +0100 In-Reply-To: "Joseph Galbraith"'s message of "Mon, 4 Dec 2000 18:06:14 -0700" Message-ID: Lines: 15 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk "Joseph Galbraith" writes: > Do we just need to change the names... for example, > x509v3-dsa and x509v3-rsa? That's a start, but I'm not sure it is enough. Consider a server that has a certificate chain for its hostkey, and the chain includes both rsa and dsa signatures. > Has there been a solution to this problem proposed on the > list? Not that I recall. /Niels From owner-ietf-ssh@clinet.fi Wed Dec 6 17:22: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 RAA13728 for ; Wed, 6 Dec 2000 17:22:09 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA14752 for ietf-ssh-outgoing; Wed, 6 Dec 2000 22:23:40 +0200 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id WAA14747 for ; Wed, 6 Dec 2000 22:23:38 +0200 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA26565 for ; Wed, 6 Dec 2000 12:23:37 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA12438 for ; Wed, 6 Dec 2000 15:23:36 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eB6KMta111830 for ; Wed, 6 Dec 2000 15:22:56 -0500 (EST) Message-Id: <200012062022.eB6KMta111830@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@clinet.fi Subject: secsh: agenda for wg meeting at 49th ietf Reply-to: sommerfeld@east.sun.com Date: Wed, 06 Dec 2000 15:22:55 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk [this is still flexible; send comments to me..] Secure Shell Working Group (secsh) Monday, December 11 at 1530-1730 ================================ CHAIR: Bill Sommerfeld AGENDA: initialization vector/agenda bashing 5 minutes core secsh protocol - changes in -08 drafts 5 minutes - open issues with core drafts 45 minutes extensions - ssh and kerberos/gssapi discussion 30 minutes - keyboard-interactive draft discussion 10 minutes random padding 25 minutes From owner-ietf-ssh@clinet.fi Wed Dec 6 18:32: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 SAA03816 for ; Wed, 6 Dec 2000 18:32:01 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA20552 for ietf-ssh-outgoing; Wed, 6 Dec 2000 23:37:45 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA20540 for ; Wed, 6 Dec 2000 23:37:44 +0200 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15618; Wed, 6 Dec 2000 13:37:41 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA26436; Wed, 6 Dec 2000 16:37:40 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eB6Laxa112155; Wed, 6 Dec 2000 16:36:59 -0500 (EST) Message-Id: <200012062136.eB6Laxa112155@thunk.east.sun.com> From: Bill Sommerfeld To: nisse@lysator.liu.se (Niels M ller) cc: sommerfeld@east.sun.com, ietf-ssh@clinet.fi Subject: Transport draft issues raised by Niels Moeller In-reply-to: Your message of "03 Dec 2000 19:13:20 +0100." Reply-to: sommerfeld@east.sun.com Date: Wed, 06 Dec 2000 16:36:59 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > But I think the most serious problem with the current (transport) > draft is the unclear specification of the "algorithm guess" feature. > > The first paragraph of section 5 says that "all" algorithms have to be > gussed right, or an implementation MUST ignore any optimistically sent > key exchange packet (which seems bogus, as the algorithms for bulk > encryption or compression are clearly irrelevant to key exchange) When this was discussed in the working group meeting, the consensus in the room seemed to be that while matching all algorithms may be excessively conservative, excessive conservatism in this case was not a problem from the point of view of interoperability. > while section 5.1, describing the kex_algorithms field, seems to imply > that a guess is considered successful iff the advertised key-exchange > methods match I don't get that implication from section 5.1; however, some clarification may be in order. > (which also seems bad, as encryption/signature capabilities of the > hostkey algorithms also have to be taken into account). right, but the hostkey algorithms are also included in the SSH_MSG_KEXINIT message; since all algorithms have to match (as is stated in section 5) this ceases to be a problem. > The second most serious problem is that the algorithm names openpgp, > x509v3 and spki are defined, even though those definitions doesn't > match the requirements (section 4.6) on a public-key algorithm name > (more precisely, an algorithm name, by itself, should provide > information about the algorithms used (rsa/dsa etc), key usage). This was raised as an issue last time around. my personal take on the situation [wg chair hat off] is that the current transport protocol draft conflates public key formats and certificate formats, and that before certificates of any format (pgp, spki, x.509) can be used with ssh, these need to be disentangled. - Bill From owner-ietf-ssh@clinet.fi Wed Dec 6 18:36: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 SAA05117 for ; Wed, 6 Dec 2000 18:36:13 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA20793 for ietf-ssh-outgoing; Wed, 6 Dec 2000 23:41:33 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA20790 for ; Wed, 6 Dec 2000 23:41:31 +0200 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18775; Wed, 6 Dec 2000 13:41:19 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA06168; Wed, 6 Dec 2000 16:41:18 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eB6Leba112166; Wed, 6 Dec 2000 16:40:38 -0500 (EST) Message-Id: <200012062140.eB6Leba112166@thunk.east.sun.com> From: Bill Sommerfeld To: Tero Kivinen cc: nisse@lysator.liu.se, "Joseph Galbraith" , sommerfeld@east.sun.com, ietf-ssh@clinet.fi Subject: Re: agenda items.. In-reply-to: Your message of "Wed, 06 Dec 2000 18:41:19 +0200." <14894.27222.601597.799914@hutcs.cs.hut.fi> Reply-to: sommerfeld@east.sun.com Date: Wed, 06 Dec 2000 16:40:37 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > I would say that if you support x509v3, then you must support both DSA > and RSA signatures inside the certificates. This is problematic from the point of view of someone looking to do a reduced-size implementation (think embedded systems here) supporting either RSA or DSA but not both. x509v3-sign-rsa x509v3-sign-dss x509v3-sign-... - Bill From owner-ietf-ssh@clinet.fi Wed Dec 6 20:08: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 UAA26622 for ; Wed, 6 Dec 2000 20:08:35 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA28755 for ietf-ssh-outgoing; Thu, 7 Dec 2000 01:25:26 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id BAA28751 for ; Thu, 7 Dec 2000 01:25:25 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 256EA2402C53; Thu, 7 Dec 2000 00:25:20 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id AAA27673; Thu, 7 Dec 2000 00:25:17 +0100 (MET) To: Tero Kivinen Cc: "Joseph Galbraith" , , Subject: Re: agenda items.. References: <200011302111.eAULB5a104779@thunk.east.sun.com> <015701c05e57$910937c0$2800a8c0@merlin> <14894.27222.601597.799914@hutcs.cs.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 07 Dec 2000 00:25:16 +0100 In-Reply-To: Tero Kivinen's message of "Wed, 6 Dec 2000 18:41:19 +0200 (EET)" Message-ID: Lines: 26 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Tero Kivinen writes: > I would say that if you support x509v3, then you must support both DSA > and RSA signatures inside the certificates. So I would change the That would be an improvement, but I don't think it is a solution. Do you want to make an analogous change to spki (I am personally more interseted n spki certificates than x509)? Neither x509 nor spki make any strong requirements on which algorithms can or cannot be used, as far as I remember. For a start, it makes it impossible for an implementation to support x509, RSA only (which kind of makes sense to me, as most x509 certificates seen use only RSA, RSA is generally easier, and it's no longer patented). And it doesn't scale well when new signature algorithms are introduced. Consider an implementation that supports x509 using some elliptic curve algorithm (and perhaps also one, but not both, of RSA and DSA). What should that implementation advertise? And at last, you don't say anything about certificates that certify an encryption-capable key. The spec makes it clear that such properties should be evident from the _name_, and they are not. /Niels From owner-ietf-ssh@clinet.fi Wed Dec 6 20:45:09 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 UAA02537 for ; Wed, 6 Dec 2000 20:45:08 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA30639 for ietf-ssh-outgoing; Thu, 7 Dec 2000 01:58:24 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id BAA30636 for ; Thu, 7 Dec 2000 01:58:23 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id DD3942407DFF; Thu, 7 Dec 2000 00:58:22 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id AAA11066; Thu, 7 Dec 2000 00:58:22 +0100 (MET) To: sommerfeld@east.sun.com Cc: ietf-ssh@clinet.fi Subject: Re: Transport draft issues raised by Niels Moeller References: <200012062136.eB6Laxa112155@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 07 Dec 2000 00:58:22 +0100 In-Reply-To: Bill Sommerfeld's message of "Wed, 06 Dec 2000 16:36:59 -0500" Message-ID: Lines: 69 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Bill Sommerfeld writes: > > The first paragraph of section 5 says that "all" algorithms have to be > > gussed right, or an implementation MUST ignore any optimistically sent > > key exchange packet (which seems bogus, as the algorithms for bulk > > encryption or compression are clearly irrelevant to key exchange) > > When this was discussed in the working group meeting, the consensus in > the room seemed to be that while matching all algorithms may be > excessively conservative, excessive conservatism in this case was not > a problem from the point of view of interoperability. In any case, the conditions need to be clarified. And I'd prefer saying that the test for the success of a guess includes only the key_exchange and server_host_key parts, not including bulk encryption algorithms, compression algorithms or language tags... Which of these are intended to be referred to by "all" is not clear from the spec, and if implementations uses different success-criteria, that breaks interoperability. > > while section 5.1, describing the kex_algorithms field, seems to imply > > that a guess is considered successful iff the advertised key-exchange > > methods match > > I don't get that implication from section 5.1; however, some > clarification may be in order. Try ripping it a just a little out of context, : kex_algorithms : Key exchange algorithms were defined above. The first algorithm : MUST be the preferred (and guessed) algorithm. If both sides make : the same guess, that algorithm MUST be used. Otherwise, the : following algorithm MUST be used to choose a key exchange method: > > The second most serious problem is that the algorithm names openpgp, > > x509v3 and spki are defined, even though those definitions doesn't > > match the requirements (section 4.6) on a public-key algorithm name > > (more precisely, an algorithm name, by itself, should provide > > information about the algorithms used (rsa/dsa etc), key usage). > > This was raised as an issue last time around. my personal take on the > situation [wg chair hat off] is that the current transport protocol > draft conflates public key formats and certificate formats, and that > before certificates of any format (pgp, spki, x.509) can be used with > ssh, these need to be disentangled. Do you think that can be fixed without either breaking backwards compatibility and architecture, or doing something ugly? I think there are three components: * The kind of certificate (implying the rules for validation, encoding rules for certificates related objects), * The algorithms that has to be supported to process the certificate(s) (advertised by the sending side), and available algorithms (advertised by the receiving side). * The algorithm and properties (e.g. key usage) of the certified key. At least the first two could be represented using algorithm names like "spki:dsa;rsa", without breaking too much. But it gets a little messy to fit all three into an identifier, in particular if one ever wants to be able to introduce new properties besides signature/encryption capability. /Niels From owner-ietf-ssh@clinet.fi Thu Dec 7 04:41:27 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 EAA15225 for ; Thu, 7 Dec 2000 04:41:26 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id JAA08809 for ietf-ssh-outgoing; Thu, 7 Dec 2000 09:50:49 +0200 Received: from mail.platform.com.cn ([202.106.134.28]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id JAA08767 for ; Thu, 7 Dec 2000 09:50:39 +0200 Received: from platform.com.cn (pc1 [172.20.1.1]) by mail.platform.com.cn (8.9.3/8.9.3) with ESMTP id PAA28505 for ; Thu, 7 Dec 2000 15:53:08 +0800 Message-ID: <3A2F3C07.C2929CDD@platform.com.cn> Date: Thu, 07 Dec 2000 15:28:07 +0800 From: cong X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ssh@clinet.fi Subject: about DISPLAY Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Hi Sir/Madam, After ssh'ing to a host, the DISPLAY variable changes to a new value. Is there any simple way for me to get the original value ? Regards Guojing From owner-ietf-ssh@clinet.fi Thu Dec 7 05:54:26 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 FAA26841 for ; Thu, 7 Dec 2000 05:54:25 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id KAA25220 for ietf-ssh-outgoing; Thu, 7 Dec 2000 10:54:38 +0200 Received: from addr15.addr.com (addr.com [209.249.147.60] (may be forged)) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id KAA25140 for ; Thu, 7 Dec 2000 10:54:27 +0200 Received: (from nobody@localhost) by addr15.addr.com (8.9.3/8.9.1) id AAA19286; Thu, 7 Dec 2000 00:51:40 -0800 (PST) (envelope-from nobody) Date: Thu, 7 Dec 2000 00:51:40 -0800 (PST) Message-Id: <200012070851.AAA19286@addr15.addr.com> To: ietf-ssh@clinet.fi From: "Хамтек Паблишер" Subject: ДЕЛОВАЯ ЛИТЕРАТУРА MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to base64 by mail.clinet.fi id KAA25220 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id FAA26841 ДЕЛОВАЯ ЛИТЕРАТУРА "ХАМТЕК ПАБЛИШЕР": "Р-СИСТЕМА: ВВЕДЕНИЕ В ЭКОНОМИЧЕСКИЙ ШПИОНАЖ. ПРАКТИКУМ ПО ЭКОНОМИЧЕСКОЙ РАЗВЕДКЕ В СОВРЕМЕННОМ РОССИЙСКОМ ПРЕДПРИНИМАТЕЛЬСТВЕ" (М "ХАМТЕК ПАБЛИШЕР", 1997, книга первая -- 494 с, кннига вторая -- 447 с., евродизайн, цена -- 70 у.е.) Книга, безусловно, лучшая из написанных на тему шпионажа, освещает темные стороны деловой жизни современной России. Обобщен профессиональный опыт российского инвестиционного агентства "Пентарекс", чьи усилия бопее шести лет помогали людям делать деньги, часто за счет менее опытных партнеров. Вашему вниманию представляется новейшая система предпринимательства с применением разведывательных технологий - Р-система. Оперативная и разведывательная деятельность по пресечению провалов в бизнесе и повышению его эффективности иллюстрирована примерами из деловых ситуаций. Практикум "Р-система…" - это хрестоматия предпринимательских рисков с рекомендациями по их нейтрализации: полная палитра рисков от макроэкономических и криминогенных до личностных. Вас ждет знакомство с азами планирования разведывательных действий, основными видами операций, методами и средствами сбора и обработки разведданных. Центральное внимание уделено вопросам оперативной психологии, методам психологического возд! ействия, коррекции поведения и самозащите. Подобной систематизации Вы не найдете нигде более. Практикум адресован всем, кто не намерен оплачивать ошибки из собственного кармана. Познакомьтесь с Р-системой -- системой построения беспроигрышного бизнеса. КАТАЛОГ "100 КОМПЬЮТЕРНЫХ ПРОГРАММ ДЛЯ БИЗНЕСА" (М., "ХАМТЕК ПАБЛИШЕР", 1997-98, 560 с, 500 иллюстраций, евродизайн, цена - 50 у.е.) В Каталоге представлены подробные описания ста российских компьютерных программ для бизнеса от офисных приложений до новейших систем искусственного интеллекта. Часть описаний охватывает практически все, что есть на рынке - инструменты финансового планирования и составления бизнес-планов, обработки текстовой и статистической информации. Часть описаний посвящена наиболее характерным представителям своего класса. В целом Вы получаете полновесный срез российского рынка программ для бизнеса. Все это - просто и доходчиво: описания адаптированы и прошли специальную психолингвистическую обработку. По каждой программе Вы сможете составить исчерпывающее представление от истории ее создания и разработчиках, основных идеях и возможностях до отзывов пользователей, цен и мест покупки. Описание типичного сеанса работы разбирается на конкретных примерах. Каталог расчитан в первую очередь на предпринимателей, руководителей и ведущих специалистов отделов планирования, системного анализа и оптимизации, маркетинга и финансов, кадровой и социологичесокй службы, рекламы и секьюрити, независимых консультантов. Ваши проблемы уже кто-то решил - пользуйтесь. "СУЧИЙ БИЗНЕС" (М., "ХАМТЕК ПАБЛИШЕР", 1999, 261с, евродизайн, цена - 30 у.е.) Документальный очерк о столичных риэлторах, фактографическое описание реального бизнеса. Впервые -- предельно откровенно о живом конкретном деле. Без лирики, отвлечений и украшательств, все как было в жизни. От первой странницы до последней "Сучий бизнес" и есть сама эта жизнь. Не для широкого круга читателей. Особо не рекомендуется нововиспеченным предпринимателям широкого профиля и лицам, склонным к торговле недвижимостью. По вопросам приобретения книг обращайтесь в издательство "ХАМТЕК ПАБЛИШЕР" (095) 955-2918 с 10.00 до 18.00 по рабочим дням. Возможна доставка покупки курьерами. демпчбс мйфетбфхтб "ибнфел рбвмйыет": "т-уйуфенб: ччедеойе ч ьлпопнйюеулйк ырйпобц. ртблфйлхн рп ьлпопнйюеулпк тбъчедле ч упчтенеоопн тпууйкулпн ртедртйойнбфемшуфче" (н "ибнфел рбвмйыет", 1997, ЛОЙЗБ РЕТЧБС -- 494 У, ЛООЙЗБ ЧФПТБС -- 447 У., ЕЧТПДЙЪБКО, ГЕОБ -- 70 Х.Е.) лОЙЗБ, ВЕЪХУМПЧОП, МХЮЫБС ЙЪ ОБРЙУБООЩИ ОБ ФЕНХ ЫРЙПОБЦБ, ПУЧЕЭБЕФ ФЕНОЩЕ УФПТПОЩ ДЕМПЧПК ЦЙЪОЙ УПЧТЕНЕООПК тПУУЙЙ. пВПВЭЕО РТПЖЕУУЙПОБМШОЩК ПРЩФ ТПУУЙКУЛПЗП ЙОЧЕУФЙГЙПООПЗП БЗЕОФУФЧБ "рЕОФБТЕЛУ", ЮШЙ ХУЙМЙС ВПРЕЕ ЫЕУФЙ МЕФ РПНПЗБМЙ МАДСН ДЕМБФШ ДЕОШЗЙ, ЮБУФП ЪБ УЮЕФ НЕОЕЕ ПРЩФОЩИ РБТФОЕТПЧ. чБЫЕНХ ЧОЙНБОЙА РТЕДУФБЧМСЕФУС ОПЧЕКЫБС УЙУФЕНБ РТЕДРТЙОЙНБФЕМШУФЧБ У РТЙНЕОЕОЙЕН ТБЪЧЕДЩЧБФЕМШОЩИ ФЕИОПМПЗЙК - т-УЙУФЕНБ. пРЕТБФЙЧОБС Й ТБЪЧЕДЩЧБФЕМШОБС ДЕСФЕМШОПУФШ РП РТЕУЕЮЕОЙА РТПЧБМПЧ Ч ВЙЪОЕУЕ Й РПЧЩЫЕОЙА ЕЗП ЬЖЖЕЛФЙЧОПУФЙ ЙММАУФТЙТПЧБОБ РТЙНЕТБНЙ ЙЪ ДЕМПЧЩИ УЙФХБГЙК. рТБЛФЙЛХН "т-УЙУФЕНБ…" - ЬФП ИТЕУФПНБФЙС РТЕДРТЙОЙНБФЕМШУЛЙИ ТЙУЛПЧ У ТЕЛПНЕОДБГЙСНЙ РП ЙИ ОЕКФТБМЙЪБГЙЙ: РПМОБС РБМЙФТБ ТЙУЛПЧ ПФ НБЛТПЬЛПОПНЙЮЕУЛЙИ Й ЛТЙНЙОПЗЕООЩИ ДП МЙЮОПУФОЩИ. чБУ ЦДЕФ ЪОБЛПНУФЧП У БЪБНЙ РМБОЙТПЧБОЙС ТБЪЧЕДЩЧБФЕМШОЩИ ДЕКУФЧЙК, ПУОПЧОЩНЙ ЧЙДБНЙ ПРЕТБГЙК, НЕФПДБНЙ Й УТЕДУФЧБНЙ УВПТБ Й ПВТБВПФЛЙ ТБЪЧЕДДБООЩИ. гЕОФТБМШОПЕ ЧОЙНБОЙЕ ХДЕМЕОП ЧПРТПУБН ПРЕТБФЙЧОПК РУЙИПМПЗЙЙ, НЕФПДБН РУЙИПМПЗЙЮЕУЛПЗП ЧПЪД! ЕКУФЧЙС, ЛПТТЕЛГЙЙ РПЧЕДЕОЙС Й УБНПЪБЭЙФЕ. рПДПВОПК УЙУФЕНБФЙЪБГЙЙ чЩ ОЕ ОБКДЕФЕ ОЙЗДЕ ВПМЕЕ. рТБЛФЙЛХН БДТЕУПЧБО ЧУЕН, ЛФП ОЕ ОБНЕТЕО ПРМБЮЙЧБФШ ПЫЙВЛЙ ЙЪ УПВУФЧЕООПЗП ЛБТНБОБ. рПЪОБЛПНШФЕУШ У т-УЙУФЕНПК -- УЙУФЕНПК РПУФТПЕОЙС ВЕУРТПЙЗТЩЫОПЗП ВЙЪОЕУБ. лбфбмпз "100 лпнршафетощи ртпзтбнн дмс вйъоеуб" (н., "ибнфел рбвмйыет", 1997-98, 560 У, 500 ЙММАУФТБГЙК, ЕЧТПДЙЪБКО, ГЕОБ - 50 Х.Е.) ч лБФБМПЗЕ РТЕДУФБЧМЕОЩ РПДТПВОЩЕ ПРЙУБОЙС УФБ ТПУУЙКУЛЙИ ЛПНРШАФЕТОЩИ РТПЗТБНН ДМС ВЙЪОЕУБ ПФ ПЖЙУОЩИ РТЙМПЦЕОЙК ДП ОПЧЕКЫЙИ УЙУФЕН ЙУЛХУУФЧЕООПЗП ЙОФЕММЕЛФБ. юБУФШ ПРЙУБОЙК ПИЧБФЩЧБЕФ РТБЛФЙЮЕУЛЙ ЧУЕ, ЮФП ЕУФШ ОБ ТЩОЛЕ - ЙОУФТХНЕОФЩ ЖЙОБОУПЧПЗП РМБОЙТПЧБОЙС Й УПУФБЧМЕОЙС ВЙЪОЕУ-РМБОПЧ, ПВТБВПФЛЙ ФЕЛУФПЧПК Й УФБФЙУФЙЮЕУЛПК ЙОЖПТНБГЙЙ. юБУФШ ПРЙУБОЙК РПУЧСЭЕОБ ОБЙВПМЕЕ ИБТБЛФЕТОЩН РТЕДУФБЧЙФЕМСН УЧПЕЗП ЛМБУУБ. ч ГЕМПН чЩ РПМХЮБЕФЕ РПМОПЧЕУОЩК УТЕЪ ТПУУЙКУЛПЗП ТЩОЛБ РТПЗТБНН ДМС ВЙЪОЕУБ. чУЕ ЬФП - РТПУФП Й ДПИПДЮЙЧП: ПРЙУБОЙС БДБРФЙТПЧБОЩ Й РТПЫМЙ УРЕГЙБМШОХА РУЙИПМЙОЗЧЙУФЙЮЕУЛХА ПВТБВПФЛХ. рП ЛБЦДПК РТПЗТБННЕ чЩ УНПЦЕФЕ УПУФБЧЙФШ ЙУЮЕТРЩЧБАЭЕЕ РТЕДУФБЧМЕОЙЕ ПФ ЙУФПТЙЙ ЕЕ УПЪДБОЙС Й ТБЪТБВПФЮЙЛБИ, ПУОПЧОЩИ ЙДЕСИ Й ЧПЪНПЦОПУФСИ ДП ПФЪЩЧПЧ РПМШЪПЧБФЕМЕК, ГЕО Й НЕУФ РПЛХРЛЙ. пРЙУБОЙЕ ФЙРЙЮОПЗП УЕБОУБ ТБВПФЩ ТБЪВЙТБЕФУС ОБ ЛПОЛТЕФОЩИ РТЙНЕТБИ. лБФБМПЗ ТБУЮЙФБО Ч РЕТЧХА ПЮЕТЕДШ ОБ РТЕДРТЙОЙНБФЕМЕК, ТХЛПЧПДЙФЕМЕК Й ЧЕДХЭЙИ УРЕГЙБМЙУФПЧ ПФДЕМПЧ РМБОЙТПЧБОЙС, УЙУФЕНОПЗП БОБМЙЪБ Й ПРФЙНЙЪБГЙЙ, НБТЛЕФЙОЗБ Й ЖЙОБОУПЧ, ЛБДТПЧПК Й УПГЙПМПЗЙЮЕУПЛК УМХЦВЩ, ТЕЛМБНЩ Й УЕЛШАТЙФЙ, ОЕЪБЧЙУЙНЩИ ЛПОУХМШФБОФПЧ. чБЫЙ РТПВМЕНЩ ХЦЕ ЛФП-ФП ТЕЫЙМ - РПМШЪХКФЕУШ. "ухюйк вйъоеу" (н., "ибнфел рбвмйыет", 1999, 261У, ЕЧТПДЙЪБКО, ГЕОБ - 30 Х.Е.) дПЛХНЕОФБМШОЩК ПЮЕТЛ П УФПМЙЮОЩИ ТЙЬМФПТБИ, ЖБЛФПЗТБЖЙЮЕУЛПЕ ПРЙУБОЙЕ ТЕБМШОПЗП ВЙЪОЕУБ. чРЕТЧЩЕ -- РТЕДЕМШОП ПФЛТПЧЕООП П ЦЙЧПН ЛПОЛТЕФОПН ДЕМЕ. вЕЪ МЙТЙЛЙ, ПФЧМЕЮЕОЙК Й ХЛТБЫБФЕМШУФЧ, ЧУЕ ЛБЛ ВЩМП Ч ЦЙЪОЙ. пФ РЕТЧПК УФТБООЙГЩ ДП РПУМЕДОЕК "уХЮЙК ВЙЪОЕУ" Й ЕУФШ УБНБ ЬФБ ЦЙЪОШ. оЕ ДМС ЫЙТПЛПЗП ЛТХЗБ ЮЙФБФЕМЕК. пУПВП ОЕ ТЕЛПНЕОДХЕФУС ОПЧПЧЙУРЕЮЕООЩН РТЕДРТЙОЙНБФЕМСН ЫЙТПЛПЗП РТПЖЙМС Й МЙГБН, УЛМПООЩН Л ФПТЗПЧМЕ ОЕДЧЙЦЙНПУФША. рП ЧПРТПУБН РТЙПВТЕФЕОЙС ЛОЙЗ ПВТБЭБКФЕУШ Ч ЙЪДБФЕМШУФЧП "ибнфел рбвмйыет" (095) 955-2918 У 10.00 ДП 18.00 РП ТБВПЮЙН ДОСН. чПЪНПЦОБ ДПУФБЧЛБ РПЛХРЛЙ ЛХТШЕТБНЙ. _________________________________________________________________________ From owner-ietf-ssh@clinet.fi Sat Dec 9 14:03: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 OAA08519 for ; Sat, 9 Dec 2000 14:03:30 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA19322 for ietf-ssh-outgoing; Sat, 9 Dec 2000 19:15:14 +0200 Message-Id: <200012091715.TAA19322@mail.clinet.fi> Received: from nt1.rocori.k12.mn.us (nt1.rocori.k12.mn.us [207.229.251.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA19318 for ; Sat, 9 Dec 2000 19:15:08 +0200 From: Mail Sender To: ietf-smime-request@imc.org CC: ietf-ssh@clinet.fi, ietf-stime@stime.org, ietf-stime-request@stime.org, ietf-tls@lists.certicom.com, ietf-tls-request@lists.certicom.com Subject: Russian Goods and Service from Moscow Reply-To: mailsender@mailsender.ru Date: 09.12.2000 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-ssh@clinet.fi Precedence: bulk www.rusgoods.com www.rusgoods.ru ================================================================ We present you the production of the 1-st Moscow Watch Factory "Poljot" (Flying). From the simple mechanical watch of the series 2609 till unique, composite and precise mechanical o'clock - Marine timer . It is unique factory in Russia, which makes mechanical hours with the Swiss quality. Factory, which makes watches for the Russian Air Forces , Russian Naval Forces. All mechanical watch which we offer to you, will be delivered to you directly from the factory. If it isn't in the warehouse of the factory, we will place your order directly at the 1-st Moscow Watch Factory without any middlemans. The submarine "Kursk" had on board mechanical marine hronometr 6MX. =============================================================== The "table" of orders. Here you can to order, to find, to know almost everything, than the Russia is rich, everything that does not contradict Russian Federation laws. Here you can receive or order: The information about any enterprise, firm, organization, or person in Russia The production or any goods of Russian manufactories, and other things if it is possible. =============================================================== www.rusgoods.com www.rusgoods.ru From owner-ietf-ssh@clinet.fi Sun Dec 10 01:38: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 BAA25299 for ; Sun, 10 Dec 2000 01:38:28 -0500 (EST) From: owner-ietf-ssh@clinet.fi Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id GAA23070 for ietf-ssh-outgoing; Sun, 10 Dec 2000 06:45:53 +0200 Received: from taco01.taco.co.jp (taco01-gw.taco.co.jp [210.132.58.50]) by mail.clinet.fi (8.9.3/8.9.3) with SMTP id GAA23030; Sun, 10 Dec 2000 06:45:24 +0200 Received: from 193.200.156.174 (1Cust103.tnt6.fort-lauderdale.fl.da.uu.net [63.25.242.103]) by taco01.taco.co.jp (8.6.11/8.6.9) with SMTP id NAA26909; Sun, 10 Dec 2000 13:51:46 +0900 Message-ID: <000042a165fe$00003f27$00007efc@193.200.156.174> To: Subject: Your Christmas Present 32508 Date: Sat, 09 Dec 2000 23:45:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit You have seen it on TV! Hard Copy, Howard Stern, Extra, Inside Edition, Etc... You have heard about it from friends! Now go and see for yourself! Click http://1082394634/hardcore_celeb/index.html The site they don't want you to see. The site that they want shut down, but the first amendment protects us! Click http://1082394634/hardcore_celeb/index.html If link does not work, cut and paste in your browsers window. remove 98572kelly@ucs.com.tw From owner-ietf-ssh@clinet.fi Mon Dec 11 15:58:21 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 PAA09315 for ; Mon, 11 Dec 2000 15:58:20 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA10882 for ietf-ssh-outgoing; Mon, 11 Dec 2000 17:41:49 +0200 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA10878 for ; Mon, 11 Dec 2000 17:41:47 +0200 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA23400 for ; Mon, 11 Dec 2000 07:41:44 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA02051 for ; Mon, 11 Dec 2000 10:41:43 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eBBFf2a118134 for ; Mon, 11 Dec 2000 10:41:02 -0500 (EST) Message-Id: <200012111541.eBBFf2a118134@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@clinet.fi Subject: SECSH: other drafts on the agenda Reply-to: sommerfeld@east.sun.com Date: Mon, 11 Dec 2000 10:41:02 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk remove From owner-ietf-ssh@clinet.fi Mon Dec 11 17:16: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 RAA19149 for ; Mon, 11 Dec 2000 17:16:04 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA10882 for ietf-ssh-outgoing; Mon, 11 Dec 2000 17:41:49 +0200 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA10878 for ; Mon, 11 Dec 2000 17:41:47 +0200 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA23400 for ; Mon, 11 Dec 2000 07:41:44 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA02051 for ; Mon, 11 Dec 2000 10:41:43 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eBBFf2a118134 for ; Mon, 11 Dec 2000 10:41:02 -0500 (EST) Message-Id: <200012111541.eBBFf2a118134@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@clinet.fi Subject: SECSH: other drafts on the agenda Reply-to: sommerfeld@east.sun.com Date: Mon, 11 Dec 2000 10:41:02 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk There are currently a few individual submission drafts related to the secsh wg. On the off chance that anyone has time to read them before the session today (15:30-17:30).. During the kerberos/gssapi stage, we'll discuss: draft-galb-secsh-gssapi-00.txt SSH GSS-API Authentication Method (Galbraith & Van Dyke) draft-salowey-secsh-kerbkeyex-00.txt Using Kerberos as a key exchange method in Secure Shell (Salowey) Questions to consider: - Does either/both of these make sense as a WG document? - Does it make sense to involve gssapi/kerberos in the key exchange phase? - gssapi? kerberos? both? In addition, we'll also briefly discuss: draft-galb-secsh-publickey-channel-00.txt Secure Shell Public Key Channel (Galbraith & Van Dyke) Questions to consider: - Does this make sense as a WG document? - Does this protocol eliminate the need for a standardized file format for public key files? --HAA18982.976548609/mercury.Sun.COM-- From owner-ietf-ssh@clinet.fi Mon Dec 11 17:45:50 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 RAA22527 for ; Mon, 11 Dec 2000 17:45:31 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA13037 for ietf-ssh-outgoing; Mon, 11 Dec 2000 23:00:44 +0200 Received: from folly.informatik.uni-erlangen.de (muedi6-212-144-216-130.arcor-ip.net [212.144.216.130]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA13032 for ; Mon, 11 Dec 2000 23:00:42 +0200 Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 13A0514D2; Mon, 11 Dec 2000 22:00:24 +0100 (CET) Date: Mon, 11 Dec 2000 22:00:24 +0100 From: Markus Friedl To: Bill Sommerfeld Cc: ietf-ssh@clinet.fi Subject: Re: agenda items.. Message-ID: <20001211220024.A886@folly> References: <200011302111.eAULB5a104779@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011302111.eAULB5a104779@thunk.east.sun.com>; from sommerfeld@east.sun.com on Thu, Nov 30, 2000 at 04:11:05PM -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk re: draft-ietf-secsh-transport-08.txt defining twofish-cbc with 256 bit keys is a bad idea. it should really be called twofish{128,192,256}-cbc similar to AES. the current keyexchange definitions do not provide 256 bits of entrophy, since the sha1 output from diffie-hellman-group1-sha1 is only 160 bits. From owner-ietf-ssh@clinet.fi Mon Dec 11 19:54:32 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 TAA17592 for ; Mon, 11 Dec 2000 19:54:32 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id AAA20420 for ietf-ssh-outgoing; Tue, 12 Dec 2000 00:33:31 +0200 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id AAA20412 for ; Tue, 12 Dec 2000 00:33:29 +0200 Received: from centralmail1.Central.Sun.COM ([129.147.62.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA28078; Mon, 11 Dec 2000 15:33:25 -0700 (MST) Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id PAA24956; Mon, 11 Dec 2000 15:33:25 -0700 (MST) Received: from Eng.Sun.COM by esun1as-mm. (SMI-8.6/SMI-SVR4) id PAA11698; Mon, 11 Dec 2000 15:47:13 -0700 Message-ID: <3A34E6D5.7A3791A5@Eng.Sun.COM> Date: Mon, 11 Dec 2000 06:38:13 -0800 From: Darren J Moffat Organization: Sun Microsystems X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17-21mdk i586) X-Accept-Language: en MIME-Version: 1.0 To: Markus Friedl CC: ietf-ssh@clinet.fi Subject: Re: agenda items.. References: <200011302111.eAULB5a104779@thunk.east.sun.com> <20001211220024.A886@folly> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Markus Friedl wrote: > > re: draft-ietf-secsh-transport-08.txt > > defining twofish-cbc with 256 bit keys is a bad idea. it should > really be called > twofish{128,192,256}-cbc > similar to AES. the current keyexchange definitions do not provide > 256 bits of entrophy, since the sha1 output from diffie-hellman-group1-sha1 > is only 160 bits. I'd like to back this up. It is important for US Export compliance to be able to "cap" algorithms at a certain key lengths. All algorithm names thus need to have the keylength included so that US domestic and international clients have a chance to interoperate. eg. A US domestic ssh client may support twofish-256-cbc but it is connecting to an ssh server that only supports twofish-128-cbc because it is located outside the US. Currently blowfish is listed in the draft only for 128, I suggest that the name be blowfish-128-cbc similarly for any other algorithms. -- Darren J Moffat From owner-ietf-ssh@clinet.fi Mon Dec 11 22:31: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 WAA16742 for ; Mon, 11 Dec 2000 22:31:02 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id DAA30928 for ietf-ssh-outgoing; Tue, 12 Dec 2000 03:40:53 +0200 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id DAA30924 for ; Tue, 12 Dec 2000 03:40:52 +0200 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id DAA04509; Tue, 12 Dec 2000 03:40:53 +0200 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14901.33317.698823.721294@asgard.tky.hut.fi> Date: Tue, 12 Dec 2000 03:40:53 +0200 To: IETF-Secsh List , Martin Forssen Subject: Comments for draft-ietf-secsh-auth-kbdinteract-01.txt X-Mailer: VM 6.87 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Couple of comments: In section 3.1: The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message if the failure is based on the user name or service name; instead it SHOULD send SSH_MSG_USERAUTH_INFO_REQUEST message(s) which look just like the one(s) which would have been sent in cases where authentication should proceed, and then send the failure message (after a suitable delay, as described below). The goal is to make it impossible to find valid user names by just comparing the results when authenticating as different users. This is not good, as the server doesn't necessarily have a method to get the possible messages from a device (library etc.). For example, we don't know what PAM would query from the user if it existed. PAM doesn't allow invalid users to continue the login after account checkin. Point being, with PAM the server shouldn't take any stand on what the PAM queries or tells the users; this depends on the PAM configuration. Section 3.2: byte SSH_MSG_USERAUTH_INFO_REQUEST string name (ISO-10646 UTF-8) string instruction (ISO-10646 UTF-8) string language tag (as defined in [RFC-1766]) int num-prompts string prompt[1] (ISO-10646 UTF-8) boolean echo[1] ... string prompt[num-prompts] (ISO-10646 UTF-8) boolean echo[num-prompts] The server SHOULD limit the length of the name and prompt fields to 30 characters. No restrictions are placed on the instruction field. 30 characters could be too little. "sjl@foobar.internal.fi.ssh.com's passcode for SecurID auth:" especially considering section 3.3 considerations --snip-- request message. Clients SHOULD NOT add any additional characters to the prompt such as ": "; the server is responsible for supplying all --snap-- -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Mon Dec 11 23:42: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 XAA03413 for ; Mon, 11 Dec 2000 23:42:13 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id EAA02866 for ietf-ssh-outgoing; Tue, 12 Dec 2000 04:59:14 +0200 Received: from nic.appgate.com (nic.appgate.com [193.12.107.226]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id EAA02862 for ; Tue, 12 Dec 2000 04:59:12 +0200 Received: from pelee.firedoor.se (pelee.firedoor.se [172.23.2.10]) by nic.appgate.com (Postfix) with ESMTP id 425F03BD31; Tue, 12 Dec 2000 03:59:12 +0100 (MET) Received: from appgate.com (appgate.firedoor.se [172.23.2.21]) by pelee.firedoor.se (Postfix) with ESMTP id E2C1D317AA; Tue, 12 Dec 2000 03:59:07 +0100 (MET) Date: Mon, 11 Dec 2000 18:59:07 -0800 (PST) From: Martin Forssen Subject: Re: Comments for draft-ietf-secsh-auth-kbdinteract-01.txt To: sjl@iki.fi Cc: ietf-ssh@clinet.fi In-Reply-To: <14901.33317.698823.721294@asgard.tky.hut.fi> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20001212025907.E2C1D317AA@pelee.firedoor.se> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On 12 Dec, Sami Lehtinen wrote: > Couple of comments: > In section 3.1: > > The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message > if the failure is based on the user name or service name; instead it > SHOULD send SSH_MSG_USERAUTH_INFO_REQUEST message(s) which look just > like the one(s) which would have been sent in cases where > authentication should proceed, and then send the failure message > (after a suitable delay, as described below). The goal is to make it > impossible to find valid user names by just comparing the results > when authenticating as different users. > > This is not good, as the server doesn't necessarily have a method to > get the possible messages from a device (library etc.). For example, > we don't know what PAM would query from the user if it existed. PAM > doesn't allow invalid users to continue the login after account > checkin. Point being, with PAM the server shouldn't take any stand on > what the PAM queries or tells the users; this depends on the PAM > configuration. Unfortunately I think this is an area where there is no good solution. We would like the server to be able to make guessing valid usernames impossible but this is not always possible. Perhaps the best we can do here is to add some text to the draft where we note that we do not live in a perfect world and although desirable authentication faking may not always be possible. Something like this (to be added below the above cited paragraph): The preceding paragraph describes how we would like things to work. Unfortunately it may sometimes not be possible for the server to predict the questions which would be sent as part of a valid authentication. In those cases it is not possible to fake authentication. We could also change the beginning of the quoted paragraph to: The server SHOULD, if possible, NOT reply with the IS tis enough or shoudl we do something more radical to the wording of the draft? > Section 3.2: > > byte SSH_MSG_USERAUTH_INFO_REQUEST > string name (ISO-10646 UTF-8) > string instruction (ISO-10646 UTF-8) > string language tag (as defined in [RFC-1766]) > int num-prompts > string prompt[1] (ISO-10646 UTF-8) > boolean echo[1] > ... > string prompt[num-prompts] (ISO-10646 UTF-8) > boolean echo[num-prompts] > > The server SHOULD limit the length of the name and prompt fields to > 30 characters. No restrictions are placed on the instruction > field. > > 30 characters could be too little. > > "sjl@foobar.internal.fi.ssh.com's passcode for SecurID auth:" In this case the server really ought to split it so for example the instruction part reads "SecurID authentication for sjl@foobar.internal.fi.ssh.com" and the actual prompt is just "Passcode: " /MaF PS If the example above was real I would also suggest applying large amount of physical force to the person who has designed your network:-) PPS To add further noise here, back in the days when I worked as a sysadmin we actually used strange hostnames on machines we did not want people to log in to. Thus we had machine with names like gashplutzga, wazewski, rejewski, zorawski and so on. From owner-ietf-ssh@clinet.fi Tue Dec 12 04:06: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 EAA24192 for ; Tue, 12 Dec 2000 04:06:05 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id JAA25220 for ietf-ssh-outgoing; Tue, 12 Dec 2000 09:14:06 +0200 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id JAA25217 for ; Tue, 12 Dec 2000 09:14:05 +0200 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id JAA04732; Tue, 12 Dec 2000 09:14:06 +0200 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14901.53310.129506.130399@asgard.tky.hut.fi> Date: Tue, 12 Dec 2000 09:14:06 +0200 To: Martin Forssen Cc: ietf-ssh@clinet.fi Subject: Re: Comments for draft-ietf-secsh-auth-kbdinteract-01.txt In-Reply-To: <20001212025907.E2C1D317AA@pelee.firedoor.se> References: <14901.33317.698823.721294@asgard.tky.hut.fi> <20001212025907.E2C1D317AA@pelee.firedoor.se> X-Mailer: VM 6.87 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Martin Forssen, on December 11. 2000, wrote: [faking authentication] : Unfortunately I think this is an area where there is no good solution. : We would like the server to be able to make guessing valid usernames : impossible but this is not always possible. Perhaps the best we can do : here is to add some text to the draft where we note that we do not live : in a perfect world and although desirable authentication faking may not : always be possible. Something like this (to be added below the above : cited paragraph): : : The preceding paragraph describes how we would like things to work. : Unfortunately it may sometimes not be possible for the server to : predict the questions which would be sent as part of a valid : authentication. In those cases it is not possible to fake : authentication. : : We could also change the beginning of the quoted paragraph to: : : The server SHOULD, if possible, NOT reply with the : : IS tis enough or shoudl we do something more radical to the wording of : the draft? I think those will suffice. However, the whole concept of faking the authentication is subject to debate. I, for one, don't have a strong opinion about this. But, I think the decision on whether to fake or not should probably be configurable by the adminkind. : > 30 characters could be too little. : > : > "sjl@foobar.internal.fi.ssh.com's passcode for SecurID auth:" : : In this case the server really ought to split it so for example the : instruction part reads : : "SecurID authentication for sjl@foobar.internal.fi.ssh.com" : : and the actual prompt is just "Passcode: " Fair enough. : PS If the example above was real I would also suggest applying large : amount of physical force to the person who has designed your : network:-) I'll forward your comments to our IT-department :) -- [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 Dec 12 04:52: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 EAA29463 for ; Tue, 12 Dec 2000 04:52:45 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id JAA31196 for ietf-ssh-outgoing; Tue, 12 Dec 2000 09:42:06 +0200 Received: from faui02.informatik.uni-erlangen.de (msfriedl@faui02.informatik.uni-erlangen.de [131.188.30.102]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id JAA31191 for ; Tue, 12 Dec 2000 09:42:05 +0200 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id IAA19792; Tue, 12 Dec 2000 08:41:49 +0100 (MET) Date: Tue, 12 Dec 2000 08:41:49 +0100 From: Markus Friedl To: Tero Kivinen Cc: Bill Sommerfeld , ietf-ssh@clinet.fi, provos@citi.umich.edu Subject: Re: agenda items.. Message-ID: <20001212084149.A19763@faui02.informatik.uni-erlangen.de> References: <200011302111.eAULB5a104779@thunk.east.sun.com> <20001211220024.A886@folly> <14901.30620.865801.520277@hutcs.cs.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <14901.30620.865801.520277@hutcs.cs.hut.fi>; from kivinen@mail.niksula.cs.hut.fi on Tue, Dec 12, 2000 at 02:56:33AM +0200 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Tue, Dec 12, 2000 at 02:56:33AM +0200, Tero Kivinen wrote: > And the standard 1024 bit Diffie-Hellman group only gives you about 80 > bits of entrophy. so you agree that draft-provos-secsh-dh-group-exchange-00.txt should be considered? -markus From owner-ietf-ssh@clinet.fi Tue Dec 12 06:50: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 GAA12596 for ; Tue, 12 Dec 2000 06:50:51 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id LAA29907 for ietf-ssh-outgoing; Tue, 12 Dec 2000 11:47:12 +0200 Received: from citi.umich.edu (citi.umich.edu [141.211.92.141]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id LAA29861 for ; Tue, 12 Dec 2000 11:47:07 +0200 Received: from citi.umich.edu (ssh-mapper.citi.umich.edu [141.211.92.147]) by citi.umich.edu (Postfix) with ESMTP id B6B32207C1; Tue, 12 Dec 2000 04:47:05 -0500 (EST) Subject: Re: agenda items.. From: Niels Provos In-Reply-To: Markus Friedl, Mon, 11 Dec 2000 22:00:24 +0100 To: Markus Friedl Cc: Bill Sommerfeld , ietf-ssh@clinet.fi Date: Tue, 12 Dec 2000 04:47:05 -0500 Message-Id: <20001212094705.B6B32207C1@citi.umich.edu> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk In message <20001211220024.A886@folly>, Markus Friedl writes: >similar to AES. the current keyexchange definitions do not provide >256 bits of entrophy, since the sha1 output from diffie-hellman-group1-sha1 >is only 160 bits. The limited entropy is due to the small group size in the Diffie-Hellman key exchange. The 160 bits of SHA1 are limiting the strength of the authentication. For the AES cipher, we should really go to something stronger like SHA-512. Of course that means not to use DSA any more. DSA is limited to signing just 160-bits. We need to use RSA instead, which seems to be a more secure signature scheme anyway. Of course, the collision attack has to be done in real time and is not feasible, the bigger problem is the limited size of the DH group. Niels. From owner-ietf-ssh@clinet.fi Tue Dec 12 15:37: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 PAA06784 for ; Tue, 12 Dec 2000 15:37:12 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA28039 for ietf-ssh-outgoing; Tue, 12 Dec 2000 20:09:33 +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 UAA28036 for ; Tue, 12 Dec 2000 20:09:33 +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 UAA11826; Tue, 12 Dec 2000 20:09:29 +0200 (EET) Received: (from mkojo@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.17) id UAA28906; Tue, 12 Dec 2000 20:09:29 +0200 (EET) Date: Tue, 12 Dec 2000 20:09:29 +0200 (EET) Message-Id: <200012121809.UAA28906@torni.hel.fi.ssh.com> X-Authentication-Warning: torni.hel.fi.ssh.com: mkojo set sender to mkojo@torni.hel.fi.ssh.com using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Mika Kojo To: Markus Friedl Cc: Tero Kivinen , Bill Sommerfeld , ietf-ssh@clinet.fi, provos@citi.umich.edu Subject: Re: agenda items.. In-Reply-To: <20001212084149.A19763@faui02.informatik.uni-erlangen.de> References: <200011302111.eAULB5a104779@thunk.east.sun.com> <20001211220024.A886@folly> <14901.30620.865801.520277@hutcs.cs.hut.fi> <20001212084149.A19763@faui02.informatik.uni-erlangen.de> X-Mailer: VM 6.34 under Emacs 20.7.2 Organization: SSH Communications Security, Finland Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Hello all, I have few questions and comments on draft-provos-secsh-dh-group-exchange-00.txt. There it reads: Either side MUST NOT send or accept e or f values that are not in the range [1, p-1]. If this condition is violated, the key exchange fails. My question is whether [1, p-1] is justified for the protocol. I would understand (1, p-1), but perhaps someone can shortly explain the need for also 1 and p-1. Also why does these protocols insist that server should select y from (0,q) when most other protocols simply take it from (1,q)? The suggested protocol makes the client choose the lower bound for the subgroup. However, there is no need to include this information to the hash as it contains already p (and g). It should be specified that the client is required to check that p is of sufficient size. In the specification it reads that: If the order is p - 1, then the exponents generate all possible public-values, evenly distributed throughout the range of the modulus p, without cycling through a smaller subset. I suspect "evenly distributed" would read better as "uniformly distributed". Although it is true that g^x is uniformly distributed, it is clearly not true that (g^x)^y would be, for fixed x, if g is of order p-1. Although having safe primes is fine, I think that some additional benefit would be achieved from use of q << p. This would satisfy still the "uniformly distributed" requirement (in the subgroup) and obtain additional efficiency. Most implementations sacrifice the uniform distribution for speed, and in a sense this is unfortunate. -- Mika Kojo SSH Communications Security Corp Markus Friedl writes: > On Tue, Dec 12, 2000 at 02:56:33AM +0200, Tero Kivinen wrote: > > And the standard 1024 bit Diffie-Hellman group only gives you about 80 > > bits of entrophy. > > so you agree that > draft-provos-secsh-dh-group-exchange-00.txt > should be considered? > > -markus From owner-ietf-ssh@clinet.fi Wed Dec 13 06:30: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 GAA03955 for ; Wed, 13 Dec 2000 06:30:29 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id LAA15513 for ietf-ssh-outgoing; Wed, 13 Dec 2000 11:07:25 +0200 Received: from citi.umich.edu (citi.umich.edu [141.211.92.141]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id LAA15503 for ; Wed, 13 Dec 2000 11:07:02 +0200 Received: from citi.umich.edu (ssh-mapper.citi.umich.edu [141.211.92.147]) by citi.umich.edu (Postfix) with ESMTP id 709B5207C1; Wed, 13 Dec 2000 04:07:01 -0500 (EST) Subject: Re: agenda items.. From: Niels Provos In-Reply-To: Darren J Moffat, Mon, 11 Dec 2000 06:38:13 PST To: Darren J Moffat Cc: Markus Friedl , ietf-ssh@clinet.fi Date: Wed, 13 Dec 2000 04:07:01 -0500 Message-Id: <20001213090701.709B5207C1@citi.umich.edu> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk In message <3A34E6D5.7A3791A5@Eng.Sun.COM>, Darren J Moffat writes: >I'd like to back this up. It is important for US Export compliance to >be able to "cap" algorithms at a certain key lengths. All algorithm >names thus need to have the keylength included so that US domestic and >international clients have a chance to interoperate. eg. A US >domestic ssh client may support twofish-256-cbc but it is connecting >to an ssh server that only supports twofish-128-cbc because it is >located outside the US. I do not think that we should concern ourselves with US Export restrictions. Nobody with any sense is going to run restricted US software, there are too many better alternatives. However, there are other good reasons to indicate the key size. These ciphers have different key size modes and to keep things simple indicating the key size in the name is the easiest. Perhaps we can resolve this in London next year ;) Niels. From owner-ietf-ssh@clinet.fi Wed Dec 13 15:03: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 PAA12086 for ; Wed, 13 Dec 2000 15:03:50 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA25522 for ietf-ssh-outgoing; Wed, 13 Dec 2000 20:05:54 +0200 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA25517 for ; Wed, 13 Dec 2000 20:05:53 +0200 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11599; Wed, 13 Dec 2000 10:05:48 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA25753; Wed, 13 Dec 2000 13:05:46 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eBDI55a119253; Wed, 13 Dec 2000 13:05:05 -0500 (EST) Message-Id: <200012131805.eBDI55a119253@thunk.east.sun.com> From: Bill Sommerfeld To: Niels Provos cc: Darren J Moffat , Markus Friedl , ietf-ssh@clinet.fi Subject: Re: agenda items.. In-reply-to: Your message of "Wed, 13 Dec 2000 04:07:01 EST." <20001213090701.709B5207C1@citi.umich.edu> Reply-to: sommerfeld@east.sun.com Date: Wed, 13 Dec 2000 13:05:04 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > I do not think that we should concern ourselves with US Export > restrictions. Correct; on the whole, the IETF does not engineer security protocols to include weak crypto or to accomodate the regulations of specific jurisdictions. The documents do not need to acknowledge export control issues, and should not specify ciphers known to be feasibly breakable. > However, there are other good reasons to indicate the key size. > These ciphers have different key size modes and to keep things > simple indicating the key size in the name is the easiest. Agreed. As I understand it, this should be sufficient to meet Darren's fundamental requirements.. > Perhaps we can resolve this in London next year ;) Assuming they don't demand copies of our private keys as a condition of entry at Heathrow ;-) - Bill From owner-ietf-ssh@clinet.fi Thu Dec 14 04:11: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 EAA05247 for ; Thu, 14 Dec 2000 04:11:18 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id IAA13508 for ietf-ssh-outgoing; Thu, 14 Dec 2000 08:52:08 +0200 Received: from stack.hamachi.org (sommerfeld.ne.mediaone.net [24.147.212.81]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id IAA13495 for ; Thu, 14 Dec 2000 08:52:06 +0200 Received: from syn.hamachi.org (orchard.hamachi.org [4.255.0.98]) by stack.hamachi.org (Postfix) with ESMTP id A67A6278C; Thu, 14 Dec 2000 01:51:59 -0500 (EST) Received: from syn.hamachi.org (localhost [[UNIX: localhost]]) by syn.hamachi.org (8.11.0/8.8.8) with ESMTP id eBE6ppR05488; Wed, 13 Dec 2000 22:51:51 -0800 (PST) Message-Id: <200012140651.eBE6ppR05488@syn.hamachi.org> From: Bill Sommerfeld To: Sami Lehtinen Cc: ietf-ssh@clinet.fi Subject: IANA considerations section in draft-ietf-secsh-architecture-06.txt In-Reply-To: Message from Sami Lehtinen of "Tue, 12 Dec 2000 09:14:06 +0200." <14901.53310.129506.130399@asgard.tky.hut.fi> Reply-To: sommerfeld@orchard.arlington.ma.us Date: Wed, 13 Dec 2000 22:51:50 -0800 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk i was about to ask iana@iana.org to review the iana consideration section, but it looks like the like the subheading for the IANA Considerations section disappeared from the architecture draft.. 6. Message Numbers . . . . . . . . . . . . . . . . . . . . . . . . 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 - Bill From owner-ietf-ssh@clinet.fi Thu Dec 14 14:25:32 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 OAA22832 for ; Thu, 14 Dec 2000 14:25:31 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA12183 for ietf-ssh-outgoing; Thu, 14 Dec 2000 19:41:44 +0200 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA12178 for ; Thu, 14 Dec 2000 19:41:43 +0200 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id TAA06555; Thu, 14 Dec 2000 19:41:33 +0200 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14905.1612.850687.523359@asgard.tky.hut.fi> Date: Thu, 14 Dec 2000 19:41:32 +0200 To: sommerfeld@orchard.arlington.ma.us Cc: ietf-ssh@clinet.fi Subject: IANA considerations section in draft-ietf-secsh-architecture-06.txt In-Reply-To: <200012140651.eBE6ppR05488@syn.hamachi.org> References: <14901.53310.129506.130399@asgard.tky.hut.fi> <200012140651.eBE6ppR05488@syn.hamachi.org> X-Mailer: VM 6.87 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Bill Sommerfeld, on December 13. 2000, wrote: : i was about to ask iana@iana.org to review the iana consideration : section, but it looks like the like the subheading for the IANA : Considerations section disappeared from the architecture draft.. : : 6. Message Numbers . . . . . . . . . . . . . . . . . . . . . . . . 8 : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 : 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 Tero answered this already. The IANA considerations weren't changed AFAIK from the last draft, so you can use that when asking. Cheers, -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Thu Dec 14 15:20: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 PAA04907 for ; Thu, 14 Dec 2000 15:20:53 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA15927 for ietf-ssh-outgoing; Thu, 14 Dec 2000 20:27:27 +0200 Received: from stack.hamachi.org (sommerfeld.ne.mediaone.net [24.147.212.81]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA15923 for ; Thu, 14 Dec 2000 20:27:25 +0200 Received: from syn.hamachi.org (orchard.hamachi.org [4.255.0.98]) by stack.hamachi.org (Postfix) with ESMTP id 7EA7C278F; Thu, 14 Dec 2000 13:27:23 -0500 (EST) Received: from syn.hamachi.org (localhost [[UNIX: localhost]]) by syn.hamachi.org (8.11.0/8.8.8) with ESMTP id eBEIRBr05983; Thu, 14 Dec 2000 10:27:11 -0800 (PST) Message-Id: <200012141827.eBEIRBr05983@syn.hamachi.org> From: Bill Sommerfeld To: Sami Lehtinen Cc: ietf-ssh@clinet.fi Subject: Re: IANA considerations section in draft-ietf-secsh-architecture-06.txt In-Reply-To: Message from Sami Lehtinen of "Thu, 14 Dec 2000 19:41:32 +0200." <14905.1612.850687.523359@asgard.tky.hut.fi> Reply-To: sommerfeld@orchard.arlington.ma.us Date: Thu, 14 Dec 2000 10:27:09 -0800 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk I was pointed at RFC2434, "Guidelines on writing an 'IANA Considerations' section". It appears that we need just a little more detail in the architecture draft; it also appears that the message numbers in section 6 of the arch draft should also end up under the control of the IANA once the documents are published as proposed standards. Translating into the terminology in 2434, it looks like a reasonable set of policies would be: - message numbers in the range of 0..191 should be allocated via IETF consensus; message numbers in the 192..255 range (the "Local extensions" set) are reserved for private use. - protocol names are divided into three pieces: - names with @ signs in them are allocated by the owner of the DNS name after the @ sign ("hierarchical allocation" in 2434 terms) - @-free names beginning with "ssh-" should be allocated using the IETF consensus process. - @-free names not beginning with ssh- should be allocated using 2434's "specification required" policy. Comments? - Bill From owner-ietf-ssh@clinet.fi Thu Dec 14 18:26:40 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 SAA12880 for ; Thu, 14 Dec 2000 18:26:38 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA29989 for ietf-ssh-outgoing; Thu, 14 Dec 2000 23:42:10 +0200 Received: from nic.appgate.com (nic.appgate.com [193.12.107.226]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA29986 for ; Thu, 14 Dec 2000 23:42:09 +0200 Received: from pelee.firedoor.se (pelee.firedoor.se [172.23.2.10]) by nic.appgate.com (Postfix) with ESMTP id B08443BE08; Thu, 14 Dec 2000 22:42:09 +0100 (MET) Received: from appgate.com (appgate.firedoor.se [172.23.2.21]) by pelee.firedoor.se (Postfix) with ESMTP id E0615317AA; Thu, 14 Dec 2000 22:41:58 +0100 (MET) Date: Thu, 14 Dec 2000 13:41:59 -0800 (PST) From: Martin Forssen Subject: Re: IANA considerations section in draft-ietf-secsh-architecture-06.txt To: sommerfeld@orchard.arlington.ma.us Cc: sjl@iki.fi, ietf-ssh@clinet.fi In-Reply-To: <200012141827.eBEIRBr05983@syn.hamachi.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20001214214158.E0615317AA@pelee.firedoor.se> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On 14 Dec, Bill Sommerfeld wrote: > - message numbers in the range of 0..191 should be allocated via IETF > consensus; message numbers in the 192..255 range (the "Local > extensions" set) are reserved for private use. No problems. > - protocol names are divided into three pieces: What do you mean by protocol names? Does it for example include the names of the encryption algorithms? /MaF From owner-ietf-ssh@clinet.fi Thu Dec 14 18:47: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 SAA19514 for ; Thu, 14 Dec 2000 18:47:16 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA31142 for ietf-ssh-outgoing; Thu, 14 Dec 2000 23:58:45 +0200 Received: from nic.appgate.com (nic.appgate.com [193.12.107.226]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA31139 for ; Thu, 14 Dec 2000 23:58:44 +0200 Received: from pelee.firedoor.se (pelee.firedoor.se [172.23.2.10]) by nic.appgate.com (Postfix) with ESMTP id CA6873BE08 for ; Thu, 14 Dec 2000 22:58:44 +0100 (MET) Received: from appgate.com (appgate.firedoor.se [172.23.2.21]) by pelee.firedoor.se (Postfix) with ESMTP id 5F2F6317AA for ; Thu, 14 Dec 2000 22:58:40 +0100 (MET) Date: Thu, 14 Dec 2000 13:58:40 -0800 (PST) From: Martin Forssen Subject: Keyboard-interactive: device names and IANA To: ietf-ssh@clinet.fi MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20001214215840.5F2F6317AA@pelee.firedoor.se> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk I did some thinking about the section in the keyboard-interactive draft which states that device-names should be registered by IANA. I reached the conclusion that I do not think this is necessary. The device-names is a field which the server MAY care about. The client will (most probably) not have any knowledge about which devices are available to the user so the contents of this field will probably be up to the user (via a preferences field or option). The net effect of this is that the actual device-name to use is something which the user and the server must agree upon. Thus this is not something which is needed for the compatibility between the server and the client. I also think we can assume that the user has knowledge about which device-name to use on the server since there already has to be interaction between them to initialize tokens etc. All this means that registering device-names with IANA does not help compatibility and only creates administrative overhead. Therefore I suggest we remove the reference to IANA from the keyboard-interactive draft. Comments? /MaF From owner-ietf-ssh@clinet.fi Thu Dec 14 20:06:27 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 UAA13482 for ; Thu, 14 Dec 2000 20:06:27 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA03465 for ietf-ssh-outgoing; Fri, 15 Dec 2000 01:09:55 +0200 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id BAA03457 for ; Fri, 15 Dec 2000 01:09:54 +0200 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA13142; Thu, 14 Dec 2000 15:09:45 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA02516; Thu, 14 Dec 2000 18:09:44 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eBEN93a119988; Thu, 14 Dec 2000 18:09:03 -0500 (EST) Message-Id: <200012142309.eBEN93a119988@thunk.east.sun.com> From: Bill Sommerfeld To: Martin Forssen cc: sommerfeld@orchard.arlington.ma.us, sjl@iki.fi, ietf-ssh@clinet.fi Subject: Re: IANA considerations section in draft-ietf-secsh-architecture-06.txt In-reply-to: Your message of "Thu, 14 Dec 2000 13:41:59 PST." <20001214214158.E0615317AA@pelee.firedoor.se> Reply-to: sommerfeld@east.sun.com Date: Thu, 14 Dec 2000 18:09:03 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > What do you mean by protocol names? Does it for example include the > names of the encryption algorithms? Yes; see the five (I think) categories of names listed in the architecture draft.. - Bill From owner-ietf-ssh@clinet.fi Thu Dec 14 20:45:38 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 UAA24049 for ; Thu, 14 Dec 2000 20:45:37 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA06251 for ietf-ssh-outgoing; Fri, 15 Dec 2000 01:54:05 +0200 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id BAA06247 for ; Fri, 15 Dec 2000 01:54:04 +0200 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id BAA06904; Fri, 15 Dec 2000 01:53:59 +0200 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14905.23959.115951.894676@asgard.tky.hut.fi> Date: Fri, 15 Dec 2000 01:53:59 +0200 To: Martin Forssen Cc: ietf-ssh@clinet.fi Subject: Keyboard-interactive: device names and IANA In-Reply-To: <20001214215840.5F2F6317AA@pelee.firedoor.se> References: <20001214215840.5F2F6317AA@pelee.firedoor.se> X-Mailer: VM 6.87 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Martin Forssen, on December 14. 2000, wrote: [snip] : All this means that registering device-names with IANA does not help : compatibility and only creates administrative overhead. Therefore I : suggest we remove the reference to IANA from the keyboard-interactive : draft. Example: securid What if your implementation calls it 'securid' and ours calls it 'securid@ssh' and some other calls it 'securid-from-rsa-labs@foo.security.com'. We don't have much compatibility then. But do we care? -- [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 Dec 14 20:57:38 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 UAA28746 for ; Thu, 14 Dec 2000 20:57:37 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA08020 for ietf-ssh-outgoing; Fri, 15 Dec 2000 02:16:26 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id CAA08016 for ; Fri, 15 Dec 2000 02:16:24 +0200 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07384; Thu, 14 Dec 2000 16:16:21 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA13179; Thu, 14 Dec 2000 19:16:20 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eBF0Fda120073; Thu, 14 Dec 2000 19:15:39 -0500 (EST) Message-Id: <200012150015.eBF0Fda120073@thunk.east.sun.com> From: Bill Sommerfeld To: Martin Forssen cc: ietf-ssh@clinet.fi Subject: Re: Keyboard-interactive: device names and IANA In-reply-to: Your message of "Thu, 14 Dec 2000 13:58:40 PST." <20001214215840.5F2F6317AA@pelee.firedoor.se> Reply-to: sommerfeld@east.sun.com Date: Thu, 14 Dec 2000 19:15:39 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > All this means that registering device-names with IANA does not help > compatibility and only creates administrative overhead. Therefore I > suggest we remove the reference to IANA from the keyboard-interactive > draft. [wg chair hat off] I agree. My understanding is that the device name is an optional way for an end-user to identify which of several possible devices in their possession they could use to authenticate. Conceivably, I might have two (differently keyed) securid cards or two sets of s/key state or... Anyone got a better name for this than "device"? - Bill From owner-ietf-ssh@clinet.fi Thu Dec 14 21:37: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 VAA14049 for ; Thu, 14 Dec 2000 21:37:15 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA09455 for ietf-ssh-outgoing; Fri, 15 Dec 2000 02:43:25 +0200 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id CAA09448 for ; Fri, 15 Dec 2000 02:43:22 +0200 Received: from centralmail1.Central.Sun.COM ([129.147.62.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA29661 for ; Thu, 14 Dec 2000 17:43:20 -0700 (MST) Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id RAA07431 for ; Thu, 14 Dec 2000 17:43:20 -0700 (MST) Received: from Eng.Sun.COM by esun1as-mm. (SMI-8.6/SMI-SVR4) id RAA24986; Thu, 14 Dec 2000 17:57:24 -0700 Message-ID: <3A396A74.FCC949B0@Eng.Sun.COM> Date: Thu, 14 Dec 2000 16:48:52 -0800 From: Darren J Moffat Organization: Sun Microsystems X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17-21mdk i586) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-ssh@clinet.fi Subject: Re: agenda items.. References: <200012131805.eBDI55a119253@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Bill Sommerfeld wrote: > > > I do not think that we should concern ourselves with US Export > > restrictions. > > Correct; on the whole, the IETF does not engineer security protocols > to include weak crypto or to accomodate the regulations of specific > jurisdictions. The documents do not need to acknowledge export > control issues, and should not specify ciphers known to be feasibly > breakable. Thats fine, I wouldn't want the text to reference anything like this that is purely political and is subject to change. I do however want to make sure that vendors based in countries that have such nonsense export restrictions can actually still ship a usable product that is compliant and able to interoperate. > > However, there are other good reasons to indicate the key size. > > These ciphers have different key size modes and to keep things > > simple indicating the key size in the name is the easiest. > > Agreed. As I understand it, this should be sufficient to meet > Darren's fundamental requirements.. Thats fine, as my comment was more intended as rational than suggested text - I could have made this clearer. -- Darren J Moffat From owner-ietf-ssh@clinet.fi Thu Dec 14 21:48: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 VAA17928 for ; Thu, 14 Dec 2000 21:48:15 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id DAA11202 for ietf-ssh-outgoing; Fri, 15 Dec 2000 03:13:16 +0200 Received: from nic.appgate.com (nic.appgate.com [193.12.107.226]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id DAA11199 for ; Fri, 15 Dec 2000 03:13:15 +0200 Received: from pelee.firedoor.se (pelee.firedoor.se [172.23.2.10]) by nic.appgate.com (Postfix) with ESMTP id D9EEA3BE08; Fri, 15 Dec 2000 02:13:14 +0100 (MET) Received: from appgate.com (appgate.firedoor.se [172.23.2.21]) by pelee.firedoor.se (Postfix) with ESMTP id 50187317AA; Fri, 15 Dec 2000 02:13:10 +0100 (MET) Date: Thu, 14 Dec 2000 17:13:11 -0800 (PST) From: Martin Forssen Subject: Re: Keyboard-interactive: device names and IANA To: sjl@iki.fi Cc: ietf-ssh@clinet.fi In-Reply-To: <14905.23959.115951.894676@asgard.tky.hut.fi> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20001215011310.50187317AA@pelee.firedoor.se> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On 15 Dec, Sami Lehtinen wrote: > Example: securid > > What if your implementation calls it 'securid' and ours calls it > 'securid@ssh' and some other calls it > 'securid-from-rsa-labs@foo.security.com'. We don't have much > compatibility then. Sure they are compatible, they just expect the user to enter different things into a field. We should also remember that in the overwhelming majority of cases users will only have one device available and this field is unneeded. /MaF From owner-ietf-ssh@clinet.fi Thu Dec 14 21:54: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 VAA20463 for ; Thu, 14 Dec 2000 21:54:50 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id DAA11209 for ietf-ssh-outgoing; Fri, 15 Dec 2000 03:13:21 +0200 Received: from nic.appgate.com (nic.appgate.com [193.12.107.226]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id DAA11205 for ; Fri, 15 Dec 2000 03:13:21 +0200 Received: from pelee.firedoor.se (pelee.firedoor.se [172.23.2.10]) by nic.appgate.com (Postfix) with ESMTP id A2E603BE08; Fri, 15 Dec 2000 02:13:20 +0100 (MET) Received: from appgate.com (appgate.firedoor.se [172.23.2.21]) by pelee.firedoor.se (Postfix) with ESMTP id 7C3C3317AA; Fri, 15 Dec 2000 02:13:16 +0100 (MET) Date: Thu, 14 Dec 2000 17:13:19 -0800 (PST) From: Martin Forssen Subject: Re: Keyboard-interactive: device names and IANA To: sommerfeld@east.sun.com Cc: ietf-ssh@clinet.fi In-Reply-To: <200012150015.eBF0Fda120073@thunk.east.sun.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20001215011316.7C3C3317AA@pelee.firedoor.se> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On 14 Dec, Bill Sommerfeld wrote: > Anyone got a better name for this than "device"? The only alternative we could think of was "token" but we preferred "device". But then again english is not my native language... /MaF From owner-ietf-ssh@clinet.fi Thu Dec 14 23:02:21 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 XAA11468 for ; Thu, 14 Dec 2000 23:02:21 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id EAA14581 for ietf-ssh-outgoing; Fri, 15 Dec 2000 04:12:19 +0200 Received: from nic.appgate.com (nic.appgate.com [193.12.107.226]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id EAA14577 for ; Fri, 15 Dec 2000 04:12:18 +0200 Received: from pelee.firedoor.se (pelee.firedoor.se [172.23.2.10]) by nic.appgate.com (Postfix) with ESMTP id 249633BE08; Fri, 15 Dec 2000 03:12:18 +0100 (MET) Received: from appgate.com (appgate.firedoor.se [172.23.2.21]) by pelee.firedoor.se (Postfix) with ESMTP id 8CCDC317AA; Fri, 15 Dec 2000 03:12:12 +0100 (MET) Date: Thu, 14 Dec 2000 18:12:13 -0800 (PST) From: Martin Forssen Subject: Re: IANA considerations section in draft-ietf-secsh-architecture-06.txt To: sommerfeld@orchard.arlington.ma.us Cc: sjl@iki.fi, ietf-ssh@clinet.fi In-Reply-To: <200012141827.eBEIRBr05983@syn.hamachi.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20001215021212.8CCDC317AA@pelee.firedoor.se> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On 14 Dec, Bill Sommerfeld wrote: > - protocol names are divided into three pieces: > - names with @ signs in them are allocated by the owner of the DNS > name after the @ sign ("hierarchical allocation" in 2434 terms) > - @-free names beginning with "ssh-" should be allocated using the > IETF consensus process. > - @-free names not beginning with ssh- should be allocated using > 2434's "specification required" policy. > > Comments? It seems as if this does not require any names to be changed, so I have no objections. But we should perhaps fix up the references to some of the encryption algorithms. Just to refer to the AES submission feels a bit vague. At least for twofish we could reference the book written about it "The Twofish Encryption Algorithm: A 128-Bit Block Cipher" ISBN 0471353817. /MaF From owner-ietf-ssh@clinet.fi Fri Dec 15 11:08:22 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 LAA07225 for ; Fri, 15 Dec 2000 11:08:20 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id QAA05359 for ietf-ssh-outgoing; Fri, 15 Dec 2000 16:02:20 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id QAA05344 for ; Fri, 15 Dec 2000 16:02:17 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 087242402810; Fri, 15 Dec 2000 14:02:16 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id PAA17017; Fri, 15 Dec 2000 15:02:12 +0100 (MET) To: sommerfeld@orchard.arlington.ma.us Cc: Sami Lehtinen , ietf-ssh@clinet.fi Subject: Re: IANA considerations section in draft-ietf-secsh-architecture-06.txt References: <200012141827.eBEIRBr05983@syn.hamachi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 15 Dec 2000 15:02:12 +0100 In-Reply-To: Bill Sommerfeld's message of "Thu, 14 Dec 2000 10:27:09 -0800" Message-ID: Lines: 32 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Bill Sommerfeld writes: > - message numbers in the range of 0..191 should be allocated via IETF > consensus; message numbers in the 192..255 range (the "Local > extensions" set) are reserved for private use. Would it make sense to subdivide the private use area into "local extensions" (within an organization, site, regardless of implementation) and "implementation extensions"? > - protocol names are divided into three pieces: > - names with @ signs in them are allocated by the owner of the DNS > name after the @ sign ("hierarchical allocation" in 2434 terms) > - @-free names beginning with "ssh-" should be allocated using the IETF > consensus process. > - @-free names not beginning with ssh- should be allocated using > 2434's "specification required" policy. To me, it seems odd that many of the names in the current spec (e.g. channel types and requests, algoritms, signals, etc) are in your third class, not the second. I would propose either * dropping the third class, having only "ietf consensus" and "hierachical", or * defining the third class as @-free names that begin with "x-". I haven't read RFC2434 yet, though. /Niels From owner-ietf-ssh@clinet.fi Fri Dec 15 14:13: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 OAA09709 for ; Fri, 15 Dec 2000 14:13:16 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA31619 for ietf-ssh-outgoing; Fri, 15 Dec 2000 19:36:42 +0200 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA31615 for ; Fri, 15 Dec 2000 19:36:41 +0200 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id TAA07555; Fri, 15 Dec 2000 19:36:34 +0200 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14906.22178.312608.835653@asgard.tky.hut.fi> Date: Fri, 15 Dec 2000 19:36:34 +0200 To: Martin Forssen Cc: sommerfeld@orchard.arlington.ma.us, ietf-ssh@clinet.fi Subject: Re: IANA considerations section in draft-ietf-secsh-architecture-06.txt In-Reply-To: <20001215021212.8CCDC317AA@pelee.firedoor.se> References: <200012141827.eBEIRBr05983@syn.hamachi.org> <20001215021212.8CCDC317AA@pelee.firedoor.se> X-Mailer: VM 6.87 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Martin Forssen, on December 14. 2000, wrote: : On 14 Dec, Bill Sommerfeld wrote: : > - protocol names are divided into three pieces: : > - names with @ signs in them are allocated by the owner of the DNS : > name after the @ sign ("hierarchical allocation" in 2434 terms) : > - @-free names beginning with "ssh-" should be allocated using the : > IETF consensus process. : > - @-free names not beginning with ssh- should be allocated using : > 2434's "specification required" policy. : > : > Comments? : : It seems as if this does not require any names to be changed, so I have : no objections. But we should perhaps fix up the references to some of : the encryption algorithms. Just to refer to the AES submission feels a : bit vague. At least for twofish we could reference the book written : about it "The Twofish Encryption Algorithm: A 128-Bit Block Cipher" ISBN : 0471353817. I'll fix that reference. -- [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 Dec 15 14:30: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 OAA15880 for ; Fri, 15 Dec 2000 14:30:16 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA32535 for ietf-ssh-outgoing; Fri, 15 Dec 2000 19:48:40 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA32524 for ; Fri, 15 Dec 2000 19:48:38 +0200 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21053; Fri, 15 Dec 2000 09:48:30 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA00253; Fri, 15 Dec 2000 12:48:30 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eBFHlma120286; Fri, 15 Dec 2000 12:47:48 -0500 (EST) Message-Id: <200012151747.eBFHlma120286@thunk.east.sun.com> From: Bill Sommerfeld To: nisse@lysator.liu.se (Niels M ller) cc: sommerfeld@orchard.arlington.ma.us, Sami Lehtinen , ietf-ssh@clinet.fi Subject: Re: IANA considerations section in draft-ietf-secsh-architecture-06.txt In-reply-to: Your message of "15 Dec 2000 15:02:12 +0100." Reply-to: sommerfeld@east.sun.com Date: Fri, 15 Dec 2000 12:47:47 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > Would it make sense to subdivide the private use area into "local > extensions" (within an organization, site, regardless of > implementation) and "implementation extensions"? I'm not sure I like where that's going from an interoperability point of view.. i.e., if you recognize what extensions to use based on the version strings, you might wind up in the same mess as http, where internet explorer claims to be a version of netscape because servers sent different content based on the browser implementation/version rather than the browser *capabilities*. > To me, it seems odd that many of the names in the current spec (e.g. > channel types and requests, algoritms, signals, etc) are in your third > class, not the second. Err, yes. My mistake. Some of the names are ssh-foo, some of them aren't. > I would propose either > > * dropping the third class, having only "ietf consensus" and > "hierachical", or > > * defining the third class as @-free names that begin with "x-". ok, how about: - protocol names are divided into three pieces: - names with @ signs in them are allocated by the owner of the DNS name after the @ sign ("hierarchical allocation" in 2434 terms) - @-free names not beginning with "x-" should be allocated using the IETF consensus process. - @-free names beginning with x- should be allocated using 2434's "specification required" policy. Or maybe we should just drop the third class entirely, given that @-form names are most likely sufficient for experimental, private, proprietary, etc., use.. comments? (can we get closure on this quickly?) - Bill From owner-ietf-ssh@clinet.fi Fri Dec 15 14:49:21 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 OAA21419 for ; Fri, 15 Dec 2000 14:49:20 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA01304 for ietf-ssh-outgoing; Fri, 15 Dec 2000 20:02:13 +0200 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA01301 for ; Fri, 15 Dec 2000 20:02:12 +0200 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id UAA07588; Fri, 15 Dec 2000 20:02:02 +0200 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14906.23706.286313.62974@asgard.tky.hut.fi> Date: Fri, 15 Dec 2000 20:02:02 +0200 To: sommerfeld@east.sun.com Cc: nisse@lysator.liu.se (Niels M ller), sommerfeld@orchard.arlington.ma.us, ietf-ssh@clinet.fi Subject: Re: IANA considerations section in draft-ietf-secsh-architecture-06.txt In-Reply-To: <200012151747.eBFHlma120286@thunk.east.sun.com> References: <200012151747.eBFHlma120286@thunk.east.sun.com> X-Mailer: VM 6.87 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Bill Sommerfeld, on December 15. 2000, wrote: : - protocol names are divided into three pieces: : - names with @ signs in them are allocated by the owner of the DNS : name after the @ sign ("hierarchical allocation" in 2434 terms) : - @-free names not beginning with "x-" should be allocated using the IETF : consensus process. : - @-free names beginning with x- should be allocated using 2434's : "specification required" policy. : : Or maybe we should just drop the third class entirely, given that : @-form names are most likely sufficient for experimental, private, : proprietary, etc., use.. Drop the third class. The @-names are sufficient. IMHO :) -- [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 Dec 15 15:30: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 PAA03726 for ; Fri, 15 Dec 2000 15:30:43 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA04071 for ietf-ssh-outgoing; Fri, 15 Dec 2000 20:40:12 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA04068 for ; Fri, 15 Dec 2000 20:40:10 +0200 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29775; Fri, 15 Dec 2000 10:39:59 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA12275; Fri, 15 Dec 2000 13:39:59 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eBFIdGa120368; Fri, 15 Dec 2000 13:39:16 -0500 (EST) Message-Id: <200012151839.eBFIdGa120368@thunk.east.sun.com> From: Bill Sommerfeld To: Tero Kivinen cc: nisse@lysator.liu.se (Niels M ller), Sami Lehtinen , ietf-ssh@clinet.fi Subject: Re: IANA considerations section in draft-ietf-secsh-architecture-06.txt In-reply-to: Your message of "Fri, 15 Dec 2000 20:20:18 +0200." <14906.24764.491751.487013@hutcs.cs.hut.fi> Reply-to: sommerfeld@east.sun.com Date: Fri, 15 Dec 2000 13:39:16 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk ok, i withdraw the proposal for the third intermediate class. suggested text: - protocol names are divided into two classes: - names with @ signs in them are allocated by the owner of the DNS name after the @ sign ("hierarchical allocation" in 2434 terms) - @-free names should be allocated by IETF consensus. From owner-ietf-ssh@clinet.fi Fri Dec 15 20:38: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 UAA08991 for ; Fri, 15 Dec 2000 20:38:54 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA24816 for ietf-ssh-outgoing; Sat, 16 Dec 2000 01:59:49 +0200 Received: from Mail6.mgfairfax.rr.com (fe6.southeast.rr.com [24.93.67.53]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id BAA24813 for ; Sat, 16 Dec 2000 01:59:48 +0200 Received: from mosquito.inet.org ([24.168.212.166]) by Mail6.mgfairfax.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Fri, 15 Dec 2000 18:59:44 -0500 Message-Id: <5.0.0.25.2.20001215175503.009e66b0@gnat.inet.org> X-Sender: rja@gnat.inet.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 15 Dec 2000 18:01:17 -0500 To: Darren J Moffat From: RJ Atkinson Subject: Re: agenda items.. Cc: ietf-ssh@clinet.fi In-Reply-To: <3A396A74.FCC949B0@Eng.Sun.COM> References: <200012131805.eBDI55a119253@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ssh@clinet.fi Precedence: bulk At 19:48 14/12/00, Darren J Moffat wrote: >I do however want to make sure that vendors based in countries >that have such nonsense export restrictions can actually still >ship a usable product that is compliant and able to interoperate. With all respect, **IETF MUST IGNORE** export rules when making decisions about what the mandatory-to-implement algorithms and key-lengths are. IETF policy, established long ago and repeated with ESP in the recent past, is to require good algorithms and good key lengths -- even if that means that companies based in countries with nonsense export restrictions (or use restrictions, consider France or Iraq or Singapore or ...) have local problems. For example, the SSH WG could choose (hypothetical example, not a suggestion) that 3DES with 112-bit keys was MUST IMPLEMENT, even if that meant that a US-based firm could not export such an implementation. This would not necessarily preclude the WG from also specifying other US-exportable algorithms as either optional or mandatory to implement. The IETF is an international organisation and MUST develop its standards on a global basis, without regard to silly local restrictions about crypto exportability or crypto use. While I am not speaking for the IAB in this note, I am confident that they concur with this (please see RFC-1984 for official IAB and IETF policy on this). Regards, Ran rja@inet.org From owner-ietf-ssh@clinet.fi Sat Dec 16 11:45: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 LAA21714 for ; Sat, 16 Dec 2000 11:45:10 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id QAA02801 for ietf-ssh-outgoing; Sat, 16 Dec 2000 16:50:53 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id QAA02798 for ; Sat, 16 Dec 2000 16:50:52 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id DBD172402806; Sat, 16 Dec 2000 14:50:50 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id PAA18204; Sat, 16 Dec 2000 15:50:50 +0100 (MET) To: sommerfeld@east.sun.com Cc: sommerfeld@orchard.arlington.ma.us, Sami Lehtinen , ietf-ssh@clinet.fi Subject: Re: IANA considerations section in draft-ietf-secsh-architecture-06.txt References: <200012151747.eBFHlma120286@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 16 Dec 2000 15:50:49 +0100 In-Reply-To: Bill Sommerfeld's message of "Fri, 15 Dec 2000 12:47:47 -0500" Message-ID: Lines: 25 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Bill Sommerfeld writes: > > Would it make sense to subdivide the private use area into "local > > extensions" (within an organization, site, regardless of > > implementation) and "implementation extensions"? > > I'm not sure I like where that's going from an interoperability point > of view.. i.e., if you recognize what extensions to use based on the > version strings, you might wind up in the same mess as http, That's not at all how I'm thinking. My scenario is as follows: I choose a private use message number, say 217, for some special message in the communication between lsh and lshg (the programs communicate by means of the unencrypted transport protocol, over a local unix socket). Next, some site using lsh or some other secsh implementation chooses a private use number for somthing else, and also happen to choose 217 => trouble when they use lshg. It seems that using distinct classes for the two types of extensions (those added by an implementation, and those of local configuration or hacks) may be a good idea. /Niels From owner-ietf-ssh@clinet.fi Sat Dec 16 14:18:41 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 OAA26420 for ; Sat, 16 Dec 2000 14:18:41 -0500 (EST) From: owner-ietf-ssh@clinet.fi Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA12055 for ietf-ssh-outgoing; Sat, 16 Dec 2000 19:34:01 +0200 Received: from smtp1.clinet.fi (smtp1.clinet.fi [194.100.2.57]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA12048; Sat, 16 Dec 2000 19:33:57 +0200 Received: from unknown (d026.p6.col.ru [212.248.5.26]) by smtp1.clinet.fi (Postfix) with SMTP id 2187416C; Sat, 16 Dec 2000 19:33:56 +0200 (EET) Subject: Cотовый телефон за 88$ с подключением к МТС Date: Сб, 16 дек 2000 16:50:37 Message-Id: <20001216173356.2187416C@smtp1.clinet.fi> To: undisclosed-recipients:; Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Извините за доставленое беспокойство. Все о сотовых телефонах, новогодние скидки на www.memphise.ru From owner-ietf-ssh@clinet.fi Sat Dec 16 14:22: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 OAA27693 for ; Sat, 16 Dec 2000 14:22:48 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA12355 for ietf-ssh-outgoing; Sat, 16 Dec 2000 19:40:05 +0200 Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA12351 for ; Sat, 16 Dec 2000 19:40:04 +0200 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id MAA06701; Sat, 16 Dec 2000 12:39:48 -0500 (EST) Date: Sat, 16 Dec 2000 12:39:47 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: nisse@lysator.liu.se (Niels Mller) Cc: sommerfeld@east.sun.com, sommerfeld@orchard.arlington.ma.us, Sami Lehtinen , ietf-ssh@clinet.fi Subject: Re: IANA considerations section in draft-ietf-secsh-architecture-06.txt In-Reply-To: Your message of 16 Dec 2000 15:50:49 +0100 Message-ID: Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > > That's not at all how I'm thinking. My scenario is as follows: I > choose a private use message number, say 217, for some special message > in the communication between lsh and lshg (the programs communicate by > means of the unencrypted transport protocol, over a local unix > socket). > > Next, some site using lsh or some other secsh implementation chooses a > private use number for somthing else, and also happen to choose 217 => > trouble when they use lshg. > > It seems that using distinct classes for the two types of extensions > (those added by an implementation, and those of local configuration or > hacks) may be a good idea. This is properly handled not by setting allocating a special range for local hacks, but by you instructing anyone hacking your code not to use certain values. From the perspective of the rest of the implementations there is no difference between a local hack and a private extension to lsh. If there is a clash in the private use name space the behavior is undefined. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. From owner-ietf-ssh@clinet.fi Mon Dec 18 14:45: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 OAA14078 for ; Mon, 18 Dec 2000 14:45:12 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA25325 for ietf-ssh-outgoing; Mon, 18 Dec 2000 19:43:12 +0200 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA25321 for ; Mon, 18 Dec 2000 19:43:11 +0200 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA17178; Mon, 18 Dec 2000 09:43:07 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.166]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id JAA23799; Mon, 18 Dec 2000 09:43:04 -0800 (PST) Received: from jurassic (jurassic [129.146.81.144]) by jurassic.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBIHh2m937483; Mon, 18 Dec 2000 09:43:03 -0800 (PST) Date: Mon, 18 Dec 2000 09:43:02 -0800 (PST) From: Darren J Moffat To: Bill Sommerfeld cc: Martin Forssen , ietf-ssh@clinet.fi Subject: Re: Keyboard-interactive: device names and IANA In-Reply-To: <200012150015.eBF0Fda120073@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Thu, 14 Dec 2000, Bill Sommerfeld wrote: > > All this means that registering device-names with IANA does not help > > compatibility and only creates administrative overhead. Therefore I > > suggest we remove the reference to IANA from the keyboard-interactive > > draft. > > Anyone got a better name for this than "device"? What about "mechanisms". -- Darren J Moffat From owner-ietf-ssh@clinet.fi Mon Dec 18 15:48:08 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 PAA15165 for ; Mon, 18 Dec 2000 15:48:07 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA30036 for ietf-ssh-outgoing; Mon, 18 Dec 2000 20:36:53 +0200 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA30032 for ; Mon, 18 Dec 2000 20:36:51 +0200 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11600; Mon, 18 Dec 2000 10:36:47 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA15995; Mon, 18 Dec 2000 13:36:45 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eBIIYXX100947; Mon, 18 Dec 2000 13:35:03 -0500 (EST) Message-Id: <200012181835.eBIIYXX100947@thunk.east.sun.com> From: Bill Sommerfeld To: Darren J Moffat cc: Bill Sommerfeld , Martin Forssen , ietf-ssh@clinet.fi Subject: Re: Keyboard-interactive: device names and IANA In-reply-to: Your message of "Mon, 18 Dec 2000 09:43:02 PST." Reply-to: sommerfeld@east.sun.com Date: Mon, 18 Dec 2000 13:34:33 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > > > All this means that registering device-names with IANA does not help > > > compatibility and only creates administrative overhead. Therefore I > > > suggest we remove the reference to IANA from the keyboard-interactive > > > draft. > > > > Anyone got a better name for this than "device"? > > What about "mechanisms". as i understand it, the field in question was meant to select between multiple cards given to a single user. those two cards could be identical (i.e., two securid cards or two enigma cards), so the "mechanism" would be the same, the only difference is the keying material in the device. "instance" would better reflect the way it's used but would be even more incomprehensible to novices.. - Bill From owner-ietf-ssh@clinet.fi Mon Dec 18 17:49:23 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 RAA17082 for ; Mon, 18 Dec 2000 17:49:22 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA09039 for ietf-ssh-outgoing; Mon, 18 Dec 2000 22:59:10 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id WAA09036 for ; Mon, 18 Dec 2000 22:59:10 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id C3BAF2402D22; Mon, 18 Dec 2000 20:58:59 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id VAA26237; Mon, 18 Dec 2000 21:58:59 +0100 (MET) To: jaltman@columbia.edu Cc: sommerfeld@east.sun.com, sommerfeld@orchard.arlington.ma.us, Sami Lehtinen , ietf-ssh@clinet.fi Subject: Re: IANA considerations section in draft-ietf-secsh-architecture-06.txt References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 18 Dec 2000 21:58:59 +0100 In-Reply-To: Jeffrey Altman's message of "Sat, 16 Dec 2000 12:39:47 EST" Message-ID: Lines: 36 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Jeffrey Altman writes: > This is properly handled not by setting allocating a special range for > local hacks, but by you instructing anyone hacking your code not to > use certain values. Thanks, that's good advice. > From the perspective of the rest of the implementations there is no > difference between a local hack and a private extension to lsh. If > there is a clash in the private use name space the behavior is > undefined. Not necessarily. I'll try to explain, even if it may be a little obscure. Consider the following setup: local hack A <-> lsh <-> network <-> locally A-hacked secsh server lshg L-^ Here, the A-hack and lshg are communicating, using a single lsh and an lsh gateway to setup the connection at one end of the network. They don't need to know about each other, and lsh doesn't need to know the hacks. The gateway just passes unknown messages on without any processing. However, if lsh and lshg also have some internal communication using "private use" message numbers, they can collide with the hack. Ok, I don't even know yet if lsh and lshg will use any new message numbers, and one can always add an extra layer of encapsulation in the gateway protocol, but if the problem could be solved by subdividing the private use area, that would be convenient. I guess I should drop this now, but I hope you at least understand the scenario? /Niels From owner-ietf-ssh@clinet.fi Mon Dec 18 18:01: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 SAA17331 for ; Mon, 18 Dec 2000 18:01:12 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA08167 for ietf-ssh-outgoing; Mon, 18 Dec 2000 22:48:56 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id WAA08153 for ; Mon, 18 Dec 2000 22:48:53 +0200 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07096 for ; Mon, 18 Dec 2000 12:48:52 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id MAA18400 for ; Mon, 18 Dec 2000 12:48:51 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with SMTP id eBIKmpm972070 for ; Mon, 18 Dec 2000 12:48:51 -0800 (PST) Message-Id: <200012182048.eBIKmpm972070@jurassic.eng.sun.com> Date: Mon, 18 Dec 2000 12:48:51 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: Keyboard-interactive: device names and IANA To: ietf-ssh@clinet.fi MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 3xE+daFpYCpkhs3kNbPYsA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_26 SunOS 5.9 sun4u sparc Sender: owner-ietf-ssh@clinet.fi Precedence: bulk >> What about "mechanisms". > >as i understand it, the field in question was meant to select between >multiple cards given to a single user. The text as I read it strongly suggests that there are "devices" of differing types not just multiple instances of the same type. Hence the suggestion of mechanism since I see Securid and Engima Safeword as different authentication mechanisms both of which happen to have an physical device, but other mechansims might not have a device. The only problem I have with using devices is that there is a strong hint that there is a bit or hardware rather then this being some alternate authentication mechanism that requires the use of the keyboard (eg draft-perlman-strong-cred-00.txt) Since Bill and I have read this differently I think some rewording is required regardless of the choice of name for the field, see below for a suggestion (which also has s/devices/mechanisms/). - --- 3.1 Initial Exchange The authentication starts with the client sending the following packet: byte SSH_MSG_USERAUTH_REQUEST string user name (ISO-10646 UTF-8) string service name (US-ASCII) string "keyboard-interactive" (US-ASCII) string language tag (as defined in [RFC-1766]) string mechanisms (ISO-10646 UTF-8) The language tag indicates the client's preferred language. The server SHOULD use this language for all text that is to be presented to the user in the subsequent exchanges. If the server cannot support the requested language, the language to be used is implementation-dependent. The mechanisms field is a comma-separated list of authentication methods (software or hardware) that are available to authenticate the user using the keyboard-interactive authentication method. The mechanisms may be mulitple instances of the same type (eg a Securid Token) or different mechanisms (eg, securid,safeword,smartcard). If the client has knowledge of the mechanisms available to the user, it MAY use the mechanisms field to pass this information to the server. Otherwise it MUST send the empty string. The client MUST NOT depend on authenticating using the mechanism list provided to the server. Server interpretation of the mechanisms is implementation-dependent. One possible implementation strategy of the mechanisms field on the server is that, unless the user may use multiple different mechanisms the server ignores this field. If the user may authenticate using one of several different mechanisms the server should treat the mechanisms field as a hint on which device the user wants to use this time. -- Darren J Moffat From owner-ietf-ssh@clinet.fi Mon Dec 18 19:40:08 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 TAA19005 for ; Mon, 18 Dec 2000 19:40:07 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id AAA16758 for ietf-ssh-outgoing; Tue, 19 Dec 2000 00:48:04 +0200 Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id AAA16754 for ; Tue, 19 Dec 2000 00:48:02 +0200 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id RAA28020; Mon, 18 Dec 2000 17:47:47 -0500 (EST) Date: Mon, 18 Dec 2000 17:47:46 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: nisse@lysator.liu.se (Niels Mller) Cc: sommerfeld@east.sun.com, sommerfeld@orchard.arlington.ma.us, Sami Lehtinen , ietf-ssh@clinet.fi Subject: Re: IANA considerations section in draft-ietf-secsh-architecture-06.txt In-Reply-To: Your message of 18 Dec 2000 21:58:59 +0100 Message-ID: Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > Not necessarily. I'll try to explain, even if it may be a little > obscure. Consider the following setup: > > local hack A <-> lsh <-> network <-> locally A-hacked secsh server > lshg L-^ > > Here, the A-hack and lshg are communicating, using a single lsh and an > lsh gateway to setup the connection at one end of the network. They > don't need to know about each other, and lsh doesn't need to know the > hacks. The gateway just passes unknown messages on without any > processing. However, if lsh and lshg also have some internal > communication using "private use" message numbers, they can collide > with the hack. > > Ok, I don't even know yet if lsh and lshg will use any new message > numbers, and one can always add an extra layer of encapsulation in the > gateway protocol, but if the problem could be solved by subdividing > the private use area, that would be convenient. > > I guess I should drop this now, but I hope you at least understand the > scenario? > I'm not sure that subdividing the address space will solve this problem. What it sounds like is that you need two different kinds of messages numbers. One type that gets forwarded when not recognized, and the other that does not. But again I think this is tied to your implementation of lsh[g]. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. From owner-ietf-ssh@clinet.fi Mon Dec 18 22:28:23 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 WAA21660 for ; Mon, 18 Dec 2000 22:28:22 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id DAA26636 for ietf-ssh-outgoing; Tue, 19 Dec 2000 03:27:43 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id DAA26627 for ; Tue, 19 Dec 2000 03:27:41 +0200 Received: from viper ([192.168.0.16]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 476 for ; Mon, 18 Dec 2000 18:31:51 -0700 Message-ID: <003501c0695a$dfd5d580$1000a8c0@viper> From: "Jeff P. Van Dyke" To: Subject: Can we make subsystems for robust? Date: Mon, 18 Dec 2000 18:27:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit I would propose that we make a change to the definition of subsystem so that subsystems are more robust and less fragile. I believe this is an old problem. However, we've had some recent experience with it. If a user has something in their .cshrc that produces output and the user attempts to use sftp, the sftp client tries to interpret this output as an sftp packet and the client fails without any useful feedback to the user. Sometimes the output in the .cshrc can be something very subtle such as an escape sequence that changes the user's xterm title bar. Here are several possible solutions: 1) Change the draft to specify that only output from the subsystem is sent to the client. 2) Change the draft to specify that the subsystem will be invoked in a way that won't produce spurious output (i.e. the .cshrc will not be used). 3) Require all subsystems to send a 'start subsystem sequence' which would allow the client to discard all prior data. 4) Add a boolean flag to the subsystem request From draft-ietf-secsh-connect-08.txt: byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "subsystem" boolean want reply string subsystem name boolean use user environment For backward compatibility, if the flag is not specified the value would be assumed to be true. If the 'use user environment' flag was false, the subsystem would exec'd without using the user's .cshrc (or equivalent). Then, individual subsystem specifications would specify the value of this flag. For example, I expect both sftp and the public key subsystem would specify false. I welcome other suggestions on how we can solve this problem. Is there consensus that we need to fix this problem? I would like to rewrite the public key channel draft as a subsystem. If we don't change the definition of subsystems, we will probably rewrite the draft using a variation on #3. However, since I believe this problem is going to exist for any subsystem, I would like to see if we can include a general solution in the draft. One more thought... It may be possible that we should separate this into two problems. 1) Spurious output prior to the subsystem running can confuse the client. 2) Running the .cshrc (or equivalent) prior to running the subsystem may make it difficult (or impossible) to implement certain site policies since any arbitrary command can be run from a .cshrc. Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Mon Dec 18 23:42: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 XAA24016 for ; Mon, 18 Dec 2000 23:42:48 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id FAA00923 for ietf-ssh-outgoing; Tue, 19 Dec 2000 05:29:02 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id FAA00917 for ; Tue, 19 Dec 2000 05:29:01 +0200 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA20873 for ; Mon, 18 Dec 2000 19:29:00 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id TAA24053 for ; Mon, 18 Dec 2000 19:28:59 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with SMTP id eBJ3Swm155608 for ; Mon, 18 Dec 2000 19:28:59 -0800 (PST) Message-Id: <200012190328.eBJ3Swm155608@jurassic.eng.sun.com> Date: Mon, 18 Dec 2000 19:28:58 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Section 3.2 of secsh-auth-kbdinteract-01 To: ietf-ssh@clinet.fi MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: cJd9RrGs/BZKJS3RLzVp1Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_26 SunOS 5.9 sun4u sparc Sender: owner-ietf-ssh@clinet.fi Precedence: bulk >Section 3.2: > The server SHOULD limit the length of the name and prompt fields to > 30 characters. No restrictions are placed on the instruction >field. > >30 characters could be too little. > > "sjl@foobar.internal.fi.ssh.com's passcode for SecurID auth:" > >especially considering section 3.3 considerations Agreed where did 30 come from ? (I'll take a wild guess here and assume it is the number of chars that can be displayed on the screen of a PalmPilot using the default font? (I checked ;-)) Maybe it means a better distinction between the intended use of the instruction and prompt fields is needed. For example code that does this: 1. Enable logins and Continue [default]\n 2. Continue without Enabling logins\n 3. Only Enable logins\n 4. Cancel\n Enter option number or return: In this example are the menu items instruction or part of the prompt ? I would code this with an empty name and the menu choices as instructions with the "Enter option number or return: " as a prompt, but that is 32 chars just for the prompt - so I still loose (since the wording prohibits the client from adding the ": "). But it is also concievable that the whole thing is the prompt with embedded newlines. 30 seems very low considering that in a large percentage of cases ssh will actually be used to access remote systems from devices emulating (at least) an 80x25 terminal session (eg xterm like). -- Darren J Moffat From owner-ietf-ssh@clinet.fi Mon Dec 18 23:44: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 XAA24046 for ; Mon, 18 Dec 2000 23:44:14 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id FAA32372 for ietf-ssh-outgoing; Tue, 19 Dec 2000 05:09:53 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id FAA32368 for ; Tue, 19 Dec 2000 05:09:52 +0200 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA14615 for ; Mon, 18 Dec 2000 19:09:51 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id TAA21614 for ; Mon, 18 Dec 2000 19:09:50 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with SMTP id eBJ39mm153453 for ; Mon, 18 Dec 2000 19:09:48 -0800 (PST) Message-Id: <200012190309.eBJ39mm153453@jurassic.eng.sun.com> Date: Mon, 18 Dec 2000 19:09:48 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Section 3.4 of secsh-auth-kdbinteract-01 To: ietf-ssh@clinet.fi MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: tOmmmlzBPR8iy4JXhHFKfQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_26 SunOS 5.9 sun4u sparc Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Comments on Section 3.4 If the server responds with a failure message, it SHOULD delay a minimum of 2 seconds before sending the failure message, to limit certain types of attacks. I think this is an implementation detail and many implementations would want to make this a tuneable value, I don't think the draft should put a lower bound on this of 2 seconds. I would rather the text said: If the server intends to respond with a failure message, it MAY delay for an implementation dependant time before sending to the client. It is suspected that implementations are likely to make the time delay a configurable, a suggested default is 2 seconds. -- Darren J Moffat From owner-ietf-ssh@clinet.fi Mon Dec 18 23:57: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 XAA24294 for ; Mon, 18 Dec 2000 23:57:15 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id FAA00961 for ietf-ssh-outgoing; Tue, 19 Dec 2000 05:30:12 +0200 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id FAA00957 for ; Tue, 19 Dec 2000 05:30:11 +0200 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA22190 for ; Mon, 18 Dec 2000 19:30:09 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id TAA24252 for ; Mon, 18 Dec 2000 19:30:09 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with SMTP id eBJ3U8m155752 for ; Mon, 18 Dec 2000 19:30:08 -0800 (PST) Message-Id: <200012190330.eBJ3U8m155752@jurassic.eng.sun.com> Date: Mon, 18 Dec 2000 19:30:08 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Section 4 of secsh-auth-kbdinteract-01 To: ietf-ssh@clinet.fi MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Ut8Nf1G/id8UFZaBA4R/Ig== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_26 SunOS 5.9 sun4u sparc Sender: owner-ietf-ssh@clinet.fi Precedence: bulk >Section 4: >(Note that the server MAY require additional authentications after successful >authentication.) Clearer text maybe: (Note that the server MAY require further interaction with the user for additional authentication mechanisms even after a successful authentication with publickey. -- Darren J Moffat From owner-ietf-ssh@clinet.fi Mon Dec 18 23:58: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 XAA24307 for ; Mon, 18 Dec 2000 23:58:13 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id FAA00899 for ietf-ssh-outgoing; Tue, 19 Dec 2000 05:28:51 +0200 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id FAA00896 for ; Tue, 19 Dec 2000 05:28:49 +0200 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA22051; Mon, 18 Dec 2000 19:28:45 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id TAA24018; Mon, 18 Dec 2000 19:28:44 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with SMTP id eBJ3Shm155590; Mon, 18 Dec 2000 19:28:43 -0800 (PST) Message-Id: <200012190328.eBJ3Shm155590@jurassic.eng.sun.com> Date: Mon, 18 Dec 2000 19:28:43 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: Comments for draft-ietf-secsh-auth-kbdinteract-01.txt To: sjl@iki.fi Cc: ietf-ssh@clinet.fi MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: oPfQkRSrUfg7OCDP8OTNRQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_26 SunOS 5.9 sun4u sparc Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE >message > if the failure is based on the user name or service name; instead >it > SHOULD send SSH_MSG_USERAUTH_INFO_REQUEST message(s) which look >just > like the one(s) which would have been sent in cases where > authentication should proceed, and then send the failure message > (after a suitable delay, as described below). The goal is to make >it > impossible to find valid user names by just comparing the results > when authenticating as different users. I think the goal here is basically sound, however as you point out this SHOULD NOT may actually be hard to implement in some cases, but being a SHOULD NOT rather than a MUST means that if it is too hard for a particular system then it can reply SSH_MSG_USERAUTH_FAILURE >This is not good, as the server doesn't necessarily have a method to >get the possible messages from a device (library etc.). For example, >we don't know what PAM would query from the user if it existed. PAM >doesn't allow invalid users to continue the login after account >checkin. Point being, with PAM the server shouldn't take any stand on >what the PAM queries or tells the users; this depends on the PAM >configuration. Whither or not PAM is used in a particular secsh server side is an implmentation detail, but it is an important one because using PAM opens up the scope for messages and interaction outside of the control of the ssh server software. It actually depends on exactly how PAM is used how difficult this becomes to implement. Personally I would say that if PAM is being used: pam_authenticate() PAM_SUCCESS => SSH_MSG_USERAUTH_SUCCESS PAM_USER_UNKNOWN => SSH_MSG_USERAUTH_FAILURE PAM_NEW_AUTHTOK_REQD => call pam_chauthtok() and send SSH_MSG_USERAUTH_SUCCESS if it returns PAM_SUCCESS otherwise SSH_MSG_USERAUTH_FAILURE Most others result in SSH_MSG_USERAUTH_FAILURE. I guess it depends on exactly how you see PAM and kbdinteract working together. The way I see it is that any converstaion that PAM does with the user is one kbdinteract "session" regardless of how many PAM modules actually get run - since there is no (supported) way for the PAM application to get information about which modules succeed and which fail or to run only certain modules. I suspect that in many cases things like Engima Safeword and Securid will actuall get implmented as PAM modules rather than coded directly into the secsh server software. Or at least the should be for systems that support PAM to avoid code duplication. I think what is needed here is an informational draft on how PAM and kdbinteract are used with each other. While it is good that we consider PAM in this draft I don't think kdinteract should depend on it or make specific consessions for it (For those that know how much I advocate using PAM that is quite a consession from me!). To back this up futher the example in the draft of a user changing their password couldn't be coded that way using PAM since you don't know what modules in the PAM stack are going to prompt you in advance, it may be that the password fails some strength checks between the inital user entry and the re-entering and the output of the error message is dependant on what the user typed. But the draft as it stands is sufficiently flexible to allow for an implmentation with PAM since the interaction would be a series of single prompt messages. I just don't see the point in the added complexity of allowing for multiple prompts. IIRC there was also disussion in the wg meeting last week about removing the ablity to send multiple prompts in one SSH_MSG_USERAUTH_INFO_REQUEST can someone remind me on the consensus of that (if there was one) ? I seem to remeber someone saying something that it helped them implement PAM support on the server (I can't see how this would be the case since the PAM framework doesn't support multiple prompts for input with out user feedback - it maybe someone has a module that does something like this but the PAM framework doesn't require it). -- Darren J Moffat From owner-ietf-ssh@clinet.fi Tue Dec 19 05:01: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 FAA10267 for ; Tue, 19 Dec 2000 05:01:55 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id KAA05663 for ietf-ssh-outgoing; Tue, 19 Dec 2000 10:26:44 +0200 Received: from nic.appgate.com (nic.appgate.com [193.12.107.226]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id KAA05658 for ; Tue, 19 Dec 2000 10:26:42 +0200 Received: from pelee.firedoor.se (pelee.firedoor.se [172.23.2.10]) by nic.appgate.com (Postfix) with ESMTP id 718633BD06; Tue, 19 Dec 2000 09:26:42 +0100 (MET) Received: from appgate.com (pelee.firedoor.se [172.23.2.10]) by pelee.firedoor.se (Postfix) with ESMTP id 29B0E317AA; Tue, 19 Dec 2000 09:26:37 +0100 (MET) Date: Tue, 19 Dec 2000 09:26:40 +0100 (MET) From: Martin Forssen Subject: Re: Keyboard-interactive: device names and IANA To: sommerfeld@east.sun.com Cc: darrenm@Eng.Sun.COM, ietf-ssh@clinet.fi In-Reply-To: <200012181835.eBIIYXX100947@thunk.east.sun.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20001219082637.29B0E317AA@pelee.firedoor.se> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On 18 Dec, Bill Sommerfeld wrote: >> > > All this means that registering device-names with IANA does not >> > > help compatibility and only creates administrative overhead. >> > > Therefore I suggest we remove the reference to IANA from the >> > > keyboard-interactive draft. >> > >> > Anyone got a better name for this than "device"? >> >> What about "mechanisms". > > as i understand it, the field in question was meant to select between > multiple cards given to a single user. That was not the intent. I think the cases where one user has multiple cards which all goes to the same account are extremely rare. > "instance" would better reflect the way it's used but would be even > more incomprehensible to novices.. Fortunately the users do not have to be exposed to the names used in the RFC, but they probably will. That is we can add explanatory text to the RFC but most implementors will probably use the name given anyway:-/ I am not sure I like "mechanism" (a purely subjective point of view though). I still think devices is a better name. Perhaps i is easier to find the right word if we try to list some possible values. The ones I can think of right now are: securid, cryptocard, desgold, s/key, opie. Perhaps "method" (or "submethod") is a better name than device, we just have to be clear in the RFC. /MaF From owner-ietf-ssh@clinet.fi Tue Dec 19 05:02: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 FAA10279 for ; Tue, 19 Dec 2000 05:02:25 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id KAA05691 for ietf-ssh-outgoing; Tue, 19 Dec 2000 10:26:54 +0200 Received: from nic.appgate.com (nic.appgate.com [193.12.107.226]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id KAA05676 for ; Tue, 19 Dec 2000 10:26:49 +0200 Received: from pelee.firedoor.se (pelee.firedoor.se [172.23.2.10]) by nic.appgate.com (Postfix) with ESMTP id 81B0E3BD06; Tue, 19 Dec 2000 09:26:48 +0100 (MET) Received: from appgate.com (pelee.firedoor.se [172.23.2.10]) by pelee.firedoor.se (Postfix) with ESMTP id 3DD55317AA; Tue, 19 Dec 2000 09:26:44 +0100 (MET) Date: Tue, 19 Dec 2000 09:26:47 +0100 (MET) From: Martin Forssen Subject: Re: Section 3.4 of secsh-auth-kdbinteract-01 To: Darren.Moffat@Eng.Sun.COM Cc: ietf-ssh@clinet.fi In-Reply-To: <200012190309.eBJ39mm153453@jurassic.eng.sun.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20001219082644.3DD55317AA@pelee.firedoor.se> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On 18 Dec, Darren Moffat wrote: > Comments on Section 3.4 > > If the server responds with a failure message, it SHOULD delay a > minimum of 2 seconds before sending the failure message, to limit > certain types of attacks. > > I think this is an implementation detail and many implementations > would want to make this a tuneable value, I don't think the draft > should put a lower bound on this of 2 seconds. I would rather the > text said: > > If the server intends to respond with a failure message, it MAY > delay for an implementation dependant time before sending to the > client. It is suspected that implementations are likely to make the > time delay a configurable, a suggested default is 2 seconds. I think I stole this almost verbatim from the userauth draft, but I can not find anything like that in the current versions of that draft. I have no problems with making this change. /MaF From owner-ietf-ssh@clinet.fi Tue Dec 19 07:47: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 HAA12440 for ; Tue, 19 Dec 2000 07:47:53 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id NAA14085 for ietf-ssh-outgoing; Tue, 19 Dec 2000 13:09:13 +0200 Received: from smtp1.clinet.fi (smtp1.clinet.fi [194.100.2.57]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id NAA14041 for ; Tue, 19 Dec 2000 13:09:09 +0200 Received: from nic.appgate.com (nic.appgate.com [193.12.107.226]) by smtp1.clinet.fi (Postfix) with ESMTP id DC6455D9 for ; Tue, 19 Dec 2000 12:08:14 +0200 (EET) Received: from pelee.firedoor.se (pelee.firedoor.se [172.23.2.10]) by nic.appgate.com (Postfix) with ESMTP id 6FAE53BD06; Tue, 19 Dec 2000 11:08:14 +0100 (MET) Received: from appgate.com (pelee.firedoor.se [172.23.2.10]) by pelee.firedoor.se (Postfix) with ESMTP id 26E44317AA; Tue, 19 Dec 2000 11:08:09 +0100 (MET) Date: Tue, 19 Dec 2000 11:08:09 +0100 (MET) From: Martin Forssen Subject: Re: Comments for draft-ietf-secsh-auth-kbdinteract-01.txt To: Darren.Moffat@Eng.Sun.COM Cc: sjl@iki.fi, ietf-ssh@clinet.fi In-Reply-To: <200012190328.eBJ3Shm155590@jurassic.eng.sun.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20001219100809.26E44317AA@pelee.firedoor.se> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On 18 Dec, Darren Moffat wrote: > I think what is needed here is an informational draft on how PAM > and kdbinteract are used with each other. While it is good that we > consider PAM in this draft I don't think kdinteract should depend on > it or make specific consessions for it (For those that know how much > I advocate using PAM that is quite a consession from me!). Do we really need an informational draft here? I think it suffices to say that the ssh-server is not always able to predict the questions which would be asked and might therefore not be able to mimic it. > To back this up futher the example in the draft of a user changing > their password couldn't be coded that way using PAM since you don't > know what modules in the PAM stack are going to prompt you in advance, > it may be that the password fails some strength checks between the > inital user entry and the re-entering and the output of the error > message is dependant on what the user typed. > > But the draft as it stands is sufficiently flexible to allow for an > implmentation with PAM since the interaction would be a series of > single prompt messages. I just don't see the point in the added > complexity of allowing for multiple prompts. The draft is not at all meant to be just a front end for PAM. It is meant to be a fronted to anything which can be used without adding any other specific code to the clients. I put the multiprompts in there because I instinctively think there might be a need for them. We actually use them in our implementation when we do SecurID authentication. Under some circumstances the user is allowed to choose a new PIN for their card, and to enter this we use two fields. I think part of the differences between us here is that we think of different user interfaces. If one envisions a tty-based interface then restricting us to one question per message is not so bad since the old question is probably still visible on the screen. But for a windows- based interface it is much more user-friendly to have as many questions as possible in one dialog instead of popping up one new dialog for each question, at least IMHO. > IIRC there was also disussion in the wg meeting last week about > removing the ablity to send multiple prompts in one > SSH_MSG_USERAUTH_INFO_REQUEST can someone remind me on the consensus > of that (if there was one) ? I seem to remeber someone saying I did not get the impression that there was any consensus to remove that ability. Actually I did not feel that there was any need to change the actual protocol at all. The draft needs some clarifications here and there and that is all. At least that is the impression I got, but I might be biased. /MaF From owner-ietf-ssh@clinet.fi Tue Dec 19 08:04: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 IAA12849 for ; Tue, 19 Dec 2000 08:04:32 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA01909 for ietf-ssh-outgoing; Tue, 19 Dec 2000 12:20:04 +0200 Received: from nic.appgate.com (nic.appgate.com [193.12.107.226]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id MAA01771 for ; Tue, 19 Dec 2000 12:19:29 +0200 Received: from pelee.firedoor.se (pelee.firedoor.se [172.23.2.10]) by nic.appgate.com (Postfix) with ESMTP id 49BD83BD06; Tue, 19 Dec 2000 11:19:28 +0100 (MET) Received: from appgate.com (pelee.firedoor.se [172.23.2.10]) by pelee.firedoor.se (Postfix) with ESMTP id 14EAB317AA; Tue, 19 Dec 2000 11:19:24 +0100 (MET) Date: Tue, 19 Dec 2000 11:19:26 +0100 (MET) From: Martin Forssen Subject: Re: Section 4 of secsh-auth-kbdinteract-01 To: Darren.Moffat@Eng.Sun.COM Cc: ietf-ssh@clinet.fi In-Reply-To: <200012190330.eBJ3U8m155752@jurassic.eng.sun.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20001219101924.14EAB317AA@pelee.firedoor.se> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On 18 Dec, Darren Moffat wrote: >>Section 4: > >>(Note that the server MAY require additional authentications after >>successful authentication.) > > Clearer text maybe: > > (Note that the server MAY require further interaction with the user > for additional authentication mechanisms even after a successful > authentication with publickey. I think this text refers to the userauth draft not to auth-kbdinteract. /MaF From owner-ietf-ssh@clinet.fi Tue Dec 19 08:05: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 IAA12867 for ; Tue, 19 Dec 2000 08:05:27 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA01908 for ietf-ssh-outgoing; Tue, 19 Dec 2000 12:20:05 +0200 Received: from nic.appgate.com (nic.appgate.com [193.12.107.226]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id MAA01796 for ; Tue, 19 Dec 2000 12:19:35 +0200 Received: from pelee.firedoor.se (pelee.firedoor.se [172.23.2.10]) by nic.appgate.com (Postfix) with ESMTP id 53CF63BD07; Tue, 19 Dec 2000 11:19:34 +0100 (MET) Received: from appgate.com (pelee.firedoor.se [172.23.2.10]) by pelee.firedoor.se (Postfix) with ESMTP id 26D0C317AA; Tue, 19 Dec 2000 11:19:30 +0100 (MET) Date: Tue, 19 Dec 2000 11:19:32 +0100 (MET) From: Martin Forssen Subject: Re: Section 3.2 of secsh-auth-kbdinteract-01 To: Darren.Moffat@Eng.Sun.COM Cc: ietf-ssh@clinet.fi In-Reply-To: <200012190328.eBJ3Swm155608@jurassic.eng.sun.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20001219101930.26D0C317AA@pelee.firedoor.se> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On 18 Dec, Darren Moffat wrote: >>Section 3.2: > >> The server SHOULD limit the length of the name and prompt fields to >> 30 characters. No restrictions are placed on the instruction >>field. >> >>30 characters could be too little. >> >> "sjl@foobar.internal.fi.ssh.com's passcode for SecurID auth:" >> >>especially considering section 3.3 considerations > > Agreed where did 30 come from ? (I'll take a wild guess here and > assume it is the number of chars that can be displayed on the screen > of a PalmPilot using the default font? (I checked ;-)) I think I already have countered this example, ut I just wanted to comment on the number 30. The number 30 is just an arbitrary number and I am not aware of any systems which actually enforces those limits. /MaF From owner-ietf-ssh@clinet.fi Tue Dec 19 08:44: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 IAA13347 for ; Tue, 19 Dec 2000 08:44:15 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id OAA27583 for ietf-ssh-outgoing; Tue, 19 Dec 2000 14:01:27 +0200 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id OAA27523 for ; Tue, 19 Dec 2000 14:01:17 +0200 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id OAA08456; Tue, 19 Dec 2000 14:01:45 +0200 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14911.20008.769998.140696@asgard.tky.hut.fi> Date: Tue, 19 Dec 2000 14:01:44 +0200 To: "Jeff P. Van Dyke" Cc: Subject: Can we make subsystems for robust? In-Reply-To: <003501c0695a$dfd5d580$1000a8c0@viper> References: <003501c0695a$dfd5d580$1000a8c0@viper> X-Mailer: VM 6.87 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Jeff P. Van Dyke, on December 18. 2000, wrote: : I would propose that we make a change to the definition : of subsystem so that subsystems are more robust and less : fragile. [snip] : Here are several possible solutions: : : 1) Change the draft to specify that only output from the : subsystem is sent to the client. This is what I've been thinking about (ie. discard anything coming from the subsystem-executable before the version packet). : 2) Change the draft to specify that the subsystem will be : invoked in a way that won't produce spurious output : (i.e. the .cshrc will not be used). This can't be used (for obvious reasons). : 3) Require all subsystems to send a 'start subsystem sequence' : which would allow the client to discard all prior data. This would break filexfer (or at the least, sftp would be an exception in subsystems). : 4) Add a boolean flag to the subsystem request [snip] Ugly ;) (I've protested against these kind of kuldges before. I don't like these 'optional' fields, where it is arbitrary whether or not a field needs to present.) : I welcome other suggestions on how we can solve this problem. : : Is there consensus that we need to fix this problem? Well, I don't think this is a serious problem (PEBKAC problem...), but it probably should be fixed, as we're trying to make crypto easy to use, and this kind of change would be to the right direction. : I would like to rewrite the public key channel draft as a : subsystem. If we don't change the definition of subsystems, : we will probably rewrite the draft using a variation on #3. : However, since I believe this problem is going to exist for : any subsystem, I would like to see if we can include a : general solution in the draft. If we can reach consensus on this, I will add 1) to the definition of subsystems. : One more thought... : : It may be possible that we should separate this into two problems. [snip] : 2) Running the .cshrc (or equivalent) prior to running the : subsystem may make it difficult (or impossible) to implement : certain site policies since any arbitrary command can be : run from a .cshrc. Yes, but so you can run any command from any shell startup file (.zshenv, .profile, whatever). And these are every time the shell is used, so we can't fix this easily. And, quite frankly, I don't see why we should. The administrator can always change a user's shell. The problem at hand is a user/client problem, and not related to security policy. -- [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 Dec 19 12:44: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 MAA19426 for ; Tue, 19 Dec 2000 12:44:36 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA12083 for ietf-ssh-outgoing; Tue, 19 Dec 2000 18:03:39 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA12076 for ; Tue, 19 Dec 2000 18:03:37 +0200 Received: from viper ([192.168.0.16]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 499; Tue, 19 Dec 2000 09:07:49 -0700 Message-ID: <001201c069d5$3e78d270$1000a8c0@viper> From: "Jeff P. Van Dyke" To: "Sami Lehtinen" Cc: References: <003501c0695a$dfd5d580$1000a8c0@viper> <14911.20008.769998.140696@asgard.tky.hut.fi> Subject: Re: Can we make subsystems for robust? Date: Tue, 19 Dec 2000 09:03:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Sami Lehtinen, on December 19, 2000, wrote: > Jeff P. Van Dyke, on December 18. 2000, wrote: > : I would propose that we make a change to the definition > : of subsystem so that subsystems are more robust and less > : fragile. > [snip] > : Here are several possible solutions: > : > : 1) Change the draft to specify that only output from the > : subsystem is sent to the client. > > This is what I've been thinking about (ie. discard anything coming > from the subsystem-executable before the version packet). This sounds good. Do we need to add language specifying the structure and details of a subsystem version packet? Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Tue Dec 19 14:20: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 OAA22195 for ; Tue, 19 Dec 2000 14:20:09 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id LAA23431 for ietf-ssh-outgoing; Tue, 19 Dec 2000 11:36:08 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id LAA23300 for ; Tue, 19 Dec 2000 11:35:07 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 688CB2402D4F; Tue, 19 Dec 2000 09:35:00 +0000 (GMT) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id KAA06366; Tue, 19 Dec 2000 10:34:59 +0100 (MET) To: "Jeff P. Van Dyke" Cc: Subject: Re: Can we make subsystems for robust? References: <003501c0695a$dfd5d580$1000a8c0@viper> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Mцller) Date: 19 Dec 2000 10:34:59 +0100 In-Reply-To: "Jeff P. Van Dyke"'s message of "Mon, 18 Dec 2000 18:27:27 -0700" Message-ID: Lines: 45 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk "Jeff P. Van Dyke" writes: > I believe this is an old problem. However, we've had > some recent experience with it. If a user has something > in their .cshrc that produces output and the user attempts > to use sftp, the sftp client tries to interpret this output > as an sftp packet and the client fails without any useful > feedback to the user. That's a configuration error, which can break all sorts of things. I don't think we should work around it in the protocol. > 2) Running the .cshrc (or equivalent) prior to running the > subsystem may make it difficult (or impossible) to implement > certain site policies since any arbitrary command can be > run from a .cshrc. It seems to be an old tradition (on unix) that commands executed by rsh are started with $LOGIN_SHELL -c "user's command line", where LOGIN_SHELL is the shell listed in the passwd database, which implies that any shell startup files are read first, and that the user can manipulate the command execution by hacking the shell startup files. A typical but harmless example: if a user runs ssh remote ls and the shell startup files at remote contains alias ls='ls -F' that alias is applied also to the command line executed via ssh. It's not entirely obvious that this way of executing "commands" is desirable or appropriate for subsystems. You could just exec the appropriate subsystem binary directly, without invoking any shell. But you have to be careful, as some sites may intentinally use /bin/false or nologin for some accounts, and bypassing that could have bad consequences. But this is all implementation issues: I'd like to hear more comments about it, but I don't think we should address in the protocol. Regards, /Niels From owner-ietf-ssh@clinet.fi Tue Dec 19 15:51: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 PAA24473 for ; Tue, 19 Dec 2000 15:51:41 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id UAA27493 for ietf-ssh-outgoing; Tue, 19 Dec 2000 20:46:57 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id UAA27490 for ; Tue, 19 Dec 2000 20:46:55 +0200 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19096 for ; Tue, 19 Dec 2000 10:46:54 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id KAA25646 for ; Tue, 19 Dec 2000 10:46:54 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with SMTP id eBJIkhm243154 for ; Tue, 19 Dec 2000 10:46:44 -0800 (PST) Message-Id: <200012191846.eBJIkhm243154@jurassic.eng.sun.com> Date: Tue, 19 Dec 2000 10:46:43 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: publickey file format To: ietf-ssh@clinet.fi MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Lm/gKcNhqQrfRhFRzNH3BA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_26 SunOS 5.9 sun4u sparc Sender: owner-ietf-ssh@clinet.fi Precedence: bulk I seem to remember some mention of creation of a draft for the secsh publickey file format at the working group meeting. First do I rember correctly and second if I did what was the action to be taken ? -- Darren J Moffat From owner-ietf-ssh@clinet.fi Tue Dec 19 17:24:22 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 RAA26336 for ; Tue, 19 Dec 2000 17:24:22 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA02872 for ietf-ssh-outgoing; Tue, 19 Dec 2000 22:17:19 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id WAA02868 for ; Tue, 19 Dec 2000 22:17:18 +0200 Received: from viper ([192.168.0.16]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 511; Tue, 19 Dec 2000 13:21:30 -0700 Message-ID: <002801c069f8$ae91a3c0$1000a8c0@viper> From: "Jeff P. Van Dyke" To: "Darren Moffat" , References: <200012191846.eBJIkhm243154@jurassic.eng.sun.com> Subject: Re: publickey file format Date: Tue, 19 Dec 2000 13:17:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit From: "Darren Moffat" > I seem to remember some mention of creation of a draft for the secsh publickey > file format at the working group meeting. > > First do I rember correctly and second if I did what was the action to be > taken ? Joseph Galbraith, Rodney Thayer, and I plan to have a draft out next month. Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Tue Dec 19 19:00:21 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 TAA28186 for ; Tue, 19 Dec 2000 19:00:21 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id AAA12236 for ietf-ssh-outgoing; Wed, 20 Dec 2000 00:15:25 +0200 Received: from faui02.informatik.uni-erlangen.de (msfriedl@faui02.informatik.uni-erlangen.de [131.188.30.102]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id AAA12228 for ; Wed, 20 Dec 2000 00:15:24 +0200 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id XAA24680; Tue, 19 Dec 2000 23:15:20 +0100 (MET) Date: Tue, 19 Dec 2000 23:15:20 +0100 From: Markus Friedl To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: "Jeff P. Van Dyke" , ietf-ssh@clinet.fi Subject: Re: Can we make subsystems for robust? Message-ID: <20001219231520.A23873@faui02.informatik.uni-erlangen.de> References: <003501c0695a$dfd5d580$1000a8c0@viper> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 In-Reply-To: ; from nisse@lysator.liu.se on Tue, Dec 19, 2000 at 10:34:59AM +0100 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id AAA12236 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA28186 On Tue, Dec 19, 2000 at 10:34:59AM +0100, Niels Mцller wrote: > That's a configuration error, which can break all sorts of things. I > don't think we should work around it in the protocol. yes, i think the protocol cannot care about user/sysadmin configuration errors. having 'echo' statements in login scripts for non-interactive sessions breaks a lot of things. > It's not entirely obvious that this way of executing "commands" is > desirable or appropriate for subsystems. You could just exec the > appropriate subsystem binary directly, without invoking any shell. But > you have to be careful, as some sites may intentinally use /bin/false > or nologin for some accounts, and bypassing that could have bad > consequences. many sites do accounting / access control with the loginshell. e.g. the loginshell just exits if the user is not allowed to login, so, IMHO the loginshell should always be executed. also, how do you know that a shell called /bin/false means 'deny login or subsystems execution' if you do not try to execute the shell. -markus From owner-ietf-ssh@clinet.fi Wed Dec 20 10:04: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 KAA27456 for ; Wed, 20 Dec 2000 10:04:43 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id OAA01144 for ietf-ssh-outgoing; Wed, 20 Dec 2000 14:35:31 +0200 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id OAA00997 for ; Wed, 20 Dec 2000 14:34:48 +0200 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id OAA00512; Wed, 20 Dec 2000 14:35:18 +0200 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14912.42886.140454.713310@asgard.tky.hut.fi> Date: Wed, 20 Dec 2000 14:35:18 +0200 To: Martin Forssen Cc: sommerfeld@east.sun.com, darrenm@Eng.Sun.COM, ietf-ssh@clinet.fi Subject: Re: Keyboard-interactive: device names and IANA In-Reply-To: <20001219082637.29B0E317AA@pelee.firedoor.se> References: <200012181835.eBIIYXX100947@thunk.east.sun.com> <20001219082637.29B0E317AA@pelee.firedoor.se> X-Mailer: VM 6.87 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Martin Forssen, on December 19. 2000, wrote: : Perhaps "method" (or "submethod") is a better name than device, we just : have to be clear in the RFC. "submethod". hmm... good, good,.. (calling it just "method" would be too similar with the wording in userauth, in my opinion ("authentication methods", IIRC).) -- [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 Dec 20 12:38: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 MAA05853 for ; Wed, 20 Dec 2000 12:38:42 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA02872 for ietf-ssh-outgoing; Wed, 20 Dec 2000 17:06:04 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA02867 for ; Wed, 20 Dec 2000 17:06:01 +0200 Received: from viper2 ([192.168.0.38]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 253; Wed, 20 Dec 2000 08:10:16 -0700 Message-ID: <001c01c06a97$09cd4f70$0201a8c0@vandyke.com> From: "Jeff P. Van Dyke" To: "Tero Kivinen" Cc: "Sami Lehtinen" , References: <003501c0695a$dfd5d580$1000a8c0@viper><14911.20008.769998.140696@asgard.tky.hut.fi><001201c069d5$3e78d270$1000a8c0@viper> <14912.50003.742331.62124@hutcs.cs.hut.fi> Subject: Re: Can we make subsystems for robust? Date: Wed, 20 Dec 2000 08:10:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit From: "Tero Kivinen" > Jeff P. Van Dyke writes: > > > : 1) Change the draft to specify that only output from the > > > : subsystem is sent to the client. > > > This is what I've been thinking about (ie. discard anything coming > > > from the subsystem-executable before the version packet). > > Do we need to add language specifying the structure > > and details of a subsystem version packet? > > I think this whole issue is implementation details and should not > concern the protocol itself. There can be implementation hits saying > that when you write your own subsystem you should add some kind of > magic cookie in the beginning so you can ignore junk sent before the > actual subsystem is started. > > I think the specification of the version packet should be in the > subsystem specification document, not in the main ssh document set. > I.e the sftp specifies its own FXP_INIT packet and the other end > should ignore everything before that. Sounds good. Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Wed Dec 20 13:00: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 NAA07122 for ; Wed, 20 Dec 2000 13:00:18 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id OAA32176 for ietf-ssh-outgoing; Wed, 20 Dec 2000 14:28:45 +0200 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id OAA32132 for ; Wed, 20 Dec 2000 14:28:33 +0200 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id OAA00507; Wed, 20 Dec 2000 14:29:01 +0200 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14912.42508.757074.818086@asgard.tky.hut.fi> Date: Wed, 20 Dec 2000 14:29:00 +0200 To: Martin Forssen Cc: Darren.Moffat@Eng.Sun.COM, ietf-ssh@clinet.fi Subject: Re: Comments for draft-ietf-secsh-auth-kbdinteract-01.txt In-Reply-To: <20001219100809.26E44317AA@pelee.firedoor.se> References: <200012190328.eBJ3Shm155590@jurassic.eng.sun.com> <20001219100809.26E44317AA@pelee.firedoor.se> X-Mailer: VM 6.87 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Martin Forssen, on December 19. 2000, wrote: : On 18 Dec, Darren Moffat wrote: : > IIRC there was also disussion in the wg meeting last week about : > removing the ablity to send multiple prompts in one : > SSH_MSG_USERAUTH_INFO_REQUEST can someone remind me on the consensus : > of that (if there was one) ? I seem to remeber someone saying : : I did not get the impression that there was any consensus to remove that : ability. Actually I did not feel that there was any need to change the : actual protocol at all. The draft needs some clarifications here and : there and that is all. At least that is the impression I got, but I : might be biased. Even though you are biased :) there was consensus that the draft currently looks good for what it is meant to do. -- [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 Dec 20 13:39:55 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 NAA09551 for ; Wed, 20 Dec 2000 13:39:54 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA14076 for ietf-ssh-outgoing; Wed, 20 Dec 2000 18:43:34 +0200 Received: from stack.hamachi.org (sommerfeld.ne.mediaone.net [24.147.212.81]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA14073 for ; Wed, 20 Dec 2000 18:43:33 +0200 Received: from syn.hamachi.org (orchard.hamachi.org [4.255.0.98]) by stack.hamachi.org (Postfix) with ESMTP id 49F56278C for ; Wed, 20 Dec 2000 11:43:32 -0500 (EST) Received: from syn.hamachi.org (localhost [[UNIX: localhost]]) by syn.hamachi.org (8.11.0/8.8.8) with ESMTP id eBKGhO622271 for ; Wed, 20 Dec 2000 11:43:24 -0500 (EST) Message-Id: <200012201643.eBKGhO622271@syn.hamachi.org> From: Bill Sommerfeld To: ietf-ssh@clinet.fi Subject: kerberos/gssapi working group drafts. Reply-To: sommerfeld@orchard.arlington.ma.us Date: Wed, 20 Dec 2000 11:43:23 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Based on what looked to me like better-than-rough consensus among the implementors at the pittsburgh meeting, and the lack of alternative proposals, I'm going to ask the IESG secretary to mark: draft-galb-secsh-gssapi-00.txt and draft-salowey-secsh-kerbkeyex-00.txt as official documents of the secsh working group. Subsequent versions should be renamed to draft-ietf-secsh-* - Bill From owner-ietf-ssh@clinet.fi Sun Dec 24 19:39: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 TAA10091 for ; Sun, 24 Dec 2000 19:39:28 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id AAA28424 for ietf-ssh-outgoing; Mon, 25 Dec 2000 00:39:27 +0200 Received: from courier01.adinet.com.uy (courier01.adinet.com.uy [206.99.44.235]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id AAA28421 for ; Mon, 25 Dec 2000 00:39:23 +0200 Received: from adinet.com.uy (r200-40-24-217.adinet.com.uy [200.40.24.217]) by courier01.adinet.com.uy (8.9.3/8.9.3) with ESMTP id TAA07482 for ; Sun, 24 Dec 2000 19:42:35 -0300 (GMT) Message-ID: <3A4679BA.72B14318@adinet.com.uy> Date: Sun, 24 Dec 2000 19:33:30 -0300 From: Marcelo David X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.11-2mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ssh@clinet.fi Subject: Hello Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Hi! I am Marcelo David and i have just signed up to be part of this working group (if you dont mind) Well, Happy Holidays Salutations from Uruguay, Marcelo David From owner-ietf-ssh@clinet.fi Wed Dec 27 19:32: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 TAA26757 for ; Wed, 27 Dec 2000 19:32:43 -0500 (EST) From: owner-ietf-ssh@clinet.fi Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id AAA02560 for ietf-ssh-outgoing; Thu, 28 Dec 2000 00:19:10 +0200 Received: from smtp1.clinet.fi (smtp1.clinet.fi [194.100.2.57]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id AAA02545; Thu, 28 Dec 2000 00:19:04 +0200 Received: from unknown (6-116.dialup.lanck.net [62.152.66.116]) by smtp1.clinet.fi (Postfix) with SMTP id 375121BF; Thu, 28 Dec 2000 00:19:01 +0200 (EET) Subject: direktoru ohrana truda Date: Чт, 28 дек 2000 02:12:14 Message-Id: <20001227221901.375121BF@smtp1.clinet.fi> To: undisclosed-recipients:; Sender: owner-ietf-ssh@clinet.fi Precedence: bulk НАЧАЛЬНИКУ ОТДЕЛА СНАБЖЕНИЯ, СБЫТА УТЕПЛИТЕЛИ Вспененный полиэтилен (ППЭ) - упругий эластичный материал с закрытой ячеистой структурой, не впитывает влагу, является прекрасным теплоизолятором 0,029-0,041Вт/мoК, хорошо поглощает звук до 74%, гасит удары и вибрацию обладает химической стойкостью, выдерживает диапазон температур от -85?С до +105?С, гигиенически и экологически безопасен. ТЕПЛОН ППЭ применяются для изоляции стен, полов, крыш, ВИЛАТЕРМ-Л трубопроводов в жилых и промышленных зданиях. ЛАТКОПЛАСТ Укладывается под сайдинг, вагонку, под отделочный СТЕНОФОН 290 слой гипсокартона. Используется как подложка под ПЕНОФЛЕКС паркет, линолеум, ламинированные полы. Также ИЗОЛОН пенополиэтилен - это надежная и легкая упаковка. АЗУРИЗОЛ-Ф Пенополиэтилен со специальным фольгированным ПЕНОФОЛ покрытием создает более эффективную теплозащиту. ВИЛАТЕРМ-СМ Жгуты для заделки щелей в конструкциях зданий, оконных и дверных проемах. СТЕНОФЛЕКС 400 Теплоизоляция для труб в виде скорлуп d = 22-108мм. А также: поролон, пенопласт и другие утеплительные материалы. ПЛЕНКИ - строительные и парниковые. АРМИРОВАННАЯ светостабилизированная пленка особой прочности, многолетняя. "Красная клеточка" - для ранних урожаев. ПОЛИАМИДНАЯ пленка суперпрозрачная, четырехслойная, особо прочная. ТЕНТ армированный с люверсами, для защиты строительных лесов. ТРАДИЦИОННЫЕ прозрачные укрывные пленки толщиной 60-200 мкм. СПЕЦИАЛЬНЫЕ пленки: черная, черно-белая, техническая, спанбонд. ЛИНОЛЕУМ - отечественного производства. Широкий ассортимент рисунков и фактуры, разнообразная цветовая гамма. Сопутствующие товары для монтажа и сварки: пороги, ленты, аппарат для сварки, клеи. Для строительства и ремонта: клеи, герметики, лаки, краски. Прайс-лист вышлем по первому Вашему требованию. Менеджеры-консультанты: Голованова Татьяна Кочуков Алексей Овечкина Оксана МЫ РАБОТАЕМ ДЛЯ ВАС!