From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 6 16:11:17 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 QAA19072 for ; Tue, 6 Jul 2004 16:11:17 -0400 (EDT) Received: (qmail 26922 invoked by uid 605); 6 Jul 2004 20:11:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26910 invoked from network); 6 Jul 2004 20:11:14 -0000 Received: from sj-iport-5.cisco.com (171.68.10.87) by mail.netbsd.org with SMTP; 6 Jul 2004 20:11:14 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 06 Jul 2004 12:42:42 -0700 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 i66JgDgI023387 for ; Tue, 6 Jul 2004 12:42:13 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA05209 for ; Tue, 6 Jul 2004 12:42:13 -0700 (PDT) Date: Tue, 6 Jul 2004 12:42:13 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: [psg.com #440] IANA - Architecture - Registries Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi Folks, Issue 440 deals with the IANA Considerations Section in [ARCH]. An IANA reviewer asked if they were existing, new, or a combination. I made a quick change from -15 to -16 stating that the "IANA Considerations" section in [ARCH] is there only for reference and that the _real_ IANA assignments are to be found in [NUMBERS]. Does anyone object to this? The alternative is to remove any information from this section in [ARCH] and simply state that all information is in [NUMBERS]. This may not be a bad alternative as most of the information in the IANA Considerations section of [ARCH] is already discussed elsewhere in [ARCH]. Can I get some consensus here: A. (default) Keep the information in [ARCH] along with the statement in [ARCH] saying that the information is reference material only and that the real info is in [NUMBERS]. B. Remove the information in [ARCH] and only point to [NUMBERS]. Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 7 12:11:15 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 MAA27996 for ; Wed, 7 Jul 2004 12:11:14 -0400 (EDT) Received: (qmail 21243 invoked by uid 605); 7 Jul 2004 16:11:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21224 invoked from network); 7 Jul 2004 16:11:03 -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; 7 Jul 2004 16:11:03 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 07 Jul 2004 08:47:53 +0000 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 i67Ffb4N023434 for ; Wed, 7 Jul 2004 08:41:37 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA18315 for ; Wed, 7 Jul 2004 08:41:35 -0700 (PDT) Date: Wed, 7 Jul 2004 08:41:35 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: [psg.com #441] IESG - Architecture - atsign Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi Folks, Let's revist the discussion of the "@". The IESG notes were relevent to the "IANA Considerations" Section in [ARCH]. However, Ticket 440 (my note from yesterday) is a request from an IANA reviewer to plainly state what parts of [ARCH] are to be used to form the initial IANA Registry. I've taken care of that by adding a note that the information in the "IANA Considerations" section of [ARCH] is there only for reference and that the _real_ IANA information is in [NUMBERS]. However, nothing about the use of "@" is actually mentioned in [NUMBERS]. I'll get that in there but I need some clarification. The discussion in [ARCH] is about algorithm names. In [NUMBERS] many of the sections prevent the use of the "@" and "," symbols with no further explanation. Are the locally defined extensions applicable to: - Service Names - Authentication Methods - Connection Protocol Channel Names - Connection Protocol Global Request Names - Connection Protocol Channel Request Names - Key Exchange Method Names - Assigned Algorithm Names - Encryption Algorithm Names - MAC Algorithm Names - Public Key Algorithm Names - Compression Algorithm Names If _ALL_ of these Names are locally extensible, then I can state quickly state that. Essentially, I'll add a section in [NUMBERS] that will state that the IANA will not accept anything with "@", but that the use of "@" in a method or name will indicate that it is outside the control of IANA. (I'll incorporate the other notes about self-control of this namespace from the prior discussion as well.) If _NOT_ALL_ of these are locally extensible, then I need to know which ones are/aren't and I'll edit appropriately. Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 7 12:21: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 MAA28488 for ; Wed, 7 Jul 2004 12:21:46 -0400 (EDT) Received: (qmail 1914 invoked by uid 605); 7 Jul 2004 16:21:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1892 invoked from network); 7 Jul 2004 16:21:45 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 7 Jul 2004 16:21:45 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6323257; Wed, 07 Jul 2004 10:21:41 -0600 Message-ID: <40EC2318.8060409@vandyke.com> Date: Wed, 07 Jul 2004 10:21:44 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040622) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Lonvick CC: ietf-ssh@NetBSD.org Subject: Re: [psg.com #441] IESG - Architecture - atsign 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 I believe all of these are locally extensible. Thanks, - Joseph Chris Lonvick wrote: > Hi Folks, > > Let's revist the discussion of the "@". The IESG notes were relevent to > the "IANA Considerations" Section in [ARCH]. However, Ticket 440 (my note > from yesterday) is a request from an IANA reviewer to plainly state what > parts of [ARCH] are to be used to form the initial IANA Registry. I've > taken care of that by adding a note that the information in the "IANA > Considerations" section of [ARCH] is there only for reference and that the > _real_ IANA information is in [NUMBERS]. However, nothing about the use > of "@" is actually mentioned in [NUMBERS]. I'll get that in there but I > need some clarification. > > The discussion in [ARCH] is about algorithm names. In [NUMBERS] many of > the sections prevent the use of the "@" and "," symbols with no further > explanation. Are the locally defined extensions applicable to: > - Service Names > - Authentication Methods > - Connection Protocol Channel Names > - Connection Protocol Global Request Names > - Connection Protocol Channel Request Names > - Key Exchange Method Names > - Assigned Algorithm Names > - Encryption Algorithm Names > - MAC Algorithm Names > - Public Key Algorithm Names > - Compression Algorithm Names > > If _ALL_ of these Names are locally extensible, then I can state quickly > state that. Essentially, I'll add a section in [NUMBERS] that will state > that the IANA will not accept anything with "@", but that the use of "@" > in a method or name will indicate that it is outside the control of IANA. > (I'll incorporate the other notes about self-control of this namespace > from the prior discussion as well.) > > If _NOT_ALL_ of these are locally extensible, then I need to know which > ones are/aren't and I'll edit appropriately. > > Thanks, > Chris > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 7 12:32: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 MAA29128 for ; Wed, 7 Jul 2004 12:32:11 -0400 (EDT) Received: (qmail 10378 invoked by uid 605); 7 Jul 2004 16:32:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10369 invoked from network); 7 Jul 2004 16:32:11 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 7 Jul 2004 16:32:10 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id MAA05088; Wed, 7 Jul 2004 12:32:09 -0400 (EDT) From: der Mouse Message-Id: <200407071632.MAA05088@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. Date: Wed, 7 Jul 2004 12:30:45 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: [psg.com #441] IESG - Architecture - atsign In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > Are the locally defined extensions applicable to: > - Service Names > - Authentication Methods > - Connection Protocol Channel Names > - Connection Protocol Global Request Names > - Connection Protocol Channel Request Names > - Key Exchange Method Names > - Assigned Algorithm Names > - Encryption Algorithm Names > - MAC Algorithm Names > - Public Key Algorithm Names > - Compression Algorithm Names > If _ALL_ of these Names are locally extensible, I think they are, and if they're not, whatever necessary should be changed so that they are. Certainly when writing my code I've been assuming they are, and in some cases it's difficult to see any good stubstitute if they're not. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 7 13:01:44 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 NAA01085 for ; Wed, 7 Jul 2004 13:01:43 -0400 (EDT) Received: (qmail 4710 invoked by uid 605); 7 Jul 2004 16:57:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4661 invoked from network); 7 Jul 2004 16:57:50 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 7 Jul 2004 16:57:50 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 1BiFCk-0002P1-00; Wed, 07 Jul 2004 17:23:30 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@NetBSD.org In-Reply-To: Subject: Re: [psg.com #441] IESG - Architecture - atsign Message-Id: Date: Wed, 07 Jul 2004 17:23:30 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Chris Lonvick wrote: > If _ALL_ of these Names are locally extensible, then I can state quickly > state that. I believe that is (or should be) correct. The only purpose in using string identifiers _at all_, with their extra space cost, is so that they can be conveniently extensible in a way that pure 32-bit integers are not. Therefore, anywhere the protocol defines a string identifier, it should be extensible using the @ mechanism. Cheers, Simon -- Simon Tatham "Every person has a thinking part that wonders what the part that isn't thinking isn't thinking about." From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Jul 11 15:39: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 PAA09419 for ; Sun, 11 Jul 2004 15:39:32 -0400 (EDT) Received: (qmail 17134 invoked by uid 605); 11 Jul 2004 19:39:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17084 invoked from network); 11 Jul 2004 19:38:57 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 11 Jul 2004 19:38:57 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 792CA152223; Sun, 11 Jul 2004 21:14: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 E32D0152220; Sun, 11 Jul 2004 21:14:22 +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 i6BJEMih027966; Sun, 11 Jul 2004 21:14:22 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i6BJEJIJ027963; Sun, 11 Jul 2004 21:14:19 +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: [psg.com #441] IESG - Architecture - atsign 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: 11 Jul 2004 21:14:18 +0200 In-Reply-To: Message-ID: Lines: 9 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: > If _ALL_ of these Names are locally extensible, then I can state quickly > state that. My understanding of the specs have always been that *all* the names are locally extendable. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 20 14:30:03 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 OAA13468 for ; Tue, 20 Jul 2004 14:30:02 -0400 (EDT) Received: (qmail 20929 invoked by uid 605); 20 Jul 2004 18:29:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20533 invoked from network); 20 Jul 2004 18:29:28 -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; 20 Jul 2004 18:29:28 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 20 Jul 2004 11:31:04 -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 i6KITQIV009501 for ; Tue, 20 Jul 2004 11:29:26 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA09958 for ; Tue, 20 Jul 2004 11:29:26 -0700 (PDT) Date: Tue, 20 Jul 2004 11:29:26 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Message Numbers and Disconnect Codes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi Folks, I'm working on adding the "@"-extension rules into [NUMBERS] and have some questions. The "Message Numbers" section allocates the ranges of numbers to specific payload types - e.g., 1 - 19 for Transport layer generic 20 - 29 for Algorithm negotiation etc. It then goes on to RESERVE the values [128..191], and then allocates [192..255] for "Local Extensions". However, the subsequent subsection on "Disconnect Codes" just has a sequential list of codes with no instructions for range allocation. My questions: - How are the Local Extension Message Numbers going to be used? If implementor A defines 200 as SSH_MSG_just_use_xor and implementor B defines 200 as SSH_MSG_Luke__use_the_Force, then there could be some problems if they meet each other in the wild. There doesn't appear to be any way to say 200@careless.org or 200@deathstar.gov as is defined with the non-numbered Local Extensions. - If we resolve that one, should we declare a range of Disconnect Codes for Local Extensions? Is anyone using the Local Extension Message Numbers and can they state how they are trying to avoid interoperability problems? Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 20 17:38:20 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 RAA08969 for ; Tue, 20 Jul 2004 17:38:19 -0400 (EDT) Received: (qmail 6694 invoked by uid 605); 20 Jul 2004 21:12:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6663 invoked from network); 20 Jul 2004 21:12:50 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 20 Jul 2004 21:12:50 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26275; Tue, 20 Jul 2004 16:23:19 -0400 (EDT) Message-Id: <200407202023.QAA26275@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-gsskeyex-08.txt Date: Tue, 20 Jul 2004 16:23:19 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : GSSAPI Authentication and Key Exchange for the Secure Shell Protocol Author(s) : J. Hutzelman, et al. Filename : draft-ietf-secsh-gsskeyex-08.txt Pages : 34 Date : 2004-7-20 The Secure Shell protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. The Generic Security Service Application Program Interface (GSS-API) [GSSAPI] provides security services to callers in a mechanism-independent fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-gsskeyex-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-gsskeyex-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-gsskeyex-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-20160343.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-gsskeyex-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-gsskeyex-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20160343.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 20 20:24:48 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 UAA10288 for ; Tue, 20 Jul 2004 20:24:48 -0400 (EDT) Received: (qmail 11239 invoked by uid 605); 21 Jul 2004 00:21:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10479 invoked from network); 21 Jul 2004 00:20:51 -0000 Received: from chiark.greenend.org.uk (193.201.200.170) by mail.netbsd.org with SMTP; 21 Jul 2004 00:20:50 -0000 Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local for ietf-ssh@netbsd.org id 1Bn3Rb-000654-00; Tue, 20 Jul 2004 23:50:43 +0100 Date: Tue, 20 Jul 2004 23:50:43 +0100 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: Data transfer during key re-exchange Message-ID: <20040720225043.GB17295@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40E04511.9020304@vandyke.com> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Joseph Galbraith writes: > Jacob Nevins wrote: > > What happens to "application data" (connection protocol etc) during a > > key re-exchange is still not specified by the current transport draft > > (transport-18). [snip my suggestion] > > If anyone has objections, this issue should at least go in the issue > > tracker, so it doesn't get lost again. > > Every time this discussion has come up before I've looked for > the language that I knew was there in section 7.1, and then > found it in section 7.3 (which really is quite clear, if misplaced) [snip] > And in section 9, [snip] > I've never quite understood the confusion on this issue... however, > I don't object to the new text. I do object to it's proposed > location though... I think it should go in Section 7.1 and section > 7.3 could be condensed a little bit to remove redunancy. Fair enough. > If a re-enforcing sentance is needed in section 9 (processed identically > including valid packet restrictions) I wouldn't mind that. > > I would strike the final paragraph of section 9-- it is wrong (key > exchanges _does_ affect the protocols because we stop sending their > data for the duration) and only introduces confusion about an issue that > is pretty well specified otherwise. I guess we could reword it as our > re-enforcing sentance: [snip] OK. How about this for a proposed change to transport-18?: At the end of Section 7.1, add the following two paragraphs: Once a party has sent a KEXINIT message for key exchange or re-exchange, it MUST NOT send any messages other than key exchange method specific messages (message numbers 30 to 49); NEWKEYS; and DISCONNECT, IGNORE, and DEBUG; until it has sent a NEWKEYS message (Section 7.3). Implementations MUST NOT accept messages other than these between receiving KEXINIT and NEWKEYS messages. Note however that during a key re-exchange, after sending a KEXINIT message, each party MUST be prepared to process an arbitrary number of received messages that may be "in flight" before seeing a KEXINIT from the other party. Replace the last paragraph of Section 7.3 ("This message is [...] receiving SSH_MSG_NEWKEYS.") with the following paragraph: The purpose of this message is to ensure that a party is able to respond with a SSH_MSG_DISCONNECT message that the other party can understand if something goes wrong with the key exchange. Replace the last paragraph of Section 9 ("More application data [...] SSH_MSG_NEWKEYS is sent") with the following paragraph: Key exchange does not affect the protocols that lie above the SSH transport layer, except that such protocol data MUST NOT be sent after a SSH_MSG_KEXINIT is sent but before a SSH_MSG_NEWKEYS is sent. (For convenience I've put a marked-up copy of transport-18 at .) From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 20 21:38:44 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 VAA22916 for ; Tue, 20 Jul 2004 21:38:43 -0400 (EDT) Received: (qmail 871 invoked by uid 605); 21 Jul 2004 01:38:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 862 invoked from network); 21 Jul 2004 01:38:40 -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; 21 Jul 2004 01:38:40 -0000 Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa31179; 20 Jul 2004 21:38 EDT Date: Tue, 20 Jul 2004 21:38:16 -0400 From: Jeffrey Hutzelman To: ietf-ssh@NetBSD.org Subject: Re: Data transfer during key re-exchange Message-ID: <53010000.1090373896@mariner.pc.cs.cmu.edu> In-Reply-To: <20040720225043.GB17295@chiark.greenend.org.uk> References: <20040720225043.GB17295@chiark.greenend.org.uk> 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 Tuesday, July 20, 2004 23:50:43 +0100 Jacob Nevins wrote: > At the end of Section 7.1, add the following two paragraphs: > > Once a party has sent a KEXINIT message for key exchange or > re-exchange, it MUST NOT send any messages other than key exchange > method specific messages (message numbers 30 to 49); NEWKEYS; and > DISCONNECT, IGNORE, and DEBUG; until it has sent a NEWKEYS message > (Section 7.3). Implementations MUST NOT accept messages other than > these between receiving KEXINIT and NEWKEYS messages. Uh, what's wrong with SSH_MSG_UNINPLEMENTED? 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. For that matter, I'm not convinced that the not-yet-defined messages in the 1-19 range should be excluded either. All of the defined messages in this range have meaning at the lowest layer, independent of key exchange state. Why do we think any future messages in this range won't have the same property? I'd say permit any messages in the 1-49 range, with the possible exception of SSH_MSG_KEXINIT itself. Note that this must be handled carefully - once you send a KEXINIT, you're not allowed to _send_ another one, but you certainly are allowed to _receive_ one if you haven't seen it yet. The text you propose seems clear enough to me in this regard; an implementation that gets this wrong won't be able to rekey at all! > Key exchange does not affect the protocols that lie above the SSH > transport layer, except that such protocol data MUST NOT be sent > after a SSH_MSG_KEXINIT is sent but before a SSH_MSG_NEWKEYS is > sent. It occurs to me that what we're really trying to say is "key exchange does not affect the STATE OF protocols that lie above the SSH transport layer...". It can introduce arbitrary delay, but that's it. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 20 23:27: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 XAA11746 for ; Tue, 20 Jul 2004 23:27:30 -0400 (EDT) Received: (qmail 13727 invoked by uid 605); 21 Jul 2004 03:27:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13714 invoked from network); 21 Jul 2004 03:27:28 -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; 21 Jul 2004 03:27:28 -0000 Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa31162; 20 Jul 2004 21:27 EDT Date: Tue, 20 Jul 2004 21:27:10 -0400 From: Jeffrey Hutzelman To: Chris Lonvick , ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes Message-ID: <52740000.1090373230@mariner.pc.cs.cmu.edu> In-Reply-To: References: 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 Tuesday, July 20, 2004 11:29:26 -0700 Chris Lonvick wrote: > - How are the Local Extension Message Numbers going to be used? > If implementor A defines 200 as SSH_MSG_just_use_xor and implementor B > defines 200 as SSH_MSG_Luke__use_the_Force, then there could be some > problems if they meet each other in the wild. There doesn't appear to be > any way to say 200@careless.org or 200@deathstar.gov as is defined with > the non-numbered Local Extensions. The various named algorithms, methods, etc use the @domain mechanism to allow naming of algorithms originating outside the IETF without placing a burden on the IANA. These apply only to the specific directions in which the protocol was designed to be extended. Such names are intended to be globally unique, even when they originate outside the IETF; this is accomplished by delegating a portion of the namespace to domain registrants. So, the user auth method "just_believe_me@cmu.edu" doesn't describe a method in use at cmu.edu; it describes a method _named by_ someone at cmu.edu, regardless of where it is used. Thus these are not "local" extensions; just delegated namespace. By contrast, the message number space is not intended to be extended in this fashion. Message numbers are not a generic extension mechanism, though in limited cases the protocol may end up being extended by the addition of a new message type. When that happens it will generally be through the IETF, and the message number will be allocated by IANA. There is no expectation that entities other than the IANA will be able to allocate globally-recognized message numbers. However, it is desirable to be able to carry out development and experimentation, and to deploy site-local (private) extensions, without allocating a globally-unique message number from IANA. This is particular true because the space available is limited, and so we can't afford to have a couple hundred sites each have a globally-unique number allocated for their experimental extension. The solution is the "Local Extensions" range, which is effectively a range of numbers guaranteed not to be assigned by IANA or used by the IETF. Thus it is safe to use these numbers for local extensions without fear of colliding with a number allocated for a new standard feature. Of course you don't get a guarantee of not colliding with a number allocated by another site, but that's what you get with a limited namespace. In practice, this usually does not turn out to be a problem. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 21 07:26: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 HAA08633 for ; Wed, 21 Jul 2004 07:26:19 -0400 (EDT) Received: (qmail 13518 invoked by uid 605); 21 Jul 2004 11:26:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13490 invoked from network); 21 Jul 2004 11:26:08 -0000 Received: from chiark.greenend.org.uk (193.201.200.170) by mail.netbsd.org with SMTP; 21 Jul 2004 11:26:07 -0000 Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local for ietf-ssh@netbsd.org id 1BnFEc-00010K-00; Wed, 21 Jul 2004 12:26:06 +0100 Date: Wed, 21 Jul 2004 12:26:06 +0100 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Transport messages during kex (was Re: Data transfer during key re-exchange) Message-ID: <20040721112606.GA10106@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53010000.1090373896@mariner.pc.cs.cmu.edu> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Jeffrey Hutzelman writes: > On Tuesday, July 20, 2004 23:50:43 +0100 Jacob Nevins > wrote: > > > At the end of Section 7.1, add the following two paragraphs: > > > > Once a party has sent a KEXINIT message for key exchange or > > re-exchange, it MUST NOT send any messages other than key exchange > > method specific messages (message numbers 30 to 49); NEWKEYS; and > > DISCONNECT, IGNORE, and DEBUG; until it has sent a NEWKEYS message > > (Section 7.3). Implementations MUST NOT accept messages other than > > these between receiving KEXINIT and NEWKEYS messages. > > Uh, what's wrong with SSH_MSG_UNINPLEMENTED? OK, now this is a whole new discussion, opening issues with the original draft. Can we get consensus and/or raise a ticket for the app-data- during-rekey issue so that it doesn't get lost yet again in this discussion? That said, I can't see a reason not to include UNIMPLEMENTED, given its status alongside the others in section 11 as being able to be sent by either party at any time. > 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. (I admit that this is partly due to the IESG's apparent paranoia about over-extensibility; I don't want to see the drafts being held up again on my account if there's some gremlin we haven't thought of.) > For that matter, I'm not convinced that the not-yet-defined messages in the > 1-19 range should be excluded either. All of the defined messages in this > range have meaning at the lowest layer, independent of key exchange state. Are you really suggesting that SERVICE_REQUEST and SERVICE_ACCEPT should be permitted during key exchange? > Why do we think any future messages in this range won't have the same > property? If we're unhappy with SERVICE_REQUEST and _ACCEPT (as I think I am), then future messages in this range may have the same undesirable properties as them. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 21 08:40:48 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 IAA13441 for ; Wed, 21 Jul 2004 08:40:47 -0400 (EDT) Received: (qmail 26981 invoked by uid 605); 21 Jul 2004 12:40:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26918 invoked from network); 21 Jul 2004 12:40:14 -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; 21 Jul 2004 12:40:14 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 21 Jul 2004 05:41:59 -0700 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 i6LCeC8a013378; Wed, 21 Jul 2004 05:40:12 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA01929; Wed, 21 Jul 2004 05:40:12 -0700 (PDT) Date: Wed, 21 Jul 2004 05:40:11 -0700 (PDT) From: Chris Lonvick To: Jeffrey Hutzelman cc: ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes In-Reply-To: <52740000.1090373230@mariner.pc.cs.cmu.edu> Message-ID: References: <52740000.1090373230@mariner.pc.cs.cmu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, On Tue, 20 Jul 2004, Jeffrey Hutzelman wrote: > > > On Tuesday, July 20, 2004 11:29:26 -0700 Chris Lonvick > wrote: > > > - How are the Local Extension Message Numbers going to be used? > > If implementor A defines 200 as SSH_MSG_just_use_xor and implementor B > > defines 200 as SSH_MSG_Luke__use_the_Force, then there could be some > > problems if they meet each other in the wild. There doesn't appear to be > > any way to say 200@careless.org or 200@deathstar.gov as is defined with > > the non-numbered Local Extensions. > > > The various named algorithms, methods, etc use the @domain mechanism to > allow naming of algorithms originating outside the IETF without placing a > burden on the IANA. These apply only to the specific directions in which > the protocol was designed to be extended. Such names are intended to be > globally unique, even when they originate outside the IETF; this is > accomplished by delegating a portion of the namespace to domain > registrants. So, the user auth method "just_believe_me@cmu.edu" doesn't > describe a method in use at cmu.edu; it describes a method _named by_ > someone at cmu.edu, regardless of where it is used. Thus these are not > "local" extensions; just delegated namespace. > > > By contrast, the message number space is not intended to be extended in > this fashion. Message numbers are not a generic extension mechanism, > though in limited cases the protocol may end up being extended by the > addition of a new message type. When that happens it will generally be > through the IETF, and the message number will be allocated by IANA. There > is no expectation that entities other than the IANA will be able to > allocate globally-recognized message numbers. For Message Numbers, I can propose text such as: Requests for assignments of new message numbers in the range of 1 to 127 MUST be done through the "IETF Consensus" method as described in [RFC2434]. Requests for assigments of new message numbers in the range of 128 to 191 MUST be done through the "Standards Action" method as described in [RFC2434]. The IANA will not control the message numbers range of 192 through 255. These are designated as "Private Use" as described in [RFC2434]. RFC-2434 has some explicit language about these things. To wit: Private Use - For private or local use only, with the type and purpose defined by the local site. No attempt is made to prevent multiple sites from using the same value in different (and incompatible) ways. There is no need for IANA to review such assignments and assignments are not generally useful for interoperability. IETF Consensus - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists). Standards Action - Values are assigned only for Standards Track RFCs approved by the IESG. The other options in this BCP are: Hierarchical allocation - Delegated managers can assign values provided they have been given control over that part of the name space. IANA controls the higher levels of the namespace according to one of the other policies. Examples: DNS names, Object Identifiers (This doesn't seem to fit this numbered name space.) First Come First Served - Anyone can obtain an assigned number, so long as they provide a point of contact and a brief description of what the value would be used for. For numbers, the exact value is generally assigned by the IANA; with names, specific names are usually requested. Examples: vnd. (vendor assigned) MIME types [MIME-REG], TCP and UDP port numbers. (I don't believe this is what we want here.) Expert Review - approval by a Designated Expert is required. (Close but I think the others above are better.) Specification Required - Values and their meaning must be documented in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible. Examples: SCSP [SCSP] (Perhaps this fits the 128..191] space?) IESG Approval - New assignments must be approved by the IESG, but there is no requirement that the request be documented in an RFC (though the IESG has discretion to request documents or other supporting materials on a case-by-case basis). (Or perhaps this fits?) For the Disconnect Codes, I can propose this text: Requests for assignments of new disconnect codes in the range of 1 to 255 MUST be done through the "IETF Consensus" method as described in [RFC2434]. Disconnect codes will be assigned sequentially. > > However, it is desirable to be able to carry out development and > experimentation, and to deploy site-local (private) extensions, without > allocating a globally-unique message number from IANA. This is particular > true because the space available is limited, and so we can't afford to have > a couple hundred sites each have a globally-unique number allocated for > their experimental extension. The solution is the "Local Extensions" > range, which is effectively a range of numbers guaranteed not to be > assigned by IANA or used by the IETF. Thus it is safe to use these numbers > for local extensions without fear of colliding with a number allocated for > a new standard feature. Of course you don't get a guarantee of not > colliding with a number allocated by another site, but that's what you get > with a limited namespace. In practice, this usually does not turn out to > be a problem. Then do we want to partition the Disconnect Code name space? Perhaps [1..191] are allocated via the "IETF Consensus" methods and [192..255] are for "Private Use"? Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 21 11:35:43 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 LAA27513 for ; Wed, 21 Jul 2004 11:35:42 -0400 (EDT) Received: (qmail 24759 invoked by uid 605); 21 Jul 2004 15:33:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24592 invoked from network); 21 Jul 2004 15:32:54 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 21 Jul 2004 15:32:53 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa03363; 21 Jul 2004 11:32 EDT Date: Wed, 21 Jul 2004 11:32:20 -0400 From: Jeffrey Hutzelman To: ietf-ssh@NetBSD.org Subject: Re: Transport messages during kex (was Re: Data transfer during key re-exchange) Message-ID: <1894342704.1090423940@minbar.fac.cs.cmu.edu> In-Reply-To: <20040721112606.GA10106@chiark.greenend.org.uk> References: <20040721112606.GA10106@chiark.greenend.org.uk> 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, July 21, 2004 12:26:06 +0100 Jacob Nevins wrote: > Jeffrey Hutzelman writes: >> On Tuesday, July 20, 2004 23:50:43 +0100 Jacob Nevins >> wrote: >> >> > At the end of Section 7.1, add the following two paragraphs: >> > >> > Once a party has sent a KEXINIT message for key exchange or >> > re-exchange, it MUST NOT send any messages other than key exchange >> > method specific messages (message numbers 30 to 49); NEWKEYS; and >> > DISCONNECT, IGNORE, and DEBUG; until it has sent a NEWKEYS message >> > (Section 7.3). Implementations MUST NOT accept messages other than >> > these between receiving KEXINIT and NEWKEYS messages. >> >> Uh, what's wrong with SSH_MSG_UNINPLEMENTED? > >> 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. > (I admit that this is partly due to the IESG's apparent paranoia about > over-extensibility; I don't want to see the drafts being held up again > on my account if there's some gremlin we haven't thought of.) 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). >> For that matter, I'm not convinced that the not-yet-defined messages in >> the 1-19 range should be excluded either. All of the defined messages >> in this range have meaning at the lowest layer, independent of key >> exchange state. > > Are you really suggesting that SERVICE_REQUEST and SERVICE_ACCEPT should > be permitted during key exchange? No. Those don't fall in the realm of not-yet-defined, and clearly should be excluded. > If we're unhappy with SERVICE_REQUEST and _ACCEPT (as I think I am), > then future messages in this range may have the same undesirable > properties as them. Well, it's expected that current implementations MUST NOT send not-yet-defined messages at all, until they are defined. The issue is with what current impleentations do when they receive a not-yet-defined message. If we ever want to extend the protocol cleanly, they need to respond with SSH_MSG_UNIMPLEMENTED and otherwise do nothing, just as they would at any other time. This isn't a general-purpose extension mechanism to be used by anyone who wants to, but it _is_ key to making it possible to define a future rev of the protocol which interoperates with this one but includes new messages (sadly, we can't just bump the protocol version, because we failed to define a way to indicate support for any version beyond 2.0 while also supporting the 1.x protocol). Again, if we decide in the future that message 17 should be permitted during rekey, a new implementation won't be able to discover if its peer support message 17 unless implementations that don't know what that is are expected to send SSH_MSG_UNIMPLEMENTED. On the other hand, if we decide that message 17 should _not_ be permitted during rekey, all we have to do is say that when we define message 17. Then new implementations will not send message 17 during rekey, and will not accept it if they see it then. Old implementations will continue to send SSH_MSG_UNIMPLEMENTED, but that shouldn't be a problem. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 21 13:23:20 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 NAA05359 for ; Wed, 21 Jul 2004 13:23:20 -0400 (EDT) Received: (qmail 14982 invoked by uid 605); 21 Jul 2004 17:19:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14919 invoked from network); 21 Jul 2004 17:19:27 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 21 Jul 2004 17:19:27 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa03318; 21 Jul 2004 11:18 EDT Date: Wed, 21 Jul 2004 11:18:42 -0400 From: Jeffrey Hutzelman To: Chris Lonvick cc: ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes Message-ID: <1883762704.1090423122@minbar.fac.cs.cmu.edu> In-Reply-To: References: <52740000.1090373230@mariner.pc.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 On Wednesday, July 21, 2004 05:40:11 -0700 Chris Lonvick wrote: > For Message Numbers, I can propose text such as: > > Requests for assignments of new message numbers in the range of 1 to > 127 MUST be done through the "IETF Consensus" method as described in > [RFC2434]. > > Requests for assigments of new message numbers in the range of 128 to > 191 MUST be done through the "Standards Action" method as described > in [RFC2434]. > > The IANA will not control the message numbers range of 192 through > 255. These are designated as "Private Use" as described in [RFC2434]. Yes, I think that pretty much captures what we're trying to do. > For the Disconnect Codes, I can propose this text: > > Requests for assignments of new disconnect codes in the range of 1 to > 255 MUST be done through the "IETF Consensus" method as described in > [RFC2434]. Disconnect codes will be assigned sequentially. > Then do we want to partition the Disconnect Code name space? Perhaps > [1..191] are allocated via the "IETF Consensus" methods and [192..255] are > for "Private Use"? Yes, it might be good to reserve a chunk of this space for private use. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 22 05:16:20 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 FAA02608 for ; Thu, 22 Jul 2004 05:16:20 -0400 (EDT) Received: (qmail 7919 invoked by uid 605); 22 Jul 2004 09:16:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7590 invoked from network); 22 Jul 2004 09:16:09 -0000 Received: from ams-iport-1.cisco.com (144.254.224.140) by mail.netbsd.org with SMTP; 22 Jul 2004 09:16:08 -0000 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 22 Jul 2004 11:21:47 +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 i6M9G5U7002920 for ; Thu, 22 Jul 2004 11:16:05 +0200 (MEST) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id KAA26157 for ietf-ssh@NetBSD.org; Thu, 22 Jul 2004 10:16:04 +0100 (BST) Date: Thu, 22 Jul 2004 10:16:04 +0100 From: Derek Fawcus To: ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes Message-ID: <20040722101604.B6151@edinburgh.cisco.com> References: <52740000.1090373230@mariner.pc.cs.cmu.edu> <1883762704.1090423122@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <1883762704.1090423122@minbar.fac.cs.cmu.edu>; from jhutz@cmu.edu on Wed, Jul 21, 2004 at 11:18:42AM -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Jul 21, 2004 at 11:18:42AM -0400, Jeffrey Hutzelman wrote: > > On Wednesday, July 21, 2004 05:40:11 -0700 Chris Lonvick > wrote: > > > For the Disconnect Codes, I can propose this text: > > > > Requests for assignments of new disconnect codes in the range of 1 to > > 255 MUST be done through the "IETF Consensus" method as described in > > [RFC2434]. Disconnect codes will be assigned sequentially. > > > > Then do we want to partition the Disconnect Code name space? Perhaps > > [1..191] are allocated via the "IETF Consensus" methods and [192..255] are > > for "Private Use"? > > Yes, it might be good to reserve a chunk of this space for private use. Well the other option would be for one code be allocated as "Private Use" and the user then utilise the description string to demux any particular reasons. Mind I'm not sure if it's worth the effort, simply to save .25 of the code space. DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 22 05:36:25 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 FAA04290 for ; Thu, 22 Jul 2004 05:36:23 -0400 (EDT) Received: (qmail 24577 invoked by uid 605); 22 Jul 2004 09:35:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24553 invoked from network); 22 Jul 2004 09:35:22 -0000 Received: from ams-iport-1.cisco.com (144.254.224.140) by mail.netbsd.org with SMTP; 22 Jul 2004 09:35:22 -0000 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 22 Jul 2004 11:11: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 i6M95XU7000643 for ; Thu, 22 Jul 2004 11:05:34 +0200 (MEST) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id KAA25744 for ietf-ssh@NetBSD.org; Thu, 22 Jul 2004 10:05:28 +0100 (BST) Date: Thu, 22 Jul 2004 10:05:28 +0100 From: Derek Fawcus Cc: ietf-ssh@NetBSD.org Subject: Re: Transport messages during kex (was Re: Data transfer during key re-exchange) Message-ID: <20040722100528.A6151@edinburgh.cisco.com> References: <20040721112606.GA10106@chiark.greenend.org.uk> <1894342704.1090423940@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <1894342704.1090423940@minbar.fac.cs.cmu.edu>; from jhutz@cmu.edu on Wed, Jul 21, 2004 at 11:32:20AM -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Jul 21, 2004 at 11:32:20AM -0400, Jeffrey Hutzelman wrote: > On Wednesday, July 21, 2004 12:26:06 +0100 Jacob Nevins > wrote: > > > Jeffrey Hutzelman writes: > >> On Tuesday, July 20, 2004 23:50:43 +0100 Jacob Nevins > >> wrote: > >> > >> > At the end of Section 7.1, add the following two paragraphs: > >> > > >> > Once a party has sent a KEXINIT message for key exchange or > >> > re-exchange, it MUST NOT send any messages other than key exchange > >> > method specific messages (message numbers 30 to 49); NEWKEYS; and > >> > DISCONNECT, IGNORE, and DEBUG; until it has sent a NEWKEYS message > >> > (Section 7.3). Implementations MUST NOT accept messages other than > >> > these between receiving KEXINIT and NEWKEYS messages. Well I'd have to object to the above, as I'd want to be able to send other transport messages (1 - 49). Moreover the original message from Bill actually said "must suspend transport of user data while rekey negotiation is in progress" not "non-rekey-related traffic should be suspended for the duration of the rekey". As to the response to receiving any such transport message, that can be discussed... > >> Uh, what's wrong with SSH_MSG_UNINPLEMENTED? I agree to the point about needing to be able to send the above during the rekey. > >> For that matter, I'm not convinced that the not-yet-defined messages in > >> the 1-19 range should be excluded either. All of the defined messages > >> in this range have meaning at the lowest layer, independent of key > >> exchange state. > > > > Are you really suggesting that SERVICE_REQUEST and SERVICE_ACCEPT should > > be permitted during key exchange? > > No. Those don't fall in the realm of not-yet-defined, and clearly should > be excluded. Well I'd suggest one treat those as protocol errors, and send a DISCONNECT in response. However if someone did a non blocking rekey implementation (say a subsequent enhancement), then we may well want to accept these during a rekey. I'd say it's a quality of implementation issue, in the absense of any extension for non blocking rekey, I'd make receipt of the above send a DISCCONECT. I don't know that it actually needs anything in the document. I suppose we could explicity say that behaviour upon receipt of those two during rekey is unspecified. > Again, if we decide in the future that message 17 should be permitted > during rekey, a new implementation won't be able to discover if its peer > support message 17 unless implementations that don't know what that is are > expected to send SSH_MSG_UNIMPLEMENTED. > > On the other hand, if we decide that message 17 should _not_ be permitted > during rekey, all we have to do is say that when we define message 17. > Then new implementations will not send message 17 during rekey, and will > not accept it if they see it then. Old implementations will continue to > send SSH_MSG_UNIMPLEMENTED, but that shouldn't be a problem. Agreed. DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 22 11:56:33 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 LAA01247 for ; Thu, 22 Jul 2004 11:56:33 -0400 (EDT) Received: (qmail 20112 invoked by uid 605); 22 Jul 2004 15:48:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20015 invoked from network); 22 Jul 2004 15:48:19 -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; 22 Jul 2004 15:48:19 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 22 Jul 2004 08:50:17 -0700 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 i6MFmG8a018510; Thu, 22 Jul 2004 08:48:16 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA28003; Thu, 22 Jul 2004 08:48:16 -0700 (PDT) Date: Thu, 22 Jul 2004 08:48:16 -0700 (PDT) From: Chris Lonvick To: Derek Fawcus cc: ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes In-Reply-To: <20040722101604.B6151@edinburgh.cisco.com> Message-ID: References: <52740000.1090373230@mariner.pc.cs.cmu.edu> <1883762704.1090423122@minbar.fac.cs.cmu.edu> <20040722101604.B6151@edinburgh.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, On Thu, 22 Jul 2004, Derek Fawcus wrote: > On Wed, Jul 21, 2004 at 11:18:42AM -0400, Jeffrey Hutzelman wrote: > > > > On Wednesday, July 21, 2004 05:40:11 -0700 Chris Lonvick > > wrote: > > > > > For the Disconnect Codes, I can propose this text: > > > > > > Requests for assignments of new disconnect codes in the range of 1 to > > > 255 MUST be done through the "IETF Consensus" method as described in > > > [RFC2434]. Disconnect codes will be assigned sequentially. > > > > > > > Then do we want to partition the Disconnect Code name space? Perhaps > > > [1..191] are allocated via the "IETF Consensus" methods and [192..255] are > > > for "Private Use"? > > > > Yes, it might be good to reserve a chunk of this space for private use. > > Well the other option would be for one code be allocated as "Private Use" > and the user then utilise the description string to demux any particular reasons. > > Mind I'm not sure if it's worth the effort, simply to save .25 of the code > space. We could say that 1..254 are assigned via IETF Consensus and 255 is reserved for Private Use. Any objections to that? Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 22 13:34: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 NAA08349 for ; Thu, 22 Jul 2004 13:34:37 -0400 (EDT) Received: (qmail 8684 invoked by uid 605); 22 Jul 2004 17:01:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8094 invoked from network); 22 Jul 2004 17:01:03 -0000 Received: from nic.appgate.com (HELO nic2.appgate.com) (212.214.117.82) by mail.netbsd.org with SMTP; 22 Jul 2004 17:01:03 -0000 Received: from shala.firedoor.se (shala.got.appgate.com [172.23.2.27]) by nic2.appgate.com (Postfix) with ESMTP id 9ECD21F30E6; Thu, 22 Jul 2004 18:31:36 +0200 (MEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 5E1F16C011; Thu, 22 Jul 2004 18:31:41 +0200 (MEST) Date: Thu, 22 Jul 2004 18:31:32 +0200 (CEST) From: Martin Forssen Subject: Re: Message Numbers and Disconnect Codes To: clonvick@cisco.com Cc: dfawcus@cisco.com, ietf-ssh@NetBSD.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE Message-Id: <20040722163141.5E1F16C011@shala.firedoor.se> Sender: ietf-ssh-owner@NetBSD.org Precedence: list On 22 Jul, Chris Lonvick wrote: > We could say that 1..254 are assigned via IETF Consensus and 255 is > reserved for Private Use. Any objections to that? Yes, I would prefer to have a number of message codes reserved for private use. Some extensions are cleaner to implement with a number of separate messages. Of course one wants to keep the number of messages needed down but to limit it to just one is IMHO tad restrictive. However I do not see any need to reserve 64 different numbers. 16 should suffice (240..255). /MaF -- Martin Forssen Development Manager Phone: +46 31 7744361 AppGate Network Security AB From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 22 19:26:43 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 TAA28950 for ; Thu, 22 Jul 2004 19:26:43 -0400 (EDT) Received: (qmail 15758 invoked by uid 605); 22 Jul 2004 23:25:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15737 invoked from network); 22 Jul 2004 23:25:00 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 22 Jul 2004 23:25:00 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i6MNOrJ6009219; Thu, 22 Jul 2004 16:24:53 -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 i6MNOrcc021053; Thu, 22 Jul 2004 19:24:53 -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 i6MNOrcI012676; Thu, 22 Jul 2004 19:24:53 -0400 (EDT) Message-Id: <200407222324.i6MNOrcI012676@thunk.east.sun.com> From: Bill Sommerfeld To: Derek Fawcus cc: ietf-ssh@NetBSD.org Subject: Re: Transport messages during kex (was Re: Data transfer during key re-exchange) In-Reply-To: Your message of "Thu, 22 Jul 2004 10:05:28 BST." <20040722100528.A6151@edinburgh.cisco.com> Reply-to: sommerfeld@east.sun.com Date: Thu, 22 Jul 2004 19:24:53 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > Well I'd have to object to the above, as I'd want to be able to send > other transport messages (1 - 49). Moreover the original message > from Bill actually said "must suspend transport of user data while > rekey negotiation is in progress" not "non-rekey-related traffic > should be suspended for the duration of the rekey". Don't view my words as gospel. The intent was twofold: - capturing and documenting what you have to do or not do during rekey interoperate with the least common denominator sshv2 installed base.. - prompt the folks looking for better-than-current-practice/seamless rekey to go off and code and then document a negotiable extension. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jul 23 09:23:43 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 JAA21007 for ; Fri, 23 Jul 2004 09:23:42 -0400 (EDT) Received: (qmail 1918 invoked by uid 605); 23 Jul 2004 13:23:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1863 invoked from network); 23 Jul 2004 13:23:35 -0000 Received: from chiark.greenend.org.uk (193.201.200.170) by mail.netbsd.org with SMTP; 23 Jul 2004 13:23:35 -0000 Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local for ietf-ssh@netbsd.org id 1Bo01O-0006i5-00; Fri, 23 Jul 2004 14:23:34 +0100 Date: Fri, 23 Jul 2004 14:23:34 +0100 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: Transport messages during kex Message-ID: <20040723132334.GA21109@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1894342704.1090423940@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list 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 Fri Jul 23 10:05: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 KAA24519 for ; Fri, 23 Jul 2004 10:05:05 -0400 (EDT) Received: (qmail 25467 invoked by uid 605); 23 Jul 2004 14:05:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25449 invoked from network); 23 Jul 2004 14:05:00 -0000 Received: from sj-iport-4.cisco.com (171.68.10.86) by mail.netbsd.org with SMTP; 23 Jul 2004 14:05:00 -0000 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i6NDrQmI002397 for ; Fri, 23 Jul 2004 06:53:26 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA03986 for ; Fri, 23 Jul 2004 06:53:26 -0700 (PDT) Date: Fri, 23 Jul 2004 06:53:26 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes In-Reply-To: <20040722163141.5E1F16C011@shala.firedoor.se> Message-ID: References: <20040722163141.5E1F16C011@shala.firedoor.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, On Thu, 22 Jul 2004, Martin Forssen wrote: > On 22 Jul, Chris Lonvick wrote: > > We could say that 1..254 are assigned via IETF Consensus and 255 is > > reserved for Private Use. Any objections to that? > > Yes, I would prefer to have a number of message codes reserved for > private use. Some extensions are cleaner to implement with a number of > separate messages. Of course one wants to keep the number of messages > needed down but to limit it to just one is IMHO tad restrictive. > > However I do not see any need to reserve 64 different numbers. 16 should > suffice (240..255). I have a bid for 16. Do I hear any other bids? Going.. going.. :-) If I don't hear any objections to reserving the Disconnect Codes of [240..255] for Private Use, then I'll incorporate that into the documents. Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 29 08:35:36 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 IAA07035 for ; Thu, 29 Jul 2004 08:35:35 -0400 (EDT) Received: (qmail 6717 invoked by uid 605); 29 Jul 2004 12:35:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6708 invoked from network); 29 Jul 2004 12:35:33 -0000 Received: from smtp.cs.auckland.ac.nz (130.216.33.151) by mail.netbsd.org with SMTP; 29 Jul 2004 12:35:33 -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 D3DFB1CD88E for ; Fri, 30 Jul 2004 00:03:14 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.32) id 1Bq9fK-0003ii-RY for ietf-ssh@NetBSD.org; Fri, 30 Jul 2004 00:05:42 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@NetBSD.org Subject: Invalid channel numbers Message-Id: Date: Fri, 30 Jul 2004 00:05:42 +1200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Is there any concept of an invalid channel number for SSH channels, akin to the Posix convention that -1 is always an invalid file descriptor/error status value? It'd be useful to have a never-valid value to use akin to the way -1 is used (or at least returned) for open/creat to indicate a non-file descriptor. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 29 12: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 MAA22079 for ; Thu, 29 Jul 2004 12:19:42 -0400 (EDT) Received: (qmail 29078 invoked by uid 605); 29 Jul 2004 16:18:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29045 invoked from network); 29 Jul 2004 16:18:24 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 29 Jul 2004 16:18:24 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id MAA15164; Thu, 29 Jul 2004 12:18:19 -0400 (EDT) From: der Mouse Message-Id: <200407291618.MAA15164@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. Date: Thu, 29 Jul 2004 12:11:03 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Invalid channel numbers In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > Is there any concept of an invalid channel number for SSH channels, > akin to the Posix convention that -1 is always an invalid file > descriptor/error status value? It'd be useful to have a never-valid > value to use akin to the way -1 is used (or at least returned) for > open/creat to indicate a non-file descriptor. For channel numbers assigned by your implementation, you can simply make sure you never assign your favourite flag value (-1 or whatever), and you're fine. For channel numbers assigned by the peer, I don't think there are any reserved values; you need to keep the valid bit somewhere else. I suppose you could build an implementation that croaks if the peer ever uses channel 0xffffffff, but that strikes me as rather broken. Since it's probably an ignorable possibility that the peer will ever use all 4294967296 distinct channel numbers, you could perhaps track what numbers have been used and use any number that hasn't as your flag, switching if the peer uses your flag value. It'd mean some interesting tapdancing and would likely be more complex than just keeping a separate valid bit, but it could be done. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 29 12:57:17 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 MAA24699 for ; Thu, 29 Jul 2004 12:57:16 -0400 (EDT) Received: (qmail 12513 invoked by uid 605); 29 Jul 2004 16:56:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12263 invoked from network); 29 Jul 2004 16:56:36 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 29 Jul 2004 16:56:36 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id A0E0E43373; Thu, 29 Jul 2004 18:25:56 +0200 (CEST) Message-ID: <41092788.9000705@siliconcircus.com> Date: Thu, 29 Jul 2004 18:36:24 +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: ietf-ssh@NetBSD.org 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 Peter Gutmann wrote: > Is there any concept of an invalid channel number for SSH channels, akin to > the Posix convention that -1 is always an invalid file descriptor/error status > value? It'd be useful to have a never-valid value to use akin to the way -1 > is used (or at least returned) for open/creat to indicate a non-file > descriptor. Just on the offchance that someone's already implemented with channel numbers counting down 0, -1, -2, I'd guess 0x80000000 might be a safer value to pick. I admit it's unlikely, but nonetheless... -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 29 13:15:18 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 NAA25966 for ; Thu, 29 Jul 2004 13:15:18 -0400 (EDT) Received: (qmail 2512 invoked by uid 605); 29 Jul 2004 17:14:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2486 invoked from network); 29 Jul 2004 17:14:42 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 29 Jul 2004 17:14:42 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i6THEYJ6028733; Thu, 29 Jul 2004 10:14:35 -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 i6THEYcc020764; Thu, 29 Jul 2004 13:14:34 -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 i6THEYeS007818; Thu, 29 Jul 2004 13:14:34 -0400 (EDT) Message-Id: <200407291714.i6THEYeS007818@thunk.east.sun.com> From: Bill Sommerfeld To: Jon Bright cc: Peter Gutmann , ietf-ssh@NetBSD.org Subject: Re: Invalid channel numbers In-Reply-To: Your message of "Thu, 29 Jul 2004 18:36:24 +0200." <41092788.9000705@siliconcircus.com> Reply-to: sommerfeld@east.sun.com Date: Thu, 29 Jul 2004 13:14:34 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list It looks like the answer to Peter's original question is a clear "No, there is no reserved channel number". (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..) - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jul 31 02:02:47 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 CAA28679 for ; Sat, 31 Jul 2004 02:02:46 -0400 (EDT) Received: (qmail 2257 invoked by uid 605); 31 Jul 2004 06:02:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2236 invoked from network); 31 Jul 2004 06:02:25 -0000 Received: from smtp.cs.auckland.ac.nz (130.216.33.151) by mail.netbsd.org with SMTP; 31 Jul 2004 06:02:25 -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 C7AF51CD908; Sat, 31 Jul 2004 17:59:57 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.32) id 1Bqmwt-0006mU-V9; Sat, 31 Jul 2004 18:02:27 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@NetBSD.org, mouse@Rodents.Montreal.QC.CA Subject: Re: Invalid channel numbers In-Reply-To: <200407291618.MAA15164@Sparkle.Rodents.Montreal.QC.CA> Message-Id: Date: Sat, 31 Jul 2004 18:02:27 +1200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list der Mouse writes: >For channel numbers assigned by the peer, I don't think there are any >reserved values; you need to keep the valid bit somewhere else. I suppose >you could build an implementation that croaks if the peer ever uses channel >0xffffffff, but that strikes me as rather broken. Actually there's another reason for requiring this (just dug it up from an old code comment): When you get a channel-specific request (channel open, channel request, etc), you're supposed to send back a succeeded or failed status. How do you send back a response for the condition that you couldn't parse the request to the point of finding the channel number to use in the response? Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jul 31 02:44:05 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 CAA11363 for ; Sat, 31 Jul 2004 02:44:05 -0400 (EDT) Received: (qmail 9492 invoked by uid 605); 31 Jul 2004 06:44:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9468 invoked from network); 31 Jul 2004 06:43:59 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 31 Jul 2004 06:43:59 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id CAA14242; Sat, 31 Jul 2004 02:43:58 -0400 (EDT) From: der Mouse Message-Id: <200407310643.CAA14242@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. Date: Sat, 31 Jul 2004 02:41:30 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Invalid channel numbers In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > When you get a channel-specific request (channel open, channel > request, etc), you're supposed to send back a succeeded or failed > status. How do you send back a response for the condition that you > couldn't parse the request to the point of finding the channel number > to use in the response? There is no such condition, because if you can't parse the request, you have no request to respond to, so you don't have to worry about framing any particular kind of response to it. You can of course send a "you sent me something I couldn't make head nor tail of" error, but that's very different from an error response to a channel-specific request. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jul 31 03:38:49 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 DAA12912 for ; Sat, 31 Jul 2004 03:38:48 -0400 (EDT) Received: (qmail 28321 invoked by uid 605); 31 Jul 2004 07:35:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27774 invoked from network); 31 Jul 2004 07:34:41 -0000 Received: from smtp.cs.auckland.ac.nz (130.216.33.151) by mail.netbsd.org with SMTP; 31 Jul 2004 07:34:41 -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 CC90C1CD84E; Sat, 31 Jul 2004 19:31:45 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.32) id 1BqoNk-0006tT-St; Sat, 31 Jul 2004 19:34:16 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@NetBSD.org, mouse@Rodents.Montreal.QC.CA Subject: Re: Invalid channel numbers In-Reply-To: <200407310643.CAA14242@Sparkle.Rodents.Montreal.QC.CA> Message-Id: Date: Sat, 31 Jul 2004 19:34:16 +1200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list der Mouse writes: >> When you get a channel-specific request (channel open, channel >> request, etc), you're supposed to send back a succeeded or failed >> status. How do you send back a response for the condition that you >> couldn't parse the request to the point of finding the channel number >> to use in the response? > >There is no such condition, because if you can't parse the request, you have >no request to respond to, so you don't have to worry about framing any >particular kind of response to it. Does the spec say this anywhere? I can see an implementation hanging while waiting for a response to a request that'll never arrive if you don't send it back at least some sort of response. Not replying seems somewhat broken to me, if the spec says (as it seems to) that you need to send back a "succeeded" or "failed" response then not sending back anything under some conditions seems wrong - you've detected an error, you should send back some indication of this. >You can of course send a "you sent me something I couldn't make head nor tail >of" error, but that's very different from an error response to a channel- >specific request. The only error message mechanism that I can see if you can't send a request- failed response is a full disconnect, which is rather drastic if there are (for example) valid data transfers in progress on other channels at the time. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jul 31 14:06:03 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 OAA08248 for ; Sat, 31 Jul 2004 14:06:03 -0400 (EDT) Received: (qmail 24171 invoked by uid 605); 31 Jul 2004 18:06:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24154 invoked from network); 31 Jul 2004 18:06:00 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 31 Jul 2004 18:06:00 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6482550; Sat, 31 Jul 2004 11:05:59 -0600 Message-ID: <410BD17A.5080607@vandyke.com> Date: Sat, 31 Jul 2004 11:06:02 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040706) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Gutmann CC: 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 Peter Gutmann wrote: > der Mouse writes: > > >>>When you get a channel-specific request (channel open, channel >>>request, etc), you're supposed to send back a succeeded or failed >>>status. How do you send back a response for the condition that you >>>couldn't parse the request to the point of finding the channel number >>>to use in the response? >> >>There is no such condition, because if you can't parse the request, you have >>no request to respond to, so you don't have to worry about framing any >>particular kind of response to it. > > > Does the spec say this anywhere? I can see an implementation hanging while > waiting for a response to a request that'll never arrive if you don't send it > back at least some sort of response. Not replying seems somewhat broken to > me, if the spec says (as it seems to) that you need to send back a "succeeded" > or "failed" response then not sending back anything under some conditions > seems wrong - you've detected an error, you should send back some indication > of this. From section 5.4: byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string request type in US-ASCII characters only boolean want reply ... type-specific data If want reply is FALSE, no response will be sent to the request. Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE, or request-specific continuation messages. If the request is not recognized or is not supported for the channel, SSH_MSG_CHANNEL_FAILURE is returned. The channel number is part of the packet that is predefined. Therefore, you can always parse the channel number, and send the response. If 'want reply' is true, and you don't understand the request, send failure. If 'want reply' is false, don't send anything, regardless of whether you understand the request. This is the only way this can work (otherwise, it is not possible to line up requests and responses.) I'm also pretty sure we've discussed it before in the working group, but I don't see in the draft, that the responses must be made in order, in the case of multiple requests. I will admit, it would be nice if the final sentance was more clear (or gone.) If any change is needed, I would say something like: If want reply is FALSE, no response will be sent to the request. Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE, or request-specific continuation messages. If the request is not recognized or is not supported for the channel, and 'want reply' is true, SSH_MSG_CHANNEL_FAILURE is returned. If 'want reply' is false, the request is ignored. The client is allowed to send further messages without waiting for the response to the request. Requests MUST be responded to in the order received. This message does not consume window space and can be sent even if no window space is available. Request types are local to each channel type. Thanks, Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jul 31 15:31: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 PAA13511 for ; Sat, 31 Jul 2004 15:31:52 -0400 (EDT) Received: (qmail 13067 invoked by uid 605); 31 Jul 2004 19:31:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13055 invoked from network); 31 Jul 2004 19:31:22 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 31 Jul 2004 19:31:21 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id PAA15984; Sat, 31 Jul 2004 15:31:18 -0400 (EDT) From: der Mouse Message-Id: <200407311931.PAA15984@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. Date: Sat, 31 Jul 2004 15:26:50 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Invalid channel numbers In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >>> How do you send back a response for the condition that you couldn't >>> parse the request to the point of finding the channel number to use >>> in the response? >> There is no such condition, because if you can't parse the request, >> you have no request to respond to [...] > Does the spec say this anywhere? Not specifically, but the spec does describ the syntax of channel requests. If the circumstance arises, either your request parsing is severely broken or the sender's request generation is severely broken. In either case, interoperability problems are only to be expected. > I can see an implementation hanging while waiting for a response to a > request that'll never arrive if you don't send it back at least some > sort of response. So can I. But if it happens for this reason, it's the fault of the end with broken code, and arises because of that broken code. No matter what we do, we can't make the protocol robust in the face of excessive implementation brokenness. >> You can of course send a "you sent me something I couldn't make head >> nor tail of" error, but that's very different from an error response >> to a channel-specific request. > The only error message mechanism that I can see if you can't send a > request-failed response is a full disconnect, which is rather drastic > if there are (for example) valid data transfers in progress on other > channels at the time. Yes, it is. But no more drastic than the sender sending a request so badly mangled as to be unparseable - or, as the case may be, your parsing code being so broken as to be unable to parse a valid request. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jul 31 16:01: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 QAA14519 for ; Sat, 31 Jul 2004 16:01:23 -0400 (EDT) Received: (qmail 8781 invoked by uid 605); 31 Jul 2004 20:01:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8759 invoked from network); 31 Jul 2004 20:01:22 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 31 Jul 2004 20:01:22 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6482728 for ietf-ssh@netbsd.org; Sat, 31 Jul 2004 14:01:21 -0600 Message-ID: <410BFA96.4080404@vandyke.com> Date: Sat, 31 Jul 2004 14:01:26 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040706) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: San Diego... 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 I guess we're not meeting in San Diego. I'm going to be there, any one else interested in the SFTP draft going to be around? - Joseph