From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Apr 1 08:50:16 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 IAA13184 for ; Thu, 1 Apr 2004 08:50:16 -0500 (EST) Received: (qmail 27932 invoked by uid 605); 1 Apr 2004 13:50:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27925 invoked from network); 1 Apr 2004 13:50:16 -0000 Received: from smtp.cs.auckland.ac.nz (130.216.33.151) by mail.netbsd.org with SMTP; 1 Apr 2004 13:50:16 -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 0F19234059; Fri, 2 Apr 2004 01:48:28 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.30) id 1B92aA-0003q3-Rw; Fri, 02 Apr 2004 01:50:10 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@NetBSD.org, mouse@Rodents.Montreal.QC.CA Subject: Re: Speaking of implementation quirks... In-Reply-To: <200403280600.BAA28954@Sparkle.Rodents.Montreal.QC.CA> Message-Id: Date: Fri, 02 Apr 2004 01:50:10 +1200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list der Mouse writes: >>Based on this, it'd be useful if the text could emphasise that the >>value refers to the total packet size by adding the "(including >>length, padding length, payload, padding, and MAC)" in -transport... > >Except the text that needs changing isn't in -transport; it's in -connect. >The description of channel opening just says it's "the maximum size of an >individual data packet that can be sent to the sender". In context, this >could reasonably be taken to refer to packets at the SSH Connection Protocol >layer, though whether it refers to data payload or payload plus nine bytes of >CHANNEL_DATA header is still ambiguous. The reason I asked for the disambiguation in -transport is that I've only ever found one implementation that, if asked for a max.packet size of nK, sends significantly more than nK. This would imply that most implementations regard the packet size as "(including length, padding length, payload, padding, and MAC)" rather than excluding all that, thus leading to over-sized packets when you add all the other bits. (Either that or they all use very small amounts of padding, I allow some slop in lengths, but not that much. In any case it needs clarification, otherwise there's not much point in being able to specify a length if there are several different interpretations of what it means. What do other implementations do?). >First, -connect 5.1's limit applies only to channel data packets; it has no >bearing whatever on other packets and thus cannot usefully be used as a limit >on other packets. That's fine, channel data packets are the only ones that are likely to get very big. >As for your own issues, nothing says that you have to have a 32K buffer in >order to receive and process packets 32K in length. You're entirely free to >process packets byte by byte, chewing your way through that 32K packet >piecemeal - though you have to be careful that you can back out any global >data structure changes in case the MAC turns out to be wrong. You're also entirely free to push a pea up a mountain with your nose, however that's not a very good way of getting it there. What critical interoperability requirement is being served by the MUST 32K? It just appeared from nowhere in one of the early drafts (-02 I think). Why not 64K? 2MB? 2GB? (or going the other way, 2K?). The point is that since it's a negotiable parameter, there's no need to have a MUST tying it to a single value. (It's interesting to note that SSL has introduced extensions to allow the use of shorter packets in resource-constrained devices, while SSH, which is often used as the CLI admin interface on such devices, mandates 32K buffers for an interface that usually transmits single keystrokes). Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Apr 1 15:54:58 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 PAA02214 for ; Thu, 1 Apr 2004 15:54:57 -0500 (EST) Received: (qmail 17491 invoked by uid 605); 1 Apr 2004 20:54:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17484 invoked from network); 1 Apr 2004 20:54:35 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 1 Apr 2004 20:54:35 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 7AC34C4C9B; Thu, 1 Apr 2004 22:54:34 +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 27837D2832; Thu, 1 Apr 2004 22:54:28 +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 i31KsRRO013771; Thu, 1 Apr 2004 22:54:27 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i31KsOUM013695; Thu, 1 Apr 2004 22:54:24 +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: ietf-ssh@NetBSD.org, mouse@Rodents.Montreal.QC.CA Subject: Re: Speaking of implementation quirks... 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: 01 Apr 2004 22:54:23 +0200 In-Reply-To: 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.1 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,J_CHICKENPOX_36, MAILTO_TO_SPAM_ADDR autolearn=no version=2.63-lysator_fetto_1.1 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > The reason I asked for the disambiguation in -transport is that I've only ever > found one implementation that, if asked for a max.packet size of nK, sends > significantly more than nK. I think it would be good if you spelled out exactly which implementation(s) you are talking about. Mine (lsh) applies the channel max packet size to the application data portion of DATA and EXTENDED_DATA packets. I don't know what other implementors do. > What critical interoperability requirement is being served by the > MUST 32K? It just appeared from nowhere in one of the early drafts > (-02 I think). Why not 64K? 2MB? 2GB? (or going the other way, 2K?). > The point is that since it's a negotiable parameter, there's no need > to have a MUST tying it to a single value. It's not *explicitly* negotiated, but as long as the largest packets are the channel data packets, one can make sure one doesn't get very large packets by advertising a small channel max packet size. So it would probably work with a required buffer size of just a few thousand bytes. The packets that may potentially hit this limit, besides channel data (which is of negotiated size), are key exchange messages including certificate chains, as well as debug and ignore messages, which can potentially be large. In practice, I think you could manage with small buffers and still be 99% compliant to the spec, by advertising a smallish max packet size on all channels, and have special code that can skip and discard messages of type DEBUG and IGNORE without buffering the complete messages. (You would fail to interoperate with implementations that put ridiculously long algorithm or language lists into their KEXINIT message, but that should not be common. Only example I'm aware of is SSH-2.0-Sun_SSH_1.0 which dumps its complete locale list into the ssh language list, resulting in a KEXINIT message of some 1400 bytes plus header, and that's a known bug which I hope will be fixed in the next release). /nisse From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Apr 1 23:25: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 XAA01991 for ; Thu, 1 Apr 2004 23:25:37 -0500 (EST) Received: (qmail 14540 invoked by uid 605); 2 Apr 2004 04:25:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14533 invoked from network); 2 Apr 2004 04:25:37 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 2 Apr 2004 04:25:37 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i324PPMt014775; Thu, 1 Apr 2004 21:25:25 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i324PPcE008415; Thu, 1 Apr 2004 21:25:25 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i324P2hf016473; Thu, 1 Apr 2004 22:25:02 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i324P10c016472; Thu, 1 Apr 2004 22:25:01 -0600 (CST) Date: Thu, 1 Apr 2004 22:25:01 -0600 From: Nicolas Williams To: Niels =?unknown-8bit?Q?M=F6ller?= Cc: Peter Gutmann , ietf-ssh@NetBSD.org, mouse@Rodents.Montreal.QC.CA Subject: Large lang tag lists (was Re: Speaking of implementation quirks...) Message-ID: <20040402042453.GA16465@binky.central.sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Apr 01, 2004 at 10:54:23PM +0200, Niels Mller wrote: > (You would fail to interoperate with implementations that put > ridiculously long algorithm or language lists into their KEXINIT > message, but that should not be common. Only example I'm aware of is > SSH-2.0-Sun_SSH_1.0 which dumps its complete locale list into the ssh > language list, resulting in a KEXINIT message of some 1400 bytes plus > header, and that's a known bug which I hope will be fixed in the next > release). The known bug is that it uses locales rather than RFC3066 language tags. The next release will use RFC3066 language tags and will send its entire list of installed locales (mapped to langtags). Do you propose that we do something different? I posted sometime last year on inconsistencies in the spec wrt language tags. I got precious few comments... This is the first that I hear of any issue with the size of our server's KEXINIT packets. If our current approach causes problems for anyone then perhaps you might like to review those comments and make some suggestions. IIRC I mentioned the possibility of the server not advertising any langtags and instead relying on the langtag fields of various packets to convey the negotiated language to the client. Since then I'm also finding that, while RFC3066 lang tags are really nice for negotiating a language for localization (L10N), they are not appropriate for negotiating other I18N matters, such as what encoding to use in a given channel. I'm afraid that SSHv2 tried valiantly to get I18N/L10N right but missed a few things (though perhaps nothing that can't be corrected with new channel requests). Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 2 02:39:21 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 CAA26967 for ; Fri, 2 Apr 2004 02:39:20 -0500 (EST) Received: (qmail 4153 invoked by uid 605); 2 Apr 2004 07:39:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4146 invoked from network); 2 Apr 2004 07:39:15 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 2 Apr 2004 07:39:15 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 487F1E4CE6; Fri, 2 Apr 2004 09:34:36 +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 D6966E4925; Fri, 2 Apr 2004 09:34:31 +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 i327YVRO011514; Fri, 2 Apr 2004 09:34:31 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i327YPSH011511; Fri, 2 Apr 2004 09:34:25 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Nicolas Williams Cc: Peter Gutmann , ietf-ssh@NetBSD.org, mouse@Rodents.Montreal.QC.CA Subject: Re: Large lang tag lists (was Re: Speaking of implementation quirks...) References: <20040402042453.GA16465@binky.central.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: 02 Apr 2004 09:34:25 +0200 In-Reply-To: <20040402042453.GA16465@binky.central.sun.com> Message-ID: Lines: 27 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.1 (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.1 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Nicolas Williams writes: > The known bug is that it uses locales rather than RFC3066 language tags. > > The next release will use RFC3066 language tags and will send its entire > list of installed locales (mapped to langtags). Do you propose that we > do something different? No, if you actually support all those languages, then including the full list seems to be the right thing to do. About how many are there? (My code does impose some arbitrary limits on the lenght of language and algorithm lists, independent of the maximum packet size, just to let me use simpler code that would waste cpu or memory for large inputs. I'll have to reconsider those limits if/when there's a reasonable use of large lists out there). > This is the first that I hear of any issue with the size of our > server's KEXINIT packets. I don't think there's any problem with the current protocol. There may be a concern with a hypothetical protocol that changes the SSH_MAX_PACKET (the packet size that implementations MUST handle) from today's 32K to a significantly smaller value, say 1K, Best regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 2 12: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 MAA20106 for ; Fri, 2 Apr 2004 12:29:44 -0500 (EST) Received: (qmail 5051 invoked by uid 605); 2 Apr 2004 17:29:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5043 invoked from network); 2 Apr 2004 17:29:40 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 2 Apr 2004 17:29:40 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i32HTMMt009545; Fri, 2 Apr 2004 10:29:23 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i32HTL4F005280; Fri, 2 Apr 2004 10:29:21 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i32HSxhf017006; Fri, 2 Apr 2004 11:28:59 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i32HSvq6017005; Fri, 2 Apr 2004 11:28:57 -0600 (CST) Date: Fri, 2 Apr 2004 11:28:57 -0600 From: Nicolas Williams To: Niels =?unknown-8bit?Q?M=F6ller?= Cc: Peter Gutmann , ietf-ssh@NetBSD.org, mouse@Rodents.Montreal.QC.CA Subject: Re: Large lang tag lists (was Re: Speaking of implementation quirks...) Message-ID: <20040402172857.GV5868@binky.central.sun.com> References: <20040402042453.GA16465@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Fri, Apr 02, 2004 at 09:34:25AM +0200, Niels Mller wrote: > Nicolas Williams writes: > > > The known bug is that it uses locales rather than RFC3066 language tags. > > > > The next release will use RFC3066 language tags and will send its entire > > list of installed locales (mapped to langtags). Do you propose that we > > do something different? > > No, if you actually support all those languages, then including the > full list seems to be the right thing to do. About how many are there? Er, many? The most locales I've seen installed was ~280. Of course, there was much overlap since, for example, "en_US" and "en_US.UTF-8" both map to the same langtag, "en-us". So say, maybe, 150 5-charater-long langtags (plus commas), so... close to 1KB. Of course, few install so many locales on a server, but it does happen. > (My code does impose some arbitrary limits on the lenght of language > and algorithm lists, independent of the maximum packet size, just to > let me use simpler code that would waste cpu or memory for large > inputs. I'll have to reconsider those limits if/when there's a > reasonable use of large lists out there). See above. One way to figure out many langtags might be sent is to figure out how many langtags of the form - are possible given the current registrations. > > This is the first that I hear of any issue with the size of our > > server's KEXINIT packets. > > I don't think there's any problem with the current protocol. There may > be a concern with a hypothetical protocol that changes the > SSH_MAX_PACKET (the packet size that implementations MUST handle) from > today's 32K to a significantly smaller value, say 1K, Clients have [almost[1]] no reason to send large KEXINITs; servers do, if they use certs, for example, or have many locales installed. [1] In the case of GSS-API keyex w/ optimistic keyex it is possible that client could send a very large packet following its KEXINIT. At least for the initial key exchange I think that we need to mandate that implementions be able to deal with large packets; after the initial kex there's no need, I think, to have a large packet support requirement. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 2 12:40: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 MAA20538 for ; Fri, 2 Apr 2004 12:40:18 -0500 (EST) Received: (qmail 13864 invoked by uid 605); 2 Apr 2004 17:40:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13841 invoked from network); 2 Apr 2004 17:40:11 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 2 Apr 2004 17:40:11 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id MAA11631; Fri, 2 Apr 2004 12:40:04 -0500 (EST) From: der Mouse Message-Id: <200404021740.MAA11631@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: Fri, 2 Apr 2004 12:34:28 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: Large lang tag lists (was Re: Speaking of implementation quirks...) In-Reply-To: <20040402172857.GV5868@binky.central.sun.com> References: <20040402042453.GA16465@binky.central.sun.com> <20040402172857.GV5868@binky.central.sun.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > At least for the initial key exchange I think that we need to mandate > that implementions be able to deal with large packets; after the > initial kex there's no need, I think, to have a large packet support > requirement. Also note that "deal with" can mean "recognize that no kex packet that can lead this implementation to a successful exchange can be over (say) 2000 bytes, so, if it's larger, read and ignore it in many small pieces and fail the protocol". This means permitting an implementation to fail kex just because the other side offers (eg) too many languages. I'd have to read the spec carefully to be sure whether there's enough latitude there for that at present.... /~\ 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 Fri Apr 2 16:20:42 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 QAA00818 for ; Fri, 2 Apr 2004 16:20:41 -0500 (EST) Received: (qmail 21827 invoked by uid 605); 2 Apr 2004 21:20:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21820 invoked from network); 2 Apr 2004 21:20:40 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 2 Apr 2004 21:20:40 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i32LKdLT012086; Fri, 2 Apr 2004 13:20:39 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i32LKdcE019171; Fri, 2 Apr 2004 14:20:39 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i32LKGhf017256; Fri, 2 Apr 2004 15:20:16 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i32LKFHx017255; Fri, 2 Apr 2004 15:20:15 -0600 (CST) Date: Fri, 2 Apr 2004 15:20:15 -0600 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: Large lang tag lists (was Re: Speaking of implementation quirks...) Message-ID: <20040402212012.GA17251@binky.central.sun.com> References: <20040402042453.GA16465@binky.central.sun.com> <20040402172857.GV5868@binky.central.sun.com> <200404021740.MAA11631@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404021740.MAA11631@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Fri, Apr 02, 2004 at 12:34:28PM -0500, der Mouse wrote: > > At least for the initial key exchange I think that we need to mandate > > that implementions be able to deal with large packets; after the > > initial kex there's no need, I think, to have a large packet support > > requirement. > > Also note that "deal with" can mean "recognize that no kex packet that > can lead this implementation to a successful exchange can be over (say) > 2000 bytes, so, if it's larger, read and ignore it in many small pieces > and fail the protocol". > > This means permitting an implementation to fail kex just because the > other side offers (eg) too many languages. I'd have to read the spec > carefully to be sure whether there's enough latitude there for that at > present.... I was thinking of how servers respond to incorrect optimistic selection of first kex packets that are too large. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 2 16:30: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 QAA01517 for ; Fri, 2 Apr 2004 16:30:37 -0500 (EST) Received: (qmail 27269 invoked by uid 605); 2 Apr 2004 21:30:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27261 invoked from network); 2 Apr 2004 21:30:34 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 2 Apr 2004 21:30:34 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id E4260E179A; Fri, 2 Apr 2004 23:26:05 +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 B8A2EEB837; Fri, 2 Apr 2004 23:25:54 +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 i32LPsRO020266; Fri, 2 Apr 2004 23:25:54 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i32LPrL7020263; Fri, 2 Apr 2004 23:25:53 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: Large lang tag lists (was Re: Speaking of implementation quirks...) References: <20040402042453.GA16465@binky.central.sun.com> <20040402172857.GV5868@binky.central.sun.com> <200404021740.MAA11631@Sparkle.Rodents.Montreal.QC.CA> 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: 02 Apr 2004 23:25:53 +0200 In-Reply-To: <200404021740.MAA11631@Sparkle.Rodents.Montreal.QC.CA> 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.1 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.1 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit der Mouse writes: > This means permitting an implementation to fail kex just because the > other side offers (eg) too many languages. I'd have to read the spec > carefully to be sure whether there's enough latitude there for that at > present.... I'm pretty sure the spec doesn't allow such behaviour. What you could do is to parse the large KEXINIT packet incrementally, so you can ignore large language lists without ever storing the full list. Similarly, you MUST be able to read and ignore DEBUG and IGNORE messages of size up to 32K. (My current code imposes the arbitrary limit of 47 elements on all lists in the KEXINIT message. I realize that I have to make that more flexible). /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Apr 3 23:39: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 XAA17736 for ; Sat, 3 Apr 2004 23:39:18 -0500 (EST) Received: (qmail 18001 invoked by uid 605); 4 Apr 2004 04:39:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17993 invoked from network); 4 Apr 2004 04:39:17 -0000 Received: from smtp.cs.auckland.ac.nz (130.216.33.151) by mail.netbsd.org with SMTP; 4 Apr 2004 04:39:17 -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 D8EA2340F8; Sun, 4 Apr 2004 16:37:19 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.30) id 1B9zPW-0007yh-4g; Sun, 04 Apr 2004 16:39:06 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: nisse@lysator.liu.se, pgut001@cs.auckland.ac.nz Subject: Re: Speaking of implementation quirks... Cc: ietf-ssh@NetBSD.org, mouse@Rodents.Montreal.QC.CA In-Reply-To: Message-Id: Date: Sun, 04 Apr 2004 16:39:06 +1200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) writes: >pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > >>The reason I asked for the disambiguation in -transport is that I've only ever >>found one implementation that, if asked for a max.packet size of nK, sends >>significantly more than nK. > >I think it would be good if you spelled out exactly which implementation(s) >you are talking about. Mine (lsh) applies the channel max packet size to the >application data portion of DATA and EXTENDED_DATA packets. I don't know what >other implementors do. Well I can't list all of them because I don't know what users are communicating with, only the ones that they complain about, which in this case was WS_FTP for Windows. I've since worked around it by increasing the amount of slop when defining upper bounds buffer sizes, but that's probably not a long-term solution. >It's not *explicitly* negotiated, but as long as the largest packets are the >channel data packets, one can make sure one doesn't get very large packets by >advertising a small channel max packet size. So it would probably work with a >required buffer size of just a few thousand bytes. Right, and that works fine. The problem is that putting in a MUST 32K means that someone can come along in the future and claim that something is non- compliant because it can't handle a 32K packet even when though explicitly asked for an 8K packet size. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Apr 3 23:42: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 XAA17837 for ; Sat, 3 Apr 2004 23:42:21 -0500 (EST) Received: (qmail 20161 invoked by uid 605); 4 Apr 2004 04:42:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20153 invoked from network); 4 Apr 2004 04:42:21 -0000 Received: from smtp.cs.auckland.ac.nz (130.216.33.151) by mail.netbsd.org with SMTP; 4 Apr 2004 04:42:21 -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 ABBB1340A5; Sun, 4 Apr 2004 16:40:38 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 4.30) id 1B9zSi-0007z3-Vz; Sun, 04 Apr 2004 16:42:24 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@NetBSD.org, mouse@Rodents.Montreal.QC.CA Subject: Re: Large lang tag lists (was Re: Speaking of implementation quirks...) In-Reply-To: <200404021740.MAA11631@Sparkle.Rodents.Montreal.QC.CA> Message-Id: Date: Sun, 04 Apr 2004 16:42:24 +1200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list der Mouse writes: >Also note that "deal with" can mean "recognize that no kex packet that can >lead this implementation to a successful exchange can be over (say) 2000 >bytes, so, if it's larger, read and ignore it in many small pieces and fail >the protocol". I can just see the code comment for this, "Encountering this behaviour is the equivalent of seeing someone wearing his underpants on his head coming down the street towards you. Best practice is to cross the read to avoid them. We now close the connection and exit..." :-). Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Apr 4 04:24:12 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 EAA22575 for ; Sun, 4 Apr 2004 04:24:11 -0400 (EDT) Received: (qmail 16053 invoked by uid 605); 4 Apr 2004 08:24:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16016 invoked from network); 4 Apr 2004 08:24:07 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 4 Apr 2004 08:24:07 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id EAA13434; Sun, 4 Apr 2004 04:24:07 -0400 (EDT) From: der Mouse Message-Id: <200404040824.EAA13434@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: Sun, 4 Apr 2004 04:07:01 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: channel-request Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Reading connect-18, I see that CHANNEL_REQUEST says that "If want reply is FALSE, no response will be sent to the request"; it also says that "If the request is not recognized or is not supported for the channel, SSH_MSG_CHANNEL_FAILURE is returned". Which of these trumps the other? That is, if an unrecognized or unsupported request arrives with want-reply FALSE, is a failure request sent, or not? Based on the difficulty of associating responses with requests if the latter wins, I would guess the former wins (ie, no response is to be sent in such a circumstance). First, is my guess correct? Second, if so, might it be good to clarify this, such as by changing the latter sentence to something like "If the request is not recognized or is not supported for the channel, SSH_MSG_CHANNEL_FAILURE is returned (unless want reply is FALSE)"? /~\ 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 Sun Apr 4 15:12: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 PAA07987 for ; Sun, 4 Apr 2004 15:12:36 -0400 (EDT) Received: (qmail 19959 invoked by uid 605); 4 Apr 2004 19:12:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19911 invoked from network); 4 Apr 2004 19:12:34 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 4 Apr 2004 19:12:34 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 11784100E63; Sun, 4 Apr 2004 21:12:33 +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 76CBD1027CB; Sun, 4 Apr 2004 21:12:29 +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 i34JCTRO005834; Sun, 4 Apr 2004 21:12:29 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i34JCSRk005831; Sun, 4 Apr 2004 21:12:28 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: channel-request References: <200404040824.EAA13434@Sparkle.Rodents.Montreal.QC.CA> 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: 04 Apr 2004 21:12:28 +0200 In-Reply-To: <200404040824.EAA13434@Sparkle.Rodents.Montreal.QC.CA> Message-ID: Lines: 12 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.1 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.1 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit der Mouse writes: > Reading connect-18, I see that CHANNEL_REQUEST says that "If want reply > is FALSE, no response will be sent to the request"; it also says that > "If the request is not recognized or is not supported for the channel, > SSH_MSG_CHANNEL_FAILURE is returned". If you set want_reply = FALSE, the other end must *not* send any reply to the request. It doesn't matter if the request succeeds or fails, and it doesn't matter why it fails if it fails. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Apr 4 17:03:29 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 RAA11303 for ; Sun, 4 Apr 2004 17:03:28 -0400 (EDT) Received: (qmail 8814 invoked by uid 605); 4 Apr 2004 21:03:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8807 invoked from network); 4 Apr 2004 21:03:27 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 4 Apr 2004 21:03:27 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i34L3QLT014771; Sun, 4 Apr 2004 14:03:26 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i34L3Q4F011920; Sun, 4 Apr 2004 15:03:26 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i34L32hf018477; Sun, 4 Apr 2004 16:03:02 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i34L31ON018476; Sun, 4 Apr 2004 16:03:01 -0500 (CDT) Date: Sun, 4 Apr 2004 16:03:00 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: channel-request Message-ID: <20040404210257.GA18358@binky.central.sun.com> References: <200404040824.EAA13434@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404040824.EAA13434@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sun, Apr 04, 2004 at 04:07:01AM -0400, der Mouse wrote: > Reading connect-18, I see that CHANNEL_REQUEST says that "If want reply > is FALSE, no response will be sent to the request"; it also says that > "If the request is not recognized or is not supported for the channel, > SSH_MSG_CHANNEL_FAILURE is returned". > > Which of these trumps the other? The former. > That is, if an unrecognized or > unsupported request arrives with want-reply FALSE, is a failure request > sent, or not? No failure reply is sent if want-reply == FALSE. > Based on the difficulty of associating responses with requests if the > latter wins, I would guess the former wins (ie, no response is to be > sent in such a circumstance). Yup. > First, is my guess correct? Yup. > Second, if so, might it be good to clarify this, such as by changing > the latter sentence to something like "If the request is not recognized > or is not supported for the channel, SSH_MSG_CHANNEL_FAILURE is > returned (unless want reply is FALSE)"? Yes. The text is a bit confsing. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 5 10:44: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 KAA04802 for ; Mon, 5 Apr 2004 10:44:49 -0400 (EDT) Received: (qmail 7082 invoked by uid 605); 5 Apr 2004 14:44:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7066 invoked from network); 5 Apr 2004 14:44:48 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 5 Apr 2004 14:44:48 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04790; Mon, 5 Apr 2004 10:44:44 -0400 (EDT) Message-Id: <200404051444.KAA04790@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-publickey-subsystem-01.txt Date: Mon, 05 Apr 2004 10:44:44 -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 : Secure Shell Public-Key Subsystem Author(s) : J. Galbraith, et al. Filename : draft-ietf-secsh-publickey-subsystem-01.txt Pages : 16 Date : 2004-4-2 SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. This protocol is intended to be used from the Secure Shell Connection Protocol [4] as a subsystem, as described in Section ``Starting aShell or a Command''. The subsystem name used with this protocol is ''publickey''. The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with various restrictions, including a mandatory command or subsystem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickey-subsystem-01.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-publickey-subsystem-01.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-publickey-subsystem-01.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-4-5110312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-publickey-subsystem-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-publickey-subsystem-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-5110312.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 5 11:38: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 LAA07377 for ; Mon, 5 Apr 2004 11:38:18 -0400 (EDT) Received: (qmail 17471 invoked by uid 605); 5 Apr 2004 15:38:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17464 invoked from network); 5 Apr 2004 15:38:18 -0000 Received: from emulex.emulex.com (138.239.112.1) by mail.netbsd.org with SMTP; 5 Apr 2004 15:38:18 -0000 Received: from xcm.ad.emulex.com (xcm.emulex.com [138.239.112.206]) by emulex.emulex.com (8.12.10/8.12.10) with ESMTP id i35FbfCL012082; Mon, 5 Apr 2004 08:37:41 -0700 (PDT) Received: by xcm.emulex.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Apr 2004 08:37:41 -0700 Message-ID: <8D43EFD7CCBDB24980134BE078C227E7093A8297@xcm.emulex.com> From: System Attendant To: "'i-d-announce@ietf.org'" , "'ietf-ssh@netbsd.org'" Subject: [MailServer Notification]To Recipient file blocking settings matc hed and action was taken. Date: Mon, 5 Apr 2004 08:37:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ietf-ssh-owner@NetBSD.org Precedence: list ScanMail for Microsoft Exchange took action on the message. The message details were: Sender = Internet-Drafts@ietf.org Recipient(s) = i-d-announce@ietf.org;ietf-ssh@netbsd.org Subject = I-D ACTION:draft-ietf-secsh-publickey-subsystem-01.txt Scanning time = 04/05/2004 08:37:40 Engine/Pattern = 7.000-1004/849 Action taken on message: The attachment draft-ietf-secsh-publickey-subsystem-01.url matched file blocking settings. ScanMail took the action: Deleted. XCM Warning to recipient: Attachment blocking action taken. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 7 11:36:21 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 LAA03914 for ; Wed, 7 Apr 2004 11:36:21 -0400 (EDT) Received: (qmail 2288 invoked by uid 605); 7 Apr 2004 15:36:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2280 invoked from network); 7 Apr 2004 15:36:20 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 7 Apr 2004 15:36:20 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03908; Wed, 7 Apr 2004 11:36:16 -0400 (EDT) Message-Id: <200404071536.LAA03908@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-publickeyfile-05.txt Date: Wed, 07 Apr 2004 11:36:16 -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 : SSH Public Key File Format Author(s) : J. Galbraith, R. Thayer Filename : draft-ietf-secsh-publickeyfile-05.txt Pages : 11 Date : 2004-4-6 This document formally documents the existing public key file format in use for exchanging public keys between different SECSH implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickeyfile-05.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-publickeyfile-05.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-publickeyfile-05.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-4-7110856.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-publickeyfile-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-publickeyfile-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-7110856.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 7 12:32:29 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 MAA07857 for ; Wed, 7 Apr 2004 12:32:28 -0400 (EDT) Received: (qmail 14168 invoked by uid 605); 7 Apr 2004 16:32:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14142 invoked from network); 7 Apr 2004 16:32:27 -0000 Received: from emulex.emulex.com (138.239.112.1) by mail.netbsd.org with SMTP; 7 Apr 2004 16:32:27 -0000 Received: from xcm.ad.emulex.com (xcm.emulex.com [138.239.112.206]) by emulex.emulex.com (8.12.10/8.12.10) with ESMTP id i37GVoCL017324; Wed, 7 Apr 2004 09:31:50 -0700 (PDT) Received: by xcm.emulex.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Apr 2004 09:31:50 -0700 Message-ID: <8D43EFD7CCBDB24980134BE078C227E7093A830A@xcm.emulex.com> From: System Attendant To: "'i-d-announce@ietf.org'" , "'ietf-ssh@netbsd.org'" Subject: [MailServer Notification]To Recipient file blocking settings matc hed and action was taken. Date: Wed, 7 Apr 2004 09:31:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ietf-ssh-owner@NetBSD.org Precedence: list ScanMail for Microsoft Exchange took action on the message. The message details were: Sender = Internet-Drafts@ietf.org Recipient(s) = i-d-announce@ietf.org;ietf-ssh@netbsd.org Subject = I-D ACTION:draft-ietf-secsh-publickeyfile-05.txt Scanning time = 04/07/2004 09:31:49 Engine/Pattern = 7.000-1004/853 Action taken on message: The attachment draft-ietf-secsh-publickeyfile-05.url matched file blocking settings. ScanMail took the action: Deleted. XCM Warning to recipient: Attachment blocking action taken. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 9 23:25:58 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 XAA07470 for ; Fri, 9 Apr 2004 23:25:56 -0400 (EDT) Received: (qmail 25868 invoked by uid 605); 10 Apr 2004 03:25:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25860 invoked from network); 10 Apr 2004 03:25:47 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 10 Apr 2004 03:25:47 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id XAA04330; Fri, 9 Apr 2004 23:25:47 -0400 (EDT) From: der Mouse Message-Id: <200404100325.XAA04330@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: Fri, 9 Apr 2004 23:18:01 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: cancel-tcpip-forward matching Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit When doing a cancel-tcpip-forward, how exactly does the request have to match the tcpip-forward request it's cancelling? For example, if I send a tcpip-forward request specifying the peer machine by name, can I cancel it specifying the peer machine by address? (To be concrete, say I tcpip-forward "sparkle-4.rodents.montreal.qc.ca" port 12345, can I cancel it by cancel-tcpip-forwarding "216.46.5.7" port 12345?) If a tcpip-forward request implies binding multiple address/port pairs, is it possible to cancel some but not all of them by specifying them by address (or more-specific name)? As a concrete example, suppose I tcpip-forward "sparkle.rodents.montreal.qc.ca" port 12345 (implying both 216.46.5.7/12345 and 3ffe:b00:4020:300::7:0/12345); can I then cancel-tcpip-forward "3ffe:b00:4020:300::7:0" port 12345 and still leave the 216.46.5.7/12345 forwarding active? Or is all this left up to the implementations? /~\ 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 Apr 10 10:54:09 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 KAA08511 for ; Sat, 10 Apr 2004 10:54:09 -0400 (EDT) Received: (qmail 29725 invoked by uid 605); 10 Apr 2004 14:54:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29718 invoked from network); 10 Apr 2004 14:54:06 -0000 Received: from mail-in-02.arcor-online.net (151.189.21.42) by mail.netbsd.org with SMTP; 10 Apr 2004 14:54:06 -0000 Received: from localhost.arcor.net (dsl-213-023-026-122.arcor-ip.net [213.23.26.122]) by mail-in-02.arcor-online.net (Postfix) with ESMTP id 6FBB1B70772; Sat, 10 Apr 2004 16:54:04 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id 7EFE22D7B3; Sat, 10 Apr 2004 16:54:00 +0200 (CEST) Date: Sat, 10 Apr 2004 16:53:59 +0200 From: Markus Friedl To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: cancel-tcpip-forward matching Message-ID: <20040410145359.GA581@folly> References: <200404100325.XAA04330@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404100325.XAA04330@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.4.2i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Fri, Apr 09, 2004 at 11:18:01PM -0400, der Mouse wrote: > Or is all this left up to the implementations? i would only cancel on exact string matches. but this is left up to the implementation. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 13 05:40:02 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 FAA00990 for ; Tue, 13 Apr 2004 05:39:59 -0400 (EDT) Received: (qmail 1349 invoked by uid 605); 13 Apr 2004 09:39:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1341 invoked from network); 13 Apr 2004 09:39:52 -0000 Received: from tonnant.concentric.net (HELO tonnant.cnchost.com) (207.155.248.72) by mail.netbsd.org with SMTP; 13 Apr 2004 09:39:52 -0000 Received: from Nucleus (BSN-95-201-67.dsl.siol.net [193.95.201.67]) by tonnant.cnchost.com id FAA21994; Tue, 13 Apr 2004 05:39:50 -0400 (EDT) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: Subject: RE: cancel-tcpip-forward matching Date: Tue, 13 Apr 2004 11:39:41 +0200 Message-ID: <007401c4213b$41fa3440$6302a8c0@Nucleus> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20040410145359.GA581@folly> Importance: Normal Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > > Or is all this left up to the implementations? > > i would only cancel on exact string matches. but this is left up > to the implementation. I don't think it's so much up to the implementation... I think this is the Correct Way. The idea being - what you effect with one request, you can cancel with a symmetric one, without having to understand the implementation semantics. I.e., regardless of the values of "listen address" and "listen port", these form the name and unique identifier of a request, and any side effects of the request are canceled by supplying the original request's unique identifier, which is the "listen address" and "listen port" as supplied previously. I think an implementation that did not adopt this idea would be broken... The whole idea of standards is to get consistent output when supplying consistent input. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 13 06:08: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 GAA02245 for ; Tue, 13 Apr 2004 06:08:36 -0400 (EDT) Received: (qmail 19121 invoked by uid 605); 13 Apr 2004 10:08:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19113 invoked from network); 13 Apr 2004 10:08:35 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 13 Apr 2004 10:08:35 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id GAA22535; Tue, 13 Apr 2004 06:08:34 -0400 (EDT) From: der Mouse Message-Id: <200404131008.GAA22535@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: Tue, 13 Apr 2004 06:02:33 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: cancel-tcpip-forward matching In-Reply-To: <007401c4213b$41fa3440$6302a8c0@Nucleus> References: <007401c4213b$41fa3440$6302a8c0@Nucleus> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >>> Or is all this left up to the implementations? >> i would only cancel on exact string matches. but this is left up to >> the implementation. > I don't think it's so much up to the implementation... I think this > is the Correct Way. The idea being - what you effect with one > request, you can cancel with a symmetric one, without having to > understand the implementation semantics. Yes; I agree that if the same string is given, the preceding request should be undone. My question really bears more on what happens when a different string is given. _Must_ the server reject the cancel attempt, or is it permitted to possibly cancel previous requests, or portions of previous requests, that match the cancel request it in an implementation-defined way? > I think an implementation that did not adopt this idea would be > broken... The whole idea of standards is to get consistent output > when supplying consistent input. For what it may be worth, my implementation as it stands does not quite do this. For numeric and wildcard forwarding, I think it does - but if the host string is a FQDN, and the set of addresses it resolves to at cancel time is not the same as the set of addresses it resolves to at request time, the cancel may not cancel exactly and only the forwardings established by the forward request. I'm not sure whether I consider this behaviour broken. After all, telnet and the DNS are standardized too, and yet nobody thinks it broken that "telnet foo.example.net" may connect you to two different hosts at different times if the DNS has changed in between. /~\ 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 Apr 14 03:10: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 DAA05456 for ; Wed, 14 Apr 2004 03:10:18 -0400 (EDT) Received: (qmail 10083 invoked by uid 605); 14 Apr 2004 07:09:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10070 invoked from network); 14 Apr 2004 07:09:50 -0000 Received: from www.mandrakesecure.net (HELO clarion.mandrax.org) (212.85.147.174) by mail.netbsd.org with SMTP; 14 Apr 2004 07:09:50 -0000 Received: (qmail 32119 invoked from network); 14 Apr 2004 08:07:20 -0000 Received: from unknown (HELO sidious.mandrakesecure.net) (127.0.0.1) by localhost with SMTP; 14 Apr 2004 08:07:20 -0000 From: discuss@mandrakesecure.net Subject: confirmation request Date: Wed, 14 Apr 2004 10:07:20 +0200 (CEST) Message-ID: <1081930040.32115.TMDA@sidious.mandrakesecure.net> To: ietf-ssh@NetBSD.org Reply-To: discuss-confirm-1081930040.32115.3290e4bb@mandrakesecure.net X-Delivery-Agent: TMDA/0.62 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Your message with the subject "Mail Delivery (failure discuss@mandrakesecure.net)" is being held because your address is not subscribed to this mailing list. You MUST reply to this confirmation request before your message is delivered. To release your message for delivery, please send an empty message to the following address, or use your mailer's "Reply" feature. If you do not wish to receive these confirmation messages on subsequent postings to the mailing list, please subscribe to the list. Please note that this list is a "subscriber-only" list, so all messages from unsubscribers will be forwarded to the moderator for approval anyways. This merely keeps the moderator from having to reject spam and unsolicited bulk email. Thank you. [ This notice was generated by TMDA/0.62 ] From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 14 03:13: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 DAA05607 for ; Wed, 14 Apr 2004 03:13:52 -0400 (EDT) Received: (qmail 12460 invoked by uid 605); 14 Apr 2004 07:13:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12452 invoked from network); 14 Apr 2004 07:13:32 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 14 Apr 2004 07:13:32 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id DAA06205; Wed, 14 Apr 2004 03:13:31 -0400 (EDT) From: der Mouse Message-Id: <200404140713.DAA06205@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, 14 Apr 2004 02:52:52 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: channel association Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit I'm working on my ssh implementation and I see more problems with the spec. There are a number of things which are conceptually associated with a session channel, but which are not actually entirely so associated. At the moment, these are primarily X and agent forwarding: they are requested with a CHANNEL_REQUESTs on a session channel, but when a forwarded connection arrives, the client gets no indication which session's forwarding it is due to. This is causing me trouble, for reasons I can go into if anyone is curious but which are mostly irrelevant here. More generally, it is a conceptual problem to associate a request with a session, but have no way to associate an asynchronous response to that request with the relevant session (or the particular request that produced it, which would allow identifying the session). In passing, I note that TCP connection forwarding was done right in this regard: it makes no pretense of being associated with any session, and is requested with not a CHANNEL_REQUEST but a GLOBAL_REQUEST. Has anyone addressed such issues before? I can think of at least two different ways of addressing them, and while I could simply pick one and implement it with private requests, I'd be interested in hearing about experiences from anyone who's tackled the issue already. /~\ 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 Apr 14 14:57:51 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 OAA14729 for ; Wed, 14 Apr 2004 14:57:50 -0400 (EDT) Received: (qmail 25783 invoked by uid 605); 14 Apr 2004 18:57:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25775 invoked from network); 14 Apr 2004 18:57:48 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 14 Apr 2004 18:57:48 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3EIvk6N002243; Wed, 14 Apr 2004 11:57:46 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i3EIvg4F005587; Wed, 14 Apr 2004 12:57:42 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i3EIvDhf026453; Wed, 14 Apr 2004 13:57:13 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i3EIvCWs026452; Wed, 14 Apr 2004 13:57:12 -0500 (CDT) Date: Wed, 14 Apr 2004 13:57:12 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: channel association Message-ID: <20040414185709.GA26430@binky.central.sun.com> References: <200404140713.DAA06205@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404140713.DAA06205@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Apr 14, 2004 at 02:52:52AM -0400, der Mouse wrote: > More generally, it is a conceptual problem to associate a request with > a session, but have no way to associate an asynchronous response to > that request with the relevant session (or the particular request that > produced it, which would allow identifying the session). Agreed. But note that the draft does say "[t]he resulting channels are independent of the session, ..." > In passing, I note that TCP connection forwarding was done right in > this regard: it makes no pretense of being associated with any session, > and is requested with not a CHANNEL_REQUEST but a GLOBAL_REQUEST. > > Has anyone addressed such issues before? I can think of at least two > different ways of addressing them, and while I could simply pick one > and implement it with private requests, I'd be interested in hearing > about experiences from anyone who's tackled the issue already. I think this problem probably ought to be fixed, but if it is to be fixed it should be fixed in a separate document. There are several fixes for this that I can imagine: a) Add a channel request for opening forwarded whatever channels. b) Add new SSH_MSG_CHANNEL_OPEN channel types for channels associated with session channels that includes the channel id of the associated session channel. c) Add new channel requests for associating an open channel with a session channel. Of course, if may be to late at that point for the client to do anything useful with this info, so this may not be useful at all. I much prefer (b). Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 14 17:18: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 RAA27373 for ; Wed, 14 Apr 2004 17:18:52 -0400 (EDT) Received: (qmail 2275 invoked by uid 605); 14 Apr 2004 21:18:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2268 invoked from network); 14 Apr 2004 21:18:50 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 14 Apr 2004 21:18:50 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id RAA09778; Wed, 14 Apr 2004 17:18:49 -0400 (EDT) From: der Mouse Message-Id: <200404142118.RAA09778@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, 14 Apr 2004 16:54:13 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: channel association In-Reply-To: <20040414185709.GA26430@binky.central.sun.com> References: <200404140713.DAA06205@Sparkle.Rodents.Montreal.QC.CA> <20040414185709.GA26430@binky.central.sun.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> More generally, it is a conceptual problem to associate a request >> with a session, but have no way to associate an asynchronous >> response to that request with the relevant session [...] > Agreed. But note that the draft does say "[t]he resulting channels > are independent of the session, ..." This is true in terms of their lifetime, but not in terms of the content they carry. (Note that the following phrase, which you didn't quote, specifically speaks of the lifetime, strongly implying that this remark is intended to refer to channel lifetimes.) > There are several fixes for this that I can imagine: > a) Add a channel request for opening forwarded whatever channels. > b) Add new SSH_MSG_CHANNEL_OPEN channel types for channels associated > with session channels that includes the channel id of the associated > session channel. > c) Add new channel requests for associating an open channel with a > session channel. > I much prefer (b). Me too, and that's what I'm doing for the moment. For example, when my client requests agent forwarding, it does so by requesting "fixed-auth-agent-req@rodents.montreal.qc.ca", and if that is refused it will fall back to trying "auth-agent-req", noting in the process that the resulting agent forwarding is inconsistent with the kind of optimization I want to do. The fixed- request is just like the one in the draft except it includes an additional uint32, which is returned in the "fixed-auth-agent@rodents.montreal.qc.ca" CHANNEL_OPEN that comes back when a forwarded connection is called for. X forwarding, when I add that, will work analogously. Unless, of course, someone comes up with a reason to do otherwise, which is why I was asking if anyone had addressed it already. /~\ 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 Apr 14 19:48: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 TAA06163 for ; Wed, 14 Apr 2004 19:48:43 -0400 (EDT) Received: (qmail 16770 invoked by uid 605); 14 Apr 2004 23:48:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16687 invoked from network); 14 Apr 2004 23:48:40 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 14 Apr 2004 23:48:40 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3ENmdgx002685; Wed, 14 Apr 2004 16:48:39 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i3ENmdcE010809; Wed, 14 Apr 2004 17:48:39 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i3ENmAhf026638; Wed, 14 Apr 2004 18:48:10 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i3ENm9f9026637; Wed, 14 Apr 2004 18:48:09 -0500 (CDT) Date: Wed, 14 Apr 2004 18:48:09 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: channel association Message-ID: <20040414234806.GA26630@binky.central.sun.com> References: <200404140713.DAA06205@Sparkle.Rodents.Montreal.QC.CA> <20040414185709.GA26430@binky.central.sun.com> <200404142118.RAA09778@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404142118.RAA09778@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Apr 14, 2004 at 04:54:13PM -0400, der Mouse wrote: > >> More generally, it is a conceptual problem to associate a request > >> with a session, but have no way to associate an asynchronous > >> response to that request with the relevant session [...] > > Agreed. But note that the draft does say "[t]he resulting channels > > are independent of the session, ..." > > This is true in terms of their lifetime, but not in terms of the > content they carry. (Note that the following phrase, which you didn't > quote, specifically speaks of the lifetime, strongly implying that this > remark is intended to refer to channel lifetimes.) Certainly reading that sentence doesn't make the problem immediately apparent, but I do think that the first clause of that sentence has meaning beyond that of the second clause. But let's not quibble. The text could be clarified and the problem could be fixed in a separate doc. > > There are several fixes for this that I can imagine: > > > a) Add a channel request for opening forwarded whatever channels. > > > b) Add new SSH_MSG_CHANNEL_OPEN channel types for channels associated > > with session channels that includes the channel id of the associated > > session channel. > > > c) Add new channel requests for associating an open channel with a > > session channel. > > > I much prefer (b). > > Me too, and that's what I'm doing for the moment. For example, when my > client requests agent forwarding, it does so by requesting > "fixed-auth-agent-req@rodents.montreal.qc.ca", and if that is refused > it will fall back to trying "auth-agent-req", noting in the process > that the resulting agent forwarding is inconsistent with the kind of > optimization I want to do. The fixed- request is just like the one in > the draft except it includes an additional uint32, which is returned in > the "fixed-auth-agent@rodents.montreal.qc.ca" CHANNEL_OPEN that comes > back when a forwarded connection is called for. X forwarding, when I > add that, will work analogously. > > Unless, of course, someone comes up with a reason to do otherwise, > which is why I was asking if anyone had addressed it already. I think this is the way to go. Obviously we'd need a standard channel open request name, but that's a minor detail. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 16 10:49: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 KAA13640 for ; Fri, 16 Apr 2004 10:49:31 -0400 (EDT) Received: (qmail 23745 invoked by uid 605); 16 Apr 2004 14:49:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23738 invoked from network); 16 Apr 2004 14:49:26 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 16 Apr 2004 14:49:26 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 5251037; Fri, 16 Apr 2004 08:49:25 -0600 Message-ID: <407FF275.8060906@vandyke.com> Date: Fri, 16 Apr 2004 08:49:25 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040414) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Pence CC: remaker@cisco.com, ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-break-01.txt 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 Brian Pence wrote: > What was the reason for abandoning this ietf draft? I've had a couple of > customer's request this functionality, but as it was never formalized as a > standard, I'm not so sure it's a good idea to implement. It's not even a > working draft any more. What gives? What's the plans for this? Basically, if I remember correctly, we are waiting for the the 'core-drafts' hairball to get to RFC status-- I'm not sure what the status of this is????? Once that happens all the other drafts that reference the core drafts can move forward. I suppose we just need to freshen the draft to keep it alive while this process drags on. As far as being formalized as a standard, it is currently as formal as any other SSH2 standard-- so if your implementing any SSH2, don't hold back :-) - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 16 11:09:40 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 LAA14851 for ; Fri, 16 Apr 2004 11:09:39 -0400 (EDT) Received: (qmail 11343 invoked by uid 605); 16 Apr 2004 15:09:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11336 invoked from network); 16 Apr 2004 15:09:38 -0000 Received: from sj-iport-5.cisco.com (171.68.10.87) by mail.netbsd.org with SMTP; 16 Apr 2004 15:09:38 -0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 16 Apr 2004 08:09:51 -0700 Received: from premakerpc (sjc-vpn4-1091.cisco.com [10.21.84.66]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id i3GF9Zqi016676; Fri, 16 Apr 2004 08:09:35 -0700 (PDT) Message-ID: <009901c423c4$d4dc0e10$667ba8c0@premakerpc> From: "Phillip Remaker" To: "Joseph Galbraith" , "Brian Pence" Cc: References: <407FF275.8060906@vandyke.com> Subject: Re: draft-ietf-secsh-break-01.txt Date: Fri, 16 Apr 2004 08:09:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Did the draft expire? We can just resubmit it. All auxillary specs are on standby until the core drafts are approved. What the heck is the holdup these days? Joe, do you want to resubmit it or should I? > Brian Pence wrote: > > What was the reason for abandoning this ietf draft? I've had a couple of > > customer's request this functionality, but as it was never formalized as a > > standard, I'm not so sure it's a good idea to implement. It's not even a > > working draft any more. What gives? What's the plans for this? > > Basically, if I remember correctly, we are waiting for the > the 'core-drafts' hairball to get to RFC status-- I'm not sure > what the status of this is????? > > Once that happens all the other drafts that reference the > core drafts can move forward. > > I suppose we just need to freshen the draft to keep it alive > while this process drags on. > > As far as being formalized as a standard, it is currently > as formal as any other SSH2 standard-- so if your implementing > any SSH2, don't hold back :-) > > - Joseph > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 16 11:20:06 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 LAA15621 for ; Fri, 16 Apr 2004 11:20:06 -0400 (EDT) Received: (qmail 18555 invoked by uid 605); 16 Apr 2004 15:19:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17784 invoked from network); 16 Apr 2004 15:19:45 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 16 Apr 2004 15:19:45 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 5251225; Fri, 16 Apr 2004 09:19:44 -0600 Message-ID: <407FF990.8080506@vandyke.com> Date: Fri, 16 Apr 2004 09:19:44 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040414) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Phillip Remaker CC: Brian Pence , ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-break-01.txt References: <407FF275.8060906@vandyke.com> <009901c423c4$d4dc0e10$667ba8c0@premakerpc> In-Reply-To: <009901c423c4$d4dc0e10$667ba8c0@premakerpc> 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'm not sure I've got the most recent XML-- Can you resubmit it? Thanks, Joseph Phillip Remaker wrote: > Did the draft expire? We can just resubmit it. All auxillary specs are on > standby until the core drafts are approved. > > What the heck is the holdup these days? > > Joe, do you want to resubmit it or should I? > > > > >>Brian Pence wrote: >> >>>What was the reason for abandoning this ietf draft? I've had a couple > > of > >>>customer's request this functionality, but as it was never formalized as > > a > >>>standard, I'm not so sure it's a good idea to implement. It's not even > > a > >>>working draft any more. What gives? What's the plans for this? >> >>Basically, if I remember correctly, we are waiting for the >>the 'core-drafts' hairball to get to RFC status-- I'm not sure >>what the status of this is????? >> >>Once that happens all the other drafts that reference the >>core drafts can move forward. >> >>I suppose we just need to freshen the draft to keep it alive >>while this process drags on. >> >>As far as being formalized as a standard, it is currently >>as formal as any other SSH2 standard-- so if your implementing >>any SSH2, don't hold back :-) >> >>- Joseph >> > > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 16 16:29: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 QAA05738 for ; Fri, 16 Apr 2004 16:29:09 -0400 (EDT) Received: (qmail 13714 invoked by uid 605); 16 Apr 2004 20:29:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13707 invoked from network); 16 Apr 2004 20:29:08 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 16 Apr 2004 20:29:08 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3GKSwgx026459; Fri, 16 Apr 2004 13:28:59 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i3GKSwcE025423; Fri, 16 Apr 2004 14:28:58 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i3GKSThf028517; Fri, 16 Apr 2004 15:28:29 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i3GKSRls028516; Fri, 16 Apr 2004 15:28:27 -0500 (CDT) Date: Fri, 16 Apr 2004 15:28:27 -0500 From: Nicolas Williams To: Joseph Galbraith Cc: Brian Pence , remaker@cisco.com, ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-break-01.txt Message-ID: <20040416202824.GA28509@binky.central.sun.com> References: <407FF275.8060906@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <407FF275.8060906@vandyke.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Fri, Apr 16, 2004 at 08:49:25AM -0600, Joseph Galbraith wrote: > Brian Pence wrote: > >What was the reason for abandoning this ietf draft? I've had a couple of > >customer's request this functionality, but as it was never formalized as a > >standard, I'm not so sure it's a good idea to implement. It's not even a > >working draft any more. What gives? What's the plans for this? > > Basically, if I remember correctly, we are waiting for the > the 'core-drafts' hairball to get to RFC status-- I'm not sure > what the status of this is????? > > Once that happens all the other drafts that reference the > core drafts can move forward. IIUC, if draft-ietf-secsh-break is ready you can request a WG last call on it and then submit it to the IESG. The IESG can actually move to publish a draft to Proposed Standard before other normative references that it depends on -- such drafts won't get published as RFCs until their normative dependencies do, of course. > I suppose we just need to freshen the draft to keep it alive > while this process drags on. Nah, freshen it then last call it. > As far as being formalized as a standard, it is currently > as formal as any other SSH2 standard-- so if your implementing > any SSH2, don't hold back :-) Heh. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Apr 16 16:38:54 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 QAA07149 for ; Fri, 16 Apr 2004 16:38:54 -0400 (EDT) Received: (qmail 20390 invoked by uid 605); 16 Apr 2004 20:38:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20383 invoked from network); 16 Apr 2004 20:38:52 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 16 Apr 2004 20:38:52 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3GKcagx002370; Fri, 16 Apr 2004 13:38:36 -0700 (PDT) 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 i3GKcYlE006408; Fri, 16 Apr 2004 16:38:34 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i3GKcYQU010711; Fri, 16 Apr 2004 16:38:34 -0400 (EDT) Message-Id: <200404162038.i3GKcYQU010711@thunk.east.sun.com> From: Bill Sommerfeld To: Nicolas Williams cc: Joseph Galbraith , Brian Pence , remaker@cisco.com, ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-break-01.txt In-Reply-To: Your message of "Fri, 16 Apr 2004 15:28:27 CDT." <20040416202824.GA28509@binky.central.sun.com> Reply-to: sommerfeld@east.sun.com Date: Fri, 16 Apr 2004 16:38:34 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list actually, I issued a last-call on secsh-break back in november. As best as I can tell, nobody said anything during the last call period (not atypical) My bad for not passing it up to the IESG. Phillip/Joseph: Please re-issue the draft and I'll forward it to our AD for IETF-wide last call. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Apr 17 21:56: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 VAA07786 for ; Sat, 17 Apr 2004 21:56:16 -0400 (EDT) Received: (qmail 12350 invoked by uid 605); 18 Apr 2004 01:56:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12335 invoked from network); 18 Apr 2004 01:56:15 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 18 Apr 2004 01:56:15 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id VAA28760; Sat, 17 Apr 2004 21:56:13 -0400 (EDT) From: der Mouse Message-Id: <200404180156.VAA28760@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, 17 Apr 2004 21:26:04 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: X forwarding Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit I'd like to dredge up something from the past (most recently, and perhaps most significantly, last November). I was starting to implement X forwarding, when I realized that the x11-req defined in connect-18 was unnecessarily complex, and, as far as I could see, pointlessly so. Rather than drag out stuff that I see from the archives has been hashed over before, I'll just ask two questions that I didn't see answers to in the archives. (It's possible I missed them; I just grepped for "x11-req". If they have been answered, something like a message-ID to grep for would be much appreciated.) I can see no value whatever in making the client pass an X authentication method and data blob to the server. The client has no idea what authentication methods may be supported by the X implementation on the server side, so it has no way to select an appropriate authentication method. There is no additional security gained from doing so, since any forwarded X connection will perforce be coming from the same entity the client gave the data blob to, so it serves no authentication use to return it. However, the people who designed the protocol are not stupid, so there must be something I'm missing. This, then, is my first question: why are those fields there? nisse@lysator.liu.se wrote, of X forwarding, that another field - "display id" is what I remember seeing - seems called for. I find this necessary too, for reasons very similar to what I mentioned recently when writing about forwarding TCP connections. > In more general terms, letting the server do the authentication is in > a way making an (X11) client responsible for X11 server security, > which is not good practice. I don't understand the point here. I have been unable to come up with a threat model against which having the client provide an authentication method and data blob provides any defense. My other question: can anyone give an example? I'm implementing X forwarding as a private request which carries only a uint32 cookie and a screen number; when the server wants to forward an X connection, the channel open carries the cookie and the first six bytes of the X protocol stream sent by the client (I could have sent these as the first data on the new connection, but this way seems marginally simpler). The rest of the Xclient->Xserver protocol setup data (the authorization name and data) are not sent; the client is expected to replace that anyway. What security horrors am I risking thereby? /~\ 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 Sun Apr 18 03:05: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 DAA05037 for ; Sun, 18 Apr 2004 03:05:44 -0400 (EDT) Received: (qmail 5972 invoked by uid 605); 18 Apr 2004 07:05:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5965 invoked from network); 18 Apr 2004 07:05:37 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 18 Apr 2004 07:05:37 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 1BF6Ms-0000C8-00; Sun, 18 Apr 2004 08:05:30 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@NetBSD.org In-Reply-To: <200404180156.VAA28760@Sparkle.Rodents.Montreal.QC.CA> Subject: Re: X forwarding Message-Id: Date: Sun, 18 Apr 2004 08:05:30 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list der Mouse wrote: > Rather than drag out stuff that I see from the archives has been > hashed over before, I'll just ask two questions that I didn't see > answers to in the archives. (It's possible I missed them; I just > grepped for "x11-req". If they have been answered, something like a > message-ID to grep for would be much appreciated.) > > I can see no value whatever in making the client pass an X > authentication method and data blob to the server. [...] > There is no additional security gained from doing so, since any > forwarded X connection will perforce be coming from the same entity > the client gave the data blob to, so it serves no authentication use > to return it. Yes, I suggested precisely this (that forwarded X connections over the SSH connection should be unauthenticated, allowing the client to insert its local auth and independently allowing the server to invent fake auth). , 23 Jan 2001. The consensus at the time was that several people thought my idea was better than the existing method, some other people thought it was at least no worse, but everybody (including me :-) agreed that even back in early 2001 it was much too late to change it for the only marginal gain. > I'm implementing X forwarding as a private request which carries only a > uint32 cookie and a screen number; [...] > What security horrors am I risking thereby? Surely the main horror you're risking is that nobody else's server will support your private request and everybody else's clients will expect you to support the standard one? -- Simon Tatham "loop, infinite _see_ infinite loop" - Index, Borland Pascal Language Guide From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Apr 18 03:36: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 DAA05752 for ; Sun, 18 Apr 2004 03:36:58 -0400 (EDT) Received: (qmail 29226 invoked by uid 605); 18 Apr 2004 07:36:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29212 invoked from network); 18 Apr 2004 07:36:16 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 18 Apr 2004 07:36:16 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id DAA15260; Sun, 18 Apr 2004 03:36:15 -0400 (EDT) From: der Mouse Message-Id: <200404180736.DAA15260@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: Sun, 18 Apr 2004 03:24:31 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: X forwarding In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> There is no additional security gained from [passing X authorization >> data from ssh client to ssh server] [...] > The consensus at the time was that several people thought my idea was > better than the existing method, some other people thought it was at > least no worse, but everybody (including me :-) agreed that even back > in early 2001 it was much too late to change it for the only marginal > gain. Only marginal gain? I don't consider getting rid of assumptions on the part of the client about what X authorization mechanisms are supported on the server "only marginal gain". :-) For my own purposes, I need an extra cookie, at least a small integer, which forces me to use a new request in any case. (I don't consider it acceptable to hijack part of the authorization cookie to carry this information.) The existing X forwarding is also rather underspecified; for example, it is clear that at least one end is expected to get its fingers into the X protocol, but it is not clear whether the data flowing through the X channel is pure X protocol or not (it might, for example, have the authorization information stripped - after all, the authorization information is the whole reason X forwarding is treated any differently from vanilla TCP forwarding). >> I'm implementing X forwarding as [...] >> What security horrors am I risking thereby? > Surely the main horror you're risking is that nobody else's server > will support your private request and everybody else's clients will > expect you to support the standard one? That's hardly a security problem, and in text which I notice you cut I quoted someone (our Swedish elf, I think it was) talking about insecurities in one way as compared to the other, but without including any specifics. As for compatability, now that I have X forwarding working at all, I will probably make it do something at least vaguely sensible with the X requests from connect-18 (though of course they will be incompatible with the connection sharing that I suspect will be one of the major features my version will offer). /~\ 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 Mon Apr 19 12:37: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 MAA22354 for ; Mon, 19 Apr 2004 12:37:35 -0400 (EDT) Received: (qmail 9807 invoked by uid 605); 19 Apr 2004 16:37:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9799 invoked from network); 19 Apr 2004 16:37:32 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 19 Apr 2004 16:37:32 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id C6CB210D104; Mon, 19 Apr 2004 18:32:08 +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 20DBB10CFC7; Mon, 19 Apr 2004 18:31:58 +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 i3JGVvcc011489; Mon, 19 Apr 2004 18:31:57 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i3JGVuDx011486; Mon, 19 Apr 2004 18:31:56 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: X forwarding References: <200404180156.VAA28760@Sparkle.Rodents.Montreal.QC.CA> 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 Apr 2004 18:31:56 +0200 In-Reply-To: <200404180156.VAA28760@Sparkle.Rodents.Montreal.QC.CA> Message-ID: Lines: 57 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.1 (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.1 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit der Mouse writes: > I can see no value whatever in making the client pass an X > authentication method and data blob to the server. The only value I see is that the munging of the X-protocol data stream, and the "fake cookie"-handling, is moved to the client rather than the server. When having the choice, I often prefer a complex client over a complex server. Besides that, I agree with what you're saying. > > In more general terms, letting the server do the authentication is in > > a way making an (X11) client responsible for X11 server security, > > which is not good practice. > > I don't understand the point here. I have been unable to come up with > a threat model against which having the client provide an > authentication method and data blob provides any defense. My other > question: can anyone give an example? Maybe not a good example, but I think you may failure mode when talking to a server that doesn't do any authentication at all (it just binds a tcp socket and starts forwarding connections). If the client expects a cookie in the ssh channel, it will reject unathorized connections. Including the cookie will of course not provide any protection from an compromised server (say, it opens a tcp socket and forwards it, and in addition stores the supplied cookie somewhere where the attacker can read it). But I think it may provide some protection from servers that are misconfigured rather than compromised. I agree all this is a pretty weak argument. > I'm implementing X forwarding as a private request which carries only a > uint32 cookie and a screen number; when the server wants to forward an > X connection, the channel open carries the cookie and the first six > bytes of the X protocol stream sent by the client (I could have sent > these as the first data on the new connection, but this way seems > marginally simpler). Please write up a spec for this. Including details such as the expectation that the server will ensure (by creating a new random cookie, or by some *stronger* authentication method) that only authorized processes can use the X forwarding. And in which way the forwarding is associated to a session (for example, if the forwarding is cancelled automatically when the session channel is closed). The lack of a display id is one of the reasons my "connection sharing thing", lshg, doesn't support X11 forwarding, so I may want to use your new request type. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 19 14:12: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 OAA28827 for ; Mon, 19 Apr 2004 14:12:59 -0400 (EDT) Received: (qmail 22181 invoked by uid 605); 19 Apr 2004 18:12:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22174 invoked from network); 19 Apr 2004 18:12:55 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 19 Apr 2004 18:12:55 -0000 Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id OAA02024; Mon, 19 Apr 2004 14:12:54 -0400 (EDT) From: der Mouse Message-Id: <200404191812.OAA02024@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: Mon, 19 Apr 2004 13:44:16 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: X forwarding In-Reply-To: References: <200404180156.VAA28760@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >>> In more general terms, letting the server do the authentication is >>> in a way making an (X11) client responsible for X11 server >>> security, which is not good practice. >> I don't understand the point here. I have been unable to come up >> with a threat model against which having the client provide an >> authentication method and data blob provides any defense. > Maybe not a good example, but I think you may failure mode when > talking to a server that doesn't do any authentication at all [...] True enough. I was considering only malicious servers and servers that cared about the security of the forwarded connection, not servers that, while not actively compromised, just didn't care. (I suppose my stance is that you shouldn't be having your client attempt X forwarding when connecting to a machine running a server whose X forwarding security stance you don't know.) > If the client expects a cookie in the ssh channel, it will reject > unathorized connections. This depends on the server doing something with the cookie like putting it in a .Xauthority file, as opposed to just saving it and bashing it into the authorization data fields of the X connection-open packet. But doing that while not taking any other measures to secure the connection is getting pretty close to the poin twhere I'd call it actively malicious. >> I'm implementing X forwarding as a private request which carries >> only a uint32 cookie and a screen number; when the server wants to >> forward an X connection, the channel open carries the cookie and the >> first six bytes of the X protocol stream sent by the client (I could >> have sent these as the first data on the new connection, but this >> way seems marginally simpler). > Please write up a spec for this. Sure. See below. > Including details such as the expectation that the server will ensure > [...] that only authorized processes can use the X forwarding. And > in which way the forwarding is associated to a session (for example, > if the forwarding is cancelled automatically when the session channel > is closed). To request X forwarding, the client sends byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "fixed-x11-req@rodents.montreal.qc.ca" boolean want reply uint32 token uint32 x11 screen number The server is, yes, expected to take appropriate steps (some form of authentication at least as strong as MIT-MAGIC-COOKIE-1) to ensure that only authorized processes use the connection. There is no single-connection boolean; that struck me as unnecessary complexity, and if the client wants those semantics, it can cancel the forwarding (see below) and reject any extra CHANNEL_OPENs that arrive because of the race or because the server rejects the cancel. The token is entirely opaque to the (ssh) server; the only things the server ever does with it are (a) send it back when an X connection is opened and (b) compare it when cancelling X forwarding. Upon getting a forwarded X connetion and its passing whatever security checks, the server generates byte SSH_MSG_CHANNEL_OPEN string "fixed-x11@rodents.montreal.qc.ca" uint32 sender channel uint32 initial window size uint32 maximum packet size uint32 token from the corresponding CHANNEL_REQUEST byte[6] first six bytes of the client X setup packet (the byte order and version numbers) string connection method ("tcp" for TCP, others not yet specified - I'm imagining things like "decnet" and "local" for DECnet sockets and /tmp/.X11-unix/* - see below for more on this). connection-method-specific data for method "tcp": string originator address (e.g. "192.168.7.38") uint32 originator port The initial client->server setup packet is not carried as channel data; the first six bytes of it are carried in the open request with the rest being synthesized locally by the client. In the Xserver->Xclient direction, the channel carries pure X data right from the beginning of the Xserver's response, but in the Xclient->Xserver direction, the first channel data consists of the client's first request, if any. In general, I don't like ssh's dependence on something TCP-like in the protocol (for example, it assumes that the protocol has something like port numbers that can fit in a uint32, and it thus is not possible to run ssh, as defined, over DECnet stream sockets). Since I didn't want to redesign the whole protocol, I've lived with this in most respects. But since I'm designing a new request for X, I wanted to fix at least that much of it, especially since the connection in question is entirely out of ssh's purview. (This also addresses the question I saw in the archives about "what originator info do I use for an AF_LOCAL X connection?"). I have not actually implemented cancelling X forwarding. Here's a first stab at it: byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "cancel-x11-req@rodents.montreal.qc.ca" boolean want reply uint32 token uint32 x11 screen number This cancels all previous X forwardings for that channel, token, and screen number. I see no need for a way to wildcard any of these; if others disagree, two additional bits (to indicate wildcarding of the token or screen number) could be added, either as two booleans or as a uint32 flags bitmask.... /~\ 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 Mon Apr 19 18:39: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 SAA17307 for ; Mon, 19 Apr 2004 18:39:09 -0400 (EDT) Received: (qmail 17507 invoked by uid 605); 19 Apr 2004 22:39:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17495 invoked from network); 19 Apr 2004 22:39:06 -0000 Received: from firestar.cisco.com (HELO fire.cisco.com) (171.68.227.75) by mail.netbsd.org with SMTP; 19 Apr 2004 22:39:06 -0000 Received: from remakerw2k01 (remaker-w2k01.cisco.com [171.69.103.14]) by fire.cisco.com (8.11.7+Sun/8.8.8) with SMTP id i3JMcci28324; Mon, 19 Apr 2004 15:38:38 -0700 (PDT) Message-ID: <01e801c4265f$0ebcf670$0e6745ab@amer.cisco.com> From: "Phillip Remaker" To: "Phillip Remaker" , "Joseph Galbraith" , "Brian Pence" Cc: References: <407FF275.8060906@vandyke.com> <009901c423c4$d4dc0e10$667ba8c0@premakerpc> Subject: Re: draft-ietf-secsh-break-01.txt Date: Mon, 19 Apr 2004 15:38:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit I just submitted draft-ietf-secsh-break-03 to internet-drafts@ietf.org. Just updated dates and informative references, so that it stays on the radar screen of the working group. Text included here for your amusement. ------------------- Secure Shell Working Group J. Galbraith Internet-Draft VanDyke Software Expires: October 18, 2004 P. Remaker Cisco Systems, Inc April 19, 2004 Session Channel Break Extension draft-ietf-secsh-break-03.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 18, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The Session Channel Break Extension provides a means to send a BREAK signal [2] over an SSH terminal session [5]. Galbraith & Remaker Expires October 18, 2004 [Page 1] Internet-Draft Session Channel Break Extension April 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Break Request . . . . . . . . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1 Normative References . . . . . . . . . . . . . . . . . . . . 7 4.2 Informative References . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . 8 Galbraith & Remaker Expires October 18, 2004 [Page 2] Internet-Draft Session Channel Break Extension April 2004 1. Introduction The SSH session channel provides a mechanism for the client-user to interactively enter commands and receive output from a remote host while taking advantage of the SSH transport's privacy and integrity features. SSH is increasingly being used to replace telnet for terminal access applications. A common application of the telnet protocol is the "Console Server" [2] whereby a telnet NVT can be connected to a physical RS-232/V.24 asynchronous port, making the telnet NVT appear as a locally attached terminal to that port, and making that physical port appear as a network addressable device. A number of major computer equipment vendors provide high level administrative functions through an asynchronous serial port and generally expect the attached terminal to be capable of send a BREAK signal. A BREAK signal is defined as the TxD signal being held in a SPACE ("0") state for a time greater than a whole character time. In practice, a BREAK signal is typically 250 to 500 ms in length. The telnet protocol furnishes a means to send a "BREAK" signal, which RFC0854 defines as a "a signal outside the USASCII set which is currently given local meaning within many systems." [1] Console Server vendors interpret the TELNET BREAK signal as a physical BREAK signal, which can then allow access to the full range of adminisrative functions available on an asynchronous serial console port. The lack of a similar facility in the SSH session channel has forced users to continue the use of telnet for the "Console Server" function. Galbraith & Remaker Expires October 18, 2004 [Page 3] Internet-Draft Session Channel Break Extension April 2004 2. The Break Request The following following channel specific request can be sent to request that the remote host perform a BREAK operation. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "break" boolean want_reply uint32 break-length in milliseconds If the BREAK length cannot be controlled by the application receiving this request, the BREAK length parameter SHOULD be ignored and the default BREAK signal length of the chipset or underlying chipset driver SHOULD be sent. If the application receiving this request can control the BREAK-length, the following suggestions are made regarding BREAK duration. If a BREAK duration request of greater than 3000ms is received, it SHOULD be processed as a 3000ms BREAK, in order to prevent an unreasonably long BREAK request causing the port to become unavailable for as long as 49.7 days while executing the BREAK. Applications that require a longer BREAK may choose to ignore this requirement. If BREAK duration request of less than 500ms, is requested a BREAK of 500ms SHOULD be sent since most devices will recognize a BREAK of that length. In the event that an application needs a shorter BREAK, this suggestion can be ignored. If the BREAK-length parameter is 0, the BREAK SHOULD be sent as 500ms or the default BREAK signal length of the chipset or underlying chipset driver. If the SSH connection does not terminate on a physical serial port, the BREAK indication SHOULD be handled in an implementation-defined manner consistent with the general use of BREAK as an attention/ interrupt signal; for instance, a service processor could use some other out-of-band facility to get the attention of a system it manages. In a case where an SSH connection cascades to another connection, the BREAK SHOULD be passed along the cascaded connection. For example, a telnet session from an SSH shell should carry along an SSH initiated BREAK and an SSH client initited from a telnet connection SHOULD pass a BREAK indication from the telnet connection. If the want_reply boolean is set, the server MUST reply using SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE [5] messages. If a BREAK of any kind was preformed, SSH_MSG_CHANNEL_SUCCESS MUST be sent. If no BREAK was preformed, SSH_MSG_CHANNEL_FAILURE MUST be Galbraith & Remaker Expires October 18, 2004 [Page 4] Internet-Draft Session Channel Break Extension April 2004 sent. This operation SHOULD be supported by any general purpose SSH client. Galbraith & Remaker Expires October 18, 2004 [Page 5] Internet-Draft Session Channel Break Extension April 2004 3. Security Considerations Many computer systems treat serial consoles as local and secured, and interpret a BREAK signal as an instruction to halt execution of the operating system or to enter priviliged configuration modes. Because of this, extra care should be taken to ensure that SSH access to BREAK-enabled ports are limited to users with appropriate priviliges to execute such functions. Alternatively, support for the BREAK facility MAY be imlemented configurable or a per port or per server basis. Implementations that literally intepret the BREAK length parameter without imposing the suggested BREAK time limit may cause a denial of service to or unexpected results from attached devices receiving the very long BREAK signal. Galbraith & Remaker Expires October 18, 2004 [Page 6] Internet-Draft Session Channel Break Extension April 2004 4. References 4.1 Normative References [1] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983. 4.2 Informative References [2] Harris, D., "Greater Scroll of Console Knowledge", March 2004. [3] Rinne, T., Ylonen, T., Kivinen, T. and S. Lehtinen, "SSH Protocol Architecture", draft-ietf-secsh-architecture-15 (work in progress), October 2003. [4] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. Lehtinen, "SSH Transport Layer Protocol", draft-ietf-secsh-transport-17 (work in progress), October 2003. [5] Rinne, T., Ylonen, T., Kivinen, T. and S. Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-18 (work in progress), October 2003. Authors' Addresses Joseph Galbraith VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 EMail: galb-list@vandyke.com Phillip Remaker Cisco Systems, Inc 170 West Tasman Drive San Jose, CA 95120 US Phone: +1 408 526 8614 EMail: remaker@cisco.com Galbraith & Remaker Expires October 18, 2004 [Page 7] Internet-Draft Session Channel Break Extension April 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Galbraith & Remaker Expires October 18, 2004 [Page 8] Internet-Draft Session Channel Break Extension April 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Galbraith & Remaker Expires October 18, 2004 [Page 9] From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 20 01:22: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 BAA09299 for ; Tue, 20 Apr 2004 01:22:37 -0400 (EDT) Received: (qmail 28604 invoked by uid 605); 20 Apr 2004 05:22:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28578 invoked from network); 20 Apr 2004 05:22:33 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 20 Apr 2004 05:22:33 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3K5MWhO023583; Mon, 19 Apr 2004 22:22:32 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i3K5MV4F012945; Mon, 19 Apr 2004 23:22:31 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i3K5M0hf001430; Tue, 20 Apr 2004 00:22:00 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i3K5Lxdb001429; Tue, 20 Apr 2004 00:21:59 -0500 (CDT) Date: Tue, 20 Apr 2004 00:21:59 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: X forwarding Message-ID: <20040420052155.GA1420@binky.central.sun.com> References: <200404180156.VAA28760@Sparkle.Rodents.Montreal.QC.CA> <200404191812.OAA02024@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404191812.OAA02024@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Apr 19, 2004 at 01:44:16PM -0400, der Mouse wrote: > To request X forwarding, the client sends > > byte SSH_MSG_CHANNEL_REQUEST > uint32 recipient channel > string "fixed-x11-req@rodents.montreal.qc.ca" > boolean want reply > uint32 token > uint32 x11 screen number If all the server has to do is repeat the token then what difference does it make? Does it help the server keep track of forwarded displays? Does it work like a generation number for when local display listeners are re-used? > The server is, yes, expected to take appropriate steps (some form of > authentication at least as strong as MIT-MAGIC-COOKIE-1) to ensure that > only authorized processes use the connection. > > There is no single-connection boolean; that struck me as unnecessary > complexity, and if the client wants those semantics, it can cancel the > forwarding (see below) and reject any extra CHANNEL_OPENs that arrive > because of the race or because the server rejects the cancel. This makes sense, yes. > The token is entirely opaque to the (ssh) server; the only things the > server ever does with it are (a) send it back when an X connection is > opened and (b) compare it when cancelling X forwarding. See above. > Upon getting a forwarded X connetion and its passing whatever security > checks, the server generates > > byte SSH_MSG_CHANNEL_OPEN > string "fixed-x11@rodents.montreal.qc.ca" > uint32 sender channel > uint32 initial window size > uint32 maximum packet size > uint32 token from the corresponding CHANNEL_REQUEST > byte[6] first six bytes of the client X setup packet (the byte > order and version numbers) What good does this byte[6] field do? It doesn't really help the client, since it's going to see those first 6 bytes in the channel data stream anyways. It can always forcefully close an x11 channel that it did accept, if it doesn't like it. > string connection method ("tcp" for TCP, others not yet > specified - I'm imagining things like "decnet" and > "local" for DECnet sockets and /tmp/.X11-unix/* - see > below for more on this). > connection-method-specific data > for method "tcp": > string originator address (e.g. "192.168.7.38") > uint32 originator port What sorts of decisions do you expect a client to make based on this information (which, after all, the client has to trust the server to be honest about)? I figure most clients will want to force local vs. non-local display opens on the server, so why not just ask for this in the request (e.g., through a boolean field)? What about multiply-forwarded display? How could the server know? Does it matter? I think a "local-only" boolean in the client's x11 request ought to suffice. Or, to more closely match the tcpip-forward request, let the client specify a display name pattern to use on the server side. > The initial client->server setup packet is not carried as channel data; > the first six bytes of it are carried in the open request with the rest > being synthesized locally by the client. In the Xserver->Xclient > direction, the channel carries pure X data right from the beginning of > the Xserver's response, but in the Xclient->Xserver direction, the > first channel data consists of the client's first request, if any. See above. BTW, the terms "client" and "server" are very confusing here. We need to keep X11 display client/server and SSHv2 client/server terminology straight. SSHv2 servers here are X11 clients and SSHv2 clients are proxies to X11 display servers. > In general, I don't like ssh's dependence on something TCP-like in the > protocol (for example, it assumes that the protocol has something like > port numbers that can fit in a uint32, and it thus is not possible to > run ssh, as defined, over DECnet stream sockets). Since I didn't want > to redesign the whole protocol, I've lived with this in most respects. > But since I'm designing a new request for X, I wanted to fix at least > that much of it, especially since the connection in question is > entirely out of ssh's purview. (This also addresses the question I saw > in the archives about "what originator info do I use for an AF_LOCAL X > connection?"). See above. I'd rather not have any of this in the channel open request. I think all any client will end up caring about will be the security of the forwarded display, not where connections to it come from but how. > I have not actually implemented cancelling X forwarding. Here's a > first stab at it: > > byte SSH_MSG_CHANNEL_REQUEST > uint32 recipient channel > string "cancel-x11-req@rodents.montreal.qc.ca" > boolean want reply > uint32 token > uint32 x11 screen number > > This cancels all previous X forwardings for that channel, token, and > screen number. I see no need for a way to wildcard any of these; if > others disagree, two additional bits (to indicate wildcarding of the > token or screen number) could be added, either as two booleans or as a > uint32 flags bitmask.... Can there be more than one X11 display forwarded per-session channel? I don't think so... but then, maybe that's just because in the *nix world there's only one DISPLAY environment variable per-process pointing to one display only So don't worry about wildcarding. See above about the token. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 20 06:48:12 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 GAA07701 for ; Tue, 20 Apr 2004 06:48:11 -0400 (EDT) Received: (qmail 18888 invoked by uid 605); 20 Apr 2004 10:48:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18881 invoked from network); 20 Apr 2004 10:48:09 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 20 Apr 2004 10:48:09 -0000 Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id GAA10378; Tue, 20 Apr 2004 06:48:08 -0400 (EDT) From: der Mouse Message-Id: <200404201048.GAA10378@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: Tue, 20 Apr 2004 06:22:00 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: X forwarding In-Reply-To: <20040420052155.GA1420@binky.central.sun.com> References: <200404180156.VAA28760@Sparkle.Rodents.Montreal.QC.CA> <200404191812.OAA02024@Sparkle.Rodents.Montreal.QC.CA> <20040420052155.GA1420@binky.central.sun.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> To request X forwarding, the client sends >> byte SSH_MSG_CHANNEL_REQUEST >> uint32 recipient channel >> string "fixed-x11-req@rodents.montreal.qc.ca" >> boolean want reply >> uint32 token >> uint32 x11 screen number > If all the server has to do is repeat the token then what difference > does it make? It allows the (ssh) client to tell which forwarding request a given forwarded X connection corresponds to (and, in particular, allows determining which session it goes with - this is cruicial for making X forwarding work with connection sharing). >> Upon getting a forwarded X connetion and its passing whatever >> security checks, the server generates >> byte SSH_MSG_CHANNEL_OPEN >> string "fixed-x11@rodents.montreal.qc.ca" >> uint32 sender channel >> uint32 initial window size >> uint32 maximum packet size >> uint32 token from the corresponding CHANNEL_REQUEST >> byte[6] first six bytes of the client X setup packet (the byte >> order and version numbers) > What good does this byte[6] field do? It's just the place I chose to put that data. I'm not fanatical about putting it there; if it would make you feel better you could put it at the beginning of the channel data, perhaps even with four zero bytes and two arbitrary bytes appended so the channel data stream is valid X protocol in isolation (I can't really see why this would matter, but I infer some such desire from your stating that the (ssh) client will see them in the channel data stream despite my trying to clearly state that that data blob is _not_ present in the channel data stream). > It doesn't really help the client, since it's going to see those > first 6 bytes in the channel data stream anyways. I don't understand. I wrote text (later) in which I tried to make it clear that that data _isn't_ in the channel data stream; you even quoted it, so you apparently read it. Was I not clear enough? Or do you just find it so horrible a thing to contemplate that you cannot even admit the possibility? Or what? > It can always forcefully close an x11 channel that it did accept, if > it doesn't like it. I don't include it for the client to see whether it likes it, but rather because the (ssh) client has to get those bytes _somehow_. >> string connection method ([...]). >> connection-method-specific data >> for method "tcp": >> string originator address (e.g. "192.168.7.38") >> uint32 originator port > What sorts of decisions do you expect a client to make based on this > information (which, after all, the client has to trust the server to > be honest about)? None in particular. Why do you assume that making decisions based on that information is the only reason to pass it? I have no trouble imagining the (ssh) client maintaining some kind of user-interface display of forwarded X connections, in which case displaying where the connection is from could be good. > What about multiply-forwarded display? How could the server know? > Does it matter? I sure hope it doesn't matter, because I don't think it can know, at least not for the TCP case. > BTW, the terms "client" and "server" are very confusing here. Yes. I've been trying to indicate which is which when I think confusion is likely, though I've doubtless missed some cases. >> string "cancel-x11-req@rodents.montreal.qc.ca" >> [...wildcarding...] > Can there be more than one X11 display forwarded per-session channel? The (ssh) client certainly can send more than one X forwarding request for a session. What happens if it does is a good question, especially for OSes like most Unices that communicate X display information to X clients via something which (like $DISPLAY) can't handle more than one display - I suspect it would have to be left up to the implementation. (My own implementation, as it stands now, rejects all but the first; I may, when I implement cancels, allow a forwarding request whenever there are no uncancelled forwarding requests on that session.) /~\ 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 Tue Apr 20 07:43: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 HAA10759 for ; Tue, 20 Apr 2004 07:43:19 -0400 (EDT) Received: (qmail 24385 invoked by uid 605); 20 Apr 2004 11:43:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24378 invoked from network); 20 Apr 2004 11:43:16 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 20 Apr 2004 11:43:16 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 7B451F633C; Tue, 20 Apr 2004 13:43:14 +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 30417F6D88; Tue, 20 Apr 2004 13:43:10 +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 i3KBh9cc020605; Tue, 20 Apr 2004 13:43:09 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i3KBh8Mo020602; Tue, 20 Apr 2004 13:43:08 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: X forwarding References: <200404180156.VAA28760@Sparkle.Rodents.Montreal.QC.CA> <200404191812.OAA02024@Sparkle.Rodents.Montreal.QC.CA> 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 Apr 2004 13:43:08 +0200 In-Reply-To: <200404191812.OAA02024@Sparkle.Rodents.Montreal.QC.CA> Message-ID: Lines: 124 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.1 (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.1 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit der Mouse writes: > > Please write up a spec for this. > > Sure. See below. Some comments. Unfortunately, it's several months since I hacked on the X11-forwarding, so I don't remember all the relevant details. > To request X forwarding, the client sends > > byte SSH_MSG_CHANNEL_REQUEST > uint32 recipient channel > string "fixed-x11-req@rodents.montreal.qc.ca" > boolean want reply > uint32 token > uint32 x11 screen number Looks ok to me. I'm not sure about the single-connection thing, at times I wished for a similar feature on the general tcpforwarding. You could rename "token" to "display id", as it's meant to identify an X11 display. > Upon getting a forwarded X connetion and its passing whatever security > checks, the server generates > > byte SSH_MSG_CHANNEL_OPEN > string "fixed-x11@rodents.montreal.qc.ca" > uint32 sender channel > uint32 initial window size > uint32 maximum packet size > uint32 token from the corresponding CHANNEL_REQUEST > byte[6] first six bytes of the client X setup packet (the byte > order and version numbers) > string connection method ("tcp" for TCP, others not yet > specified - I'm imagining things like "decnet" and > "local" for DECnet sockets and /tmp/.X11-unix/* - see > below for more on this). > connection-method-specific data > for method "tcp": > string originator address (e.g. "192.168.7.38") > uint32 originator port I think this is a little too complex for my taste. I think I understand why you want to include the part of the initial X message that comes before the authentication data, but it does make the request more dependent on X protocol details than I really like. I think I'd prefer something like byte SSH_MSG_CHANNEL_OPEN string "fixed-x11@rodents.montreal.qc.ca" uint32 sender channel uint32 initial window size uint32 maximum packet size uint32 token from the corresponding CHANNEL_REQUEST string prefix string originator address uint32 originator port The prefix is the initial part of the X11 client's initial message, before the authentication data. It's usually 6 bytes, and the first byte is the byte-order mark, 'B' for a big-endian client, 'L' for a little endian client. (XXX Some X implementations seem to use 'b" and 'l' instead. I'm not sure if that is something we need to care about, or what a canonical X reference says about the case of the byte order characters). As for the connection information, I don't quite like having the structure of the request to depend on the connection type. If you *really* want to support arbitrary connection information, I think I'd prefer something like string connection type ("tcpip" or "foo@example.com") string address blob (internal structure depends on the type). But we already have at least threee types of addresses mapped into a string format (dns, ipv4, ipv6), so perhaps it's simpler to use just a pair , where the number part need not be used for connection types where it isn't relevant. I think it is unfortunate to introduce a new type of address abstraction just for x11 forwarding; if the address abstraction in the connection document isn't general enough, it's better to fix it there (or in the architecture spec). > byte SSH_MSG_CHANNEL_REQUEST > uint32 recipient channel > string "cancel-x11-req@rodents.montreal.qc.ca" > boolean want reply > uint32 token > uint32 x11 screen number > > This cancels all previous X forwardings for that channel, token, and > screen number. You should also say what should happen when a channel is closed. It would make sense to me to say that a channel close on the session, or a cancel-x11-request, should cause the ssh server to stop accepting new x11 connections, but let existing forwarded channels live. Finally, one alternative to using a special token to identify displays is to just add the id of the associated session to the "x11" CHANNEL_OPEN message, byte SSH_MSG_CHANNEL_OPEN string "x11-mk2" uint32 sender channel uint32 initial window size uint32 maximum packet size ! uint32 session channel (receiver's id for the associated session) string originator address (e.g. "192.168.7.38") uint32 originator port This is equivalent to the new display id token, under the assumptions that No new x11 channels can be opened after the session channel is closed. A session can only have a single forwarded x11 display. Both of these make sense to me. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 20 15:08:02 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 PAA14008 for ; Tue, 20 Apr 2004 15:08:01 -0400 (EDT) Received: (qmail 8914 invoked by uid 605); 20 Apr 2004 19:07:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8275 invoked from network); 20 Apr 2004 19:07:40 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 20 Apr 2004 19:07:40 -0000 Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id PAA11966; Tue, 20 Apr 2004 15:07:38 -0400 (EDT) From: der Mouse Message-Id: <200404201907.PAA11966@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: Tue, 20 Apr 2004 14:42:56 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: X forwarding In-Reply-To: References: <200404180156.VAA28760@Sparkle.Rodents.Montreal.QC.CA> <200404191812.OAA02024@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> string "fixed-x11-req@rodents.montreal.qc.ca" > You could rename "token" to "display id", as it's meant to identify > an X11 display. Calling it "display id" would, I suspect, confuse people into thinking it's meant to be the display number (eg, the 2 in "hostname:2.0"). >> byte[6] first six bytes of the client X setup packet (the byte >> order and version numbers) > I think I understand why you want to include the part of the initial > X message that comes before the authentication data, but it does make > the request more dependent on X protocol details than I really like. You do have a good point there. I hadn't really thought about it much; even though I have trouble imagining this causing any problem (I don't really think X is going to change that in the foreseeable future), I do agree that the two protocols shouldn't be intertwined this much. While it seems silly from an efficiency point of view, I'm now inclined to remove that from the CHANNEL_OPEN entirely and put it in the channel data stream, probably with zero-length authorization data (that is, the ssh protocol as it appears on the wire then knows nothing about the X11 protocol - only the manipulation of the data stream at each end has any knowledge of X). > I think I'd prefer something like > string prefix > The prefix is the initial part of the X11 client's initial message, > before the authentication data. Who says that in the revision that changes this, the part of interest will remain a prefix? > It's usually 6 bytes, and the first byte is the byte-order mark, > 'B' for a big-endian client, 'L' for a little endian client. (XXX > Some X implementations seem to use 'b" and 'l' instead. I'm not > sure if that is something we need to care about, or what a > canonical X reference says about the case of the byte order > characters). The R4 protocol document says #x42 MSB first #x6C LSB first Those are ASCII 'B' and 'l'; while this is not coincidence, 'b' and 'L' are invalid X protocol, same as 'q' and '&'. > As for the connection information, I don't quite like having the > structure of the request to depend on the connection type. If you > *really* want to support arbitrary connection information, I think > I'd prefer something like > string connection type ("tcpip" or "foo@example.com") > string address blob (internal structure depends on the type). I suppose I can understand that. I don't quite see what's wrong with the way I did it, but it's certainly not a difference I'll make a fuss over. > But we already have at least threee types of addresses mapped into a > string format (dns, ipv4, ipv6), Not quite - those name (in three different ways) the machine, but not the per-machine demultiplexing information (ports for TCP), which the protocol shoehorns into a uint32. DECnet, for example, uses strings for the demultiplexer names, not small integers. > so perhaps it's simpler to use just a pair , where > the number part need not be used for connection types where it isn't > relevant. But there's no standard way - as far as I know - to combine a DECnet node name and demultiplexing string (I don't know the canonical DECnet terminology for them) into a single string. > I think it is unfortunate to introduce a new type of address > abstraction just for x11 forwarding; if the address abstraction in > the connection document isn't general enough, it's better to fix it > there (or in the architecture spec). True. But fixing it everywhere is not practical for me alone, as it would completely break interoperability. I would certainly support an effort to fix the whole protocol (I would be inclined to do it by converting all the pairs into pairs, where the address type is something like "tcp" and the string is something like (for tcp) the pair we use now). We already have this issue, when dealing with AF_LOCAL forwarded X connections: the addressing scheme in use is insufficient to the task. >> string "cancel-x11-req@rodents.montreal.qc.ca" > You should also say what should happen when a channel is closed. That's true. I'm inclined to agree with you, that closing the session implicitly cancels, but neither close nor explicit cancel breaks existing forwadred channels. > Finally, one alternative to using a special token to identify > displays is to just add the id of the associated session to the "x11" > CHANNEL_OPEN message, Yes. I considered that, briefly. The principal reason I didn't do it was practical: the way my implementation is layered, that's somewhat inconvenient information to get at. > This is equivalent to the new display id token, under the assumptions > that > No new x11 channels can be opened after the session channel is > closed. > A session can only have a single forwarded x11 display. > Both of these make sense to me. The former sounds more reasonable to me than the latter. I'm rather uncomfortable wiring the assumption that a session has at most one X display into the protocol. (I already have three programs that talk to two X displays, and one that cna talk to an effectively unlimited number...while at present all but at most one of those displays must be named on the command line, it seems to me it would hamper innovation to assume this will always be the case.) /~\ 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 Tue Apr 20 15:44: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 PAA17136 for ; Tue, 20 Apr 2004 15:43:59 -0400 (EDT) Received: (qmail 2804 invoked by uid 605); 20 Apr 2004 19:43:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2785 invoked from network); 20 Apr 2004 19:43:55 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 20 Apr 2004 19:43:55 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 65699F4996; Tue, 20 Apr 2004 21:43:24 +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 29C76F498B; Tue, 20 Apr 2004 21:43: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 i3KJhIcc024694; Tue, 20 Apr 2004 21:43:18 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i3KJhH9b024690; Tue, 20 Apr 2004 21:43:17 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: X forwarding References: <200404180156.VAA28760@Sparkle.Rodents.Montreal.QC.CA> <200404191812.OAA02024@Sparkle.Rodents.Montreal.QC.CA> <200404201907.PAA11966@Sparkle.Rodents.Montreal.QC.CA> 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 Apr 2004 21:43:17 +0200 In-Reply-To: <200404201907.PAA11966@Sparkle.Rodents.Montreal.QC.CA> Message-ID: Lines: 76 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.1 (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.1 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit der Mouse writes: > While it seems silly from an efficiency point of view, I'm now inclined > to remove that from the CHANNEL_OPEN entirely and put it in the channel > data stream, probably with zero-length authorization data (that is, the > ssh protocol as it appears on the wire then knows nothing about the X11 > protocol - only the manipulation of the data stream at each end has any > knowledge of X). That is cleaner, at least from a narrow ssh protocol viewpoint. I think it was something similar I was suggesting the last time X11 forwarding was discussed. > The R4 protocol document says > > #x42 MSB first > #x6C LSB first > > Those are ASCII 'B' and 'l'; while this is not coincidence, 'b' and 'L' > are invalid X protocol, same as 'q' and '&'. Thanks for the correction. RFC 1013 (UNKNOWN status) agrees with you. I missed that detail when I read it a long time ago. [ about representation of connection information ] > But there's no standard way - as far as I know - to combine a DECnet > node name and demultiplexing string (I don't know the canonical DECnet > terminology for them) into a single string. I don't quite buy this argument. There ought to be some character that could work as a separator? Something (to allow the format to be extended to other non-ip addressing schemes as well) like "decnet!address!demultiplexor". Or if all else fails, use explicit embedded length fields,"decnet!7:address13:demultiplexor". Both formats should work as extensions of the current ssh conventions for representing addresses. I'd be a little surprised if there's no "standard" way to represent decnet endpoint addresses as strings, but I don't know decnet at all. It's preferable to use a standard format, like an text string (in ascii or utf8)) + an optional port number. This makes it easy for an implementation to display and/or log the connection information for any connection type, including types the implementation doesn't understand. > > Finally, one alternative to using a special token to identify > > displays is to just add the id of the associated session to the "x11" > > CHANNEL_OPEN message, > > Yes. I considered that, briefly. The principal reason I didn't do it > was practical: the way my implementation is layered, that's somewhat > inconvenient information to get at. Both ways seem ok to me. (And I think both should be as easy to implement: using the session channel id to identify a forwarded display is equivalent to using a separate token, and a token creation function that by chance happens to always generate a token that equals the channel id of the associated session channel). Using a separate token gives the client (which chooses the values) a little more freedom. > > A session can only have a single forwarded x11 display. > > > Both of these make sense to me. > > The former sounds more reasonable to me than the latter. I'm rather > uncomfortable wiring the assumption that a session has at most one X > display into the protocol. I think I can agree with that, even if I don't think it matters much in practice. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Apr 20 19:43: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 TAA07654 for ; Tue, 20 Apr 2004 19:43:08 -0400 (EDT) Received: (qmail 7365 invoked by uid 605); 20 Apr 2004 23:43:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7354 invoked from network); 20 Apr 2004 23:43:01 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 20 Apr 2004 23:43:01 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3KNh0ms025144; Tue, 20 Apr 2004 16:43:00 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i3KNh04F004383; Tue, 20 Apr 2004 17:43:00 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i3KNgShf002267; Tue, 20 Apr 2004 18:42:28 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i3KNgRKG002266; Tue, 20 Apr 2004 18:42:27 -0500 (CDT) Date: Tue, 20 Apr 2004 18:42:27 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: X forwarding Message-ID: <20040420234223.GA2259@binky.central.sun.com> References: <200404180156.VAA28760@Sparkle.Rodents.Montreal.QC.CA> <200404191812.OAA02024@Sparkle.Rodents.Montreal.QC.CA> <20040420052155.GA1420@binky.central.sun.com> <200404201048.GAA10378@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404201048.GAA10378@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Apr 20, 2004 at 06:22:00AM -0400, der Mouse wrote: > >> To request X forwarding, the client sends > > >> byte SSH_MSG_CHANNEL_REQUEST > >> uint32 recipient channel > >> string "fixed-x11-req@rodents.montreal.qc.ca" > >> boolean want reply > >> uint32 token > >> uint32 x11 screen number > > > If all the server has to do is repeat the token then what difference > > does it make? > > It allows the (ssh) client to tell which forwarding request a given > forwarded X connection corresponds to (and, in particular, allows > determining which session it goes with - this is cruicial for making X > forwarding work with connection sharing). I thought the related channel ID ought to suffice. Damien points out a way in which multiple displays could be accessed from a session channel, and later so do you, so ok, I'll grant the need for some additional request matching beyond related channel ID. > >> Upon getting a forwarded X connetion and its passing whatever > >> security checks, the server generates > > >> byte SSH_MSG_CHANNEL_OPEN > >> string "fixed-x11@rodents.montreal.qc.ca" > >> uint32 sender channel > >> uint32 initial window size > >> uint32 maximum packet size > >> uint32 token from the corresponding CHANNEL_REQUEST > >> byte[6] first six bytes of the client X setup packet (the byte > >> order and version numbers) > > What good does this byte[6] field do? > > It's just the place I chose to put that data. I'm not fanatical about > putting it there; if it would make you feel better you could put it at > the beginning of the channel data, perhaps even with four zero bytes > and two arbitrary bytes appended so the channel data stream is valid X > protocol in isolation (I can't really see why this would matter, but I > infer some such desire from your stating that the (ssh) client will see > them in the channel data stream despite my trying to clearly state that > that data blob is _not_ present in the channel data stream). [...] You seem to have changed your mind since writing this, so I'll leave it at this: the protocol is cleaner if this field is removed. > >> string connection method ([...]). > >> connection-method-specific data > >> for method "tcp": > >> string originator address (e.g. "192.168.7.38") > >> uint32 originator port > > What sorts of decisions do you expect a client to make based on this > > information (which, after all, the client has to trust the server to > > be honest about)? > > None in particular. Why do you assume that making decisions based on > that information is the only reason to pass it? I have no trouble > imagining the (ssh) client maintaining some kind of user-interface > display of forwarded X connections, in which case displaying where the > connection is from could be good. Ok. I agree that it could be useful to have this info, but if it's meant to be displayed and not interpreted by software, then we don't need to worry about structuring the different transports' address/instance data types and instead can just get away with a free-form string. > > What about multiply-forwarded display? How could the server know? > > Does it matter? > > I sure hope it doesn't matter, because I don't think it can know, at > least not for the TCP case. Right. > > BTW, the terms "client" and "server" are very confusing here. > > Yes. I've been trying to indicate which is which when I think > confusion is likely, though I've doubtless missed some cases. You've been doing ok, but other readers probably could use that clarification. > >> string "cancel-x11-req@rodents.montreal.qc.ca" > >> [...wildcarding...] > > > Can there be more than one X11 display forwarded per-session channel? > > The (ssh) client certainly can send more than one X forwarding request > for a session. What happens if it does is a good question, especially > for OSes like most Unices that communicate X display information to X > clients via something which (like $DISPLAY) can't handle more than one > display - I suspect it would have to be left up to the implementation. > (My own implementation, as it stands now, rejects all but the first; I > may, when I implement cancels, allow a forwarding request whenever > there are no uncancelled forwarding requests on that session.) Ok. There is a caveat here that has to be mentioned in any I-D text about this: for many SSHv2 servers the x11 fwd channel request has to arrive prior to starting the session, so clients SHOULD strive to ensure this. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 21 15:39:06 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 PAA10201 for ; Wed, 21 Apr 2004 15:39:06 -0400 (EDT) Received: (qmail 23544 invoked by uid 605); 21 Apr 2004 19:39:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23537 invoked from network); 21 Apr 2004 19:39:01 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 21 Apr 2004 19:39:01 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10164; Wed, 21 Apr 2004 15:38:28 -0400 (EDT) Message-Id: <200404211938.PAA10164@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-break-02.txt Date: Wed, 21 Apr 2004 15:38:27 -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 : Session Channel Break Extension Author(s) : J. Galbraith, P. Remaker Filename : draft-ietf-secsh-break-02.txt Pages : 9 Date : 2004-4-21 The Session Channel Break Extension provides a means to send a BREAK signal [2] over an SSH terminal session [5]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-break-02.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-break-02.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-break-02.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-4-21154758.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-break-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-break-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-21154758.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 21 16:09:40 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 QAA11517 for ; Wed, 21 Apr 2004 16:09:40 -0400 (EDT) Received: (qmail 14389 invoked by uid 605); 21 Apr 2004 20:09:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14382 invoked from network); 21 Apr 2004 20:09:38 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 21 Apr 2004 20:09:38 -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 i3LK9Z4U024222; Wed, 21 Apr 2004 14:09:35 -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 i3LK9Zcc012013; Wed, 21 Apr 2004 16:09:35 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i3LK9YQU028917; Wed, 21 Apr 2004 16:09:34 -0400 (EDT) Message-Id: <200404212009.i3LK9YQU028917@thunk.east.sun.com> From: Bill Sommerfeld To: remaker@cisco.com, galb-list@vandyke.com Cc: ietf-ssh@NetBSD.org Subject: WG Chair Copyediting for draft-ietf-secsh-break-02 Reply-to: sommerfeld@east.sun.com Date: Wed, 21 Apr 2004 16:09:34 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list I found a few nits: 1) I Garbled sentence in the security considerations section: Alternatively, support for the BREAK facility MAY be imlemented configurable or a per port or per server basis. The meaning is clear but could definitely use some sanding and polishing. 2) misplaced comma and missing article: change: If BREAK duration request of less than 500ms, is requested a BREAK of 500ms SHOULD be sent since most devices will recognize a BREAK of that length. to: If a BREAK duration request of less than 500ms is requested, a BREAK of 500ms SHOULD be sent since most devices will recognize a BREAK of that length. 3) spelling error, ambiguity: If a BREAK of any kind was preformed, SSH_MSG_CHANNEL_SUCCESS MUST be sent. If no BREAK was preformed, SSH_MSG_CHANNEL_FAILURE MUST be s/preformed/performed or passed on/ (fix typo; clarify that the server doing break-passthrough NEED NOT wait for the break to be ack'ed, as this may not be possible to do reliably in some cases). --- And, I couldn't help myself: Break-length section rewording: A BREAK-length parameter of 0 is a request for a default-length break; by default, this SHOULD be a 500ms break. Some implementations will not be in a position to control the length of a BREAK; such implementations SHOULD instead generate an fixed-length break of an implementation-defined length in response to this request. Others SHOULD limit the minimum and maximum length of BREAK durations. The encoding specified above allows a sender to request a maximum BREAK duration of approximately 49.7 days. By default, durations less than 500ms SHOULD be silently extended to 500ms (as some devices may not recognize BREAKS much shorter than this); durations longer than 3000ms SHOULD be silently truncated to 3000ms. Implementations MAY allow an administrator to adjust the default, minimum, and maximum break lengths. --- Let's have a quick 1-week WG review on this followed by a respin. WG members: please review this document and send comments on or before 4/28/2004 - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 21 16:21: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 QAA12107 for ; Wed, 21 Apr 2004 16:21:58 -0400 (EDT) Received: (qmail 27616 invoked by uid 605); 21 Apr 2004 20:21:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27597 invoked from network); 21 Apr 2004 20:21:57 -0000 Received: from firestar.cisco.com (HELO fire.cisco.com) (171.68.227.75) by mail.netbsd.org with SMTP; 21 Apr 2004 20:21:57 -0000 Received: from remakerw2k01 (remaker-w2k01.cisco.com [171.69.103.14]) by fire.cisco.com (8.11.7+Sun/8.8.8) with SMTP id i3LKLri26982; Wed, 21 Apr 2004 13:21:53 -0700 (PDT) Message-ID: <004601c427de$506473c0$0e6745ab@amer.cisco.com> From: "Phillip Remaker" To: , Cc: References: <200404212009.i3LK9YQU028917@thunk.east.sun.com> Subject: Re: WG Chair Copyediting for draft-ietf-secsh-break-02 Date: Wed, 21 Apr 2004 13:22:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Ugh. How embarassing. I apologize for failing to do enough grammar checking. I promise that -03 will be better. And spell checked, too. > Alternatively, support for the BREAK facility MAY be imlemented > configurable or a per port or per server basis. How about The support for BREAK over SSH MAY be implemented such that the recognition of BREAK over SSH may be activated or deactivated a per port or per server basis. > If BREAK duration request of less than 500ms, is > requested a BREAK of 500ms SHOULD be sent since most devices will > recognize a BREAK of that length. > > to: > > If a BREAK duration request of less than 500ms is requested, a BREAK > of 500ms SHOULD be sent since most devices will recognize a BREAK > of that length. Yes, that is exactly what I meant. > 3) spelling error, ambiguity: > > If > a BREAK of any kind was preformed, SSH_MSG_CHANNEL_SUCCESS MUST be > sent. If no BREAK was preformed, SSH_MSG_CHANNEL_FAILURE MUST be > > s/preformed/performed or passed on/ I agree with that change. > Break-length section rewording: > > A BREAK-length parameter of 0 is a request for a default-length break; > by default, this SHOULD be a 500ms break. > > Some implementations will not be in a position to control the > length of a BREAK; such implementations SHOULD instead generate an > fixed-length break of an implementation-defined length in response > to this request. "implementation-defined." Hmmm. What I am really trying to say here is that if the coder has no control over the break length, a break of any available length should be sent. That is, if you only available command is to tell a chipset to "send a break," that is what you should do. How best to word that? > Others SHOULD limit the minimum and maximum length of BREAK > durations. The encoding specified above allows a sender to request > a maximum BREAK duration of approximately 49.7 days. > > By default, durations less than 500ms SHOULD be silently extended > to 500ms (as some devices may not recognize BREAKS much shorter > than this); durations longer than 3000ms SHOULD be silently truncated to > 3000ms. Great. > Implementations MAY allow an administrator to adjust the default, minimum, > and maximum break lengths. ..up to and including the bizzare and ridculous lengths, of course 8-) Thanks for the quick review. I will happily spin up -03 next week with the comments incorporated. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 21 16:41: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 QAA13041 for ; Wed, 21 Apr 2004 16:41:08 -0400 (EDT) Received: (qmail 9780 invoked by uid 605); 21 Apr 2004 20:41:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9754 invoked from network); 21 Apr 2004 20:41:05 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 21 Apr 2004 20:41:05 -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 i3LKeqms017923; Wed, 21 Apr 2004 13:40:52 -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 i3LKepcc020338; Wed, 21 Apr 2004 16:40:52 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i3LKepQU029100; Wed, 21 Apr 2004 16:40:51 -0400 (EDT) Message-Id: <200404212040.i3LKepQU029100@thunk.east.sun.com> From: Bill Sommerfeld To: "Phillip Remaker" cc: galb-list@vandyke.com, ietf-ssh@NetBSD.org Subject: Re: WG Chair Copyediting for draft-ietf-secsh-break-02 In-Reply-To: Your message of "Wed, 21 Apr 2004 13:22:05 PDT." <004601c427de$506473c0$0e6745ab@amer.cisco.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 21 Apr 2004 16:40:51 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > "implementation-defined." Hmmm. What I am really trying to say here is > that if the coder has no control over the break length, a break of any > available length should be sent. That is, if you only available command is > to tell a chipset to "send a break," that is what you should do. How best > to word that? I was thinking about it from an outside-the-system-box perspective. The ssh(d) module may can't control it, but some other piece of the system (serial chipset, device driver, serial i/o subsystem, etc.) may be the entity which controls it in an implementation-of-that-piece-of-the-system-defined manner. That then becomes an implementation-defined property of the system as a whole. Anyone else got a wording suggestion? - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 21 17:46: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 RAA18504 for ; Wed, 21 Apr 2004 17:46:36 -0400 (EDT) Received: (qmail 27462 invoked by uid 605); 21 Apr 2004 21:46:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27453 invoked from network); 21 Apr 2004 21:46:36 -0000 Received: from emulex.emulex.com (138.239.112.1) by mail.netbsd.org with SMTP; 21 Apr 2004 21:46:36 -0000 Received: from xcm.ad.emulex.com (xcm.emulex.com [138.239.112.206]) by emulex.emulex.com (8.12.10/8.12.10) with ESMTP id i3LLjtcj013149; Wed, 21 Apr 2004 14:45:55 -0700 (PDT) Received: by xcm.emulex.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Apr 2004 14:45:55 -0700 Message-ID: <8D43EFD7CCBDB24980134BE078C227E7093A84F8@xcm.emulex.com> From: System Attendant To: "'i-d-announce@ietf.org'" , "'ietf-ssh@netbsd.org'" Subject: [MailServer Notification]To Recipient file blocking settings matc hed and action was taken. Date: Wed, 21 Apr 2004 14:45:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ietf-ssh-owner@NetBSD.org Precedence: list ScanMail for Microsoft Exchange took action on the message. The message details were: Sender = Internet-Drafts@ietf.org Recipient(s) = i-d-announce@ietf.org;ietf-ssh@netbsd.org Subject = I-D ACTION:draft-ietf-secsh-break-02.txt Scanning time = 04/21/2004 14:45:44 Engine/Pattern = 7.000-1004/863 Action taken on message: The attachment draft-ietf-secsh-break-02.url matched file blocking settings. ScanMail took the action: Deleted. XCM Warning to recipient: Attachment blocking action taken. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 21 19:39:04 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 TAA00926 for ; Wed, 21 Apr 2004 19:39:04 -0400 (EDT) Received: (qmail 1908 invoked by uid 605); 21 Apr 2004 23:39:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1901 invoked from network); 21 Apr 2004 23:39:01 -0000 Received: from firestar.cisco.com (HELO fire.cisco.com) (171.68.227.75) by mail.netbsd.org with SMTP; 21 Apr 2004 23:39:01 -0000 Received: from remakerw2k01 (remaker-w2k01.cisco.com [171.69.103.14]) by fire.cisco.com (8.11.7+Sun/8.8.8) with SMTP id i3LNcvi17221; Wed, 21 Apr 2004 16:38:57 -0700 (PDT) Message-ID: <01e401c427f9$d8101890$0e6745ab@amer.cisco.com> From: "Phillip Remaker" To: Cc: , References: <200404212040.i3LKepQU029100@thunk.east.sun.com> Subject: Re: WG Chair Copyediting for draft-ietf-secsh-break-02 Date: Wed, 21 Apr 2004 16:39:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > The ssh(d) module may can't control it, but some other piece of the > system (serial chipset, device driver, serial i/o subsystem, etc.) > may be the entity which controls it in an > implementation-of-that-piece-of-the-system-defined manner. Exactly. I knew what you meant. But since there is "the implementation of sshd" and the "implementation of the drivers" and the "implementation of the UART/chipset," I want to be clear that implementation specific is not the responsibility of the writer of the SSHD "If the SSH server responsible for sending the break has no control over the hardware that sends break length (as in an opaque UART driver), or has no way to pass break length information (as in an SSH to telnet gateway), the implementation MAY (MUST?) still send a BREAK signal, omitting the length information. Sending a break signal without the length information is still considered a successful sending of a BREAK." Bottom line: Break length is a SUGGESTION, which may be used by the receiver if it is so capable.. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 26 10:54:16 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 KAA25402 for ; Mon, 26 Apr 2004 10:54:15 -0400 (EDT) Received: (qmail 12341 invoked by uid 605); 26 Apr 2004 14:54:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12333 invoked from network); 26 Apr 2004 14:54:14 -0000 Received: from mailbo.westgroup.com (167.68.0.71) by mail.netbsd.org with SMTP; 26 Apr 2004 14:54:14 -0000 Received: from morley.int.westgroup.com (localhost.localdomain [127.0.0.1]) by mailbo.westgroup.com (8.12.10/8.12.10) with ESMTP id i3QEs7qi025467 for ; Mon, 26 Apr 2004 09:54:07 -0500 Received: from eg-msgimc-a03.int.westgroup.com (eg-msgimc-a03.int.westgroup.com [163.231.102.184]) by morley.int.westgroup.com (8.12.10/8.12.10) with ESMTP id i3QEs7fc025464 for ; Mon, 26 Apr 2004 09:54:07 -0500 Received: by eg-msgimc-a03.int.westgroup.com with Internet Mail Service (5.5.2657.72) id ; Mon, 26 Apr 2004 09:54:06 -0500 Message-ID: From: "Harding, Matthew" To: "'ietf-ssh@netbsd.org'" Subject: Secure Shell question on ASCII transfers Date: Mon, 26 Apr 2004 09:54:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@NetBSD.org Precedence: list I am new to the ietf and am not sure if this is the correct place for this to go, but please forward this to where ever it should go. I had a question about why ASCII transfers have not been added to the SFTP protocol? In a day in age where security is a severe issue and many companies and organizations are moving away from FTP to SFTP has the issue of ASCII transfers been addressed at all? I would like to hear any feedback or insight anyone would be able to give me on this issue. Matthew Harding From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Apr 26 11:09: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 LAA26034 for ; Mon, 26 Apr 2004 11:09:34 -0400 (EDT) Received: (qmail 22966 invoked by uid 605); 26 Apr 2004 15:09:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22959 invoked from network); 26 Apr 2004 15:09:33 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 26 Apr 2004 15:09:33 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2657.72) id ; Mon, 26 Apr 2004 11:09:33 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86051AC5D2@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: FW: Secure Shell question on ASCII transfers Date: Mon, 26 Apr 2004 11:09:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@NetBSD.org Precedence: list (resent to list due a typo I made in the address the first time) -----Original Message----- From: Richard Whalen Sent: Monday, April 26, 2004 11:08 AM To: 'Harding, Matthew'; 'ietf-ssg@netbsd.org' Subject: RE: Secure Shell question on ASCII transfers Text (or ASCII) transfers were added in draft-ietf-secsh-filexfer-04 and are included in the current draft (http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-05.txt). Many implementations are of the 03 draft, which did not include text transfers. ---------------------- Richard Whalen Process Software -----Original Message----- From: Harding, Matthew [mailto:Matthew.Harding@thomson.com] Sent: Monday, April 26, 2004 10:54 AM To: 'ietf-ssh@netbsd.org' Subject: Secure Shell question on ASCII transfers I am new to the ietf and am not sure if this is the correct place for this to go, but please forward this to where ever it should go. I had a question about why ASCII transfers have not been added to the SFTP protocol? In a day in age where security is a severe issue and many companies and organizations are moving away from FTP to SFTP has the issue of ASCII transfers been addressed at all? I would like to hear any feedback or insight anyone would be able to give me on this issue. Matthew Harding From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 28 15:31:40 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 PAA11283 for ; Wed, 28 Apr 2004 15:31:39 -0400 (EDT) Received: (qmail 7301 invoked by uid 605); 28 Apr 2004 19:31:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7294 invoked from network); 28 Apr 2004 19:31:37 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 28 Apr 2004 19:31:37 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11280; Wed, 28 Apr 2004 15:31:34 -0400 (EDT) Message-Id: <200404281931.PAA11280@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-auth-kbdinteract-06.txt Date: Wed, 28 Apr 2004 15:31:34 -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 : Generic Message Exchange Authentication For SSH Author(s) : M. Forssen, F. Cusack Filename : draft-ietf-secsh-auth-kbdinteract-06.txt Pages : 12 Date : 2004-4-28 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard. The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-auth-kbdinteract-06.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-auth-kbdinteract-06.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-auth-kbdinteract-06.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-4-28153249.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-auth-kbdinteract-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-auth-kbdinteract-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-28153249.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Apr 28 16:58: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 QAA19819 for ; Wed, 28 Apr 2004 16:58:08 -0400 (EDT) Received: (qmail 29814 invoked by uid 605); 28 Apr 2004 20:58:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29774 invoked from network); 28 Apr 2004 20:58:07 -0000 Received: from emulex.emulex.com (138.239.112.1) by mail.netbsd.org with SMTP; 28 Apr 2004 20:58:07 -0000 Received: from xcm.ad.emulex.com (xcm.emulex.com [138.239.112.206]) by emulex.emulex.com (8.12.10/8.12.10) with ESMTP id i3SKvU4G018130; Wed, 28 Apr 2004 13:57:30 -0700 (PDT) Received: by xcm.emulex.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Apr 2004 13:57:30 -0700 Message-ID: <8D43EFD7CCBDB24980134BE078C227E7093A85ED@xcm.emulex.com> From: System Attendant To: "'i-d-announce@ietf.org'" , "'ietf-ssh@netbsd.org'" Subject: [MailServer Notification]To Recipient file blocking settings matc hed and action was taken. Date: Wed, 28 Apr 2004 13:57:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ietf-ssh-owner@NetBSD.org Precedence: list ScanMail for Microsoft Exchange took action on the message. The message details were: Sender = Internet-Drafts@ietf.org Recipient(s) = i-d-announce@ietf.org;ietf-ssh@netbsd.org Subject = I-D ACTION:draft-ietf-secsh-auth-kbdinteract-06.txt Scanning time = 04/28/2004 13:57:29 Engine/Pattern = 7.000-1004/877 Action taken on message: The attachment draft-ietf-secsh-auth-kbdinteract-06.url matched file blocking settings. ScanMail took the action: Deleted. XCM Warning to recipient: Attachment blocking action taken.