From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Dec 2 01:55:16 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03256 for ; Sun, 2 Dec 2001 01:55:15 -0500 (EST) Received: (qmail 15197 invoked by uid 605); 2 Dec 2001 06:55:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15190 invoked from network); 2 Dec 2001 06:55:11 -0000 Received: from becasse.cs.stevens-tech.edu (155.246.89.38) by mail.netbsd.org with SMTP; 2 Dec 2001 06:55:11 -0000 Received: by becasse.cs.stevens-tech.edu (Postfix, from userid 3330) id 8E5D61BAFC; Sun, 2 Dec 2001 01:54:54 -0500 (EST) Date: Sun, 2 Dec 2001 01:54:54 -0500 From: Thor Simon To: RJ Atkinson Cc: ietf-ssh@netbsd.org Subject: Re: des-cbc cipher Message-ID: <20011202015454.A8328@cs.stevens-tech.edu> References: <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3> <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <200111290215.fAT2F1Eu998747@jurassic.eng.sun.com> <5.1.0.14.2.20011128213452.01d824e0@10.30.15.3> <20011129094341.B27343@faui02> <5.1.0.14.2.20011129100958.00a45ae0@10.30.15.3> <20011130064553.B823471@cs.stevens-tech.edu> <5.1.0.14.2.20011130105953.01db7d40@10.30.15.3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.2.20011130105953.01db7d40@10.30.15.3>; from rja@inet.org on Fri, Nov 30, 2001 at 11:01:20AM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Nov 30, 2001 at 11:01:20AM -0500, RJ Atkinson wrote: > At 06:45 30/11/01, Thor Simon wrote: > >It's the plain fault of the folks who chose to name their DES-CBC > >implementation "des-cbc" instead of "des-cbc@ssh.com" that this situation > >exists. Why should we break the standard just for them? Should we do so > >in the future any time an implementation that's widely used violates any > >detail of any standard? > > Thor, > > Those implementations PRE-DATE the first draft spec. So > they can't be blamed now for following a draft that DIDN'T EXIST > at the time it was coded up. The history is relevant here -- ugly > to be sure, but highly relevant. As has been repeatedly pointed out, the implementations that existed when the draft first appeared (and did *not* include the des-cbc cipher) were of a different, if ancestral protocol; they would quite simply not interoperate with an implementation of the protocol described by this year's (or last year's!) drafts. The people who maintain those implementations are parties to this process; they had their chance to fix their implementation long ago; they didn't (accidentally, it seems). Nonetheless, why bend the protocol to suit their implementation? Would you suggest that we document or even require every *other* rejected protocol feature that those implementations support (or once supported) just to avoid causing them inconvenience? That seems wrong, particularly (and maybe this is just my personal bias showing, but I have a *big* smoking hole in my pocket here...) given the lengths some of those implementors went to to cause trouble for other implementors of the protocol, for which so far as I know none of us have received so much as a simple apology. Heck, so far as I know, they *still* might slap me with a specious lawsuit next week! Why should the other participants in this group, pretty much all of whom are in the same situation, and some of whom maintain an implementation that's freely available and *wildly* more popular than the noncompliant ones in question, pretend there's consensus to include des-cbc in the protocol when there's clearly not? There is no compelling technical reason; and unfortunately for your position, I suspect that even if they are not undiplomatic enough to say so, many others in this group feel as I do: the people who would most benefit from this are not people to whom we are prone to do any favors. Thor From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Dec 2 08:27:16 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19596 for ; Sun, 2 Dec 2001 08:27:16 -0500 (EST) Received: (qmail 15519 invoked by uid 605); 2 Dec 2001 13:27:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15512 invoked from network); 2 Dec 2001 13:27:12 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 2 Dec 2001 13:27:12 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id OAA11161; Sun, 2 Dec 2001 14:26:58 +0100 (MET) Date: Sun, 2 Dec 2001 14:26:57 +0100 From: Markus Friedl To: RJ Atkinson , ietf-ssh@netbsd.org Subject: Re: des-cbc cipher Message-ID: <20011202142657.D10755@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Nov 30, 2001 at 11:01:20AM -0500, RJ Atkinson wrote: > Those implementations PRE-DATE the first draft spec. So > they can't be blamed now for following a draft that DIDN'T EXIST > at the time it was coded up. The history is relevant here -- ugly > to be sure, but highly relevant. implementations pre-dating the first draft can never be compliant, since they won't be using the correct session id, for example. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Dec 3 03:31:42 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24278 for ; Mon, 3 Dec 2001 03:31:42 -0500 (EST) Received: (qmail 23532 invoked by uid 605); 3 Dec 2001 08:31:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23525 invoked from network); 3 Dec 2001 08:31:39 -0000 Received: from pdns.ndu.edu.cn (HELO ndu.edu.cn) (202.205.32.253) by mail.netbsd.org with SMTP; 3 Dec 2001 08:31:39 -0000 Received: from yahoo.com by ndu.edu.cn (SMI-8.6/SMI-SVR4) id QAA18346; Mon, 3 Dec 2001 16:31:07 +0800 From: Kattie Kilbourne To: ietf-ssh@netbsd.org Subject: I haven't heard from you lately. Date: Mon, 3 Dec 2001 00:26:05 Message-Id: <380.652189.634758@yahoo.com> Reply-To: morewomen4u@yahoo.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list FREE Seduction eBook: Sweep Women Off Their Feet and Into Your Bed (120 Full Pages!) +plus FREE Seduction Articles FREE Seduction Links ...and much, much more, all under one roof. Simply reply to this email to receive more information. To be remove from our mailing list, send and email to: rem_listsrvr@yahoo.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Dec 3 06:24:39 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26082 for ; Mon, 3 Dec 2001 06:24:39 -0500 (EST) Received: (qmail 13990 invoked by uid 605); 3 Dec 2001 11:23:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13588 invoked from network); 3 Dec 2001 11:22:52 -0000 Received: from delivery1.cdg.co.th (157.179.6.16) by mail.netbsd.org with SMTP; 3 Dec 2001 11:22:52 -0000 Received: from serangeti (interscan.cdg.co.th [157.179.6.15]) by delivery1.cdg.co.th (8.11.5/8.11.5) with SMTP id fB3BZpX05709 for ; Mon, 3 Dec 2001 18:35:51 +0700 (GMT) Received: from 157.179.6.13 by serangeti (InterScan E-Mail VirusWall NT); Mon, 03 Dec 2001 21:20:34 +0700 Received: from logicmail.logic.co.th (logicmail.cdg.co.th [202.22.12.20]) by cdgrelay1.cdg.co.th (8.11.1/8.11.2) with ESMTP id fB3BVGJ13320 for ; Mon, 3 Dec 2001 18:31:17 +0700 (GMT) Received: from khunying ([157.179.9.43]) by logicmail.logic.co.th (8.12.1/8.12.1) with SMTP id fB3BM6Pd020916 for ; Mon, 3 Dec 2001 18:22:08 +0700 (GMT) Message-ID: <016f01c17bec$9ae6cd80$2b09b39d@cdg.co.th> From: "K.Ying" To: Subject: I have DSA host key problem. Date: Mon, 3 Dec 2001 18:21:06 +0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: ietf-ssh-owner@netbsd.org Precedence: list This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----=_NextPart_000_016C_01C17C27.4620AD80" ------=_NextPart_000_016C_01C17C27.4620AD80 Content-Type: text/plain; charset="windows-874" Content-Transfer-Encoding: quoted-printable Hi sir, I try to ssh to remote host with ssh remote_host command. It has error = " No DSA host key is known for remote_host and you have requested strict = checking. Please recommend. Thanks for your help, Aekauma P. ------=_NextPart_000_016C_01C17C27.4620AD80 Content-Type: text/html; charset="windows-874" Content-Transfer-Encoding: quoted-printable
Hi sir,
I try to ssh to remote host with ssh = remote_host=20 command.  It has error " No DSA host key is known for remote_host = and you=20 have requested strict checking.
 
Please recommend.
 
