From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Aug 1 20:02:08 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03542 for ; Sun, 1 Aug 2004 20:02:07 -0400 (EDT) Received: (qmail 5316 invoked by uid 605); 1 Aug 2004 23:59:15 -0000 Delivered-To: ietf-ssh@netbsd.org Date: 1 Aug 2004 23:59:15 -0000 Message-ID: <20040801235915.5313.qmail@mail.netbsd.org> From: alias@NetBSD.org Cc: recipient list not shown: ; Received: (qmail 5244 invoked from network); 1 Aug 2004 23:59:11 -0000 Received: from unknown (HELO 222.117.215.9) (222.117.215.9) by mail.netbsd.org with SMTP; 1 Aug 2004 23:59:10 -0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 2 09:19:50 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05409 for ; Mon, 2 Aug 2004 09:19:50 -0400 (EDT) Received: (qmail 3434 invoked by uid 605); 2 Aug 2004 13:19:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3399 invoked from network); 2 Aug 2004 13:19:46 -0000 Received: from smtp.cs.auckland.ac.nz (130.216.33.151) by mail.netbsd.org with SMTP; 2 Aug 2004 13:19:45 -0000 Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id DB36B1CD8A8; Tue, 3 Aug 2004 01:17:08 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.32) id 1BrcjF-0001tI-0y; Tue, 03 Aug 2004 01:19:49 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: galb-list@vandyke.com, pgut001@cs.auckland.ac.nz Subject: Re: Invalid channel numbers Cc: ietf-ssh@NetBSD.org, mouse@Rodents.Montreal.QC.CA In-Reply-To: <410BD17A.5080607@vandyke.com> Message-Id: Date: Tue, 03 Aug 2004 01:19:49 +1200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Joseph Galbraith writes: >The channel number is part of the packet that is predefined. Therefore, you >can always parse the channel number, and send the response. What if it's a channel open where the packet ends halfway through the channel number? You've got a request, there seems to be a requirement to send a response, but you can't respond without some facility that lets you say "The last channel-related request was disallowed". Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 2 09:51:53 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07462 for ; Mon, 2 Aug 2004 09:51:53 -0400 (EDT) Received: (qmail 26994 invoked by uid 605); 2 Aug 2004 13:40:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26966 invoked from network); 2 Aug 2004 13:40:56 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 2 Aug 2004 13:40:56 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 49F4B433D0; Mon, 2 Aug 2004 15:40:49 +0200 (CEST) Message-ID: <410E46B2.3020105@siliconcircus.com> Date: Mon, 02 Aug 2004 15:50:42 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Gutmann Cc: galb-list@vandyke.com, ietf-ssh@NetBSD.org, mouse@Rodents.Montreal.QC.CA Subject: Re: Invalid channel numbers References: In-Reply-To: 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 Hi, Peter Gutmann wrote: > Joseph Galbraith writes: > > >>The channel number is part of the packet that is predefined. Therefore, you >>can always parse the channel number, and send the response. > > > What if it's a channel open where the packet ends halfway through the channel > number? You've got a request, there seems to be a requirement to send a > response, but you can't respond without some facility that lets you say "The > last channel-related request was disallowed". This seems broken enough to just close the connection - it's not in accordance with the current spec, or any future possible altered spec. If you're really eager not to close the connection, sending an SSH_MSG_UNIMPLEMENTED might be a reasonable alternative. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 2 10:08:01 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08292 for ; Mon, 2 Aug 2004 10:08:00 -0400 (EDT) Received: (qmail 16912 invoked by uid 605); 2 Aug 2004 14:00:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16897 invoked from network); 2 Aug 2004 14:00:24 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 2 Aug 2004 14:00:23 -0000 Received: from folly.informatik.uni-erlangen.de (localhost [127.0.0.1]) by faui03.informatik.uni-erlangen.de (8.12.9/8.12.9) with ESMTP id i72Di5rP028672; Mon, 2 Aug 2004 13:44:06 GMT Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 2FCFBF192; Mon, 2 Aug 2004 15:44:04 +0200 (CEST) Date: Mon, 2 Aug 2004 15:44:04 +0200 From: Markus Friedl To: Peter Gutmann Cc: galb-list@vandyke.com, ietf-ssh@NetBSD.org, mouse@Rodents.Montreal.QC.CA Subject: Re: Invalid channel numbers Message-ID: <20040802134403.GA29447@folly> References: <410BD17A.5080607@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Aug 03, 2004 at 01:19:49AM +1200, Peter Gutmann wrote: > Joseph Galbraith writes: > > >The channel number is part of the packet that is predefined. Therefore, you > >can always parse the channel number, and send the response. > > What if it's a channel open where the packet ends halfway through the channel > number? if you get a completely corrupt message, why not send a SSH_DISCONNECT_PROTOCOL_ERROR? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 2 10:19:50 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09820 for ; Mon, 2 Aug 2004 10:19:50 -0400 (EDT) Received: (qmail 29476 invoked by uid 605); 2 Aug 2004 14:12:14 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20040802141213.29473.qmail@mail.netbsd.org> Received: (qmail 29364 invoked from network); 2 Aug 2004 14:12:08 -0000 Received: from 201009086169.user.veloxzone.com.br (HELO mail.com) (201.9.86.169) by mail.netbsd.org with SMTP; 2 Aug 2004 14:12:08 -0000 From: "Cristina Oliveira" To: Subject: Cartas comerciais 400 Modelos prontos Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Mon, 2 Aug 2004 11:12:29 -0300 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Indicado para: secretárias em geral, gerências, Rh, executivos, estudantes, empresas de toda ordem, etc. O custo é ínfimo em relação ao que poderá gerar no aperfeiçoamento da comunicação de sua empresa. http://www.gueb.de/cartascomerciais As cartas comerciais, têm grande importância na administração de qualquer empreendimento, pois uma parte significativa das transações mundiais se realiza por esse meio. A carta é o instrumento que faz a conexão entre os negociantes. http://www.gueb.de/cartascomerciais Estamos lançando o CD MODELOS DE CARTAS COMERCIAIS, que sana suas dúvidas na elaboração de todos os tipos de cartas e documentos empresariais: agradecimentos, atestados e declarações, avisos, cartas de cobrança, cartas em inglês, comunicados, convites, contratos, propostas, empregos, solicitações e pedidos, telegramas, cartas por e-mail, etc. http://www.gueb.de/cartascomerciais O CD contém mais de 400 modelos de Cartas Comerciais e inúmeras técnicas de Redação Comercial. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 2 10:39:35 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11201 for ; Mon, 2 Aug 2004 10:39:35 -0400 (EDT) Received: (qmail 24114 invoked by uid 605); 2 Aug 2004 14:33:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24065 invoked from network); 2 Aug 2004 14:33:18 -0000 Received: from smtp.cs.auckland.ac.nz (130.216.33.151) by mail.netbsd.org with SMTP; 2 Aug 2004 14:33:18 -0000 Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 3A1681CD870; Tue, 3 Aug 2004 02:30:44 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.32) id 1BrdsT-0001wd-3D; Tue, 03 Aug 2004 02:33:25 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jon@siliconcircus.com, pgut001@cs.auckland.ac.nz Subject: Re: Invalid channel numbers Cc: galb-list@vandyke.com, ietf-ssh@NetBSD.org, mouse@Rodents.Montreal.QC.CA In-Reply-To: <410E46B2.3020105@siliconcircus.com> Message-Id: Date: Tue, 03 Aug 2004 02:33:25 +1200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Jon Bright writes: >If you're really eager not to close the connection, sending an >SSH_MSG_UNIMPLEMENTED might be a reasonable alternative. Yeah, I guess that would do. The reason why I'd prefer not to close the connection outright is that there might he half a dozen data transfers currently in progress, and I'd prefer not to abort them all just because of one malformed packet on an unrelated channel. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 2 11:01:32 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12102 for ; Mon, 2 Aug 2004 11:01:32 -0400 (EDT) Received: (qmail 24784 invoked by uid 605); 2 Aug 2004 15:01:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24747 invoked from network); 2 Aug 2004 15:01:10 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 2 Aug 2004 15:01:10 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 1Bre30-0001Wb-00; Mon, 02 Aug 2004 15:44:18 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@NetBSD.org In-Reply-To: Subject: Re: Invalid channel numbers Message-Id: Date: Mon, 02 Aug 2004 15:44:18 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Peter Gutmann wrote: > Yeah, I guess that would do. The reason why I'd prefer not to close the > connection outright is that there might he half a dozen data transfers > currently in progress, and I'd prefer not to abort them all just because of > one malformed packet on an unrelated channel. The question is, though, why would you _get_ such a malformed packet? The SSH data channel is required to be free of corruption and data loss (and the MACs enforce this vigorously), so it's not as if half of an SSH message is going to routinely disappear en route. The only way it can happen is as a result of a pretty fundamental bug in the SSH implementation at the far end. Therefore, it isn't unreasonable to assume that an SSH implementation which has sent you a packet that badly formed is in a state of total internal confusion, and to terminate the connection before it sends you any more plausible rubbish that you might accidentally trust! I can't imagine any situation in which this sort of error condition would occur routinely, such that it would make sense to spend effort on salvaging everything possible from the rest of the SSH connection. It really ought to only ever occur when the client or server is in development, in which case you weren't transferring any important data through it anyway. -- Simon Tatham What do we want? ROT13! When do we want it? ABJ! From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 2 14:19:46 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24364 for ; Mon, 2 Aug 2004 14:19:44 -0400 (EDT) Received: (qmail 15785 invoked by uid 605); 2 Aug 2004 18:19:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15773 invoked from network); 2 Aug 2004 18:19:40 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 2 Aug 2004 18:19:40 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i72IJLil019944; Mon, 2 Aug 2004 12:19:33 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i72IJJii018073; Mon, 2 Aug 2004 14:19:20 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i72IJJHs016107; Mon, 2 Aug 2004 14:19:19 -0400 (EDT) Message-Id: <200408021819.i72IJJHs016107@thunk.east.sun.com> From: Bill Sommerfeld To: pgut001@cs.auckland.ac.nz (Peter Gutmann) cc: galb-list@vandyke.com, ietf-ssh@NetBSD.org, mouse@Rodents.Montreal.QC.CA Subject: Re: Invalid channel numbers In-Reply-To: Your message of "Tue, 03 Aug 2004 01:19:49 +1200." Reply-to: sommerfeld@east.sun.com Date: Mon, 02 Aug 2004 14:19:19 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > What if it's a channel open where the packet ends halfway through the channel > number? You've got a request, there seems to be a requirement to send a > response, but you can't respond without some facility that lets you say "The > last channel-related request was disallowed". so, my sense is that there will always be a level of peer-brokenness for which the only possible recovery is for the implementation to throw up its virtual hands and give up. This bit of the protocol runs on top of an integrity-protected channel; a parse error either indicates a buggy peer, buggy integrity protection, or a bug in your own implementation, and distinguishing these cases is hard. exactly how hard you try to keep going before that is something of a quality-of-implementation issue. dropping the connection seems like an entirely reasonable response.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 2 14:29:45 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25194 for ; Mon, 2 Aug 2004 14:29:44 -0400 (EDT) Received: (qmail 22768 invoked by uid 605); 2 Aug 2004 18:27:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22621 invoked from network); 2 Aug 2004 18:27:37 -0000 Received: from mail-in-03.arcor-online.net (151.189.21.43) by mail.netbsd.org with SMTP; 2 Aug 2004 18:27:37 -0000 Received: from folly.informatik.uni-erlangen.de (dsl-213-023-023-019.arcor-ip.net [213.23.23.19]) by mail-in-03.arcor-online.net (Postfix) with ESMTP id 76F3437988; Mon, 2 Aug 2004 20:27:35 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 5320EF192; Mon, 2 Aug 2004 17:41:23 +0200 (CEST) Date: Mon, 2 Aug 2004 17:41:23 +0200 From: Markus Friedl To: Simon Tatham Cc: ietf-ssh@NetBSD.org Subject: Re: Invalid channel numbers Message-ID: <20040802154122.GA26662@folly> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Aug 02, 2004 at 03:44:18PM +0100, Simon Tatham wrote: > Peter Gutmann wrote: > > Yeah, I guess that would do. The reason why I'd prefer not to close the > > connection outright is that there might he half a dozen data transfers > > currently in progress, and I'd prefer not to abort them all just because of > > one malformed packet on an unrelated channel. > > The question is, though, why would you _get_ such a malformed > packet? The SSH data channel is required to be free of corruption > and data loss (and the MACs enforce this vigorously), so it's not as > if half of an SSH message is going to routinely disappear en route. > The only way it can happen is as a result of a pretty fundamental > bug in the SSH implementation at the far end. > > Therefore, it isn't unreasonable to assume that an SSH > implementation which has sent you a packet that badly formed is in a > state of total internal confusion, and to terminate the connection > before it sends you any more plausible rubbish that you might > accidentally trust! i can only agree with you, and this is why i'd prefer SSH_DISCONNECT_PROTOCOL_ERROR. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 4 07:37:22 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28287 for ; Wed, 4 Aug 2004 07:37:21 -0400 (EDT) Received: (qmail 14657 invoked by uid 605); 4 Aug 2004 11:29:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14631 invoked from network); 4 Aug 2004 11:29:05 -0000 Received: from unknown (HELO LocalHost) (164.100.60.247) by mail.netbsd.org with SMTP; 4 Aug 2004 11:29:01 -0000 Message-ID: From: hw.geitz@_chello.nl.cnri.reston.va.us To: ietf-ssh@NetBSD.org Subject: YOUR EMAIL ADDRESS HAS BEEN ADDED TO MY WHITE LIST Date: Wed, 04 Aug 2004 17:05:32 +0530 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Your email address has been added to my Spam Fighter White List. Adding your address to the White List ensures that I will always receive email you send to me. If you aren't using All-in-One SECRETMAKER, I recommend that you examine this powerful freeware. I recommend All-in-One SECRETMAKER software to all my friends and email contacts. This compact, smart tool includes Spam Fighter, Pop-Up Killer, Banner Blocker, Cookie Eraser, History Cleaner, Privacy Protector and more. Innovative new features, with many refinements, are presently being tested. All-in-One SECRETMAKER has been downloaded and restored Internet privacy for thousands of satisfied users. More detailed information about the All-in-One SECRETMAKER can be found at the SECRETMAKER home page, located at: WWW.SECRETMAKER.COM (copy / paste the URL in to your browser) If you would like to turn email and surfing the Web into a pleasant and secure experience once again, you can download the totally free All-in-One SECRETMAKER at WWW.SECRETMAKER.COM/DOWNLOADS/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 4 12:42:31 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17346 for ; Wed, 4 Aug 2004 12:42:30 -0400 (EDT) Received: (qmail 25590 invoked by uid 605); 4 Aug 2004 16:42:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25581 invoked from network); 4 Aug 2004 16:42:26 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by mail.netbsd.org with SMTP; 4 Aug 2004 16:42:26 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 04 Aug 2004 09:44:58 +0000 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i74GgNmY019155 for ; Wed, 4 Aug 2004 09:42:23 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA27326 for ; Wed, 4 Aug 2004 09:42:24 -0700 (PDT) Date: Wed, 4 Aug 2004 09:42:24 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, I was hoping that this was a closed issue but I believe that Tero knows something about this subject. Can we have some discussion on this? I'd like to try to come to some consensus around one of the following: - Tero knows of what he is saying and we need to adjust our wording. - Tero knows of what he is saying but what we now have is good enough for our purposes. - "And now for something entirely different..." Thanks, Chris ---------- Forwarded message ---------- Date: Wed, 4 Aug 2004 01:28:35 +0300 (EEST) From: Tero Kivinen To: Chris Lonvick Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal [I am not normally following secsh list, I am just reading last few hundred emails, because I am bored in the PMTUD meeting, and I am going through all ietf mailing list, so I do not send this directly to the list (probably wouldn't go through because of spam filters), you can forward this to the list if you feel like so. I will not be reading the list again in near future, so I will not see any replies to my email in few months...] Chris Lonvick writes: > diffie-hellman-group1-sha1 REQUIRED > diffie-hellman-group14-sha1 REQUIRED I think the group14 is very misleading. The number 14 is from the IANA number allocated for the IKE to the "2048-bit MODP group" of the RFC 3526. (http://www.iana.org/assignments/ipsec-registry). The next revision of the RFC 3526 might not have the numbers at all, or the numbers might be different. Also IPsec WG might decide to change the numbers if they want to do it. It would be same as renaming the 3des-cbc with cipher5 etc... > Additional methods may be defined as specified in [SSH-NUMBERS]. > Note that, for historical reasons, the name > "diffie-hellman-group1-sha1" is used for a key exchange method > using > Oakley Group 2. This is considered an aberration and should not > be It happens to use the same group that is also used in the IPsec and there it has been allocated number 2 from the IANA... There is no reason why secsh should use the IPsec IANA registry for the numbers. > repeated. Any future specifications of Diffie Hellman key > exchange > using Oakley groups defined in [RFC2412] or its successors should > be > named using the group numbers assigned by IANA, and names of the > form > "diffie-hellman-groupN-sha1" should be reserved for this purpose. Note, that group 14 is NOT oakley group. It is not defined in the RFC2412, and the RFC 3526 does not use name oakley group anywhere. The IANA registry for IKE (ipsec-registry) allocates the numbers for those groups. > 8.2 diffie-hellman-group14-sha1 > > The "diffie-hellman-group14-sha1" method specifies Diffie-Hellman > key > exchange with SHA-1 as HASH, and Oakley Group 14 [RFC3526] > (2048bit > MODP Group), and it MUST also be supported. Oakley group 14 is very misleading and plainly wrong. Any groups defined in the RFC3526 are not oakley groups. They do not have anything to do with the oakley document. The "2048-bit MODP group" group defined in the RFC3526 has been allocated number 14 in the IPsec/IKE registry, but secsh should be using their own registries, not to share the IKE registry. Note, that IKEv2 will have its own registry for the groups, and that registry might not be kept sync with the IKEv1 registry of groups. > Please send back your comments to this proposal. -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 4 13:15:00 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19918 for ; Wed, 4 Aug 2004 13:15:00 -0400 (EDT) Received: (qmail 23039 invoked by uid 605); 4 Aug 2004 17:13:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22980 invoked from network); 4 Aug 2004 17:13:39 -0000 Received: from sj-iport-4.cisco.com (171.68.10.86) by mail.netbsd.org with SMTP; 4 Aug 2004 17:13:39 -0000 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i74GwoLl010450 for ; Wed, 4 Aug 2004 09:58:51 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA18379 for ; Wed, 4 Aug 2004 09:58:50 -0700 (PDT) Date: Wed, 4 Aug 2004 09:58:50 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: Transport messages during kex In-Reply-To: <20040723132334.GA21109@chiark.greenend.org.uk> Message-ID: References: <20040723132334.GA21109@chiark.greenend.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi Everyone, Is everyone OK with the following proposal? - Integrate Jacob's replacement Section 7.1 from below. - Integrate Jacob's text in other parts of the document as noted in http://www.chiark.greenend.org.uk/~jacobn/2004/07/ssh2-kex-data-diff.html If I don't hear objections, then I'll incorporate those changes into [TRANS]. Thanks, Chris On Fri, 23 Jul 2004, Jacob Nevins wrote: > Jeffrey Hutzelman writes: > > > On Wednesday, July 21, 2004 12:26:06 +0100 Jacob Nevins > > wrote: > > > > > Jeffrey Hutzelman writes: > > >> And what's wrong with other (not yet defined) messages in the 20-29 > > >> range? Without these, it will become difficult to extend algorithm > > >> negotiation, which I know we've discussed in the past. > > > > > > In principle yes, but at this point I'd be inclined to defer resolving > > > this to such time as such extensions are actually defined. > > > > That doesn't help. The issue is that in order to extend the exchange in > > the future, an new peer needs to be able to send a not-yet-defined message > > to an old peer and get SSH_MSG_UNIMPLEMENTED back. In order for that to > > work, old peers must accept the not-yet-defined message and return > > SSH_MSG_UNIMPLEMENTED, rather than ignoring the not-yet-defined message or > > deciding to disconnect (either of which would appear to be OK -- we don't > > define what happens if you get a message that you MUST NOT accept). > [snip other explanation] > > OK, you've convinced me. How does the following replacement Section 7.1 > paragraph for my proposal sound?: > > Once a party has sent a KEXINIT message for key exchange or > re-exchange, until is has sent a NEWKEYS message (Section 7.3), it > MUST NOT send any messages other than: > o Transport layer generic messages (1 to 19) (but SERVICE_REQUEST > and SERVICE_ACCEPT MUST NOT be sent); > o Algorithm negotiation messages (20 to 29) (but further KEXINITs > MUST NOT be sent); > o Key exchange method specific messages (30 to 49). > The provisions of Section 11 apply for unrecognised messages, etc. > > (the rest of my proposal is unchanged; see it in full at > > or > > To attempt to address Derek Fawcus' comments elsewhere: I don't believe > this precludes the future implementation of a non-blocking rekey > extension. (I'd have thought the obvious way to do that would be to > substitute a new KEXINIT_NONBLOCK in the 20-29 range for the KEXINIT > used for a re-exchange.) I don't think there's a need to leave responses > to any messages formally unspecified given the UNIMPLEMENTED mechanism. > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 5 07:47:00 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12274 for ; Thu, 5 Aug 2004 07:47:00 -0400 (EDT) Received: (qmail 2537 invoked by uid 605); 5 Aug 2004 11:46:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2528 invoked from network); 5 Aug 2004 11:46:57 -0000 Received: from shitei.mindrot.org (203.217.30.81) by mail.netbsd.org with SMTP; 5 Aug 2004 11:46:57 -0000 Received: from mindrot.org (unknown [172.29.84.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shitei.mindrot.org (Postfix) with ESMTP id 6DF3527C18B; Thu, 5 Aug 2004 21:16:04 +1000 (EST) Message-ID: <411216B5.5080308@mindrot.org> Date: Thu, 05 Aug 2004 21:15:01 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 0.5 (X11/20040629) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Lonvick , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal (fwd) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Chris Lonvick wrote: > Hi, > > I was hoping that this was a closed issue but I believe that Tero knows > something about this subject. Can we have some discussion on this? I'd > like to try to come to some consensus around one of the following: I think that we should just change the drafts to read "RFC3526 group 14" instead of "oakley group 14". The RFC isn't going to change retrospectively and it seems like total overkill to set up an IANA registry for a couple of groups, especially if DHGEX is going to be preferred in the future. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 5 13:23:10 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01262 for ; Thu, 5 Aug 2004 13:23:09 -0400 (EDT) Received: (qmail 5578 invoked by uid 605); 5 Aug 2004 17:10:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5361 invoked from network); 5 Aug 2004 17:10:09 -0000 Received: from relais.videotron.ca (24.201.245.36) by mail.netbsd.org with SMTP; 5 Aug 2004 17:10:09 -0000 Received: from xoxoxo ([24.203.234.205]) by VL-MO-MR005.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1Z001JMGXFL4@VL-MO-MR005.ip.videotron.ca> for ietf-ssh@netbsd.org; Thu, 05 Aug 2004 13:08:06 -0400 (EDT) Date: Thu, 05 Aug 2004 13:08:06 -0400 From: Team SkyBusters Subject: Get In GearDishNetWorx This Is The Revolution Of Testing www.skybusters.net To: SkyBusters Members And Buyers Message-id: <388-220048451786343@xoxoxo> Organization: Team SkyBusters MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable {DishnetWorks Hardware Software} SkyBusters=2Enet Coupon Code 793797C704 SkyBusters=2Enet has a surprise in stock for newcomers and current members= =2EWe are offering you today a unique special given to you to acquire your= ever looking signal to explore your testing needs=2EIf you were HIT this = week via ECM (Card Down,Reciever Hit) and are looking for a excellent sour= ce for this solution, well we are here=2EWith this coupon code (793797C704= ) you will be able to access our private ATMEGA/ROM 3M in minutes upon app= roval=2EThe wonderful special is choose the ****3MONTH**** option and wiit= h the code 793797C704 your 3 month package now becomes 15$ as oppose to 35= $ you save 20$ when you join between today and tommorrow only=2EHow does t= his work=3F Apply now,you will type in your own user name and password and= then join the SkyBusters=2Enet forums with same login as you may change a= s you wish and simply with your NEW login you are able to access PRIVATE 3= M in seconds,Download and away and feel the pleasure of T=2EV=2E again=2EP= lease remember that if you do not have a Digital Lock Installed you are ev= en more subject to ECM again please check free forums for details=2E=2EWe = also encourage you to ask our technicians or Live Help staff as well as Fo= rums for questions you have or may need to know about HardWare or Utilizin= g Scripts=2EWe are open 24hres 7 days a week=2EWe accept ALL major credit = cards and Also Have Money Order system for your convenience and of course = safety=2EWe hope that you will enjoy what is offered and please ask whatev= er you like=2EAs always SkyBusters=2ENet is here to serve you better=2E Thanks Coupon Code 793797C704 SkyBusters=2Enet=20 From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 10 05:01:27 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04769 for ; Tue, 10 Aug 2004 05:01:26 -0400 (EDT) Received: (qmail 2340 invoked by uid 605); 10 Aug 2004 09:01:26 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20040810090126.2337.qmail@mail.netbsd.org> Received: (qmail 2331 invoked from network); 10 Aug 2004 09:01:25 -0000 Received: from cm-24-121-21-64.payson.az.npgco.com (HELO 24.121.21.64) (24.121.21.64) by mail.netbsd.org with SMTP; 10 Aug 2004 09:01:23 -0000 From: Janet Sabatino To: ietf-ssh@NetBSD.org Subject: Re: website traffic Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 10 Aug 2004 02:01:19 -0700 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In order to be at the top of the list with a search engine, you need to qualify with them. Our company qualifies for Google, Yahoo!, MSN, and several other companies. If you'd like to see if your website qualifies for a better position, reply with your contact info and web address. Usual response will come in a couple days after review. Sincerely, Janet Sabatino Website Positioning Services 37 Business Center Dr. Austin, TX From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 13 09:12:08 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13478 for ; Fri, 13 Aug 2004 09:12:08 -0400 (EDT) Received: (qmail 5700 invoked by uid 605); 13 Aug 2004 13:09:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5666 invoked from network); 13 Aug 2004 13:09:53 -0000 Received: from quick.recoil.org (194.70.3.133) by mail.netbsd.org with SMTP; 13 Aug 2004 13:09:53 -0000 Received: (qmail 26724 invoked by uid 10000); 13 Aug 2004 13:09:51 -0000 Date: Fri, 13 Aug 2004 14:09:51 +0100 From: Anil Madhavapeddy To: ietf-ssh@NetBSD.org Subject: query about draft-ietf-secsh-connect-19.txt Message-ID: <20040813130951.GA27573@quick.recoil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i Sender: ietf-ssh-owner@NetBSD.org Precedence: list In draft-ietf-secsh-connect-19.txt, Section 7.1, there is a reference to: byte SSH_MSG_GLOBAL_REQUEST_SUCCESS uint32 port that was bound on the server which should probably be "SSH_MSG_REQUEST_SUCCESS" The other odd thing about this packet is that it's the only one which doesn't encode the request type in which it's in response to. This form would appear to make more sense: byte SSH_MSG_REQUEST_SUCCESS string "tcpip-forward" uint32 port that was bound on the server As this is the only packet for which the contents of the packet can vary without a "constant field" on which to make the decision of which further packets to inspect. In other cases, e.g. SSH_MSG_CHANNEL_REQUEST, the decision to decode further fields can be taken by lookinng at the first string argument. -- Anil Madhavapeddy http://anil.recoil.org University of Cambridge http://www.cl.cam.ac.uk From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 16 00:27:24 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20822 for ; Mon, 16 Aug 2004 00:27:23 -0400 (EDT) Received: (qmail 1912 invoked by uid 605); 16 Aug 2004 04:27:20 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20040816042720.1909.qmail@mail.netbsd.org> Received: (qmail 1899 invoked from network); 16 Aug 2004 04:27:19 -0000 Received: from 201009086102.user.veloxzone.com.br (HELO bol.com.br) (201.9.86.102) by mail.netbsd.org with SMTP; 16 Aug 2004 04:27:18 -0000 From: "Erica Silveira" To: Subject: listagem de e-mails Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Mon, 16 Aug 2004 01:27:37 -0300 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Mais Emails, venda online de listas de email, fazemos mala direta e propaganda de sua empresa ou negócio para milhões de emails. Temos listas de email Mala Direta, Mala-Direta, Cadastro de Emails, Lista de Emails, Mailing List, Milhões de Emails, Programas de Envio de Email, Email Bombers, Extratores de Email, Listas Segmentadas de Email, Emails Segmentados, Emails em Massa, E-mails http://www.promonet.mx.gs Temos listas de email Mala Direta, Mala-Direta, Cadastro de Emails, Lista de Emails, Mailing List, Milhões de Emails, Programas de Envio de Email, Email Bombers, Extratores de Email, Listas Segmentadas de Email, Emails Segmentados, Emails em Massa, E-mails http://www.promonet.mx.gs From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 19 16:35:26 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06076 for ; Thu, 19 Aug 2004 16:35:26 -0400 (EDT) Received: (qmail 22442 invoked by uid 605); 19 Aug 2004 14:59:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22322 invoked from network); 19 Aug 2004 14:59:29 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 19 Aug 2004 14:59:29 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 738F018D0B9; Thu, 19 Aug 2004 16:59:27 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 493261645E5; Thu, 19 Aug 2004 16:59:24 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i7JExNih014644; Thu, 19 Aug 2004 16:59:23 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i7JExESP014641; Thu, 19 Aug 2004 16:59:14 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: sommerfeld@east.sun.com Cc: Jon Bright , Peter Gutmann , ietf-ssh@NetBSD.org Subject: Re: Invalid channel numbers References: <200407291714.i6THEYeS007818@thunk.east.sun.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 19 Aug 2004 16:59:12 +0200 In-Reply-To: <200407291714.i6THEYeS007818@thunk.east.sun.com> Message-ID: Lines: 17 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Bill Sommerfeld writes: > (In any event, you likely need more than just a channel number to track > peer channel state, so a valid bit or state variable doesn't seem like > such a big deal. no reason to change the protocol..) I use a channel table indexed by local channel number. I choose to use small non-negative integers for my local numbers, and -1 as a flag value in a few places. The remote channel number is a totally opaque identifier stored in this table together with the other channel state. This seems like a natural way to organize the channel table. I can not remember that I have ever wanted or needed a reserved flag value in the remote number space. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 19 16:43:27 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07038 for ; Thu, 19 Aug 2004 16:43:27 -0400 (EDT) Received: (qmail 9905 invoked by uid 605); 19 Aug 2004 15:18:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9853 invoked from network); 19 Aug 2004 15:18:19 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 19 Aug 2004 15:18:18 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 9FCF2171CC9; Thu, 19 Aug 2004 16:49:02 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 4756218AB0A; Thu, 19 Aug 2004 16:48:59 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i7JEmuih014569; Thu, 19 Aug 2004 16:48:56 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i7JEmgDX014560; Thu, 19 Aug 2004 16:48:42 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: galb-list@vandyke.com, ietf-ssh@NetBSD.org, mouse@Rodents.Montreal.QC.CA Subject: Re: Invalid channel numbers References: Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 19 Aug 2004 16:48:34 +0200 In-Reply-To: Message-ID: Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > What if it's a channel open where the packet ends halfway through the channel > number? You've got a request, there seems to be a requirement to send a > response, but you can't respond without some facility that lets you say "The > last channel-related request was disallowed". I don't see any problem here. Whenever you receive a packet that clearly doesn't follow the spec, just reply with SSH_MSG_DISCONNECT, SSH_DISCONNECT_PROTOCOL_ERROR, then hang up the connection. Truncated channel requests are in this class. If you *really* want to be more forgiving than that, send a SSH_MSG_DEBUG explaining the problem, and then ignore the packet. But such behaviour goes beyond the specification. My reading of the spec is that SSH_MSG_DISCONNECT is the only appropriate response in this case. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 19 16:44:59 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07344 for ; Thu, 19 Aug 2004 16:44:58 -0400 (EDT) Received: (qmail 17350 invoked by uid 605); 19 Aug 2004 15:25:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17329 invoked from network); 19 Aug 2004 15:25:52 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 19 Aug 2004 15:25:52 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 37DC7181D7C; Thu, 19 Aug 2004 17:25:17 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 7B4671817CF; Thu, 19 Aug 2004 17:25:12 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i7JFPBih014852; Thu, 19 Aug 2004 17:25:11 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i7JFP2jV014847; Thu, 19 Aug 2004 17:25:02 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Damien Miller Cc: Chris Lonvick , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal (fwd) References: <411216B5.5080308@mindrot.org> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 19 Aug 2004 17:25:00 +0200 In-Reply-To: <411216B5.5080308@mindrot.org> Message-ID: Lines: 42 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Damien Miller writes: > I think that we should just change the drafts to read "RFC3526 group 14" > instead of "oakley group 14". The RFC isn't going to change > retrospectively and it seems like total overkill to set up an IANA > registry for a couple of groups, especially if DHGEX is going to be > preferred in the future. I'm sorry if I haven't been following the group closely enough recently, but now I'm confused. I thought the entire purpose of the secsh-numbers document was to specify an IANA registry for ssh-related names and numbers. The creation of that new registry seems totally orthogonal to whether or not we try to keep some of the numbers in the registry somehow in "sync" with the ipsec iana registry. As for the appropriateness of the name "oakley group 14" for our group, I have been assuming that the group, and the name "group 14", originates in some paper (outside of the RFC series), together with some motivation and analysis of the method by which the primes were selected. I would have expected a reference to such a paper in RFC 2412 and RFC 3526, but I can't seem to find any. If that's not the case, I'd have to agree with Tero that it doesn't make much sense to copy arbitrary numbers from the ipsec iana registry into our registry. Can any onebody shed some light on the origins of the "oakley groups" and their names? Confusedly yours, /Niels PS. And also "RFC3526 group 14" doesn't make much sense to me; the motivation for the "group14" naming we've been discussing have been to make it *easily* generalizable to new groups that appear in some well defined (by somebody else) series. Doing that, and then referring to a fix document like RFC3526 defining precisely 6 groups for the definition of the supposedly growing series, makes it all pretty pointless. PPS. I've been on vacation off the net for a few weeks. Hence my late comments. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 19 16:48:28 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07674 for ; Thu, 19 Aug 2004 16:48:27 -0400 (EDT) Received: (qmail 6975 invoked by uid 605); 19 Aug 2004 15:46:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6942 invoked from network); 19 Aug 2004 15:46:14 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 19 Aug 2004 15:46:14 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 06FAC18A2B8; Thu, 19 Aug 2004 17:46:12 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id B080E18EF79; Thu, 19 Aug 2004 17:46:09 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i7JFk8ih015107; Thu, 19 Aug 2004 17:46:08 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i7JFk2L9015104; Thu, 19 Aug 2004 17:46:02 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Anil Madhavapeddy Cc: ietf-ssh@NetBSD.org Subject: Re: query about draft-ietf-secsh-connect-19.txt References: <20040813130951.GA27573@quick.recoil.org> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 19 Aug 2004 17:46:02 +0200 In-Reply-To: <20040813130951.GA27573@quick.recoil.org> Message-ID: Lines: 40 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Anil Madhavapeddy writes: > In draft-ietf-secsh-connect-19.txt, Section 7.1, there is a reference > to: > > byte SSH_MSG_GLOBAL_REQUEST_SUCCESS > uint32 port that was bound on the server > > which should probably be "SSH_MSG_REQUEST_SUCCESS" I think you're right. > The other odd thing about this packet is that it's the only one which > doesn't encode the request type in which it's in response to. The *reply* messages in general includes *no* request type identifier: byte SSH_MSG_REQUEST_SUCCESS ..... response specific data -- byte SSH_MSG_REQUEST_FAILURE -- byte SSH_MSG_CHANNEL_SUCCESS uint32 recipient_channel -- byte SSH_MSG_CHANNEL_FAILURE uint32 recipient_channel To make it possible for the originator of a request to identify to which request each reply refers to, it is required that replies to SSH_MSG_GLOBAL_REQUESTS must be sent in the same order as the corresponding request messages. And for channel requests, replies that relate to the same channel must also be replied to in the right order (channel requests for *distinct* channels can be replied to out-of-order, at least that's my understanding of things). Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 19 19:42:19 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19836 for ; Thu, 19 Aug 2004 19:42:19 -0400 (EDT) Received: (qmail 13352 invoked by uid 605); 19 Aug 2004 23:42:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13339 invoked from network); 19 Aug 2004 23:42:12 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 19 Aug 2004 23:42:12 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa28212; 19 Aug 2004 17:40 EDT Date: Thu, 19 Aug 2004 17:39:59 -0400 From: Jeffrey Hutzelman To: =?ISO-8859-1?Q?Niels_M=F6ller?= , Damien Miller cc: Chris Lonvick , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal (fwd) Message-ID: <3920060000.1092951599@minbar.fac.cs.cmu.edu> In-Reply-To: References: <411216B5.5080308@mindrot.org> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable On Thursday, August 19, 2004 17:25:00 +0200 Niels M=F6ller=20 wrote: > Damien Miller writes: > >> I think that we should just change the drafts to read "RFC3526 group 14" >> instead of "oakley group 14". The RFC isn't going to change >> retrospectively and it seems like total overkill to set up an IANA >> registry for a couple of groups, especially if DHGEX is going to be >> preferred in the future. > > I'm sorry if I haven't been following the group closely enough > recently, but now I'm confused. I thought the entire purpose of the > secsh-numbers document was to specify an IANA registry for ssh-related > names and numbers. The creation of that new registry seems totally > orthogonal to whether or not we try to keep some of the numbers in the > registry somehow in "sync" with the ipsec iana registry. The numbers document _does_ create a registry for the names of key exchange = methods. What we are discussing is a guideline for choosing the names of a = certain class of key exchanges; namely, those defined in the same way as=20 the existing diffie-hellman-group1-sha1 but using different groups. > As for the appropriateness of the name "oakley group 14" for our > group, I have been assuming that the group, and the name "group 14", > originates in some paper (outside of the RFC series), together with > some motivation and analysis of the method by which the primes were > selected. I would have expected a reference to such a paper in RFC > 2412 and RFC 3526, but I can't seem to find any. The name "group 14" does not originate in any paper; it derives from the=20 fact that the group in question is identified by the constant 14 in IKE.=20 See the IANA registry for IKE attributes. > PS. And also "RFC3526 group 14" doesn't make much sense to me; the > motivation for the "group14" naming we've been discussing have been to > make it *easily* generalizable to new groups that appear in some well > defined (by somebody else) series. Yup. The appropriate phrase would be IKE group 14, preferably with a=20 reference to the aforementioned registry. -- 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 Fri Aug 20 02:27:52 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21514 for ; Fri, 20 Aug 2004 02:27:51 -0400 (EDT) Received: (qmail 28956 invoked by uid 605); 20 Aug 2004 06:27:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28942 invoked from network); 20 Aug 2004 06:27:45 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 20 Aug 2004 06:27:44 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 638D2194247; Fri, 20 Aug 2004 08:25:23 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id E85A018FF0E; Fri, 20 Aug 2004 08:25:19 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i7K6PJih024470; Fri, 20 Aug 2004 08:25:19 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i7K6PBCU024467; Fri, 20 Aug 2004 08:25:11 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Jeffrey Hutzelman Cc: Damien Miller , Chris Lonvick , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal (fwd) References: <411216B5.5080308@mindrot.org> <3920060000.1092951599@minbar.fac.cs.cmu.edu> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 20 Aug 2004 08:25:10 +0200 In-Reply-To: <3920060000.1092951599@minbar.fac.cs.cmu.edu> Message-ID: Lines: 19 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Jeffrey Hutzelman writes: > > PS. And also "RFC3526 group 14" doesn't make much sense to me; the > > motivation for the "group14" naming we've been discussing have been to > > make it *easily* generalizable to new groups that appear in some well > > defined (by somebody else) series. > > Yup. The appropriate phrase would be IKE group 14, preferably with a > reference to the aforementioned registry. But then, do we mean ike-1 or ike-2? If these numbers are arbitrarily selected by the ipsec wg, as my understanding is now, then that matters, because there's no requirement that ike-1 and ike-2 use the same numbers, right? (I'm not following ipsec closely, but my impression is that ike-2 is not a small incremental change to ike-1, but more or less a rewrite, trying to remedy the ike-1 disaster). Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 20 12:54:34 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26973 for ; Fri, 20 Aug 2004 12:54:33 -0400 (EDT) Received: (qmail 9253 invoked by uid 605); 20 Aug 2004 16:54:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9221 invoked from network); 20 Aug 2004 16:54:25 -0000 Received: from dsl093-061-085.pit1.dsl.speakeasy.net (HELO mariner.pc.cs.cmu.edu) (66.93.61.85) by mail.netbsd.org with SMTP; 20 Aug 2004 16:54:25 -0000 Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa29203; 20 Aug 2004 11:12 EDT Date: Fri, 20 Aug 2004 11:12:13 -0400 From: Jeffrey Hutzelman To: =?ISO-8859-1?Q?Niels_M=F6ller?= cc: Jeffrey Hutzelman , Damien Miller , Chris Lonvick , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal (fwd) Message-ID: <36860000.1093014733@mariner.pc.cs.cmu.edu> In-Reply-To: References: <411216B5.5080308@mindrot.org> <3920060000.1092951599@minbar.fac.cs.cmu.edu> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable On Friday, August 20, 2004 08:25:10 +0200 Niels M=F6ller=20 wrote: > Jeffrey Hutzelman writes: > >> > PS. And also "RFC3526 group 14" doesn't make much sense to me; the >> > motivation for the "group14" naming we've been discussing have been to >> > make it *easily* generalizable to new groups that appear in some well >> > defined (by somebody else) series. >> >> Yup. The appropriate phrase would be IKE group 14, preferably with a >> reference to the aforementioned registry. > > But then, do we mean ike-1 or ike-2? If these numbers are arbitrarily > selected by the ipsec wg, as my understanding is now They're not selected arbitrarily. There is an IANA registry. If you go look at the registry, you'll see that so far, group numbers have been assigned in sequence, though not all of the groups are MODP groups and not all are defined in the documents we're discussing. So, the problem here was that we borrowed a group defined elsewhere (good), = and then gave it our own number which didn't match the number it had in the = other place (bad), and did match the number that some other group had in=20 the other place (even more bad). The proposed solution is "don't do that"; particularly, don't make up our=20 own numbers. As long as we are borrowing groups from that registry, we=20 should borrow the numbers along with them. We can include a reference to the group table in the Internet Key Exchange=20 Attributes registry at IANA. I think that will be sufficiently=20 non-ambiguous, especially if ikev2 reuses the registry, as it should. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 20 13:05:11 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27919 for ; Fri, 20 Aug 2004 13:05:10 -0400 (EDT) Received: (qmail 20921 invoked by uid 605); 20 Aug 2004 17:05:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20912 invoked from network); 20 Aug 2004 17:05:10 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 20 Aug 2004 17:05:10 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i7KH3k35026478; Fri, 20 Aug 2004 10:03:46 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i7KH3jQH024544; Fri, 20 Aug 2004 13:03:45 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7KH3jkJ015695; Fri, 20 Aug 2004 13:03:45 -0400 (EDT) Message-Id: <200408201703.i7KH3jkJ015695@thunk.east.sun.com> From: Bill Sommerfeld To: Jeffrey Hutzelman cc: =?ISO-8859-1?Q?Niels_M=F6ller?= , Damien Miller , Chris Lonvick , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal (fwd) In-Reply-To: Your message of "Fri, 20 Aug 2004 11:12:13 EDT." <36860000.1093014733@mariner.pc.cs.cmu.edu> Reply-to: sommerfeld@east.sun.com Date: Fri, 20 Aug 2004 13:03:45 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list the problem is that we've already gone down the road of defining our own group numbers. IIRC, SSH group 1 is IKE group 2. names such as "rfc3526-modp2048" seem more appropriate and unambiguous for the family of groups defined in that document. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 20 16:31:28 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12163 for ; Fri, 20 Aug 2004 16:31:28 -0400 (EDT) Received: (qmail 24086 invoked by uid 605); 20 Aug 2004 20:31:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24062 invoked from network); 20 Aug 2004 20:31:25 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 20 Aug 2004 20:31:24 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 2989F10060E; Fri, 20 Aug 2004 22:31:23 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id E61E9100172; Fri, 20 Aug 2004 22:31:18 +0200 (MEST) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i7KKVIih001424; Fri, 20 Aug 2004 22:31:18 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i7KKVAV9001421; Fri, 20 Aug 2004 22:31:10 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: sommerfeld@east.sun.com Cc: Jeffrey Hutzelman , Damien Miller , Chris Lonvick , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal (fwd) References: <200408201703.i7KH3jkJ015695@thunk.east.sun.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 20 Aug 2004 22:31:06 +0200 In-Reply-To: <200408201703.i7KH3jkJ015695@thunk.east.sun.com> Message-ID: Lines: 60 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Bill Sommerfeld writes: > names such as "rfc3526-modp2048" seem more appropriate and unambiguous > for the family of groups defined in that document. In this case, we're considering two different naming schemes: A: diffie-hellman-group1-sha1 "well known group 2", see RFC 2412 diffie-hellman-group2-sha1 "2048-bit modp group", see RFC 3526 B: diffie-hellman-group1-sha1 "well known group 2", see RFC 2412 diffie-hellman-group14-sha1 "2048-bit modp group"/"IKE group 14", see RFC 3526 The first consistently uses an independent ssh-specific name space. The second attempts to borrow a subspace of that namespace from a namespace defined elsewhere, and by doing so, it also *attempt* to define the meaning of diffie-hellman-groupx-sha1 for arbitrary x. That's the main selling point of B, right? I believe this selling point simply fails. To define e.g. diffie-hellman-group3-sha1, an RFC must be published that defines its meaning unambigously. That requirement is from draft-ietf-secsh-assignednumbers-06.txt, section 4.3, and I think it's an appropriate requirement. To me, it seems cleaner and less confusing to stick to the original intentions of Tero and others and use a small ssh-specific name space, and naming scheme A above. Then diffie-hellman-group1-sha1 means "well known group 2" from one RFC. diffie-hellman-group2-sha1 means a 2028-bit group from a different RFC. diffie-hellman-group3-sha1 will mean whatever we choose it to mean at the time we decide we need yet another fixed group. (Also note that it is consistent with the numbers document to have some later RFC define diffie-hellman-ike2-groupx-sha1 for some set of x, if we ever want that. That's however something that we *don't* need to address at the moment). I'm sorry we're digging up this old issue again. I want to state that I don't feel very strongly about this naming stuff, but I'd prefer that we get it right and clean. And from the earlier discussions, I think the rest of you have a similar attitude to it. So, what's the right thing to do now? Regards, /Niels -- There are two difficult unsolved problems in computer science: 1. Cache invalidation 2. Naming of things -- Phil Karton From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Aug 21 15:27:07 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29421 for ; Sat, 21 Aug 2004 15:27:07 -0400 (EDT) Received: (qmail 19726 invoked by uid 605); 21 Aug 2004 19:27:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19695 invoked from network); 21 Aug 2004 19:27:01 -0000 Received: from mail.ozu.es (HELO ozu.es) (194.30.32.179) by mail.netbsd.org with SMTP; 21 Aug 2004 19:27:00 -0000 Received: from [219.93.230.42] (account ethel_kambili@ozu.es) by ozu.es (CommuniGate Pro WebUser 4.2b5) with HTTP id 15064406; Sat, 21 Aug 2004 21:26:53 +0200 From: "Ethel Kambili" Subject: PLEASE GET BACK TO ME To: ethel_kambili@ozu.es X-Mailer: CommuniGate Pro WebUser Interface v.4.2b5 Date: Sat, 21 Aug 2004 21:26:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Attention, MD/CEO. I am Ethel Kambili,of Golden Peak security company. Malaysia,the Hq and the umbrella company for most of the security company in the west Africa.I am deeply sorry for the rude intrusion of your privacy due to the fact that we have not met either in person or in the field of communication,thus i tender my unreserved apology on the subject matter. You might be wondering how i got your contact and why i am contacting you,As regards your contact i obtain it from the proffesional database found in the internet and picked interest in you because of the nature of your profession as well as being near to the situation on which i want to sougth out your assistance on. The situation on ground now that warrant urgent attention that prompted me in contacting you is that there is a consignment that was forwaded to one Mr Mohammed Ibrahim Sayeed,a Lebanon national,but has not been claim since the time of forwarding due to the fact that the consinee at that time decided to come over to Benin,but on getting here he learnt has already been left and in a bid to catch up with it,he boarded the ill fated flight that crashed on the 23 december 2003(http://www.cnn.com/2003/WORLD/africa/12/26/benin.crash/index.html) Thus the consignment has be left without any claimant as he did not list anybody as his next of keen,and in view of this development ,the management of the freight forwarding services are now on the verge of concluding declaring the box for inspection of the custom and exise board over there,a situation which i want to avoid by seizing this opportunity of presenting somebody as capable as you to come forward in claiming the consignment,i will do all the papperwook that will guarantee and qualify you as an eligible person to claim this if you accept my proposition of being in partnership on this transaction. If you accept by giving me green light in your reply.I will divulge the value of the content consignment to you,and explain the procedure to you as well.The terms and mode of the sharing of the proceed will be on 50/50 bases.In order for you to check the genuity of this proposition.you may please contact the Zonal operation Manager in Malaysia useing the contact coordiate below. contact person:Mr. Matt Hall telephone no :00 60163550557 Email address :ethelkambili_1@yahoo.co.uk Consignment ref.nos :CSF/BEN/MIS1203-K068(Please quote this number during enquiry) I will appreciate it if you can please expedite your response so as to enable me forward the necessary paper that will facilitate the retriever of the box by you. Thanking you in anticipation of your kind co-operations. Ethel Kambili. -------------------------------------------------- Nuevo Depósito a un mes 6% T.A.E. de ING http://ingdirect.ozu.es/ -------------------------------------------------- Correo enviado desde http://www.ozu.es From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Aug 21 18:02:37 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06894 for ; Sat, 21 Aug 2004 18:02:37 -0400 (EDT) Received: (qmail 21300 invoked by uid 605); 21 Aug 2004 22:02:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21280 invoked from network); 21 Aug 2004 22:02:31 -0000 Received: from fw.hel.fi.ssh.com (195.20.116.97) by mail.netbsd.org with SMTP; 21 Aug 2004 22:02:30 -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.16) with SMTP id i7LLTlQs027223 for ; Sun, 22 Aug 2004 00:29:47 +0300 (EEST) Received: (qmail 25224 invoked from network); 21 Aug 2004 21:29:47 -0000 Received: from unknown (HELO ?127.0.0.1?) ([10.1.0.55]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 21 Aug 2004 21:29:47 -0000 Message-ID: <4127BF41.4060801@ssh.com> Date: Sun, 22 Aug 2004 00:31:45 +0300 From: "Timo J. Rinne" Reply-To: tri@ssh.com Organization: SSH Communications Security Corp. User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niels_M=F6ller?= CC: sommerfeld@east.sun.com, Jeffrey Hutzelman , Damien Miller , Chris Lonvick , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal (fwd) References: <200408201703.i7KH3jkJ015695@thunk.east.sun.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Niels Möller wrote: > To me, it seems cleaner and less confusing to stick to the original > intentions of Tero and others and use a small ssh-specific name space, > and naming scheme A above. Then diffie-hellman-group1-sha1 means "well > known group 2" from one RFC. diffie-hellman-group2-sha1 means a > 2028-bit group from a different RFC. diffie-hellman-group3-sha1 will > mean whatever we choose it to mean at the time we decide we need yet > another fixed group. I fully agree with Niels here. This way we would get it clear once and for all. Should we borrow group numbering from ike, we should then include all of them instead of arbitrary subset. Anyways, it is much simpler and straightforward to use independent numbering in SecSh. -- Timo J. Rinne -+-+-+- http://www.ssh.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 23 08:21:44 2004 Received: from mail.netbsd.org ([204.152.184.164]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03284 for ; Mon, 23 Aug 2004 08:21:44 -0400 (EDT) Received: (qmail 24535 invoked by uid 605); 23 Aug 2004 12:21:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24525 invoked from network); 23 Aug 2004 12:21:40 -0000 Received: from chiark.greenend.org.uk (193.201.200.170) by mail.netbsd.org with SMTP; 23 Aug 2004 12:21:40 -0000 Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local for ietf-ssh@netbsd.org id 1BzC5M-0005cp-00; Mon, 23 Aug 2004 11:29:56 +0100 Date: Mon, 23 Aug 2004 11:29:56 +0100 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: query about draft-ietf-secsh-connect-19.txt Message-ID: <20040823102956.GA19874@chiark.greenend.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Niels Moller writes: > To make it possible for the originator of a request to identify to > which request each reply refers to, it is required that replies to > SSH_MSG_GLOBAL_REQUESTS must be sent in the same order as the > corresponding request messages. > > And for channel requests, replies that relate to the same channel must > also be replied to in the right order (channel requests for *distinct* > channels can be replied to out-of-order, at least that's my > understanding of things). I can't find language spelling out these requirements in connect-19 after a brief skim through. Perhaps some should be added? (Would current implementations meet these requirements?) From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 25 13:58:47 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05316 for ; Wed, 25 Aug 2004 13:58:46 -0400 (EDT) Received: (qmail 24624 invoked by uid 605); 25 Aug 2004 17:58:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24615 invoked from network); 25 Aug 2004 17:58:33 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by mail.netbsd.org with SMTP; 25 Aug 2004 17:58:33 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 25 Aug 2004 11:05:08 +0000 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7PHwQiQ013419 for ; Wed, 25 Aug 2004 10:58:27 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA27971 for ; Wed, 25 Aug 2004 10:58:26 -0700 (PDT) Date: Wed, 25 Aug 2004 10:58:26 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal (fwd) In-Reply-To: <4127BF41.4060801@ssh.com> Message-ID: References: <200408201703.i7KH3jkJ015695@thunk.east.sun.com> <4127BF41.4060801@ssh.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: QUOTED-PRINTABLE Hi, It appears that there is some consensus about going back to our own namespce " diffie-hellman-groupN-sha1 " We have defined N=3D1 and N=3D2 so we could propose to the IANA that new on= es - be created via the consensus method - N monotonically increases - once assigned, N must not be reused - future assignments not using DH and/or SHA1 may have entirely different formats. This will remove the proposal for the use of diffie-hellman-group14-sha1 . Is there any significant dissent? Thanks, Chris On Sun, 22 Aug 2004, Timo J. Rinne wrote: > Niels M=F6ller wrote: > > To me, it seems cleaner and less confusing to stick to the original > > intentions of Tero and others and use a small ssh-specific name space, > > and naming scheme A above. Then diffie-hellman-group1-sha1 means "well > > known group 2" from one RFC. diffie-hellman-group2-sha1 means a > > 2028-bit group from a different RFC. diffie-hellman-group3-sha1 will > > mean whatever we choose it to mean at the time we decide we need yet > > another fixed group. > > I fully agree with Niels here. This way we would get it clear once and > for all. Should we borrow group numbering from ike, we should then > include all of them instead of arbitrary subset. Anyways, it is much > simpler and straightforward to use independent numbering in SecSh. > > -- > Timo J. Rinne -+-+-+- http://www.ssh.com > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 25 16:13:52 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16279 for ; Wed, 25 Aug 2004 16:13:51 -0400 (EDT) Received: (qmail 8918 invoked by uid 605); 25 Aug 2004 20:13:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8730 invoked from network); 25 Aug 2004 20:13:45 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 25 Aug 2004 20:13:44 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa01681; 25 Aug 2004 16:08 EDT Date: Wed, 25 Aug 2004 16:08:13 -0400 From: Jeffrey Hutzelman To: Chris Lonvick , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal (fwd) Message-ID: <1553312704.1093464493@minbar.fac.cs.cmu.edu> In-Reply-To: References: <200408201703.i7KH3jkJ015695@thunk.east.sun.com> <4127BF41.4060801@ssh.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Wednesday, August 25, 2004 10:58:26 -0700 Chris Lonvick wrote: > It appears that there is some consensus about going back to our own > namespce " diffie-hellman-groupN-sha1 " > > We have defined N=1 and N=2 so we could propose to the IANA that new ones > - be created via the consensus method > - N monotonically increases > - once assigned, N must not be reused > - future assignments not using DH and/or SHA1 may have entirely different > formats. > > This will remove the proposal for the use of diffie-hellman-group14-sha1 (1) I don't see a need for a sub-registry. There is a registry of key exchange method names; that is all that is required. Saying "use these group numbers defined over here" made sense when the intent was to normalize our naming to reflect another existing registry. If we're not going to do that, than no more needs to be said. (2) I still think it is a bad idea to continue the practice of using phrases like "group N" to mean completely different groups than the rest of the community means when they say "group N". I wonder how many times various members of this WG are going to have to explain that no, the group size is not inadequate, because by "group 2" we mean not the 1024-bit MODP group that everyone else means when they say "group 2", but instead a 2048-bit MODP group, which in the rest of the world is known as "group 14". There is value in using the same names as other people. There is value in using them to mean the same things. Doing so is fundamental to successful communication. BTW, I seem to recall someone asking about how these group moduli were selected, and asking for a reference. The appropriate reference is RFC2412, appendix E, in which the original 5 well-known Oakley groups are defined. The appendix describes the algorithm in some detail, such that one could repeat the process and get the same values, or apply it to generate larger groups of arbitrary size. It also explains why that particular algorithm was chosen. -- 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 Thu Aug 26 06:41:38 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20046 for ; Thu, 26 Aug 2004 06:41:37 -0400 (EDT) Received: (qmail 570 invoked by uid 605); 26 Aug 2004 10:41:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 559 invoked from network); 26 Aug 2004 10:41:25 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 26 Aug 2004 10:41:25 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 1F1D619F0C0; Thu, 26 Aug 2004 12:41:23 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 3746B19F0C1; Thu, 26 Aug 2004 12:41:19 +0200 (MEST) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i7QAfGih009428; Thu, 26 Aug 2004 12:41:17 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i7QAf5F9009425; Thu, 26 Aug 2004 12:41:06 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Jeffrey Hutzelman Cc: Chris Lonvick , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal (fwd) References: <200408201703.i7KH3jkJ015695@thunk.east.sun.com> <4127BF41.4060801@ssh.com> <1553312704.1093464493@minbar.fac.cs.cmu.edu> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 26 Aug 2004 12:41:01 +0200 In-Reply-To: <1553312704.1093464493@minbar.fac.cs.cmu.edu> Message-ID: Lines: 50 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Jeffrey Hutzelman writes: > On Wednesday, August 25, 2004 10:58:26 -0700 Chris Lonvick > wrote: > > > It appears that there is some consensus about going back to our own > > namespce " diffie-hellman-groupN-sha1 " I think a lot of peple are silent. It's hard to tell if that's because they agree, or don't care, or are all on vacation. > > We have defined N=1 and N=2 so we could propose to the IANA that new ones > > - be created via the consensus method > > - N monotonically increases > > - once assigned, N must not be reused > > - future assignments not using DH and/or SHA1 may have entirely different > > formats. > > > > This will remove the proposal for the use of diffie-hellman-group14-sha1 > > > (1) I don't see a need for a sub-registry. There is a registry of key > exchange method names; that is all that is required. Saying "use > these group numbers defined over here" made sense when the intent was > to normalize our naming to reflect another existing registry. If > we're not going to do that, than no more needs to be said. Agree fully. Keep it simple. > (2) I still think it is a bad idea to continue the practice of using > phrases like "group N" to mean completely different groups than the > rest of the community means when they say "group N". I don't think it's possible to fix that, given that we already have "diffie-hellman-group1-sha1 mean "well known group 2", (and I think we have agreed that it is far too late to change our name for that group). I'm afraid that using both an ssh-specific numbering scheme (for oakley group 2) and an ipsec-spcific numbering (for oakley group 14) will cause even more confusion than sticking to an ssh-specific numbering. > BTW, I seem to recall someone asking about how these group moduli were > selected, and asking for a reference. The appropriate reference is > RFC2412, appendix E, in which the original 5 well-known Oakley groups > are defined. It was me asking about that some days ago. Thanks. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 26 07:25:55 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22477 for ; Thu, 26 Aug 2004 07:25:54 -0400 (EDT) Received: (qmail 12377 invoked by uid 605); 26 Aug 2004 11:25:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12365 invoked from network); 26 Aug 2004 11:25:51 -0000 Received: from harpo.itss.auckland.ac.nz (HELO smtpc.itss.auckland.ac.nz) (130.216.190.13) by mail.netbsd.org with SMTP; 26 Aug 2004 11:25:51 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id B59C43437E; Thu, 26 Aug 2004 22:55:27 +1200 (NZST) Received: from smtpc.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06596-05; Thu, 26 Aug 2004 22:55:27 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 11BEE3437D; Thu, 26 Aug 2004 22:55:27 +1200 (NZST) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id ED61137745; Thu, 26 Aug 2004 22:55:26 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 3.36 #1 (Debian)) id 1C0Huo-00081d-00; Thu, 26 Aug 2004 22:55:34 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jhutz@cmu.edu, nisse@lysator.liu.se Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal (fwd) Cc: clonvick@cisco.com, ietf-ssh@NetBSD.org In-Reply-To: Message-Id: Date: Thu, 26 Aug 2004 22:55:34 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) writes: >I think a lot of peple are silent. Well there's a challenge I can't back down from: IMHO the most appropriate solution is to use SSH-specific values, monotonically increasing small integers, etc etc as already proposed. Perhaps we could have a quick straw poll on this. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 26 08:34:28 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26522 for ; Thu, 26 Aug 2004 08:34:28 -0400 (EDT) Received: (qmail 18855 invoked by uid 605); 26 Aug 2004 12:34:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18844 invoked from network); 26 Aug 2004 12:34:25 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 26 Aug 2004 12:34:25 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 1C0J46-0004VL-00; Thu, 26 Aug 2004 13:09:14 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@NetBSD.org In-Reply-To: Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal (fwd) Message-Id: Date: Thu, 26 Aug 2004 13:09:14 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Niels Möller wrote: > I think a lot of peple are silent. It's hard to tell if that's because > they agree, or don't care, or are all on vacation. I think any scheme would be perfectly adequate provided it was clearly defined what name went with which group, and clearly defined which groups implementors needed to support in the general case. As far as I'm concerned, this is one of those situations in which the utilities of the various choices go something like: * choice A, ten points * choice B, nine and a half points * choice C, nine points * long delay caused by debating the various options in detail, minus one thousand points. :-) -- Simon Tatham "Happiness is having a large, warm, loving, caring, close-knit family in another city." From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 26 10:33:37 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04802 for ; Thu, 26 Aug 2004 10:33:37 -0400 (EDT) Received: (qmail 12085 invoked by uid 605); 26 Aug 2004 14:33:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12073 invoked from network); 26 Aug 2004 14:33:35 -0000 Received: from ams-iport-1.cisco.com (144.254.224.140) by mail.netbsd.org with SMTP; 26 Aug 2004 14:33:34 -0000 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 Aug 2004 16:35:16 +0200 X-BrightmailFiltered: true Received: from cisco.com (edinburgh.cisco.com [144.254.112.76]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7QENFO4008276 for ; Thu, 26 Aug 2004 16:23:18 +0200 (MEST) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id PAA23215 for ietf-ssh@NetBSD.org; Thu, 26 Aug 2004 15:23:14 +0100 (BST) Date: Thu, 26 Aug 2004 15:23:14 +0100 From: Derek Fawcus To: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal (fwd) Message-ID: <20040826152314.A22669@edinburgh.cisco.com> References: <200408201703.i7KH3jkJ015695@thunk.east.sun.com> <4127BF41.4060801@ssh.com> <1553312704.1093464493@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0.1i In-Reply-To: ; from nisse@lysator.liu.se on Thu, Aug 26, 2004 at 12:41:01PM +0200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit On Thu, Aug 26, 2004 at 12:41:01PM +0200, Niels Möller wrote: > Jeffrey Hutzelman writes: > > > On Wednesday, August 25, 2004 10:58:26 -0700 Chris Lonvick > > wrote: > > > > > It appears that there is some consensus about going back to our own > > > namespce " diffie-hellman-groupN-sha1 " > > I think a lot of peple are silent. It's hard to tell if that's because > they agree, or don't care, or are all on vacation. Oh - All right then :-) I happen to agree with using our own range of simple numbers for the above, N=1, N=2, etc... DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 26 10:40:36 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06026 for ; Thu, 26 Aug 2004 10:40:36 -0400 (EDT) Received: (qmail 18383 invoked by uid 605); 26 Aug 2004 14:40:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18373 invoked from network); 26 Aug 2004 14:40:32 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 26 Aug 2004 14:40:32 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa03270; 26 Aug 2004 10:38 EDT Date: Thu, 26 Aug 2004 10:38:41 -0400 From: Jeffrey Hutzelman To: =?ISO-8859-1?Q?Niels_M=F6ller?= cc: Chris Lonvick , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal (fwd) Message-ID: <1807472704.1093531121@minbar.fac.cs.cmu.edu> In-Reply-To: References: <200408201703.i7KH3jkJ015695@thunk.east.sun.com> <4127BF41.4060801@ssh.com> <1553312704.1093464493@minbar.fac.cs.cmu.edu> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit >> (2) I still think it is a bad idea to continue the practice of using >> phrases like "group N" to mean completely different groups than the >> rest of the community means when they say "group N". > > I don't think it's possible to fix that, given that we already have > "diffie-hellman-group1-sha1 mean "well known group 2", (and I think we > have agreed that it is far too late to change our name for that > group). I'm afraid that using both an ssh-specific numbering scheme > (for oakley group 2) and an ipsec-spcific numbering (for oakley group > 14) will cause even more confusion than sticking to an ssh-specific > numbering. Yes, I think we're agreed we can't rename diffie-hellman-group1-sha1. Personally, I think living with one legacy exception is acceptable, and I think consistency with other usage is more important than consistency with the previous (IMHO poor) choice. But, I don't think it's more important than getting the documents out sometime this century. So yes, let's take a straw poll, and move on. I think everyone knows my position. :-) -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 26 10:52:59 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07415 for ; Thu, 26 Aug 2004 10:52:59 -0400 (EDT) Received: (qmail 28433 invoked by uid 605); 26 Aug 2004 14:52:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28407 invoked from network); 26 Aug 2004 14:52:50 -0000 Received: from fw.hel.fi.ssh.com (195.20.116.97) by mail.netbsd.org with SMTP; 26 Aug 2004 14:52:50 -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.16) with SMTP id i7QEqmQs001756 for ; Thu, 26 Aug 2004 17:52:48 +0300 (EEST) Received: (qmail 843 invoked from network); 26 Aug 2004 14:52:48 -0000 Received: from unknown (HELO ?127.0.0.1?) ([10.1.0.55]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 26 Aug 2004 14:52:48 -0000 Message-ID: <412DF9BF.8040809@ssh.com> Date: Thu, 26 Aug 2004 17:54:55 +0300 From: "Timo J. Rinne" Reply-To: tri@ssh.com Organization: SSH Communications Security Corp. User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal (fwd) References: <200408201703.i7KH3jkJ015695@thunk.east.sun.com> <4127BF41.4060801@ssh.com> <1553312704.1093464493@minbar.fac.cs.cmu.edu> <1807472704.1093531121@minbar.fac.cs.cmu.edu> In-Reply-To: <1807472704.1093531121@minbar.fac.cs.cmu.edu> 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 Jeffrey Hutzelman wrote: > So yes, let's take a straw poll, and move on. > > I think everyone knows my position. :-) > > -- Jeff My vote goes goes for having a SecSh protocol specific namespace for groups. 1, 2, 3 ... -- Timo J. Rinne From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 26 13:02:38 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18540 for ; Thu, 26 Aug 2004 13:02:37 -0400 (EDT) Received: (qmail 8641 invoked by uid 605); 26 Aug 2004 17:02:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8572 invoked from network); 26 Aug 2004 17:02:19 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 26 Aug 2004 17:02:19 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6561130 for ietf-ssh@NetBSD.org; Thu, 26 Aug 2004 10:02:17 -0600 Message-ID: <412E098D.6000404@vandyke.com> Date: Thu, 26 Aug 2004 10:02:21 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040823) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal (fwd) References: <200408201703.i7KH3jkJ015695@thunk.east.sun.com> <4127BF41.4060801@ssh.com> <1553312704.1093464493@minbar.fac.cs.cmu.edu> <1807472704.1093531121@minbar.fac.cs.cmu.edu> <412DF9BF.8040809@ssh.com> In-Reply-To: <412DF9BF.8040809@ssh.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Timo J. Rinne wrote: > Jeffrey Hutzelman wrote: > >> So yes, let's take a straw poll, and move on. >> >> I think everyone knows my position. :-) >> >> -- Jeff > > > My vote goes goes for having a SecSh protocol specific namespace for > groups. 1, 2, 3 ... My vote goes for secsh protocol specific namespace as well. Thanks, Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 26 13:26:57 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21253 for ; Thu, 26 Aug 2004 13:26:57 -0400 (EDT) Received: (qmail 1735 invoked by uid 605); 26 Aug 2004 17:26:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1705 invoked from network); 26 Aug 2004 17:26:53 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 26 Aug 2004 17:26:53 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i7QHQqil018720; Thu, 26 Aug 2004 11:26:52 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i7QHQqQH003748; Thu, 26 Aug 2004 13:26:52 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7QHQqgC023903; Thu, 26 Aug 2004 13:26:52 -0400 (EDT) Message-Id: <200408261726.i7QHQqgC023903@thunk.east.sun.com> From: Bill Sommerfeld To: Joseph Galbraith cc: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal (fwd) In-Reply-To: Your message of "Thu, 26 Aug 2004 10:02:21 MDT." <412E098D.6000404@vandyke.com> Reply-to: sommerfeld@east.sun.com Date: Thu, 26 Aug 2004 13:26:52 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list hang on. i'm collecting some data on what other protocols have done on this front and will send it out shortly and will (re)start the straw poll at that time.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 26 16:19:33 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07495 for ; Thu, 26 Aug 2004 16:19:33 -0400 (EDT) Received: (qmail 18145 invoked by uid 605); 26 Aug 2004 20:19:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18128 invoked from network); 26 Aug 2004 20:19:29 -0000 Received: from brmea-mail-4.sun.com (192.18.98.36) by mail.netbsd.org with SMTP; 26 Aug 2004 20:19:29 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i7QKJR53005485 for ; Thu, 26 Aug 2004 14:19:28 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i7QKJRQH013810 for ; Thu, 26 Aug 2004 16:19:27 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7QKJRvU025309 for ; Thu, 26 Aug 2004 16:19:27 -0400 (EDT) Message-Id: <200408262019.i7QKJRvU025309@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Subject: Straw Poll on group name Reply-to: sommerfeld@sun.com Date: Thu, 26 Aug 2004 16:19:27 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list At the end of this message, you'll find a summary from Tero Kivinen of the usage by other protocols of the common MODP groups on the saag list; I think it conclusively demonstrates that every user of the MODP groups is doing something different. That only leaves straw poll: [A] we should use small integers to refer to common groups [sample] diffie-hellman-group2-sha1 [B] we should refer to groups by size: [sample] diffie-hellman-group2048-sha1 [C] we should refer to groups by the ike number [sample] diffie-hellman-group14-sha1 In your response to the poll, please: a) explain the one you prefer and why. b) list any options you find unacceptable and explain why. I'll use this to gauge consensus. - Bill ------- Forwarded Message From: Tero Kivinen To: sommerfeld@sun.com Cc: saag@mit.edu Subject: [saag] naming/use of rfc2412/rfc3526 groups by other protocols In-Reply-To: <200408252136.i7PLaoOY023143@thunk.east.sun.com> References: <200408252136.i7PLaoOY023143@thunk.east.sun.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 19 min X-Total-Time: 29 min Sender: kivinen@iki.fi Content-Length: 2079 Bill Sommerfeld writes: > rfc2412 (oakley) defines several "MODP" diffie-hellman groups of > varying sizes in appendix E. Several larger groups were defined in > RFC3526. And their numbers are handled by the IANA registry for the Internet Key Exchange (IKE) attributes (http://www.iana.org/assignments/ipsec-registry). > SSHv2 uses one of these groups, and also includes an extension to > allow the group to be dynamically negotiated. > > Muddying the waters, SSHv2 defined its own group-numbering space; > diffie-hellman-group1-sha1 is the same as IKE's "group 2". Yes, that is correct, it should use its own number space, as it wants to control what groups are allowed etc. Thats why it should have its own registry listing the groups. > Do any protocols other than SSHv2 reuse IKE's MODP Diffie-Hellman > groups? Yes. > If so, what naming convention, if any, is used in that protocol? iSCSI RFC 3723 (Securing Block Storage Protocols over IP) uses same prime number, but different generator for those groups, and names them with nameslike "MODP-XXXX" where XXXX is the number of bits. Their groups are named in their own IANA registry (http://www.iana.org/assignments/iscsi-parameters). draft-clancy-eap-pax-00.txt uses the 3072 bit group and gives it number 0x01. draft-moskowitz-hip-09.txt uses 1536-8192 bit groups, and gives them their own numbers from 3-6. draft-riikonen-silc-ke-auth-08.txt uses 1024-2048 bit groups, and gives them their own name diffie-hellman-group1 - diffie-hellman-group3. draft-tuexen-sctp-auth-chunk-01.txt uses all IKE modp groups, and uses the same numbers than IKE, but it seems they will allocate their own IANA registry for number, the initial values will simply be same. draft-cam-winget-eap-fast-00.txt uses 2048 bit group, but I think they send the whole group every time, i.e the groups do not have registry or name. draft-ietf-tls-srp-07.txt also uses 3072-8192 bit groups, but different generators, and they send the whole group every time (I think), thus there is no registry or name. - -- kivinen@safenet-inc.com ------- End of Forwarded Message From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 26 17:05:16 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12331 for ; Thu, 26 Aug 2004 17:05:15 -0400 (EDT) Received: (qmail 3032 invoked by uid 605); 26 Aug 2004 21:05:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3004 invoked from network); 26 Aug 2004 21:05:11 -0000 Received: from av9-2-sn3.vrr.skanova.net (81.228.9.186) by mail.netbsd.org with SMTP; 26 Aug 2004 21:05:10 -0000 Received: by av9-2-sn3.vrr.skanova.net (Postfix, from userid 502) id D876837FED; Thu, 26 Aug 2004 22:34:19 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av9-2-sn3.vrr.skanova.net (Postfix) with ESMTP id C64ED37EDD; Thu, 26 Aug 2004 22:34:19 +0200 (CEST) Received: from [192.168.0.105] (h32n1fls31o985.telia.com [213.65.16.32]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 7594337E4C; Thu, 26 Aug 2004 22:34:19 +0200 (CEST) Message-ID: <412E494A.9010109@streamsec.se> Date: Thu, 26 Aug 2004 22:34:18 +0200 From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= Organization: StreamSec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sommerfeld@sun.com Cc: ietf-ssh@NetBSD.org Subject: Re: Straw Poll on group name References: <200408262019.i7QKJRvU025309@thunk.east.sun.com> In-Reply-To: <200408262019.i7QKJRvU025309@thunk.east.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Bill Sommerfeld wrote: > straw poll: > [A] we should use small integers to refer to common groups > [sample] diffie-hellman-group2-sha1 > > [B] we should refer to groups by size: > [sample] diffie-hellman-group2048-sha1 > > [C] we should refer to groups by the ike number > [sample] diffie-hellman-group14-sha1 I prefer [B] and I find [C] unacceptable. The reason is that most application developers and administrators have never even heard of IKE so "Group 14" would not mean anything to them, but they probably would understand the significance of the number 2048. Using the name "diffie-hellman-group14-sha1" is the worst option. It would in my case only lead to a stream of feature requests for the schemes ranging from "diffie-hellman-group2-sha1" to "diffie-hellman-group13-sha1", and would leave me with having to explain that these scheme will not be implemented because they simply do not exist. Alternative [A] is better than [C], but I prefer [B] since it is the most self-documenting name. -- Henrick Hellström www.streamsec.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 26 18:59:15 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22642 for ; Thu, 26 Aug 2004 18:59:14 -0400 (EDT) Received: (qmail 22491 invoked by uid 605); 26 Aug 2004 22:59:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22472 invoked from network); 26 Aug 2004 22:59:09 -0000 Received: from shitei.mindrot.org (203.217.30.81) by mail.netbsd.org with SMTP; 26 Aug 2004 22:59:08 -0000 Received: from baragon.mindrot.org (unknown [IPv6:3ffe:8001:22:1:202:6fff:fe34:51fd]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "baragon.mindrot.org", Issuer "mindrot.org root CA" (verified OK)) by shitei.mindrot.org (Postfix) with ESMTP id BB74527C189; Fri, 27 Aug 2004 08:27:09 +1000 (EST) Received: from mindrot.org (localhost [127.0.0.1]) by baragon.mindrot.org (Postfix) with ESMTP id 380931BAC53; Fri, 27 Aug 2004 08:30:06 +1000 (EST) Message-ID: <412E646D.50007@mindrot.org> Date: Fri, 27 Aug 2004 08:30:05 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 0.5 (X11/20040808) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Tatham Cc: ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal (fwd) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Simon Tatham wrote: > Niels Möller wrote: > >>I think a lot of peple are silent. It's hard to tell if that's because >>they agree, or don't care, or are all on vacation. > > > I think any scheme would be perfectly adequate provided it was > clearly defined what name went with which group, and clearly defined > which groups implementors needed to support in the general case. > > As far as I'm concerned, this is one of those situations in which > the utilities of the various choices go something like: > > * choice A, ten points > * choice B, nine and a half points > * choice C, nine points > * long delay caused by debating the various options in detail, > minus one thousand points. :-) Hear, hear. IMO the cost of having a slightly inconsistent group naming convention (which we already agreed on) is much less than the cost of deploying secsh yet again. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 26 18:59:23 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22662 for ; Thu, 26 Aug 2004 18:59:22 -0400 (EDT) Received: (qmail 22501 invoked by uid 605); 26 Aug 2004 22:59:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22474 invoked from network); 26 Aug 2004 22:59:09 -0000 Received: from shitei.mindrot.org (203.217.30.81) by mail.netbsd.org with SMTP; 26 Aug 2004 22:59:08 -0000 Received: from baragon.mindrot.org (unknown [IPv6:3ffe:8001:22:1:202:6fff:fe34:51fd]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "baragon.mindrot.org", Issuer "mindrot.org root CA" (verified OK)) by shitei.mindrot.org (Postfix) with ESMTP id 6424527C187; Fri, 27 Aug 2004 08:25:01 +1000 (EST) Received: from mindrot.org (localhost [127.0.0.1]) by baragon.mindrot.org (Postfix) with ESMTP id 0C8AC1BAC53; Fri, 27 Aug 2004 08:27:58 +1000 (EST) Message-ID: <412E63ED.8050807@mindrot.org> Date: Fri, 27 Aug 2004 08:27:57 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 0.5 (X11/20040808) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sommerfeld@sun.com Cc: ietf-ssh@NetBSD.org Subject: Re: Straw Poll on group name References: <200408262019.i7QKJRvU025309@thunk.east.sun.com> In-Reply-To: <200408262019.i7QKJRvU025309@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Bill Sommerfeld wrote: > At the end of this message, you'll find a summary from Tero Kivinen of > the usage by other protocols of the common MODP groups on the saag > list; I think it conclusively demonstrates that every user of the MODP > groups is doing something different. > > That only leaves > > straw poll: > In your response to the poll, please: > a) explain the one you prefer and why. > [C] we should refer to groups by the ike number > [sample] diffie-hellman-group14-sha1 Why: because it is deployed, because we should be way past the point of making fiddling changes to things we have already agreed upon, and because the mooted move to DH-GEX means the registry will only be of passing importance anyway. > b) list any options you find unacceptable and explain why. The other two: diffie-hellman-group14-sha1 is deployed. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 26 19:24:46 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24061 for ; Thu, 26 Aug 2004 19:24:45 -0400 (EDT) Received: (qmail 15713 invoked by uid 605); 26 Aug 2004 23:24:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15703 invoked from network); 26 Aug 2004 23:24:44 -0000 Received: from shitei.mindrot.org (203.217.30.81) by mail.netbsd.org with SMTP; 26 Aug 2004 23:24:43 -0000 Received: from baragon.mindrot.org (unknown [61.95.66.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "baragon.mindrot.org", Issuer "mindrot.org root CA" (verified OK)) by shitei.mindrot.org (Postfix) with ESMTP id DC77227C187; Fri, 27 Aug 2004 09:21:37 +1000 (EST) Received: from mindrot.org (localhost [127.0.0.1]) by baragon.mindrot.org (Postfix) with ESMTP id 751D31BAC78; Fri, 27 Aug 2004 09:24:23 +1000 (EST) Message-ID: <412E7127.5000308@mindrot.org> Date: Fri, 27 Aug 2004 09:24:23 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 0.5 (X11/20040808) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Damien Miller Cc: Simon Tatham , ietf-ssh@NetBSD.org Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal (fwd) References: <412E646D.50007@mindrot.org> In-Reply-To: <412E646D.50007@mindrot.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Damien Miller wrote: > Hear, hear. IMO the cost of having a slightly inconsistent group naming > convention (which we already agreed on) is much less than the cost of > deploying secsh yet again. s/deploying/delaying/ -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 26 19:24:57 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24079 for ; Thu, 26 Aug 2004 19:24:57 -0400 (EDT) Received: (qmail 16060 invoked by uid 605); 26 Aug 2004 23:24:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16048 invoked from network); 26 Aug 2004 23:24:56 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 26 Aug 2004 23:24:55 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6562311 for ietf-ssh@netbsd.org; Thu, 26 Aug 2004 17:24:54 -0600 Message-ID: <412E714B.3070103@vandyke.com> Date: Thu, 26 Aug 2004 17:24:59 -0600 From: Joseph Galbraith Reply-To: sommerfeld@sun.com User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040823) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Straw Poll on group name Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > straw poll: > [A] we should use small integers to refer to common groups > [sample] diffie-hellman-group2-sha1 > > [B] we should refer to groups by size: > [sample] diffie-hellman-group2048-sha1 > > [C] we should refer to groups by the ike number > [sample] diffie-hellman-group14-sha1 I prefer [A]. People definitely already have a deployed instance of [A] (diffie-hellman-group1-sha1.) It sounds like some people already have a deployed instance that could fit into [C] (diffie-hellman-group14-sha1.) I propose that we actually interpret 'diffie-hellman-group14-sha1 as a member of the ssh specific registry, and put a note in that groups 2-13 are not defined. Alternatively, we can quick, grab 12 more groups out of IKE, randomize their numbers, and assign them to 2-13 so we can have the monotonically increasing property :-) (I'm kidding!) I agree that if we've got shipping code already using group14-sha1 it would not be good to change it at this point. (This is one of the results of the SSH working group having taken ______wayyyy_____ to long to get something out the door; we've got code shipping on drafts making it hard to change things. So my vote is for [A], with a note that for historical reasons, groups 2-13 are unused. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 26 20:00:53 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25992 for ; Thu, 26 Aug 2004 20:00:53 -0400 (EDT) Received: (qmail 18110 invoked by uid 605); 27 Aug 2004 00:00:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18087 invoked from network); 27 Aug 2004 00:00:38 -0000 Received: from quick.recoil.org (194.70.3.133) by mail.netbsd.org with SMTP; 27 Aug 2004 00:00:38 -0000 Received: (qmail 24269 invoked by uid 10000); 26 Aug 2004 23:33:54 -0000 Date: Fri, 27 Aug 2004 00:33:54 +0100 From: Anil Madhavapeddy To: Bill Sommerfeld Cc: ietf-ssh@NetBSD.org Subject: Re: Straw Poll on group name Message-ID: <20040826233354.GA27429@quick.recoil.org> References: <200408262019.i7QKJRvU025309@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408262019.i7QKJRvU025309@thunk.east.sun.com> User-Agent: Mutt/1.4.2i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Aug 26, 2004 at 04:19:27PM -0400, Bill Sommerfeld wrote: > > straw poll: > [A] we should use small integers to refer to common groups > [sample] diffie-hellman-group2-sha1 > > [B] we should refer to groups by size: > [sample] diffie-hellman-group2048-sha1 > > [C] we should refer to groups by the ike number > [sample] diffie-hellman-group14-sha1 > I fail to see how anything other than [C] would be useful, given that: $ pwd /usr/src/usr.bin/ssh $ grep -r diffie-hellman-group14-sha1 * kex.h:#define KEX_DH14 "diffie-hellman-group14-sha1" Any implementation would have to support it anyway for good interop with OpenSSH. -- Anil Madhavapeddy http://anil.recoil.org University of Cambridge http://www.cl.cam.ac.uk From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 27 02:49:26 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03734 for ; Fri, 27 Aug 2004 02:49:26 -0400 (EDT) Received: (qmail 24348 invoked by uid 605); 27 Aug 2004 06:49:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24338 invoked from network); 27 Aug 2004 06:49:23 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 27 Aug 2004 06:49:23 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 14A0119B9DF; Fri, 27 Aug 2004 08:49:22 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id B729F18D369; Fri, 27 Aug 2004 08:49:18 +0200 (MEST) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i7R6nIih022124; Fri, 27 Aug 2004 08:49:18 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i7R6nEeE022121; Fri, 27 Aug 2004 08:49:14 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: sommerfeld@sun.com Cc: ietf-ssh@NetBSD.org Subject: Re: Straw Poll on group name References: <200408262019.i7QKJRvU025309@thunk.east.sun.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 27 Aug 2004 08:49:13 +0200 In-Reply-To: <200408262019.i7QKJRvU025309@thunk.east.sun.com> Message-ID: Lines: 17 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Bill Sommerfeld writes: > straw poll: > [A] we should use small integers to refer to common groups > [sample] diffie-hellman-group2-sha1 > > [B] we should refer to groups by size: > [sample] diffie-hellman-group2048-sha1 > > [C] we should refer to groups by the ike number > [sample] diffie-hellman-group14-sha1 I prefer A. It's simple, consistent with the naming of diffie-hellman-group1-sha1, and I think we need our own registry anyway. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 27 03:11:13 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04887 for ; Fri, 27 Aug 2004 03:11:12 -0400 (EDT) Received: (qmail 19220 invoked by uid 605); 27 Aug 2004 07:11:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19206 invoked from network); 27 Aug 2004 07:11:11 -0000 Received: from nic.appgate.com (HELO nic2.appgate.com) (212.214.117.82) by mail.netbsd.org with SMTP; 27 Aug 2004 07:11:10 -0000 Received: from shala.firedoor.se (shala.got.appgate.com [172.23.2.27]) by nic2.appgate.com (Postfix) with ESMTP id 2ED891F348B; Fri, 27 Aug 2004 08:54:10 +0200 (MEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id E614E6C094; Fri, 27 Aug 2004 08:54:11 +0200 (MEST) Date: Fri, 27 Aug 2004 08:53:39 +0200 (CEST) From: Martin Forssen Subject: Re: Straw Poll on group name To: sommerfeld@sun.com Cc: ietf-ssh@NetBSD.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE Message-Id: <20040827065411.E614E6C094@shala.firedoor.se> Sender: ietf-ssh-owner@NetBSD.org Precedence: list On 26 Aug, Joseph Galbraith wrote: > I prefer [A]. > > People definitely already have a deployed instance > of [A] (diffie-hellman-group1-sha1.) It sounds > like some people already have a deployed instance > that could fit into [C] (diffie-hellman-group14-sha1.) > > I propose that we actually interpret 'diffie-hellman-group14-sha1 > as a member of the ssh specific registry, and put a note > in that groups 2-13 are not defined. I also think this is the best solution. /MaF -- Martin Forssen Development Manager Phone: +46 31 7744361 AppGate Network Security AB From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 27 05:45:14 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14439 for ; Fri, 27 Aug 2004 05:45:14 -0400 (EDT) Received: (qmail 7074 invoked by uid 605); 27 Aug 2004 09:45:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7048 invoked from network); 27 Aug 2004 09:45:12 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 27 Aug 2004 09:45:12 -0000 Received: from folly.informatik.uni-erlangen.de (localhost [127.0.0.1]) by faui03.informatik.uni-erlangen.de (8.12.9/8.12.9) with ESMTP id i7R9HbIJ012603 for ; Fri, 27 Aug 2004 09:17:37 GMT Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 0843614258; Fri, 27 Aug 2004 11:17:34 +0200 (CEST) Date: Fri, 27 Aug 2004 11:17:34 +0200 From: Markus Friedl To: ietf-ssh@NetBSD.org Subject: Re: Straw Poll on group name Message-ID: <20040827091734.GA20971@folly> References: <200408262019.i7QKJRvU025309@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408262019.i7QKJRvU025309@thunk.east.sun.com> User-Agent: Mutt/1.4.2i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Aug 26, 2004 at 04:19:27PM -0400, Bill Sommerfeld wrote: > [C] we should refer to groups by the ike number > [sample] diffie-hellman-group14-sha1 We already agreed on the name "diffie-hellman-group14-sha1" and OpenSSH 3.9 ships with this identifier. The other groups don't matter since we agreed to recommend DH-GEX for the future. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 27 06:25:17 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16856 for ; Fri, 27 Aug 2004 06:25:17 -0400 (EDT) Received: (qmail 14509 invoked by uid 605); 27 Aug 2004 10:25:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14497 invoked from network); 27 Aug 2004 10:25:15 -0000 Received: from mailhost.auckland.ac.nz (HELO smtpd.itss.auckland.ac.nz) (130.216.190.14) by mail.netbsd.org with SMTP; 27 Aug 2004 10:25:15 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 0486533F54; Fri, 27 Aug 2004 21:56:10 +1200 (NZST) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19442-04; Fri, 27 Aug 2004 21:56:09 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id B3EFC33F32; Fri, 27 Aug 2004 21:56:09 +1200 (NZST) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 89BCD37747; Fri, 27 Aug 2004 21:56:09 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 3.36 #1 (Debian)) id 1C0dSy-0000cB-00; Fri, 27 Aug 2004 21:56:16 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: sommerfeld@sun.com Subject: Re: Straw Poll on group name Cc: ietf-ssh@NetBSD.org In-Reply-To: <200408262019.i7QKJRvU025309@thunk.east.sun.com> Message-Id: Date: Fri, 27 Aug 2004 21:56:16 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list >In your response to the poll, please: > a) explain the one you prefer and why. [A]. SSH will need to maintain its own registry anyway even if we go for [B] (the exact definition of "group 2048" will need to be specified somewhere in the same way that "group 2" will), and monotonically-increasing small integers are much cleaner and more flexible than a pile of arbitrary-sized numbers. In addition the fixed-bit-size numbers are non-reusable, so if (for example) a problem is found in "group 2048" necessitating its replacement with a different "group 2048" without the problem, there's no way to do it. With "group 2" you just replace it with "group 3". As for the "group 14" issue, just CNAME it to "group 2" with a note about it being that way for historical purposes, it's an absolutely trivial fix. > b) list any options you find unacceptable and explain why. [C]. It's tying SSH to the (unpredictable and uncontrollable) decisions of a completely unrelated standards group. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 27 07:27:02 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20769 for ; Fri, 27 Aug 2004 07:27:01 -0400 (EDT) Received: (qmail 14456 invoked by uid 605); 27 Aug 2004 11:26:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14446 invoked from network); 27 Aug 2004 11:26:56 -0000 Received: from fw.hel.fi.ssh.com (195.20.116.97) by mail.netbsd.org with SMTP; 27 Aug 2004 11:26:56 -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.16) with SMTP id i7RBQsQs020140 for ; Fri, 27 Aug 2004 14:26:54 +0300 (EEST) Received: (qmail 25904 invoked from network); 27 Aug 2004 11:26:53 -0000 Received: from unknown (HELO ?127.0.0.1?) ([10.1.54.184]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 27 Aug 2004 11:26:53 -0000 Message-ID: <412F1A7D.7040206@ssh.com> Date: Fri, 27 Aug 2004 14:26:53 +0300 From: "Timo J. Rinne" Reply-To: tri@ssh.com Organization: SSH Communications Security Corp. User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sommerfeld@sun.com CC: ietf-ssh@NetBSD.org Subject: Re: Straw Poll on group name References: <200408262019.i7QKJRvU025309@thunk.east.sun.com> In-Reply-To: <200408262019.i7QKJRvU025309@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 Bill Sommerfeld wrote: > At the end of this message, you'll find a summary from Tero Kivinen of > the usage by other protocols of the common MODP groups on the saag > list; I think it conclusively demonstrates that every user of the MODP > groups is doing something different. > > That only leaves > > straw poll: > [A] we should use small integers to refer to common groups > [sample] diffie-hellman-group2-sha1 > > [B] we should refer to groups by size: > [sample] diffie-hellman-group2048-sha1 > > [C] we should refer to groups by the ike number > [sample] diffie-hellman-group14-sha1 > > In your response to the poll, please: > a) explain the one you prefer and why. > b) list any options you find unacceptable and explain why. I prefer A and find C unacceptable. A is simple and gives us simple and unambiguous way to refer any dh-group in any standard document we like. It is also logic continuation of the current practise. B is better since we probably are not going to make more than one group of one specific size. However we already have a group not using this convention. Also why knowingly limit the possibility to consistently name several groups in a consistent matter. C is clearly against the common practise in current protocol standard drafts. It is also inherently inconsistent having already one exception in ssh-draft. More inconsistency arises from the fact that we are not going to use entire ike namespace. -- Timo J. Rinne http://www.ssh.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 27 08:20:31 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24330 for ; Fri, 27 Aug 2004 08:20:30 -0400 (EDT) Received: (qmail 6348 invoked by uid 605); 27 Aug 2004 12:20:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6338 invoked from network); 27 Aug 2004 12:20:28 -0000 Received: from sj-iport-5.cisco.com (171.68.10.87) by mail.netbsd.org with SMTP; 27 Aug 2004 12:20:28 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 27 Aug 2004 05:20:27 -0700 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7RCKN6B008452 for ; Fri, 27 Aug 2004 05:20:23 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA02511 for ; Fri, 27 Aug 2004 05:20:25 -0700 (PDT) Date: Fri, 27 Aug 2004 05:20:25 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: Straw Poll on group name In-Reply-To: <20040826233354.GA27429@quick.recoil.org> Message-ID: References: <200408262019.i7QKJRvU025309@thunk.east.sun.com> <20040826233354.GA27429@quick.recoil.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, I'll keep my "editor" hat on so don't consider this to be a vote. On Fri, 27 Aug 2004, Anil Madhavapeddy wrote: > > [C] we should refer to groups by the ike number > > [sample] diffie-hellman-group14-sha1 > > > > I fail to see how anything other than [C] would be useful, given that: > We could continue with [A] and define diffie-hellman-group14-sha1 in [TRANS]. A simple note to the IANA in [NUMBERS] could state that future values of N MUST NOT include 14. For some reason, I am reminded of the scene from "Monty Python and the Holy Grail" in which they discuss counting to three before throwing the Holy Hand Grenade. :-) Let's get this resolved and move on. Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 27 10:17:21 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01924 for ; Fri, 27 Aug 2004 10:17:21 -0400 (EDT) Received: (qmail 2759 invoked by uid 605); 27 Aug 2004 14:17:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2749 invoked from network); 27 Aug 2004 14:17:19 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 27 Aug 2004 14:17:19 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 85B7D1985D6; Fri, 27 Aug 2004 16:16:51 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 62A9119861C; Fri, 27 Aug 2004 16:16:48 +0200 (MEST) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i7REGmih026041; Fri, 27 Aug 2004 16:16:48 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i7REGgbk026038; Fri, 27 Aug 2004 16:16:42 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Chris Lonvick Cc: ietf-ssh@NetBSD.org Subject: Re: Straw Poll on group name References: <200408262019.i7QKJRvU025309@thunk.east.sun.com> <20040826233354.GA27429@quick.recoil.org> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 27 Aug 2004 16:16:41 +0200 In-Reply-To: Message-ID: Lines: 18 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Chris Lonvick writes: > We could continue with [A] and define diffie-hellman-group14-sha1 in > [TRANS]. A simple note to the IANA in [NUMBERS] could state that future > values of N MUST NOT include 14. Such a note makes no sense to me at all. If we want "diffie-hellman-group14-sha1", then we go with [C], and that's it. It may be a little ugly (depending on one's taste), but it's *not* formally a special case in any way at all. When we use words like "MUST" in a spec, those words are directed to everyone who wants to implement the specification properly. It's pointless to put in "MUST":s which are directed not at implementors of our specification, but to some future working group specifying revisions or extensions to the specification. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Aug 28 18:11:15 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16160 for ; Sat, 28 Aug 2004 18:11:14 -0400 (EDT) Received: (qmail 15961 invoked by uid 605); 28 Aug 2004 22:09:31 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20040828220931.15960.qmail@mail.netbsd.org> Received: (qmail 14236 invoked from network); 28 Aug 2004 20:06:20 -0000 Received: from 205-11.dedicado.com.uy (HELO 67.17.11.205) (67.17.11.205) by mail.netbsd.org with SMTP; 28 Aug 2004 20:06:19 -0000 From: "Escuela de Logistica" To: Subject: Logistica: esa herramienta de competitividad empresarial y personal. Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Date: Sat, 28 Aug 2004 17:20:17 -0500 Reply-To: "Escuela de Logistica" Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit CORPORACION LOGISTICA SUDAMERICANA. Uruguay, Argentina, Brasil, Paraguay, Ecuador. www.csl-uy.org www.csl-uy.ar csl-uy@cslog.org FORMACION LOGISTICA: se anuncia el comienzo de la Tercera Edicion en 2004 del Diploma de Experto en Logistica, el lunes 6 de septiembre. La importancia de la Logistica: La Logistica puede ser encarada desde varios puntos de utilidad: como mejora de la competitividad de la empresa; como un complemento de la carrera profesional, en particular para todos aquellos que se encuentran en ventas, exportacion, importacion, desarrollo industrial, gestion del transporte, ingenieria, transporte aereo, maritimo y carretero, marketing, etc.; o bien como una salida laboral importante en tiempos donde el mercado exige mayores grados de especializacion e, inclusive, como un complemento laboral de utilidad inmediata. Formacion internacional, solida y practica: Nuestra filosofia de formacion es la de utilidad de aplicacion practica inmediata, formacion solida, operacional, practica y constantemente actualizada. De hecho, la sintonia con los desarrollos mas importantes en la materia, tanto europeos como norteamericanos ha hecho que, ademas de los 4000 formados que la Escuela lleva hasta este momento, seamos el soporte de formacion en MBA de Logistica y Transporte de varias universidades en la region, y que hayamos extendido nuestra formacion a Argentina, Paraguay, Brasil y Ecuador, encontrandonos en este momento en la implementacion del proeycto de formacion para operadores en Italia. Por eso es que le extendemos una cordial invitacion: venga a desarrollar sus conocimientos en logistica con quienes saben realmente de logistica. Diploma Operacional en Logistica Integral: www.csl-uy.org/pactividades.html La Logística es una herramienta estratégica para aumentar ventas, reducir costos y competir eficientemente en el mercado. Desde esa perspectiva, puede afirmarse que es una de las materias más importantes a partir de la cual elaborar el concepto de competitividad empresarial. La Logística estudia, analiza y planifica los vínculos que existen entre los eslabones productivos, el transporte, las operaciones de distribución y la gestión de inventarios; la relación entre costos y calidad del servicio y entre flujos de producto e información, hasta la comprobación de la satisfacción del cliente final. El enfoque que propone el Programa es estudiar y pensar sobre la realidad de la empresa, relacionando muchos temas que normalmente se ven por separado, permitiendo, además, profundizar verticalmente en esos temas, consiguiendo una mayor armonía y eficacia entre las diferentes funciones de la empresa. Componentes del Programa: El Programa de Formación Práctica en Logística apunta a la formación de especialistas en esta disciplina, pero, además, a que el participante pueda ver a la empresa en el mercado, compitiendo, e integrada en una cadena de interrelación con otras empresas y con los consumidores finales, convirtiéndose en una pieza eficaz de ese desarrollo. Al culminar los cursos componentes del Programa el participante estará en condiciones de utilizar y operar en la práctica los conceptos y las herramientas de logística para iniciarse profesionalmente en esta disciplina, o, estando en actividad, mejorar la gestión de su empresa y de su puesto de trabajo. Con esto, se busca la optimización de todos los recursos de la empresa, mejorando sustancialmente la competitividad de la misma. Los componentes del Programa son: þ Curso de Logística Integral. þ Curso de Gestión de Compras y Aprovisionamiento. þ Curso de Gestión de la Distribución Física. þ Curso de Gestión y Diseño de Depósitos y Almacenes. þ Curso de Gestión del Transporte. con una duracion de 20 horas cada uno. El Primer Modulo, Logistica Integral, comienza el 6 de septiembre de 2004, el Programa completo puede realizarse en el periodo septiembre - noviembre de 2004, de una forma en que no interfiera con las ocupaciones laborales de los participantes. El desarrollo completo de los contenidos del programa pueden consultarse en: www.csl-uy.org/oplogistica.html Los contenidos analiticos de los modulos y sus fechas de realizacion pueden verse en www.csl-uy.org/pactividades.html El Programa puede realizarse en modalidad presencial o a distancia con tutor personalizado. Se realizara en asociacion con la Universidad Tecnologica Nacional (Argentina). Informacion adicional: www.csl-uy.org www.csl-ar.org infogral@ilacon.org - csl-uy@cslog.org - Escuela Sudamericana de Logistica. Tristan Narvaja 1729, Montevideo, Uruguay. Telefonos 4080618 y 4080628 - Sres. Federico, Juan Manuel o Sra. Maria Noel. Horario: 9.30 a 19.00 horas, de lunes a viernes. En caso de desear ser removido de la base de informacion, por favor envie un correo a csl-uy@cslog.org. Muchas Gracias. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 30 04:53:54 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02710 for ; Mon, 30 Aug 2004 04:53:54 -0400 (EDT) Received: (qmail 6633 invoked by uid 605); 30 Aug 2004 08:53:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6624 invoked from network); 30 Aug 2004 08:53:50 -0000 Received: from mail.lcpnet.com (HELO cityserver.be) (212.35.124.73) by mail.netbsd.org with SMTP; 30 Aug 2004 08:53:50 -0000 Received: from [212.35.124.73] by cityserver.be [212.35.124.73] with SmartMax MailMax for ietf-ssh@netbsd.org; Mon, 30 Aug 2004 08:53:35 +0200 To: ietf-ssh@NetBSD.org From: "kelly-tychtl" Date: Date: Mon, 30 Aug 2004 08:53:34 +0200 Subject: Out of office Message-ID: <1093848815.15017@cityserver.be> Sender: ietf-ssh-owner@NetBSD.org Precedence: list I will be back in the office on Monday, September 6 19 2004. To leave an urgent message you can call Isabelle at: 02-548-04-90 Vazeni kolegove a kolegyne budu zpet v kancelari v pondeli 6.9. Pokud potrebujete zanechat urgentni vzkaz, volejte prosim Isabelle na cisle: 00-322-548-04-90 Pokud potrebujete jakekoli informace o projektu COOPERATE, kontaktujte, prosim, moji kolegyni Florianu Nappini: f.nappini@ecas.org From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 31 13:29:13 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07742 for ; Tue, 31 Aug 2004 13:29:12 -0400 (EDT) Received: (qmail 4397 invoked by uid 605); 31 Aug 2004 17:29:10 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20040831172910.4394.qmail@mail.netbsd.org> Received: (qmail 4387 invoked from network); 31 Aug 2004 17:29:09 -0000 Received: from unknown (HELO 211.176.161.157) (211.176.161.157) by mail.netbsd.org with SMTP; 31 Aug 2004 17:29:08 -0000 Date: Tue, 31 Aug 2004 17:03:13 +0000 From: luong To: ietf-ssh@NetBSD.org Subject: - MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1251 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 31 14:47:11 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15221 for ; Tue, 31 Aug 2004 14:47:11 -0400 (EDT) Received: (qmail 26109 invoked by uid 605); 31 Aug 2004 18:47:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26097 invoked from network); 31 Aug 2004 18:47:09 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by mail.netbsd.org with SMTP; 31 Aug 2004 18:47:09 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 31 Aug 2004 11:53:24 -0700 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7VIl1b2004836 for ; Tue, 31 Aug 2004 11:47:01 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA19475 for ; Tue, 31 Aug 2004 11:47:03 -0700 (PDT) Date: Tue, 31 Aug 2004 11:47:03 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: Invalid channel numbers In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: QUOTED-PRINTABLE Hi, Just following up on this. I believe that no editing needs to go into any of the documents from this discussion. Does anyone disagree with that? Thanks, Chris On Thu, 19 Aug 2004, [iso-8859-1] Niels M=F6ller wrote: > pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > > > What if it's a channel open where the packet ends halfway through the c= hannel > > number? You've got a request, there seems to be a requirement to send = a > > response, but you can't respond without some facility that lets you say= "The > > last channel-related request was disallowed". > > I don't see any problem here. Whenever you receive a packet that > clearly doesn't follow the spec, just reply with SSH_MSG_DISCONNECT, > SSH_DISCONNECT_PROTOCOL_ERROR, then hang up the connection. Truncated > channel requests are in this class. > > If you *really* want to be more forgiving than that, send a > SSH_MSG_DEBUG explaining the problem, and then ignore the packet. But > such behaviour goes beyond the specification. My reading of the spec > is that SSH_MSG_DISCONNECT is the only appropriate response in this > case. > > Regards, > /Niels > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 31 15:04:34 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16430 for ; Tue, 31 Aug 2004 15:04:34 -0400 (EDT) Received: (qmail 7117 invoked by uid 605); 31 Aug 2004 19:04:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7107 invoked from network); 31 Aug 2004 19:04:31 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 31 Aug 2004 19:04:30 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i7VJ3Hil010824; Tue, 31 Aug 2004 13:03:17 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i7VJ3GQH019683; Tue, 31 Aug 2004 15:03:16 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i7VJ3Gul004159; Tue, 31 Aug 2004 15:03:16 -0400 (EDT) Message-Id: <200408311903.i7VJ3Gul004159@thunk.east.sun.com> From: Bill Sommerfeld To: Chris Lonvick cc: ietf-ssh@NetBSD.org Subject: Re: Invalid channel numbers In-Reply-To: Your message of "Tue, 31 Aug 2004 11:47:03 PDT." Reply-to: sommerfeld@east.sun.com Date: Tue, 31 Aug 2004 15:03:16 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > Just following up on this. I believe that no editing needs to go into any > of the documents from this discussion. Does anyone disagree with > that? So, my sense: Clear consensus is that there is no need for any protocol changes as a result of this discussion. If someone wants to improve the existing text on error handling (fitting Niels's first paragraph on error handling into the spec), they should do so now but I don't believe it's critical. - Bill