Thanks for your help,
Aekauma P.
------=_NextPart_000_016C_01C17C27.4620AD80-- --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="InterScan_SafeStamp.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_SafeStamp.txt" Content-Transfer-Encoding: 7bit ****** Message from InterScan E-Mail VirusWall NT ****** ** No virus found in attached file noname.htm ** No virus found in attached file noname.htm ***************** End of message *************** --------------InterScan_NT_MIME_Boundary-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Dec 3 14:30:59 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23935 for ; Mon, 3 Dec 2001 14:30:59 -0500 (EST) Received: (qmail 22906 invoked by uid 605); 3 Dec 2001 19:30:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22898 invoked from network); 3 Dec 2001 19:30:56 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 3 Dec 2001 19:30:56 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11499; Mon, 3 Dec 2001 12:30:29 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12738; Mon, 3 Dec 2001 14:30:46 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fB3JUkU8020514; Mon, 3 Dec 2001 14:30:46 -0500 (EST) Message-Id: <200112031930.fB3JUkU8020514@thunk.east.sun.com> From: Bill Sommerfeld To: Thor Simon cc: RJ Atkinson , ietf-ssh@netbsd.org Subject: Re: des-cbc cipher In-Reply-To: Your message of "Sun, 02 Dec 2001 01:54:54 EST." <20011202015454.A8328@cs.stevens-tech.edu> Reply-to: sommerfeld@east.sun.com Date: Mon, 03 Dec 2001 14:30:45 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > As has been repeatedly pointed out, the implementations that existed > when the draft first appeared (and did *not* include the des-cbc cipher) > were of a different, if ancestral protocol... So, this being "ancestral", seems like it would be appropriate to list them (in the IANA registry once it exists) as Historic. Ran pointed out to me that a strict reading of the spec as it stands now would be that interoperable implementations otherwise compliant to the spec become non-compliant simply because they offer to use "des-cbc" as a crypto algorithm in addition to (for example) 3des. This strikes me as unnecessarily harsh, in particular because the language in the architecture draft stating that un-@-qualified ssh protocol names are assigned soley by IETF consensus is significantly more recent than the current generation of the protocol (to my knowledge, it was first discussed in detail around the time of the San Diego ietf about a year ago). Before that text was added to the draft, the use of non-@-qualified names was designated as "assigned by IANA"; this turns out to have very little meaning -- as IANA requires guidance from the IETF in how to do these assignments, and no such registry exists (and it won't exist until our documents get to the IESG). So it strikes me as unnecessarily restrictive to attempt to exert retroactive control here. Anyhow, RFC2026 says about the "historic" designation: A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level. This seems to fit the situation closely; also, according to Jeff Schiller, it is possible for RFC's to be "born historic". What does this mean for the specs: - No change is necessary to the core protocol drafts. - The working group needs to allocate "des-cbc" as historic (deprecated) and/or Not Recommended - an additional working group document (which I believe Ran has volunteered to write) would designate des-cbc as historic and deprecated, and would be intended for publication as a Historic RFC. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Dec 3 14:44:30 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24807 for ; Mon, 3 Dec 2001 14:44:30 -0500 (EST) Received: (qmail 25780 invoked by uid 605); 3 Dec 2001 19:44:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25773 invoked from network); 3 Dec 2001 19:44:26 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 3 Dec 2001 19:44:26 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA14639 for ; Mon, 3 Dec 2001 11:44:25 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.166]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id LAA17612 for ; Mon, 3 Dec 2001 11:44:47 -0800 (PST) Received: from quirm (dsl-192-32.Eng.Sun.COM [129.146.192.32]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with SMTP id fB3JiMEu859482 for ; Mon, 3 Dec 2001 11:44:24 -0800 (PST) Message-Id: <200112031944.fB3JiMEu859482@jurassic.eng.sun.com> Date: Mon, 3 Dec 2001 11:43:58 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: des-cbc cipher To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: dgRCLK+8wCQCL4IV24IRig== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >What does this mean for the specs: > > - No change is necessary to the core protocol drafts. Good. > - The working group needs to allocate "des-cbc" as historic > (deprecated) and/or Not Recommended My preference would be for Historic and Not Recommended. > - an additional working group document (which I believe Ran has >volunteered to write) would designate des-cbc as historic and >deprecated, and would be intended for publication as a Historic RFC. I'm happy with that as an outcome since it makes the status of desc-cbc clear and it doesn't require further changes to the core drafts. Ran if you wish I could help out with the editiing of the new draft since I have everything setup (including references) for generating the core drafts. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Dec 3 15:53:13 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29759 for ; Mon, 3 Dec 2001 15:53:12 -0500 (EST) Received: (qmail 8096 invoked by uid 605); 3 Dec 2001 20:53:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8089 invoked from network); 3 Dec 2001 20:53:09 -0000 Received: from smtp-rt-9.wanadoo.fr (HELO alisier.wanadoo.fr) (193.252.19.55) by mail.netbsd.org with SMTP; 3 Dec 2001 20:53:09 -0000 Received: from villosa.wanadoo.fr (193.252.19.122) by alisier.wanadoo.fr; 3 Dec 2001 21:53:02 +0100 Received: from win2000 (193.253.203.227) by villosa.wanadoo.fr; 3 Dec 2001 21:52:21 +0100 From: "Emmanuel Penove" To: Subject: denyusers & ssh Date: Mon, 3 Dec 2001 21:50:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit hello , i've just have a question very simple : why when i write : DenyUsers XXX i already can connect with this login XXX !!!! i reaload the sshd daemon it's says me "erroe configuration" but i don't know why !!!! if somebody can help me , thanks a lot Scuse for my poor english .... i'm french !!! Manu From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Dec 3 16:03:53 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00579 for ; Mon, 3 Dec 2001 16:03:52 -0500 (EST) Received: (qmail 11525 invoked by uid 605); 3 Dec 2001 21:03:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11518 invoked from network); 3 Dec 2001 21:03:50 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 3 Dec 2001 21:03:50 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id E61EF82F528; Mon, 3 Dec 2001 22:03:48 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.3/8.8.7) id WAA17969; Mon, 3 Dec 2001 22:03:48 +0100 (MET) X-Authentication-Warning: sture.lysator.liu.se: nisse set sender to nisse@sture.lysator.liu.se using -f To: sommerfeld@east.sun.com Cc: Thor Simon , RJ Atkinson , ietf-ssh@netbsd.org Subject: Re: des-cbc cipher References: <200112031930.fB3JUkU8020514@thunk.east.sun.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 03 Dec 2001 22:03:47 +0100 In-Reply-To: <200112031930.fB3JUkU8020514@thunk.east.sun.com> Message-ID: Lines: 52 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Bill Sommerfeld writes: > Before that text was added to the draft, the use of non-@-qualified > names was designated as "assigned by IANA"; this turns out to have > very little meaning -- as IANA requires guidance from the IETF in how > to do these assignments, and no such registry exists (and it won't > exist until our documents get to the IESG). So it strikes me as > unnecessarily restrictive to attempt to exert retroactive control > here. I don't want to object to your proposed resolution for this issue, but I want to point out that even if the IANA considerations section of older drafts was quite vague, I think the algorithm naming section makes it pretty clear. My reading of that is all valid names are defined either * directly in in the spec (these names will turn up in the initial IANA approved list whenever the IANA registration process is opened), or * by IANA registration (and this set of names have so far always been empty as no registration process have ever been started), or * by using the @-form. From draft-ietf-secsh-architecture-02.txt, section 5 (the oldest architecture draft I have around): : There are two formats for algorithm names: : : o Names that do not contain an at-sign (@) are reserved to be assigned : by IANA (Internet Assigned Numbers Authority). Examples include : `3des-cbc', `sha-1', `hmac-sha1', and `zlib' (the quotes are not part : of the name). Additional names of this format may be registered with : IANA; see Section ``IANA Considerations''. Names of this format MUST : NOT be used without first registering with IANA. Registered names : MUST NOT contain an at-sign (@) or a comma (,). : : o Anyone can define additional algorithms by using names in the format : name@domainname, e.g. "ourcipher-cbc@ssh.fi". The format of the part : preceding the at sign is not specified; it MUST consist of US-ASCII : characters except at-sign and comma. The part following the at-sign : MUST be a valid fully qualified internet domain name [RFC-1034] : controlled by the person or organization defining the name. It is up : to each domain how it manages its local namespace. If anyone can explain how to read that as allowing the unregistered name `des-cbc', please mail me privately, I hope we need not discuss that anymore on this list. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Dec 3 17:35:13 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07894 for ; Mon, 3 Dec 2001 17:35:13 -0500 (EST) Received: (qmail 6756 invoked by uid 605); 3 Dec 2001 22:35:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6749 invoked from network); 3 Dec 2001 22:35:10 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 3 Dec 2001 22:35:10 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA29123; Mon, 3 Dec 2001 14:35:09 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.81.144]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id OAA24663; Mon, 3 Dec 2001 14:35:31 -0800 (PST) Received: from quirm (dsl-192-32.Eng.Sun.COM [129.146.192.32]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with SMTP id fB3MZ4Eu899265; Mon, 3 Dec 2001 14:35:08 -0800 (PST) Message-Id: <200112032235.fB3MZ4Eu899265@jurassic.eng.sun.com> Date: Mon, 3 Dec 2001 14:34:42 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: denyusers & ssh To: ietf-ssh@netbsd.org, nsl@free.fr MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: s2PAAGLs4QAVVTHehcBDTw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list The ietf-ssh@netbsd.org mailing list is for discussion of the network protocol issues. The network protocol does not deal with host based access control mechanisms such as a DenyUsers setting. If you are using OpenSSH then a more appropriate mailing list would be openssh-dev-unix@mindrot.org. Or try usenet group comp.protocols.ssh -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Dec 4 17:05:08 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14508 for ; Tue, 4 Dec 2001 17:05:07 -0500 (EST) Received: (qmail 21653 invoked by uid 605); 4 Dec 2001 22:05:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21646 invoked from network); 4 Dec 2001 22:05:05 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 4 Dec 2001 22:05:05 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA00484 for ; Tue, 4 Dec 2001 14:05:03 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA12104 for ; Tue, 4 Dec 2001 17:05:02 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fB4M52U8002088 for ; Tue, 4 Dec 2001 17:05:02 -0500 (EST) Message-Id: <200112042205.fB4M52U8002088@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: WG Last Call for secsh core drafts. Reply-to: sommerfeld@east.sun.com Date: Tue, 04 Dec 2001 17:05:02 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list A Working Group Last Call begins today and will end in two weeks for the following four drafts: draft-ietf-secsh-architecture-11.txt draft-ietf-secsh-transport-11.txt draft-ietf-secsh-userauth-13.txt draft-ietf-secsh-connect-14.txt I believe that these documents likely the current consensus of the working group and should be submitted to the IESG for consideration for publication as a Proposed Standard RFC. Comments regarding the content of these documents should be sent to the working group mailing list, . If you believe a change to a document is necessary, please include revised wording along with your comment. This Last Call period extends until December 18th, 2001. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Dec 4 17:27:03 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15248 for ; Tue, 4 Dec 2001 17:27:02 -0500 (EST) Received: (qmail 24223 invoked by uid 605); 4 Dec 2001 22:27:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24216 invoked from network); 4 Dec 2001 22:27:01 -0000 Received: from sentry.gw.tislabs.com (192.94.214.100) by mail.netbsd.org with SMTP; 4 Dec 2001 22:27:01 -0000 Received: by sentry.gw.tislabs.com; id RAA01840; Tue, 4 Dec 2001 17:32:01 -0500 (EST) Received: from beale.gw.tislabs.com(10.33.30.51) by sentry.gw.tislabs.com via smap (V5.5) id xma001822; Tue, 4 Dec 01 17:31:03 -0500 Received: (from wgriffin@localhost) by beale.gw.tislabs.com (8.11.4/8.11.3) id fB4MQ1b19100 for ietf-ssh@netbsd.org; Tue, 4 Dec 2001 17:26:01 -0500 (EST) X-Authentication-Warning: beale.gw.tislabs.com: wgriffin set sender to wgriffin@tislabs.com using -f Date: Tue, 4 Dec 2001 17:26:01 -0500 From: Wes Griffin To: ietf-ssh@netbsd.org Subject: Missing words in transport draft? Message-ID: <20011204172600.D17867@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: ietf-ssh-owner@netbsd.org Precedence: list I was just reading the transport draft and noticed what I think is a missing "session identifier" in section 5.2 where the lone comma is: >these. The exchange hash H from the first key exchange is >additionally used as the , which is a unique identifier for this >connection. It is used by authentication methods as a part of the -- Wes Griffin NAI Labs wgriffin at tislabs.com 443.259.2388 From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Dec 4 17:32:48 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15608 for ; Tue, 4 Dec 2001 17:32:48 -0500 (EST) Received: (qmail 25186 invoked by uid 605); 4 Dec 2001 22:32:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25179 invoked from network); 4 Dec 2001 22:32:47 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 4 Dec 2001 22:32:47 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29664; Tue, 4 Dec 2001 15:32:26 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id OAA19398; Tue, 4 Dec 2001 14:33:08 -0800 (PST) Received: from Sun.COM (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4MWhEt178311; Tue, 4 Dec 2001 14:32:43 -0800 (PST) Message-ID: <3C0D4F0A.8090405@Sun.COM> Date: Tue, 04 Dec 2001 14:32:42 -0800 From: Darren J Moffat Organization: Sun Microsystems, Solaris Software Security Technologies Group User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.2) Gecko/20011002 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Wes Griffin CC: ietf-ssh@netbsd.org Subject: Re: Missing words in transport draft? References: <20011204172600.D17867@tislabs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Wes Griffin wrote: > I was just reading the transport draft and noticed what I think is a > missing "session identifier" in section 5.2 where the lone comma is: > > >>these. The exchange hash H from the first key exchange is >>additionally used as the , which is a unique identifier for this >>connection. It is used by authentication methods as a part of the Yep that should indeed say "session identifier". It was missing because the doc sources that I started with had this surrounded by for some reason, as a result the xml2rfc program ignores it because it doesn't understand the tag, oops. I'll have to wait until after the SLC IETF meeting before reissuing the draft - it will also be good to wait until the 18th anyway for any issues resulting from last call. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Dec 5 11:25:24 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26336 for ; Wed, 5 Dec 2001 11:25:23 -0500 (EST) Received: (qmail 20973 invoked by uid 605); 5 Dec 2001 16:25:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20966 invoked from network); 5 Dec 2001 16:25:22 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 5 Dec 2001 16:25:22 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA25082; Wed, 5 Dec 2001 08:25:21 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15734; Wed, 5 Dec 2001 11:25:20 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fB5GPJU8010232; Wed, 5 Dec 2001 11:25:19 -0500 (EST) Message-Id: <200112051625.fB5GPJU8010232@thunk.east.sun.com> From: Bill Sommerfeld To: agenda@ietf.org cc: ietf-ssh@netbsd.org Subject: 52nd IETF - Secure Shell WG (secsh) agenda Reply-to: sommerfeld@east.sun.com Date: Wed, 05 Dec 2001 11:25:19 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Secure Shell Working Group (secsh) Monday, December 10 at 1530-1730 ================================ CHAIR: Bill Sommerfeld AGENDA: initialization vector/agenda bashing 5 minutes status of working group 5 minutes core secsh protocol - changes in latest drafts 5 minutes - last-call issues with core drafts 15 minutes SSH Protocol Architecture draft-ietf-secsh-architecture-11.txt SSH Connection Protocol draft-ietf-secsh-connect-14.txt SSH Authentication Protocol draft-ietf-secsh-userauth-13.txt SSH Transport Layer Protocol draft-ietf-secsh-transport-11.txt - handling of "legacy"/historic identifiers 5 minutes - status of other WG items: 30 minutes Generic Message Exchange Authentication For SSH draft-ietf-secsh-auth-kbdinteract-02.txt GSSAPI Authentication and Key Exchange for the Secure Shell Protocol draft-ietf-secsh-gsskeyex-02.txt SECSH Public Key File Format draft-ietf-secsh-publickeyfile-02.txt Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol draft-ietf-secsh-dh-group-exchange-01.txt Storing SSH Host Keys in DNS draft-ietf-secsh-dns-key-format-00.txt SSH File Transfer Protocol draft-ietf-secsh-filexfer-02.txt - future directions 30 minutes agent forwarding review milestones other ? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Dec 5 18:31:17 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20568 for ; Wed, 5 Dec 2001 18:31:16 -0500 (EST) Received: (qmail 28867 invoked by uid 605); 5 Dec 2001 23:31:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28859 invoked from network); 5 Dec 2001 23:31:13 -0000 Received: from mxout2.cac.washington.edu (140.142.33.4) by mail.netbsd.org with SMTP; 5 Dec 2001 23:31:13 -0000 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.12]) by mxout2.cac.washington.edu (8.11.6+UW01.08/8.11.6+UW01.10) with ESMTP id fB5NVDx09641 for ; Wed, 5 Dec 2001 15:31:13 -0800 Received: from D-140-142-21-29.dhcp2.washington.edu (D-140-142-21-29.dhcp2.washington.edu [140.142.21.29]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW01.10) with ESMTP id fB5NVD5n015484 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 5 Dec 2001 15:31:13 -0800 Date: Wed, 5 Dec 2001 15:31:31 -0800 (PST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perx.cac.washington.edu Reply-To: "RL 'Bob' Morgan" To: IETF ssh WG Subject: outstanding issues with draft-ietf-secsh-gsskeyex-02 ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list I observe that there hasn't been any recent discussion of the GSS document (dated July 20, 2001). The only implementation I'm aware of, Simon Wilkinson's patch for openssh, dates from before that and so I suspect doesn't conform to -02. I'm curious whether there are known open issues that would prevent this document from going to WG Last Call, as I would like to see it advance. It looks OK to me, but I'm not enough of an ssh expert to judge. Thanks, - RL "Bob" From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Dec 7 19:35:11 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03538 for ; Fri, 7 Dec 2001 19:35:10 -0500 (EST) Received: (qmail 11403 invoked by uid 605); 8 Dec 2001 00:35:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11396 invoked from network); 8 Dec 2001 00:35:03 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 8 Dec 2001 00:35:03 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA08220; Fri, 7 Dec 2001 16:34: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,v2.1p1) with ESMTP id TAA26030; Fri, 7 Dec 2001 19:34:57 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fB80YvjM021431; Fri, 7 Dec 2001 19:34:57 -0500 (EST) Message-Id: <200112080034.fB80YvjM021431@thunk.east.sun.com> From: Bill Sommerfeld To: "RL 'Bob' Morgan" cc: IETF ssh WG Subject: Re: outstanding issues with draft-ietf-secsh-gsskeyex-02 ? In-Reply-To: Your message of "Wed, 05 Dec 2001 15:31:31 PST." Reply-to: sommerfeld@east.sun.com Date: Fri, 07 Dec 2001 19:34:57 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list I'll last-call this one once we're out of last-call on the core drafts. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Dec 9 07:42:10 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00415 for ; Sun, 9 Dec 2001 07:42:10 -0500 (EST) Received: (qmail 20690 invoked by uid 605); 9 Dec 2001 12:42:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20683 invoked from network); 9 Dec 2001 12:42:07 -0000 Received: from nic.appgate.com (193.12.107.226) by mail.netbsd.org with SMTP; 9 Dec 2001 12:42:07 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id CA65E3BD1E for ; Sun, 9 Dec 2001 13:42:02 +0100 (MET) Received: from appgate.com (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id DA9606C007 for ; Sun, 9 Dec 2001 13:42:02 +0100 (MET) Date: Sun, 9 Dec 2001 13:42:13 +0100 (MET) From: maf@appgate.com Subject: Status of draft-ietf-secsh-auth-kbdinteract To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20011209124202.DA9606C007@shala.firedoor.se> Sender: ietf-ssh-owner@netbsd.org Precedence: list I am not aware of any outstanding issues with the keyboard-interactive draft. And there are multiple independent implementations. I therefore think this draft is also ready for final-call once the core-drafts are done. /MaF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Dec 10 16:32:43 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12005 for ; Mon, 10 Dec 2001 16:32:43 -0500 (EST) Received: (qmail 14118 invoked by uid 605); 10 Dec 2001 21:32:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14111 invoked from network); 10 Dec 2001 21:32:40 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 10 Dec 2001 21:32:40 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA18962 for ; Mon, 10 Dec 2001 13:32:38 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.130]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id NAA12551 for ; Mon, 10 Dec 2001 13:33:09 -0800 (PST) Received: from Sun.COM (vpn-129-150-5-21.EBay.Sun.COM [129.150.5.21]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALWabF139311 for ; Mon, 10 Dec 2001 13:32:37 -0800 (PST) Message-ID: <3C152C46.4070105@Sun.COM> Date: Mon, 10 Dec 2001 13:42:30 -0800 From: Darren J Moffat Organization: Sun Microsystems User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-ssh@netbsd.org Subject: Reminder Connectathon 2002 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit A reminder that the early registration for Connectathon closes at the end of this month I would like to see all of the vendors who implement the SSH protocol to attend this is a good opportunity to debug and fix interoper problems. The testing will include the 4 core drafts, sftp, and keyboard interactive. If there is interest we may also be able to test the GSS drafts since there will be a Kerberos infrastructure at connectathon. - ------------------------------------------------------------------ The Connectathon team is delighted to announce its 16th annual event will take place as scheduled. Connectathon 2002, an interoperability testing event for engineers only, will be held Feb. 28-Mar. 7, 2002 in San Jose, California. Sponsored by Sun Microsystems, Inc., Connectathon hosts over 50 companies from around the globe in an effort to test and debug source code. Currently, the following technologies and protocols are on the agenda: NFS versions 2, 3 and 4 NFS over RDMA WebNFS Lock Manager NIS/NIS+ Automounter Kerberos IPv6 IPsec Mobile IPv4 Mobile IPv6 Secure Shell NDMP Based on demand, in addition we are considering to offer: Service Location Protocol Diameter/AAA CIFS ATM If you are interested in testing any of the above 4 protocols, please send a note to Cthon@Sun.com and we'll gauge interest. Or if you have a suggestion for another technology, feel free to contact us as well. Testing continues 24 hours per day. Technology testing coordinators will organize testing procedures and test suite material. In addition, there will be seminars with speakers addressing various topics. The registration deadline is February 7, 2002. An Early Bird Discount on station fees is available to those who register and pay by December 31, 2001. For registration information, please see our web site at http://www.connectathon.org. If you have any questions, please feel free to contact Audrey Van Belleghem at audrey@vanb.com or (408) 358-9598. We look forward to seeing you at the 16th annual Connectathon event! Audrey Van Belleghem Darren Moffat Connectathon Manager Secure Shell Connectathon Coordinator From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Dec 10 17:22:06 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13245 for ; Mon, 10 Dec 2001 17:22:05 -0500 (EST) Received: (qmail 24087 invoked by uid 605); 10 Dec 2001 22:21:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24029 invoked from network); 10 Dec 2001 22:21:52 -0000 Received: from 158-202-131-12.bellhead.com (HELO zalon.pc.cs.cmu.edu) (12.131.202.158) by mail.netbsd.org with SMTP; 10 Dec 2001 22:21:52 -0000 Received: from zalon.pc.cs.cmu.edu by zalon.pc.cs.cmu.edu id aa01210; 10 Dec 2001 15:21 MST Date: Mon, 10 Dec 2001 15:21:21 -0700 (MST) From: Jeffrey Hutzelman X-Sender: jhutz@zalon.pc.cs.cmu.edu To: "RL 'Bob' Morgan" cc: IETF ssh WG Subject: Re: outstanding issues with draft-ietf-secsh-gsskeyex-02 ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, 5 Dec 2001, RL 'Bob' Morgan wrote: > I observe that there hasn't been any recent discussion of the GSS document > (dated July 20, 2001). The only implementation I'm aware of, Simon > Wilkinson's patch for openssh, dates from before that and so I suspect > doesn't conform to -02. I'm curious whether there are known open issues > that would prevent this document from going to WG Last Call, as I would > like to see it advance. It looks OK to me, but I'm not enough of an ssh > expert to judge. There are a couple of open issues. I'll try to mention them at the working group meeting (in about 10 minutes). Most of them are minor, though, so I agree that it would be good to last call this draft after the next version is published. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Dec 10 17:40:19 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13691 for ; Mon, 10 Dec 2001 17:40:18 -0500 (EST) Received: (qmail 26896 invoked by uid 605); 10 Dec 2001 22:40:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26889 invoked from network); 10 Dec 2001 22:40:16 -0000 Received: from muck.dcs.ed.ac.uk (129.215.216.15) by mail.netbsd.org with SMTP; 10 Dec 2001 22:40:16 -0000 Received: from canna.dcs.ed.ac.uk (sxw@canna.dcs.ed.ac.uk [129.215.216.106]) by muck.dcs.ed.ac.uk with ESMTP id WAA08059; Mon, 10 Dec 2001 22:40:13 GMT Received: (from sxw@localhost) by canna.dcs.ed.ac.uk (8.8.8+Sun/8.8.8) id WAA18293; Mon, 10 Dec 2001 22:40:13 GMT Date: Mon, 10 Dec 2001 22:40:13 GMT Message-Id: <200112102240.WAA18293@canna.dcs.ed.ac.uk> From: Simon Wilkinson Subject: Re: outstanding issues with draft-ietf-secsh-gsskeyex-02 ? To: Jeffrey Hutzelman , "RL 'Bob' Morgan" In-Reply-To: Jeffrey Hutzelman's message of Mon, 10 Dec 2001 15:21:21 -0700 (MST) Cc: IETF ssh WG Sender: ietf-ssh-owner@netbsd.org Precedence: list > On Wed, 5 Dec 2001, RL 'Bob' Morgan wrote: > > > I observe that there hasn't been any recent discussion of the GSS document > > (dated July 20, 2001). The only implementation I'm aware of, Simon > > Wilkinson's patch for openssh, dates from before that and so I suspect > > doesn't conform to -02. The current published patch doesn't conform to -02. I have a patch that does, and also resolves some PAM chain issues. It should be published shortly, after the changes affecting GSI support have been checked. I'd be happy to send a copy of my current code to anyone who's interested. Cheers, Simon. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Dec 11 12:32:49 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21232 for ; Tue, 11 Dec 2001 12:32:48 -0500 (EST) Received: (qmail 20916 invoked by uid 605); 11 Dec 2001 17:32:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20909 invoked from network); 11 Dec 2001 17:32:46 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 11 Dec 2001 17:32:46 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21792; Tue, 11 Dec 2001 10:32:27 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18596; Tue, 11 Dec 2001 12:32:44 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBBHWiXt023374; Tue, 11 Dec 2001 12:32:44 -0500 (EST) Message-Id: <200112111732.fBBHWiXt023374@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Cc: jis@mit.edu Subject: summary of Secure Shell (secsh) meeting at ietf52 Reply-to: sommerfeld@east.sun.com Date: Tue, 11 Dec 2001 12:32:44 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list The Secure Shell [secsh] working group met on monday afternoon. The ssh core drafts are in WG last call (ending next week) and appear to be extremely close to done, and the same appears to be true for about half of the extension drafts. One new technical issue with the core drafts was raised during the meeting which will require a respin of the userauth draft; Jeffrey Hutzelman will describe this issue in more detail for the list. Once the core drafts are out of WG last call, we'll start last calls on the extensions drafts which appear to be done (key file format, dh group negotiation, keyboard-interactive); gssapi should be next (authors indicate that there are a few minor issues to resolve). sftp and dns key storage both need a bit more work; we expect revised drafts by the next IETF meeting. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Dec 11 12:55:03 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21689 for ; Tue, 11 Dec 2001 12:55:02 -0500 (EST) Received: (qmail 23991 invoked by uid 605); 11 Dec 2001 17:54:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23971 invoked from network); 11 Dec 2001 17:54:55 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 11 Dec 2001 17:54:55 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA22325; Tue, 11 Dec 2001 09:54:53 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id JAA15275; Tue, 11 Dec 2001 09:55:24 -0800 (PST) Received: from Sun.COM (dsl-192-32.Eng.Sun.COM [129.146.192.32]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBHskbF292775; Tue, 11 Dec 2001 09:54:47 -0800 (PST) Message-ID: <3C16488C.3090407@Sun.COM> Date: Tue, 11 Dec 2001 09:55:24 -0800 From: Darren J Moffat User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: sommerfeld@east.sun.com CC: ietf-ssh@netbsd.org, jis@mit.edu Subject: Re: summary of Secure Shell (secsh) meeting at ietf52 References: <200112111732.fBBHWiXt023374@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > and dns key storage both need a bit more work; we expect revised > drafts by the next IETF meeting. If I remeber correctly the author of the DNS host key storage draft said that the have no intention of continuting with it in its current form and that the draft will be left to expire unchanged. They wish to go back to requirements gathering and this may result in solving the problem space a different way (ie maybe not DNS as I gathered). I also volunteered to start a new draft for agent forwarding - requirements for this will be done via this list with at least an 00 draft by next meeting. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Dec 11 13:05:51 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21855 for ; Tue, 11 Dec 2001 13:05:50 -0500 (EST) Received: (qmail 26783 invoked by uid 605); 11 Dec 2001 18:05:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26774 invoked from network); 11 Dec 2001 18:05:45 -0000 Received: from ns2.pkiclue.com (HELO xena.pkiclue.com) (216.218.196.15) by mail.netbsd.org with SMTP; 11 Dec 2001 18:05:45 -0000 Received: from skylab3.tillerman.to (IDENT:root@localhost [127.0.0.1]) by xena.pkiclue.com (8.9.3/8.9.3) with ESMTP id KAA30315; Tue, 11 Dec 2001 10:07:34 -0800 Message-Id: <5.1.0.14.2.20011211105859.02f9c8b8@127.0.0.1> X-Sender: rodney@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 11 Dec 2001 11:01:09 -0700 To: Darren J Moffat , sommerfeld@east.sun.com From: Rodney Thayer Subject: Re: summary of Secure Shell (secsh) meeting at ietf52 Cc: ietf-ssh@netbsd.org In-Reply-To: <3C16488C.3090407@Sun.COM> References: <200112111732.fBBHWiXt023374@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ietf-ssh-owner@netbsd.org Precedence: list At the DNSEXT meeting, there was a (mildly surreal) exchange where they attempted to not allow "yucky applications", like SSH, to store keys in DNS. They claimed to want to dodge that work by waiting until the apps asked for it, and when several people in the room pointed out that people in the SSH wg were talking about it, this got ignored. So I think we need to have something, requirements or whatever, that we whack the DNSEXT wg with, so they know we're thinking about it, regardless of what 'we' want to do. At 09:55 AM 12/11/2001 -0800, Darren J Moffat wrote: >>and dns key storage both need a bit more work; we expect revised >>drafts by the next IETF meeting. > > >If I remeber correctly the author of the DNS host key storage draft >said that the have no intention of continuting with it in its current >form and that the draft will be left to expire unchanged. They wish >to go back to requirements gathering and this may result in solving >the problem space a different way (ie maybe not DNS as I gathered). > >I also volunteered to start a new draft for agent forwarding - >requirements for this will be done via this list with at least an 00 >draft by next meeting. > >-- >Darren J Moffat > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Dec 11 13:20:02 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22121 for ; Tue, 11 Dec 2001 13:20:02 -0500 (EST) Received: (qmail 2723 invoked by uid 605); 11 Dec 2001 18:19:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2715 invoked from network); 11 Dec 2001 18:19:58 -0000 Received: from sentry.gw.tislabs.com (192.94.214.100) by mail.netbsd.org with SMTP; 11 Dec 2001 18:19:58 -0000 Received: by sentry.gw.tislabs.com; id NAA29258; Tue, 11 Dec 2001 13:25:01 -0500 (EST) Received: from beale.gw.tislabs.com(10.33.30.51) by sentry.gw.tislabs.com via smap (V5.5) id xma029225; Tue, 11 Dec 01 13:24:30 -0500 Received: (from wgriffin@localhost) by beale.gw.tislabs.com (8.11.4/8.11.3) id fBBIJPG25878; Tue, 11 Dec 2001 13:19:25 -0500 (EST) X-Authentication-Warning: beale.gw.tislabs.com: wgriffin set sender to wgriffin@tislabs.com using -f Date: Tue, 11 Dec 2001 13:19:25 -0500 From: Wes Griffin To: Rodney Thayer Cc: Darren J Moffat , sommerfeld@east.sun.com, ietf-ssh@netbsd.org Subject: Re: summary of Secure Shell (secsh) meeting at ietf52 Message-ID: <20011211131924.A20378@tislabs.com> References: <200112111732.fBBHWiXt023374@thunk.east.sun.com> <3C16488C.3090407@Sun.COM> <5.1.0.14.2.20011211105859.02f9c8b8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.2.20011211105859.02f9c8b8@127.0.0.1>; from rodney@tillerman.to on Tue, Dec 11, 2001 at 11:01:09AM -0700 Sender: ietf-ssh-owner@netbsd.org Precedence: list * Rodney Thayer [12/11/01 13:06]: > At the DNSEXT meeting, there was a (mildly surreal) exchange where > they attempted to not allow "yucky applications", like SSH, to > store keys in DNS. They claimed to want to dodge that work > by waiting until the apps asked for it, and when several people > in the room pointed out that people in the SSH wg were talking > about it, this got ignored. > > So I think we need to have something, requirements or whatever, > that we whack the DNSEXT wg with, so they know we're thinking > about it, regardless of what 'we' want to do. That is the idea, and what I'm in the process of doing, but for a larger group of applications, not just SSH. I was also told after the meeting, that I could gut the current draft and re-write it to keep the title, which I might infact do and turn it into a requirements document. Is that reasonable? > At 09:55 AM 12/11/2001 -0800, Darren J Moffat wrote: > >If I remeber correctly the author of the DNS host key storage draft > >said that the have no intention of continuting with it in its current > >form and that the draft will be left to expire unchanged. They wish > >to go back to requirements gathering and this may result in solving > >the problem space a different way (ie maybe not DNS as I gathered). -- Wes Griffin NAI Labs wgriffin at tislabs.com 443.259.2388 From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Dec 11 13:22:16 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22181 for ; Tue, 11 Dec 2001 13:22:16 -0500 (EST) Received: (qmail 3431 invoked by uid 605); 11 Dec 2001 18:22:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3422 invoked from network); 11 Dec 2001 18:22:14 -0000 Received: from ns2.pkiclue.com (HELO xena.pkiclue.com) (216.218.196.15) by mail.netbsd.org with SMTP; 11 Dec 2001 18:22:14 -0000 Received: from skylab3.tillerman.to (IDENT:root@localhost [127.0.0.1]) by xena.pkiclue.com (8.9.3/8.9.3) with ESMTP id KAA30379 for ; Tue, 11 Dec 2001 10:24:17 -0800 Message-Id: <5.1.0.14.2.20011211112121.02fb8678@127.0.0.1> X-Sender: rodney@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 11 Dec 2001 11:22:00 -0700 To: ietf-ssh@netbsd.org From: Rodney Thayer Subject: Re: summary of Secure Shell (secsh) meeting at ietf52 In-Reply-To: <20011211131924.A20378@tislabs.com> References: <5.1.0.14.2.20011211105859.02f9c8b8@127.0.0.1> <200112111732.fBBHWiXt023374@thunk.east.sun.com> <3C16488C.3090407@Sun.COM> <5.1.0.14.2.20011211105859.02f9c8b8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ietf-ssh-owner@netbsd.org Precedence: list works for me. At 01:19 PM 12/11/2001 -0500, Wes Griffin wrote: > > So I think we need to have something, requirements or whatever, > > that we whack the DNSEXT wg with, so they know we're thinking > > about it, regardless of what 'we' want to do. > >That is the idea, and what I'm in the process of doing, but for a larger >group of applications, not just SSH. I was also told after the meeting, >that I could gut the current draft and re-write it to keep the title, >which I might infact do and turn it into a requirements document. Is >that reasonable? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Dec 11 13:31:27 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22324 for ; Tue, 11 Dec 2001 13:31:27 -0500 (EST) Received: (qmail 5640 invoked by uid 605); 11 Dec 2001 18:31:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5632 invoked from network); 11 Dec 2001 18:31:24 -0000 Received: from watsun.cc.columbia.edu (128.59.39.2) by mail.netbsd.org with SMTP; 11 Dec 2001 18:31:24 -0000 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id NAA21684; Tue, 11 Dec 2001 13:31:18 -0500 (EST) Date: Tue, 11 Dec 2001 13:31:18 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Rodney Thayer Cc: Darren J Moffat , sommerfeld@east.sun.com, ietf-ssh@netbsd.org Subject: Re: summary of Secure Shell (secsh) meeting at ietf52 In-Reply-To: Your message of Tue, 11 Dec 2001 11:01:09 -0700 Message-ID: Sender: ietf-ssh-owner@netbsd.org Precedence: list DNS implementors are very concerned about the size of the zone files which will need to be protected by DNSSEC. I believe that this is the primary reason why any application specific information such as keys or certificates are desired to not be in DNS. > At the DNSEXT meeting, there was a (mildly surreal) exchange where > they attempted to not allow "yucky applications", like SSH, to > store keys in DNS. They claimed to want to dodge that work > by waiting until the apps asked for it, and when several people > in the room pointed out that people in the SSH wg were talking > about it, this got ignored. > > So I think we need to have something, requirements or whatever, > that we whack the DNSEXT wg with, so they know we're thinking > about it, regardless of what 'we' want to do. > > At 09:55 AM 12/11/2001 -0800, Darren J Moffat wrote: > >>and dns key storage both need a bit more work; we expect revised > >>drafts by the next IETF meeting. > > > > > >If I remeber correctly the author of the DNS host key storage draft > >said that the have no intention of continuting with it in its current > >form and that the draft will be left to expire unchanged. They wish > >to go back to requirements gathering and this may result in solving > >the problem space a different way (ie maybe not DNS as I gathered). > > > >I also volunteered to start a new draft for agent forwarding - > >requirements for this will be done via this list with at least an 00 > >draft by next meeting. > > > >-- > >Darren J Moffat > > > > > Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 Beta available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Dec 11 15:43:54 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24554 for ; Tue, 11 Dec 2001 15:43:53 -0500 (EST) Received: (qmail 27313 invoked by uid 605); 11 Dec 2001 20:43:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26624 invoked from network); 11 Dec 2001 20:42:28 -0000 Received: from ns2.pkiclue.com (HELO xena.pkiclue.com) (216.218.196.15) by mail.netbsd.org with SMTP; 11 Dec 2001 20:42:28 -0000 Received: from skylab3.tillerman.to (IDENT:root@localhost [127.0.0.1]) by xena.pkiclue.com (8.9.3/8.9.3) with ESMTP id MAA30944; Tue, 11 Dec 2001 12:44:19 -0800 Message-Id: <5.1.0.14.2.20011211133541.03d72348@127.0.0.1> X-Sender: rodney@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 11 Dec 2001 13:38:29 -0700 To: jaltman@columbia.edu From: Rodney Thayer Subject: Re: summary of Secure Shell (secsh) meeting at ietf52 Cc: ietf-ssh@netbsd.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ietf-ssh-owner@netbsd.org Precedence: list and protecting, for example, the ssh keys describing my routers is something I would consider high priority to store in my zone. In a world where google can keep 9,610 hits on "rodney thayer" I find it difficult to get excited about the cost of storing the ssh keys for my routing infrastructure servers, for example. But, the SSH-specific point, if there's consensus, is that there is a application user need for this, and that is the thing the DNSEXT group was asking for. At 01:31 PM 12/11/2001 -0500, Jeffrey Altman wrote: >DNS implementors are very concerned about the size of the zone files >which will need to be protected by DNSSEC. I believe that this is the >primary reason why any application specific information such as keys >or certificates are desired to not be in DNS. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Dec 11 18:54:34 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27818 for ; Tue, 11 Dec 2001 18:54:33 -0500 (EST) Received: (qmail 4320 invoked by uid 605); 11 Dec 2001 23:54:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4310 invoked from network); 11 Dec 2001 23:54:29 -0000 Received: from nic.crt.se (193.12.107.10) by mail.netbsd.org with SMTP; 11 Dec 2001 23:54:29 -0000 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id 862535288; Wed, 12 Dec 2001 00:54:28 +0100 (MET) Received: from crt.se (fonbella.crt.se [172.16.1.169]) by mail.crt.se (Postfix) with ESMTP id 1984A1DA3; Wed, 12 Dec 2001 00:54:26 +0100 (MET) Date: Wed, 12 Dec 2001 00:54:25 +0100 (MET) From: Jakob Schlyter To: Jeffrey Altman Cc: Rodney Thayer , Darren J Moffat , , Subject: Re: summary of Secure Shell (secsh) meeting at ietf52 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 11 Dec 2001, Jeffrey Altman wrote: > DNS implementors are very concerned about the size of the zone files > which will need to be protected by DNSSEC. I believe that this is the > primary reason why any application specific information such as keys or > certificates are desired to not be in DNS. this might be a problem for large TLDs, but I do not think this is a big issue for normal use. the zone files will increase in size, but will not grow out of what is manageable. jakob From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Dec 18 11:49:19 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21652 for ; Tue, 18 Dec 2001 11:49:18 -0500 (EST) Received: (qmail 17016 invoked by uid 605); 18 Dec 2001 16:49:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17008 invoked from network); 18 Dec 2001 16:49:10 -0000 Received: from fw.hel.fi.ssh.com (193.64.193.124) by mail.netbsd.org with SMTP; 18 Dec 2001 16:49:10 -0000 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id fBIGn8f16590 for ; Tue, 18 Dec 2001 18:49:09 +0200 (EET) Received: (qmail 12875 invoked from network); 18 Dec 2001 16:49:08 -0000 Received: from unknown (HELO localhost) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 18 Dec 2001 16:49:08 -0000 Date: Tue, 18 Dec 2001 17:49:10 +0200 (EET) From: X-Sender: jml@oma.koti.fi To: ietf-ssh@netbsd.org Subject: Comment on drafts in last call Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Regarding the Secure Shell I-D's presently in WG Last Call: The name "SSH" is, and always has been, a major identifier of SSH Communications Security Corp. To protect the identifier in commercial settings, we have obtained trademark registration for the name in the United States, Europe, and Japan. The Secure Shell protocol has often been referred to with the name "SSH". This has not always been a source of confusion, as until some time ago we were the only major source of products associated with the Secure Shell protocol. Another reason adding to the confusion is that the user base of Secure Shell products has only recently grown well outside the group of early adopters who know the technology and the field. Presently, with the user base continually growing, the confusion of the protocol and a major participant in the field is real and increasing. We note that the confusion affects all producers of Secure Shell products - we often get the blame as well as the praise for products made by others. This is not a benefit for anyone. Official names in standard documents have a large influence on the usage of terms in everyday practice. Therefore, we present the wish that the IETF would not elect to support the present situation and the continuing increase in the confusion. We note that RFC 2026, section 10.1, states that In all matters of intellectual property rights and procedures, the intention is to benefit the Internet community and the public at large, while respecting the legitimate rights of others. To minimize the confusion and to reach the objectives of that section, we propose that the official name of the protocol - which is defined by the titles of the corresponding Internet Drafts - be changed to refer to "Secure Shell". Markus Levlin Intellectual Property Rights Manager SSH Communications Security Corp From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Dec 18 14:36:10 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24855 for ; Tue, 18 Dec 2001 14:36:09 -0500 (EST) Received: (qmail 25113 invoked by uid 605); 18 Dec 2001 19:36:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25106 invoked from network); 18 Dec 2001 19:36:04 -0000 Received: from 12-232-138-154.client.attbi.com (HELO heebiejeebies.maybe.org) (12.232.138.154) by mail.netbsd.org with SMTP; 18 Dec 2001 19:36:04 -0000 Received: by heebiejeebies.maybe.org (Postfix, from userid 1000) id DC6F01BDDE; Tue, 18 Dec 2001 11:36:03 -0800 (PST) Date: Tue, 18 Dec 2001 11:36:03 -0800 From: Dale Harris To: ietf-ssh@netbsd.org Subject: Re: Comment on drafts in last call Message-ID: <20011218193603.GB11533@maybe.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Dec 18, 2001 at 05:49:10PM +0200, jml@ssh.com elucidated: > > Regarding the Secure Shell I-D's presently in WG Last Call: > > The name "SSH" is, and always has been, a major identifier of SSH > Communications Security Corp. To protect the identifier in commercial > settings, we have obtained trademark registration for the name in the > United States, Europe, and Japan. > > The Secure Shell protocol has often been referred to with the name > "SSH". This has not always been a source of confusion, as until some > time ago we were the only major source of products associated with the > Secure Shell protocol. Another reason adding to the confusion is that > the user base of Secure Shell products has only recently grown well > outside the group of early adopters who know the technology and the > field. > I have a question. Once the term "ssh" has been used a port name identifier in our /etc/services for years and years, and that tag has been in the public domain for such a long time that a trademark wouldn't necessarily be enforceable? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dale Harris GPG key: 372FBD57 http://www.maybe.org/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Dec 18 14:45:23 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25067 for ; Tue, 18 Dec 2001 14:45:22 -0500 (EST) Received: (qmail 26905 invoked by uid 605); 18 Dec 2001 19:45:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26898 invoked from network); 18 Dec 2001 19:45:19 -0000 Received: from becasse.cs.stevens-tech.edu (155.246.89.38) by mail.netbsd.org with SMTP; 18 Dec 2001 19:45:19 -0000 Received: by becasse.cs.stevens-tech.edu (Postfix, from userid 3330) id 050931C005; Tue, 18 Dec 2001 14:45:10 -0500 (EST) Date: Tue, 18 Dec 2001 14:45:10 -0500 From: Thor Simon To: ietf-ssh@netbsd.org Cc: poised@lists.tislabs.com, tls@rek.tjls.com Subject: Re: Comment on drafts in last call Message-ID: <20011218144510.A22744@cs.stevens-tech.edu> Reply-To: tls@rek.tjls.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jml@ssh.com on Tue, Dec 18, 2001 at 05:49:10PM +0200 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Dec 18, 2001 at 05:49:10PM +0200, jml@ssh.com wrote: > > Regarding the Secure Shell I-D's presently in WG Last Call: > > The name "SSH" is, and always has been, a major identifier of SSH > Communications Security Corp. To protect the identifier in commercial > settings, we have obtained trademark registration for the name in the > United States, Europe, and Japan. Hey, look! Their low-quality, high-priced lawyers told them to "assert their trademark rights" again in Yet Another feeble attempt to cover up the fact that they screwed up. Once more, folks, the real deal on this: 1) They have no trademark on "ssh" nor on "SSH". They have only a trademark on *one particular typed representation* of the letters "ssh", as used in their corporate logo. 2) They have fraudulently claimed here and elsewhere that they own the name "ssh" and that nobody else can use it, when in fact they own only the rights to one particular drawing of those glyphs. 3) They have wasted countless time, effort, and money of the other participants in this working group with specious threats of legal action here and elsewhere. Unfortunately, even their own law firm admits, in those very threats, that: 4) "SSH" is an abbreviation for "Secure Shell", and thus... 5) "SSH" cannot be trademarked, as abbreviations cannot be trademarked. Need I mention that 6) "Secure Shell" is a generic term, which cannot be trademarked, thus rendering this whole debate even more idiotic? I have supplied copious documentation of all of these points both in this forum and (with the help of Jason Thorpe) at an IETF meeting. This documentation has included copies of all trademark files, with full history, for any mark containing "ssh" in its description, as well as copies of extensive correspondence with attorneys, including the "smoking gun" letter in which SSH's own counsel admits that "ssh" is an abbreviation. As evidence of further duplicity, while originally attempting to coerce this working group into changing the name of the protocol to "Secure Shell", these same parties had a *pending trademark application for "Secure Shell"*. This kind of continued harassment of other IETF participants is completely unconscionable. It is *precisely* why the IETF should have a policy requiring authors or editors of standards-track documents to disclaim trademark rights to the words used in the document title and to the protocol name. Unfortunately, when I last brought this up in POISSON, which our WG chair suggested was the proper forum for these concerns, I was pretty much shouted down. Perhaps the continued existence of the problem (unethical draft authors/editors naming protocols/standards so as to set up intellectual property ambushes for other implementors) will serve to help persuade that the problem is real, and that some solution needs to be found. For the moment, it would be nice if *this particular* harassment would stop, before it wastes enough of my time and money that it becomes economical for me to simply seek a declaratory judgement to shut these idiots up. My lawyer is a nice guy and I don't like wasting his time dealing with the corporate drone morons who are milking SSH Comm Oy for billable hours after their own mistakes have helped make their own client's position not only unethical, but also totally untenable. Thor From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Dec 18 19:15:11 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01290 for ; Tue, 18 Dec 2001 19:15:10 -0500 (EST) Received: (qmail 927 invoked by uid 605); 19 Dec 2001 00:15:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 920 invoked from network); 19 Dec 2001 00:15:01 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 19 Dec 2001 00:15:01 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 411818 for ietf-ssh@netbsd.org; Tue, 18 Dec 2001 17:19:38 -0700 Message-ID: <00c401c18822$2bf50cb0$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: Subject: userauth and multiple simultaneous requests... Date: Tue, 18 Dec 2001 17:14:48 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Just before the meeting in SLC, I discovered a flaw in the userauth protocol while reviewing outstanding issues for the gss draft, and we spent some time discussing this at the meeting. I was asked to summarize the problem for the list -- I've since reread the userauth draft and am not sure if the problem really exists. So, here goes -- The problem, as discussed in the meeting, is that the client is allowed to send multiple outstanding requests. So, lets say there is an authentication method "x", which requires multiple messages to be sent, and uses message number 61 for the server to request additional information from the client, which is sent by the client using message number 62. Let's also say there is a different method, "y", which also uses message number 61 for the server to request additional information from the client, and message number 62 for the client to send that information. So, if the client sends "x" and then "y", the server will respond to "x" with a message 61 and than to y with a packet type 61. Now the client sends a packet 62 to the server. However, the server has no way to determine if packet 62 goes with request "x" or request "y". ---- Now, for the relevant texts from the draft, that make this impossible, and make the problem (mostly) go away: The userauth draft contains the following text in section 2.1: An authentication request MAY result in a further exchange of messages. All such messages depend on the authentication method used, and the client MAY at any time continue with a new SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST abandon the previous authentication attempt and continue with the new one. and in 2.2: The client MAY send several authentication requests without waiting for responses from previous requests. The server MUST acknowledge any failed requests with a SSH_MSG_USERAUTH_FAILURE message. However, SSH_MSG_USERAUTH_SUCCESS MUST be sent only once, and once SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication requests received after that SHOULD be silently ignored. So as soon as the client sends "y", the server discards "x". --- The only real problem is that it is unclear what should happen in the event that a implementation receives "y" before it has finished processing "x" -- in most unix implementations this isn't possible, but in a NT implementation it is much more likely (to be possible.) Should the server discard (and fail) "x", aborting any processing being done on it, or, should it finish processing "x" and then only process "y" if "x" wasn't sufficient to authenticate the user? I would suggest the following wording change for section 2.2: The client MAY send several authentication requests without waiting for responses from previous requests. The server MUST process each request completely and acknowledge any failed requests with a SSH_MSG_USERAUTH_FAILURE message before processing the next request. A request that results in further exchange of messages will be aborted by second request, so it is not possible to send a second request without waiting for a response from the server, if the first request will result in further exchange of messages. No SSH_MSG_USERAUTH_FAILURE message will be sent for the aborted method. SSH_MSG_USERAUTH_SUCCESS MUST be sent only once, and once SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication requests received after that SHOULD be silently ignored. This clarifies that the SSH_MSG_USERAUTH_REQUEST packet must be completely processed before considering further requests (which might abort the method started by the SSH_MSG_USERAUTH_REQUEST packet.) And that if a method is abandoned due to a new SSH_MSG_USERAUTH_REQUEST being received, there is no notification of such to the client. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Dec 18 19:24:12 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01589 for ; Tue, 18 Dec 2001 19:24:11 -0500 (EST) Received: (qmail 2294 invoked by uid 605); 19 Dec 2001 00:24:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2285 invoked from network); 19 Dec 2001 00:24:10 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 19 Dec 2001 00:24:10 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06800; Tue, 18 Dec 2001 17:23:51 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17394; Tue, 18 Dec 2001 19:24:08 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBJ0O8Xt010469; Tue, 18 Dec 2001 19:24:08 -0500 (EST) Message-Id: <200112190024.fBJ0O8Xt010469@thunk.east.sun.com> From: Bill Sommerfeld To: "Joseph Galbraith" cc: ietf-ssh@netbsd.org Subject: Re: userauth and multiple simultaneous requests... In-Reply-To: Your message of "Tue, 18 Dec 2001 17:14:48 MST." <00c401c18822$2bf50cb0$2800a8c0@test.vandyke.com> Reply-to: sommerfeld@east.sun.com Date: Tue, 18 Dec 2001 19:24:08 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list A couple comments on the wording: A request that results in further exchange of messages will be aborted by second request by "a" second request ? so it is not possible to send a second request without waiting for a response from the server, if the first request will Perhaps "may" here? Userauth requests could involve variable numbers of messages (GSSAPI is notorious for this). result in further exchange of messages. No SSH_MSG_USERAUTH_FAILURE message will be sent for the aborted method. SSH_MSG_USERAUTH_SUCCESS MUST be sent only once, and once SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication requests received after that SHOULD be silently ignored. Is there any good reason why the second SHOULD shouldn't be a MUST? Doesn't seem like it should be hard to get this right.. is there deployed code which gets this wrong? - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Dec 18 21:07:57 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03422 for ; Tue, 18 Dec 2001 21:07:57 -0500 (EST) Received: (qmail 19038 invoked by uid 605); 19 Dec 2001 02:07:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19030 invoked from network); 19 Dec 2001 02:07:55 -0000 Received: from smtp6.andrew.cmu.edu (128.2.10.86) by mail.netbsd.org with SMTP; 19 Dec 2001 02:07:55 -0000 Received: from MANTICORE.ANDREW.CMU.EDU (MANTICORE.ANDREW.CMU.EDU [128.2.122.204]) (user=jhutz mech=KERBEROS_V4 (0 bits)) by smtp6.andrew.cmu.edu (8.12.2.Beta1/8.12.2.Beta1) with ESMTP id fBJ27olV004352; Tue, 18 Dec 2001 21:07:50 -0500 Date: Tue, 18 Dec 2001 21:07:49 -0500 (EST) From: Jeffrey Hutzelman X-X-Sender: jhutz@manticore.andrew.cmu.edu To: jml@ssh.com cc: ietf-ssh@netbsd.org Subject: Re: Comment on drafts in last call In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 18 Dec 2001 jml@ssh.com wrote: > To minimize the confusion and to reach the objectives of that section, we > propose that the official name of the protocol - which is defined by the > titles of the corresponding Internet Drafts - be changed to refer to > "Secure Shell". This proposal has been made and rejected by the working group. IMHO it is not worth our time to discuss it again. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Dec 19 06:21:50 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26983 for ; Wed, 19 Dec 2001 06:21:50 -0500 (EST) Received: (qmail 10079 invoked by uid 605); 19 Dec 2001 11:21:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10060 invoked from network); 19 Dec 2001 11:21:45 -0000 Received: from sockittome.aldigital.co.uk (HELO scuzzy.ben.algroup.co.uk) (194.128.162.252) by mail.netbsd.org with SMTP; 19 Dec 2001 11:21:45 -0000 Received: from algroup.co.uk (wiese.ben.algroup.co.uk [193.133.15.150]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 4C9F813608; Wed, 19 Dec 2001 11:21:43 +0000 (GMT) Message-ID: <3C207847.2463D3C6@algroup.co.uk> Date: Wed, 19 Dec 2001 11:21:43 +0000 From: Ben Laurie X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: tls@rek.tjls.com Cc: ietf-ssh@netbsd.org, poised@lists.tislabs.com Subject: Re: Comment on drafts in last call References: <20011218144510.A22744@cs.stevens-tech.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Thor Simon wrote: > This kind of continued harassment of other IETF participants is completely > unconscionable. It is *precisely* why the IETF should have a policy > requiring authors or editors of standards-track documents to disclaim > trademark rights to the words used in the document title and to the protocol > name. Unfortunately, when I last brought this up in POISSON, which our WG > chair suggested was the proper forum for these concerns, I was pretty much > shouted down. Perhaps POISSON is a red herring? :-) Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Dec 20 14:27:56 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17849 for ; Thu, 20 Dec 2001 14:27:56 -0500 (EST) Received: (qmail 25883 invoked by uid 605); 20 Dec 2001 19:27:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25876 invoked from network); 20 Dec 2001 19:27:52 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 20 Dec 2001 19:27:52 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 417902; Thu, 20 Dec 2001 12:32:33 -0700 Message-ID: <000b01c1898c$5fb70060$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: Cc: References: <200112190024.fBJ0O8Xt010469@thunk.east.sun.com> Subject: Re: userauth and multiple simultaneous requests... Date: Thu, 20 Dec 2001 12:27:33 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > A couple comments on the wording: > > A request that results in further exchange of messages > will be aborted by second request > > by "a" second request ? Yep. > so it is not possible > to send a second request without waiting for a response > from the server, if the first request will > > Perhaps "may" here? Userauth requests could involve variable numbers > of messages (GSSAPI is notorious for this). I think the "if" in "if the first" reflect the conditional nature of this -- I guess I'm not sure where "may" would be put -- it doesn't really make sense as in "if the first request may" does it? > SSH_MSG_USERAUTH_SUCCESS MUST be sent only once, and once > SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication > requests received after that SHOULD be silently ignored. > > Is there any good reason why the second SHOULD shouldn't be a MUST? > Doesn't seem like it should be hard to get this right.. is there > deployed code which gets this wrong? Well -- I consider it a bug, but I believe our implementation currently would probably send a unimplemented packet, or possible disconnect. In fact, a SHOULD at least leaves the door open for a client / server to refresh expired credentials by later sending additional USERAUTH request messages -- though there is currently no way for the server to notify the client that this is necessary. (I'm not actually sure this feature is necessary.) - Joseph