From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Dec 01 00:47:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhhHp-0006YF-Rw for secsh-archive@megatron.ietf.org; Thu, 01 Dec 2005 00:47:18 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22297 for ; Thu, 1 Dec 2005 00:46:30 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 95F0A63B198; Thu, 1 Dec 2005 05:47:12 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 4B22663B18B for ; Thu, 1 Dec 2005 05:47:11 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id AAA00778; Thu, 1 Dec 2005 00:47:10 -0500 (EST) From: der Mouse Message-Id: <200512010547.AAA00778@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Thu, 1 Dec 2005 00:41:39 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: Who's at fault here? In-Reply-To: <438E7C7B.8070501@vandyke.com> References: <200510210450.AAA26839@Sparkle.Rodents.Montreal.QC.CA> <20051201012929.GA22059@binky.Central.Sun.COM> <438E7C7B.8070501@vandyke.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >>> The thing is, the implementation I'm talking to (which is bannering >>> as "SSH-1.99-OpenSSH_3.4 NetBSD_Secure_Shell-20020626") is logging >>> "Received window adjust for non-open channel 0." in response to >>> this. >> This sort of thing can happen with "window-change" channel requests >> received before the shell/exec/subsystem channel requests on the >> same channel. That was my own conclusion after some grubbing around in the OpenSSH source code (modulo the exact wording; see below). Looking at my debug traces, that sure seems to be exactly what's happening, and looking over my code, I can see how and when it happens. > But it shouldn't, should it? > My reading of the draft has always been it is legal to send a window > adjust any time the channel is open. That's my reading too, which is why I suspected this of being a bug in OpenSSH rather than in my code. > Wait... did you say "window-change" ? As in the size of the screen > changed message. I can't attribute that to anything but a mistake by Nicolas. There are no "window-change" SSH_MSG_CHANNEL_REQUEST messages involved in the cases I've looked at; SSH_MSG_CHANNEL_WINDOW_ADJUST messages are what I was talking about. /~\ 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 bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Dec 01 01:53:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhiK9-0000es-4V for secsh-archive@megatron.ietf.org; Thu, 01 Dec 2005 01:53:45 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28270 for ; Thu, 1 Dec 2005 01:52:56 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 81B5363B24A; Thu, 1 Dec 2005 06:53:39 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by mail.netbsd.org (Postfix) with ESMTP id 2794D63B164 for ; Thu, 1 Dec 2005 06:53:38 +0000 (UTC) Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id jB16rb3F007108 for ; Wed, 30 Nov 2005 23:53:37 -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 jB16rb5I017786 for ; Wed, 30 Nov 2005 23:53:37 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id jB16raDd022800; Thu, 1 Dec 2005 00:53:36 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id jB16rZE6022799; Thu, 1 Dec 2005 00:53:35 -0600 (CST) Date: Thu, 1 Dec 2005 00:53:35 -0600 From: Nicolas Williams To: Joseph Galbraith Cc: der Mouse , ietf-ssh@NetBSD.org Subject: Re: Who's at fault here? Message-ID: <20051201065335.GH21090@binky.Central.Sun.COM> Mail-Followup-To: Nicolas Williams , Joseph Galbraith , der Mouse , ietf-ssh@NetBSD.org References: <200510210450.AAA26839@Sparkle.Rodents.Montreal.QC.CA> <20051201012929.GA22059@binky.Central.Sun.COM> <438E7C7B.8070501@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438E7C7B.8070501@vandyke.com> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Nov 30, 2005 at 09:30:51PM -0700, Joseph Galbraith wrote: > Nicolas Williams wrote: > > On Fri, Oct 21, 2005 at 12:26:29AM -0400, der Mouse wrote: > >> The thing is, the implementation I'm talking to (which is bannering as > >> "SSH-1.99-OpenSSH_3.4 NetBSD_Secure_Shell-20020626") is logging > >> "Received window adjust for non-open channel 0." in response to this. > > > > This sort of thing can happen with "window-change" channel requests > > received before the shell/exec/subsystem channel requests on the same > > channel. > > But it shouldn't, should it? Indeed, it shouldn't, by my reading. > My reading of the draft has always been it is legal to send a > window adjust any time the channel is open. > > Wait... did you say "window-change" ? As in the size of the > screen changed message. Are you saying the error is ... I meant that this type of error happens when "window-change" channel requests... Not that that very same error message message is elicited. > unclear ... and should really read "Received window-change > for non-open channel 0?" and it occurs because a "window-change" > was sent before pty has been allocated? The issue is that the window-change request may be sent before the shell/exec/subsystem request but after the pty-req request. Our bug ID for it is: 6336266 ssh SIGWINCH handling races; some servers are very unforgiving Nico -- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Dec 01 02:02:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhiSg-0004pd-TX for secsh-archive@megatron.ietf.org; Thu, 01 Dec 2005 02:02:39 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29218 for ; Thu, 1 Dec 2005 02:01:47 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3FD7363B267; Thu, 1 Dec 2005 07:02:31 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by mail.netbsd.org (Postfix) with ESMTP id 81F2D63B164 for ; Thu, 1 Dec 2005 07:02:30 +0000 (UTC) Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id jB172U3F013924 for ; Thu, 1 Dec 2005 00:02:30 -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 jB172T5I023254 for ; Thu, 1 Dec 2005 00:02:30 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id jB172N7O022809; Thu, 1 Dec 2005 01:02:23 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id jB172Nua022808; Thu, 1 Dec 2005 01:02:23 -0600 (CST) Date: Thu, 1 Dec 2005 01:02:22 -0600 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: Who's at fault here? Message-ID: <20051201070222.GI21090@binky.Central.Sun.COM> Mail-Followup-To: Nicolas Williams , der Mouse , ietf-ssh@NetBSD.org References: <200510210450.AAA26839@Sparkle.Rodents.Montreal.QC.CA> <20051201012929.GA22059@binky.Central.Sun.COM> <438E7C7B.8070501@vandyke.com> <200512010547.AAA00778@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200512010547.AAA00778@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Dec 01, 2005 at 12:41:39AM -0500, der Mouse wrote: > > Wait... did you say "window-change" ? As in the size of the screen > > changed message. > > I can't attribute that to anything but a mistake by Nicolas. There are > no "window-change" SSH_MSG_CHANNEL_REQUEST messages involved in the > cases I've looked at; SSH_MSG_CHANNEL_WINDOW_ADJUST messages are what I > was talking about. There are in cases I've seen that are similar to what you described, only involving window-change instead of window adjusts (oof, confusing terms). Nico -- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Dec 01 10:30:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhqO1-00030z-0e for secsh-archive@megatron.ietf.org; Thu, 01 Dec 2005 10:30:17 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04792 for ; Thu, 1 Dec 2005 10:29:30 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 12F5263B1D2; Thu, 1 Dec 2005 15:30:06 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id BA49763B1A7 for ; Thu, 1 Dec 2005 15:30:04 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id KAA02452; Thu, 1 Dec 2005 10:30:03 -0500 (EST) From: der Mouse Message-Id: <200512011530.KAA02452@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Thu, 1 Dec 2005 10:27:36 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: Who's at fault here? In-Reply-To: <20051201070222.GI21090@binky.Central.Sun.COM> References: <200510210450.AAA26839@Sparkle.Rodents.Montreal.QC.CA> <20051201012929.GA22059@binky.Central.Sun.COM> <438E7C7B.8070501@vandyke.com> <200512010547.AAA00778@Sparkle.Rodents.Montreal.QC.CA> <20051201070222.GI21090@binky.Central.Sun.COM> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >>> Wait... did you say "window-change" ? >> I can't attribute that to anything but a mistake by Nicolas. [...] > There are in cases I've seen that are similar to what you described, > only involving window-change instead of window adjusts Aha. My apologies for thinking it was a mistake you made, then. Given what I saw of the OpenSSH code, though, it's not surprising, since it doesn't seem to consider session channels "real" until the shell/exec/etc request has come in - I would expect a lot of things to fail when applied to such channels. (I didn't dig into it enough to know exactly what things.) > (oof, confusing terms). Quite. Too many "window"s floating around. /~\ 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 bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Dec 01 12:20:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehs6N-0006nV-R5 for secsh-archive@megatron.ietf.org; Thu, 01 Dec 2005 12:20:12 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20697 for ; Thu, 1 Dec 2005 12:19:24 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 205D463B14F; Thu, 1 Dec 2005 17:20:06 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by mail.netbsd.org (Postfix) with ESMTP id 3B81663B120 for ; Thu, 1 Dec 2005 17:20:05 +0000 (UTC) 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 jB1HK44u019586 for ; Thu, 1 Dec 2005 09:20:04 -0800 (PST) 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 jB1HK3gr014834 for ; Thu, 1 Dec 2005 10:20:04 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id jB1HK393024173; Thu, 1 Dec 2005 11:20:03 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id jB1HK3W0024172; Thu, 1 Dec 2005 11:20:03 -0600 (CST) Date: Thu, 1 Dec 2005 11:20:03 -0600 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: Who's at fault here? Message-ID: <20051201172003.GM21090@binky.Central.Sun.COM> Mail-Followup-To: Nicolas Williams , der Mouse , ietf-ssh@NetBSD.org References: <200510210450.AAA26839@Sparkle.Rodents.Montreal.QC.CA> <20051201012929.GA22059@binky.Central.Sun.COM> <438E7C7B.8070501@vandyke.com> <200512010547.AAA00778@Sparkle.Rodents.Montreal.QC.CA> <20051201070222.GI21090@binky.Central.Sun.COM> <200512011530.KAA02452@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200512011530.KAA02452@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Dec 01, 2005 at 10:27:36AM -0500, der Mouse wrote: > >>> Wait... did you say "window-change" ? > >> I can't attribute that to anything but a mistake by Nicolas. [...] > > There are in cases I've seen that are similar to what you described, > > only involving window-change instead of window adjusts > > Aha. My apologies for thinking it was a mistake you made, then. Given > what I saw of the OpenSSH code, though, it's not surprising, since it > doesn't seem to consider session channels "real" until the > shell/exec/etc request has come in - I would expect a lot of things to > fail when applied to such channels. (I didn't dig into it enough to > know exactly what things.) Well, recent versions of the OpenSSH server do the right thing, IIRC, older versions didn't. The client still sends window-change requests too soon for broken servers, but the client could be smarter about this. Hmmm, delaying a window-change request until after the shell/exec/ subsystem request might lead to the app starting to draw with the wrong window size -- not pretty, but the app will get the size change notification eventually. Not delaying it can cause broken servers to disconnect -- worse than not pretty. A job for the compat db? Sigh. > > (oof, confusing terms). > > Quite. Too many "window"s floating around. Yes. Wish that had been "terminal-size-change" -- but it is what it is. Nico -- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Dec 01 12:37:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhsN4-0002Ls-0l for secsh-archive@megatron.ietf.org; Thu, 01 Dec 2005 12:37:26 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22967 for ; Thu, 1 Dec 2005 12:36:37 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 8DE4863B3A6; Thu, 1 Dec 2005 17:37:17 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by mail.netbsd.org (Postfix) with ESMTP id D759163B389 for ; Thu, 1 Dec 2005 17:37:16 +0000 (UTC) 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 jB1H5fdK017883 for ; Thu, 1 Dec 2005 09:05:41 -0800 (PST) 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 jB1H5egr006690 for ; Thu, 1 Dec 2005 10:05:40 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id jB1H5eKN024160; Thu, 1 Dec 2005 11:05:40 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id jB1H5d3h024159; Thu, 1 Dec 2005 11:05:39 -0600 (CST) Date: Thu, 1 Dec 2005 11:05:39 -0600 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: Practical forwarding problem Message-ID: <20051201170533.GB22059@binky.Central.Sun.COM> References: <200509230108.VAA21474@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509230108.VAA21474@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Sep 22, 2005 at 08:47:55PM -0400, der Mouse wrote: > Thoughts, anyone? It's a race, and there isn't much you can do about it as it is, but... ...why are you doing this in the first place? Why start the X11 application in the background and with stdio redirected to something other than the exec channel's pipe/whatever? Those two things cause the channel close to race with the applications X11 display open. If you don't do either of those two things the problem goes away. The OpenSSH client has a "-f" option that is supposed to be useful for this sort of thing, but it isn't because it forks too soon to provide feedback about errors in starting the app -- it forks after userauth. A client option like "-f" but which causes the client to fork into the background after a specified event other than userauth completion (e.g., X11 channel opens, agent channel opens, etc...) would be better. Then you could fire off X11 apps on remote hosts and get feedback if there's errors or silence once the app successfully opens the forwarded display. Cheers, Nico -- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Dec 03 14:35:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EidA4-0001ud-Ue for secsh-archive@megatron.ietf.org; Sat, 03 Dec 2005 14:35:09 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26412 for ; Sat, 3 Dec 2005 14:34:20 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id DBA8D63B317; Sat, 3 Dec 2005 19:35:02 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 8E50863B293 for ; Sat, 3 Dec 2005 19:35:00 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1Eid9v-0007Ga-00 for ietf-ssh@netbsd.org; Sat, 03 Dec 2005 19:34:59 +0000 Date: Sat, 3 Dec 2005 19:34:59 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: Core IDs - last review Message-ID: <20051203193459.GA28505@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Chris Lonvick writes: > I've placed a set of diffs from what the RFC Editor had previously > proposed to what is currently being proposed here: > http://www.employees.org/~lonvick/secsh-wg/2005-nov-30/4250diff.html > http://www.employees.org/~lonvick/secsh-wg/2005-nov-30/4251diff.html > http://www.employees.org/~lonvick/secsh-wg/2005-nov-30/4252diff.html > http://www.employees.org/~lonvick/secsh-wg/2005-nov-30/4253diff.html > http://www.employees.org/~lonvick/secsh-wg/2005-nov-30/4254diff.html Following is a straight comparison of the change requests you posted to the WG mailing list and the edits actually made by RFC-Editor, based on the diffs at employees.org. (This assumes that what was posted here is what was sent to RFC-Editor, modulo the corrections also posted here.) I've also highlighted a few nits with the original change requests. Executive summary: everything I've picked up is a tedious little nit which won't affect understanding (with the possible exception of RFC4252 comment 11). Not worth the documents languishing for another month, anyway. RFC4250 (assignednumbers): pathetically tiny nits: > 4) > Section 4.5.1, first paragraph > - replace the paragraph > OLD: > Protocol packets containing the SSH_MSG_CHANNEL_REQUEST message with > a "pty-req" string MUST contain "encoded terminal modes" with an > opcode of 1 byte. The opcode values are in the range of 1 to 255. > Opcodes 1 to 159 have a single uint32 argument. Opcodes 160 to 255 > are not yet defined. > NEW: > Protocol packets containing the SSH_MSG_CHANNEL_REQUEST message with > a "pty-req" string MUST contain a 'encoded terminal modes' value. > The opcode values consist of a single byte and are in the range of 1 > to 255. Opcodes 1 to 159 have a uint32 argument. Opcodes 160 to > 255 are not yet defined. Nit: was edited as requested, but >>a 'encoded terminal modes' value<< should be >>an 'encoded terminal modes' value<< in the new text (2nd line). > 8) > Section 4.6.1, first paragraph > - add a clause > OLD: > at-sign ("@"), a comma (","), whitespace, or control characters > ^^^ > (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT > NEW: > at-sign ("@"), a comma (","), whitespace, control characters > (ASCII codes 32 or less), or the ASCII code 127 (DEL). Names are > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > case-sensitive, and MUST NOT ... Nit: old text did not say >>a comma (",")<<, it said just >>comma (",")<< (1st line). RFC-Editor has inserted "a". This should be reverted. RFC4251 (architecture): pathetically tiny nits: > 3) > Section 4.1, last paragraph > - restore the previous wording > OLD: > Thus, providing the option to not check the server host key is > ^^^^^^ > NEW: > Thus, providing the option not to check the server host key is > ^^^^^^ The second-to-last paragraph, which contained a similar phrase, was edited. The last paragraph was not. > 4) > Section 4.3, third bullet in the first paragraph > - modify a line > OLD: > depend on the location from which the user is trying to log in. > NEW: > depend on the location from where the client is trying to gain > access. Only 'which' has been changed to 'where'. (To be honest, I'm not too bothered about the missing changes.) > 6) > Section 4.5, next to last paragraph > - reword the last line > OLD: > names. Straight, bit-wise, binary comparison is RECOMMENDED. > ^ ^ > NEW: > names. Straight bit-wise binary comparison is RECOMMENDED. > > 7) > Section 5.4, third paragraph > - remove a comma > OLD: > names. Straight, bit-wise, binary comparison is RECOMMENDED. > ^ > NEW: > names. Straight bit-wise, binary comparison is RECOMMENDED. There is no section 5.4, and this phrase appears only once in the document. RFC-Editor has implemented the second edit to section 4.5. > 8) > Section 6, first bullet in second paragraph > - add a clause > OLD: > at-sign ("@"), a comma (","), whitespace, or control characters > ^^^ > (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT > NEW: > at-sign ("@"), a comma (","), whitespace, control characters > (ASCII codes 32 or less), or the ASCII code 127 (DEL). Names are > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > case-sensitive, and MUST NOT Same comment as assignednumbers re >>a comma<<, except that it does appear thus in the original version of this document. RFC4252 (userauth): mostly nits, one borderline-semantic comment: > 2) > Section 5, packet description after the first paragrah > - the packet syntax is not consistent with the format used in RFC 4254. > OLD: > byte SSH_MSG_USERAUTH_REQUEST > string user name in ISO-10646 UTF-8 encoding [RFC3629] > string service name in US-ASCII > string method name in US-ASCII > > The rest of the packet is method-specific. > NEW: > byte SSH_MSG_USERAUTH_REQUEST > string user name in ISO-10646 UTF-8 encoding [RFC3629] > string service name in US-ASCII > string method name in US-ASCII > .... method specific fields follow RFC-Editor has put just >>method specific fields<<. (*shrug*.) > 4) > Section 5.2, second paragraph > - replace the paragraph > OLD: > If no authentication is needed for the user, the server MUST return > SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return > SSH_MSG_USERAUTH_FAILURE and MAY return it with a list of > authentication 'method name' values. > NEW: > If no authentication is needed for the user, the server MUST return > SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return > SSH_MSG_USERAUTH_FAILURE and MAY return it a list of methods that > may continue in its 'authentications that can continue' value. RFC-Editor's edit matches this, but on the third line, I'd s/return it a list/return with it a list/. > 8) > Section 7, Second paragraph > - replace the paragraph > OLD: > With this method, the possession of a private key serves as > authentication. This method works by sending a 'signature' created > with a private key of the user. The server MUST check that the key > is a valid authenticator for the user, and MUST check that the > 'signature' is valid. If both hold, the authentication request MUST > be accepted; otherwise, it MUST be rejected. (Note that the server > MAY require additional authentications after successful > authentication.) > NEW: > With this method, the possession of a private key serves as > authentication. This method works by sending a signature created > with a private key of the user. The server MUST check that the key > is a valid authenticator for the user, and MUST check that the > signature is valid. If both hold, the authentication request MUST > be accepted; otherwise, it MUST be rejected. (Note that the server > MAY require additional authentications after successful > authentication.) Parentheses on the final sentence seem to have been removed. (*shrug*.) Extra edits have appeared in sections 7, 8, and 9 in packet descriptions: s/service/service name/ in a couple of places. However, there is still one place in section 8 (packet description after 1st paragraph) where it just says 'service'. > 11) > Section 8, second paragraph > - change the wording > OLD: > added to the database, or compare them (with or without hashing) to > ^^^^^^^^^^^^ > NEW: > added to the database, or compared (with or without hashing) to RFC-Editor hasn't removed the "them". The resulting sentence doesn't make sense. IIRC the consensus from previous discussion was that the original edit approached a semantic change, so it would be good to have this clear. > 13) > Section 9, in the fourth paragraph > - add a reference > OLD: > key' are defined in the transport layer specification. The 'public > NEW: > key' are defined in the transport layer specification [RFC4253]. The 'public Actually edited to [SSH-TRANS] (which I prefer, and is consistent with references elsewhere). RFC4253 (transport): missing edits, but nits really: > 5) > Section 6.1, first paragraph > - revise a line > OLD: > larger packets MAY be sent if the version string indicates that the > ^^^^^^^ > NEW: > larger packets MAY be sent if the identification string indicates that > the > ^^^^^^^^^^^^^^ RFC-Editor's version has lost the final "the" (possibly due to confusing wrapping as above). Text now reads "[...] indicates that other party is able [...]". An extra, but welcome, edit has appeared in 6.3 third paragraph. > 13) > Section 7.1, seventh paragraph > - replace the paragraph > OLD: > Note, however, that during a key re-exchange, after sending a KEXINIT > message, each party MUST be prepared to process an arbitrary number > of messages that may be in-flight before receiving a KEXINIT from the > other party. > NEW: > Note, however, that during a key re-exchange, after sending a > SSH_MSG_KEXINIT message, each party MUST be prepared to process an > arbitrary number of messages that may be in-flight before receiving a > SSH_MSG_KEXINIT messages from the other party. RFC-Editor's text matches this, but on the last line, "messages" should be just "message". > 15) > Section 8, second paragraph with bullets > - replace the paragraph with bullets > - do not break the bulleted sections across page boundaries > OLD: > The following steps are used to exchange a key. In this, C is the > client; S is the server; p is a large safe prime; g is a generator > for a subgroup of GF(p); q is the order of the subgroup; V_S is S's > version string; V_C is C's version string; K_S is S's public host > key; I_C is C's KEXINIT message and I_S is S's KEXINIT message that > have been exchanged before this part begins. > > 1. C generates a random number x (1 < x < q) and computes e = g^x mod > p. C sends "e" to S. > > 2. S generates a random number y (0 < y < q) and computes f = g^y mod > p. S receives "e". It computes K = e^y mod p, H = hash(V_C || > V_S || I_C || I_S || K_S || e || f || K) (these elements are > encoded according to their types; see below), and signature s on H > with its private host key. S sends "K_S || f || s" to C. The > signing operation may involve a second hashing operation. > > 3. C verifies that K_S really is the host key for S (e.g., using > certificates or a local database). C is also allowed to accept > the key without verification; however, doing so will render the > protocol insecure against active attacks (but may be desirable for > practical reasons in the short term in many environments). C then > computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || K_S > || e || f || K), and verifies the signature s on H. > NEW: > The following steps are used to exchange a key. In this, C is the > client; S is the server; p is a large safe prime; g is a generator > for a subgroup of GF(p); q is the order of the subgroup; V_S is S's > identification string; V_C is C's identification string; K_S is S's > public host key; I_C is C's SSH_MSG_KEXINIT message and I_S is S's > SSH_MSG_KEXINIT message that have been exchanged before this part > begins. > > 1. C generates a random number x (1 < x < q) and computes > 'e' = g^x mod p. C sends 'e' to S. > > 2. S generates a random number y (0 < y < q) and computes > 'f' = g^y mod p. S receives 'e'. It computes K = e^y mod p, > H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K) > (these elements are encoded according to their types; see below), > and s ('signature of H') with its private host key. S sends > "K_S || f || s" to C. The signing operation may involve a > second hashing operation. > > 3. C verifies that K_S really is the host key for S (e.g., using > certificates or a local database). C is also allowed to accept > the key without verification; however, doing so will render the > protocol insecure against active attacks (but may be desirable for > practical reasons in the short term in many environments). C then > computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || K_S > || e || f || K), and verifies the 'signature of H' (s). The text change requested here has not been performed. (The requested changes boil down to: s/version/identification/; s/KEXINIT/SSH_MSG_KEXINIT/; s/signature s on H/s ('signature of H')/ and similar; quote character changes and quote mark additions) (It's not clear to me what you meant by your request "replace the paragraph with bullets". Nothing seems to have happened, anyway.) RFC4254 (connection): > 7) > Section 5.2, fourth paragraph > - replace the paragraph > OLD: > The maximum amount of data allowed is the current window size. The > window size is decremented by the amount of data sent. Both parties > MAY ignore all extra data sent after the allowed window is empty. > NEW: > The maximum amount of data allowed is determined by the maximum > packet size for the channel, and the current window size, whichever > is smaller. The window size is decremented by the amount of data > sent. Both parties MAY ignore all extra data sent after the allowed > window is empty. > > Implementations are expected to have some limit on the ssh > transport layer packet size (any limit for rececived packets MUST > be 32768 bytes or larger, as described in [SSH-TRANS]). The > implementation of the SSH connection layer > > o MUST NOT advertise a maximum packet size that would result in > transport packets larger than its transport layer is willing to > receive. > > o MUST NOT generate data packets larger that its transport layer is > willing to send, even if the remote end would be willing to > accept very large packets. RFC-Editor's changes match the request (modulo the typo 'rececived' above). A couple of further nits: s/ssh transport layer/SSH transport layer/ in the second paragraph; s/larger that/larger than/ in the second bullet. An extra edit was made in section 6.10 first paragraph: remove "after this message". > 14) > Section 6.10, fourth paragraph > - do not break a hyphen segmented name > OLD: > Additional 'signal name' values MAY be sent in the format "sig- > name@xyz", where "sig-name" and "xyz" may be anything a particular > NEW: > Additional 'signal name' values MAY be sent in the format > "sig-name@xyz", where "sig-name" and "xyz" may be anything a particular This edit has not been made. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Dec 03 14:48:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EidMv-0006Cm-4C for secsh-archive@megatron.ietf.org; Sat, 03 Dec 2005 14:48:25 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27503 for ; Sat, 3 Dec 2005 14:47:36 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5095C63B31F; Sat, 3 Dec 2005 19:48:22 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 8696C63B31D for ; Sat, 3 Dec 2005 19:48:21 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1EidMp-0004X8-00; Sat, 03 Dec 2005 19:48:19 +0000 Date: Sat, 3 Dec 2005 19:48:19 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Cc: Frank Cusack , Martin Forssen , Jakob Schlyter , Wesley Griffin Subject: Re: collated comments for -dns (RFC 4255) and -kbdinteract (RFC 4256) Message-ID: <20051203194819.GB28505@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051118004250.GD5569@chiark.greenend.org.uk> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list [CC'd to listed authors in the secsh-dns and secsh-kbdinteract Internet-Drafts] I wrote (18 Nov): > Since there hasn't been any obvious activity on -dns (4255) and > -kbdinteract (4256), I've taken it upon myself to collate the comments > I've made and seen on the list in the format the RFC Editor appears to > want. > > Since I'm not a listed author, I don't plan to actually send this to > the RFC Editor (unless someone suggests that I do); I hope that it > saves someone some time. Neither of these documents has been updated on ftp.rfc-editor.org for over a month. Is anything happening with them? As far as comments on the WG mailing list are concerned: - secsh-dns is fine as is and just needs acking by the authors; - secsh-kbdinteract has a few suggested edits, collated in the message to which this is a reply. As I understand it (from the material Chris Lonvick has forwarded), every listed author needs to respond in order for the RFC to be published. I note that the email address for Frank Cusack in secsh-kbdinteract is not the same as the From: header of a message recently sent to this list. Are the contact details in these documents up-to-date? If not, perhaps the authors haven't seen any email from the RFC Editor? (I guess I'll find out if the email addresses bounce from the CCs of this message.) From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Dec 03 20:17:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiiV2-0004tO-S1 for secsh-archive@megatron.ietf.org; Sat, 03 Dec 2005 20:17:09 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21370 for ; Sat, 3 Dec 2005 20:16:19 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 722B363B166; Sun, 4 Dec 2005 01:16:58 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from renown.cnchost.com (renown.concentric.net [207.155.248.7]) by mail.netbsd.org (Postfix) with ESMTP id 891D363B11F for ; Sun, 4 Dec 2005 01:16:57 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by renown.cnchost.com id SAA19844; Sat, 3 Dec 2005 18:57:25 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: denis bider To: X-Mailer: Barca 1.4 (1000) - Licensed Version Date: Sun, 4 Dec 2005 00:57:18 +0100 Message-ID: <200512405718.775980@nucleus> Subject: SFTP ACLs need inheritance support Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Hello all, I believe the ACL support which SFTP has lifted from NFS v4 is insufficient.= It seems as if this system was developed directly with Windows NT4 ACLs in= mind. It does not support inheritance which is an important feature of NTFS= file security since Windows 2000. To address this, I suggest the following additions to the SFTP draft: 1. In the Attributes structure, in addition to the ACL string, there should= be an "ACL flags" value containing any combination of the following= values: DACL present =3D ... DACL protected =3D ... SACL present =3D ... SACL protected =3D ... Without the DACL present and SACL present flags, there is no way for a= server to know whether the client, by sending an ACL with no system audit= entries, wishes to clear the SACL or leave it intact. This is important= because a special privilege is required to set or clear the SACL, and this= privilege is not held by regular users. An explicit flag would make it= easier for the server to determine the user's intent. The "protected" flags are necessary to control inheritance of ACEs from the= parent container. Without these flags, there is no way for the SFTP client= to control ACE inheritance. 2. The ACE flags need to be extended with something like= "INHERITED_ACE_FLAG". When the client retrieves an ACL, this flag would be= set by the server to indicate that the particular ACE entry is inherited= from a parent directory. The SFTP client would Obviously we probably won't call this ACE4_INHERITED_ACE_FLAG, since this= flag is not in NFS v4. 3. Optionally, one might also choose to support "inherited from" information= so that the SFTP client could be told about the source of an inherited= ACE. I believe these changes are necessary to implement a quality SFTP client. If= these additions are not agreed to, I will have to devise a private= extension for them. That will be bad for interoperability. If these additions are incorporated into the SFTP draft, they could be made= backwards compatible by specifying the Attributes structure ACL flag as an= extension. However, as far as I'm concerned, the protocol version might= also be bumped up to 7; that seems a bit cleaner, but otherwise it is all= the same to me. So, what does everyone think? Best regards, denis From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Dec 04 05:59:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eirao-00086O-Vt for secsh-archive@megatron.ietf.org; Sun, 04 Dec 2005 05:59:43 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28104 for ; Sun, 4 Dec 2005 05:58:52 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id B84A363B296; Sun, 4 Dec 2005 10:59:38 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.rfc.se (nic.rfc.se [195.47.254.20]) by mail.netbsd.org (Postfix) with ESMTP id 029C563B144 for ; Sun, 4 Dec 2005 10:59:37 +0000 (UTC) Received: from criollo.schlyter.se (criollo.schlyter.se [195.47.254.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id 9C2CC5A01; Sun, 4 Dec 2005 11:35:07 +0100 (CET) Date: Sun, 4 Dec 2005 11:35:06 +0100 (CET) From: Jakob Schlyter To: ietf-ssh@NetBSD.org cc: Frank Cusack , Martin Forssen , Jakob Schlyter , Wesley Griffin Subject: Re: collated comments for -dns (RFC 4255) and -kbdinteract (RFC 4256) In-Reply-To: <20051203194819.GB28505@chiark.greenend.org.uk> Message-ID: References: <20051203194819.GB28505@chiark.greenend.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sat, 3 Dec 2005, Jacob Nevins wrote: > As far as comments on the WG mailing list are concerned: > - secsh-dns is fine as is and just needs acking by the authors; I far as I know, both wes and I have ack'd the secsh-dns draft to the rfc editor. jakob -- Jakob Schlyter +46 70 595 07 94 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Dec 04 16:00:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ej0xy-000337-29 for secsh-archive@megatron.ietf.org; Sun, 04 Dec 2005 16:00:14 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16942 for ; Sun, 4 Dec 2005 15:59:24 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 8DE9463B12A; Sun, 4 Dec 2005 20:59:59 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from computador1 (201008230244.user.veloxzone.com.br [201.8.230.244]) by mail.netbsd.org (Postfix) with ESMTP id 91B4763B111 for ; Sun, 4 Dec 2005 20:59:57 +0000 (UTC) To: ietf-ssh@NetBSD.org From: "Paula Durval" Subject: Modelos de Cartas comerciais: tipos de solicitação de emprego Date: Sun, 04 Dec 2005 17:59:54 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20051204205957.91B4763B111@mail.netbsd.org> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA16942 tipos de solicita=E7=E3o de emprego modelos de convites para festas model= os de cartas=20 comerciais: http://www.gueb.de/cartascomerciais ou http://geocities.yahoo.com.br/cartascomerciais2006/conteudo.htm Documentos prontos para uso de pessoas f=EDsicas e empresas. modelos de c= onvites=20 para festas tipos de solicita=E7=E3o de emprego modelos de convites para = festas Modelos=20 de contratos, modelos de documentos, modelos de cartas: http://www.gueb.de/cartascomerciais ou http://geocities.yahoo.com.br/cartascomerciais2006/conteudo.htm Modelos de cartas comerciais para todas as ocasi=F5es. Contratos, avisos,= curr=EDculos=20 ... Veja modelos de convites para festas e muito mais. Visite nosso site From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Dec 04 16:32:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ej1TR-0002PT-GN for secsh-archive@megatron.ietf.org; Sun, 04 Dec 2005 16:32:45 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19736 for ; Sun, 4 Dec 2005 16:31:56 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id D745863B12A; Sun, 4 Dec 2005 21:32:42 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 3584063B2B9 for ; Sun, 4 Dec 2005 21:32:42 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1Ej1TN-0001Ai-00 for ietf-ssh@netbsd.org; Sun, 04 Dec 2005 21:32:41 +0000 Date: Sun, 4 Dec 2005 21:32:41 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: Core IDs - last review Message-ID: <20051204213241.GA1390@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Chris Lonvick writes: > ftp://ftp.rfc-editor.org/in-notes/authors/rfc4250.txt I see the IANA registry at hasn't been updated yet (to remove KEXDH_*, spki-sign-* and so on). Are they waiting for RFC4250 to be finalised? (Is there any way for a mere mortal to see the status of "rt.icann.org #2774"?) From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Dec 04 20:37:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ej5IK-0006tD-Ko for secsh-archive@megatron.ietf.org; Sun, 04 Dec 2005 20:37:33 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10614 for ; Sun, 4 Dec 2005 20:36:41 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5E6FF63B2C3; Mon, 5 Dec 2005 01:37:27 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.netbsd.org (Postfix) with ESMTP id 11FC163B177 for ; Mon, 5 Dec 2005 01:37:25 +0000 (UTC) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 04 Dec 2005 17:37:25 -0800 X-IronPort-AV: i="3.99,213,1131350400"; d="scan'208"; a="237153151:sNHT31750320" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jB51bNpg003277 for ; Sun, 4 Dec 2005 17:37:23 -0800 (PST) Date: Sun, 4 Dec 2005 17:37:23 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: Core IDs - last review In-Reply-To: <20051203193459.GA28505@chiark.greenend.org.uk> Message-ID: References: <20051203193459.GA28505@chiark.greenend.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, Very good catches. Comments in line. On Sat, 3 Dec 2005, Jacob Nevins wrote: > Chris Lonvick writes: >> I've placed a set of diffs from what the RFC Editor had previously >> proposed to what is currently being proposed here: >> http://www.employees.org/~lonvick/secsh-wg/2005-nov-30/4250diff.html >> http://www.employees.org/~lonvick/secsh-wg/2005-nov-30/4251diff.html >> http://www.employees.org/~lonvick/secsh-wg/2005-nov-30/4252diff.html >> http://www.employees.org/~lonvick/secsh-wg/2005-nov-30/4253diff.html >> http://www.employees.org/~lonvick/secsh-wg/2005-nov-30/4254diff.html > > Following is a straight comparison of the change requests you posted to > the WG mailing list and the edits actually made by RFC-Editor, based on > the diffs at employees.org. (This assumes that what was posted here is > what was sent to RFC-Editor, modulo the corrections also posted here.) > I've also highlighted a few nits with the original change requests. > > Executive summary: everything I've picked up is a tedious little nit > which won't affect understanding (with the possible exception of RFC4252 > comment 11). Not worth the documents languishing for another month, > anyway. > > RFC4250 (assignednumbers): pathetically tiny nits: >> 4) >> Section 4.5.1, first paragraph >> - replace the paragraph >> OLD: >> Protocol packets containing the SSH_MSG_CHANNEL_REQUEST message with >> a "pty-req" string MUST contain "encoded terminal modes" with an >> opcode of 1 byte. The opcode values are in the range of 1 to 255. >> Opcodes 1 to 159 have a single uint32 argument. Opcodes 160 to 255 >> are not yet defined. >> NEW: >> Protocol packets containing the SSH_MSG_CHANNEL_REQUEST message with >> a "pty-req" string MUST contain a 'encoded terminal modes' value. >> The opcode values consist of a single byte and are in the range of 1 >> to 255. Opcodes 1 to 159 have a uint32 argument. Opcodes 160 to >> 255 are not yet defined. > > Nit: was edited as requested, but >>a 'encoded terminal modes' value<< > should be >>an 'encoded terminal modes' value<< in the new text > (2nd line). I think it's "a value" (or "a blob value") rather than "an value". I'll leave this unless I get an additional request to change it. > >> 8) >> Section 4.6.1, first paragraph >> - add a clause >> OLD: >> at-sign ("@"), a comma (","), whitespace, or control characters >> ^^^ >> (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT >> NEW: >> at-sign ("@"), a comma (","), whitespace, control characters >> (ASCII codes 32 or less), or the ASCII code 127 (DEL). Names are >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> case-sensitive, and MUST NOT ... > > Nit: old text did not say >>a comma (",")<<, it said just >>> comma (",")<< (1st line). RFC-Editor has inserted "a". This should be > reverted. OK > > RFC4251 (architecture): pathetically tiny nits: >> 3) >> Section 4.1, last paragraph >> - restore the previous wording >> OLD: >> Thus, providing the option to not check the server host key is >> ^^^^^^ >> NEW: >> Thus, providing the option not to check the server host key is >> ^^^^^^ > > The second-to-last paragraph, which contained a similar phrase, was > edited. The last paragraph was not. OK > >> 4) >> Section 4.3, third bullet in the first paragraph >> - modify a line >> OLD: >> depend on the location from which the user is trying to log in. >> NEW: >> depend on the location from where the client is trying to gain >> access. > > Only 'which' has been changed to 'where'. (To be honest, I'm not too > bothered about the missing changes.) It still bothers me. I'll request that it be changed. > >> 6) >> Section 4.5, next to last paragraph >> - reword the last line >> OLD: >> names. Straight, bit-wise, binary comparison is RECOMMENDED. >> ^ ^ >> NEW: >> names. Straight bit-wise binary comparison is RECOMMENDED. >> >> 7) >> Section 5.4, third paragraph >> - remove a comma >> OLD: >> names. Straight, bit-wise, binary comparison is RECOMMENDED. >> ^ >> NEW: >> names. Straight bit-wise, binary comparison is RECOMMENDED. > > There is no section 5.4, and this phrase appears only once in the > document. RFC-Editor has implemented the second edit to section 4.5. I caught that before submitting to the RFC Editor. Is "Straight bit-wise, binary comparison..." acceptable? > >> 8) >> Section 6, first bullet in second paragraph >> - add a clause >> OLD: >> at-sign ("@"), a comma (","), whitespace, or control characters >> ^^^ >> (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT >> NEW: >> at-sign ("@"), a comma (","), whitespace, control characters >> (ASCII codes 32 or less), or the ASCII code 127 (DEL). Names are >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> case-sensitive, and MUST NOT > > Same comment as assignednumbers re >>a comma<<, except that it does > appear thus in the original version of this document. OK > > RFC4252 (userauth): mostly nits, one borderline-semantic comment: >> 2) >> Section 5, packet description after the first paragrah >> - the packet syntax is not consistent with the format used in RFC 4254. >> OLD: >> byte SSH_MSG_USERAUTH_REQUEST >> string user name in ISO-10646 UTF-8 encoding [RFC3629] >> string service name in US-ASCII >> string method name in US-ASCII >> >> The rest of the packet is method-specific. ^^^^^^^^^^^^^^^^^^^^^^^.. this line still needs to be removed >> NEW: >> byte SSH_MSG_USERAUTH_REQUEST >> string user name in ISO-10646 UTF-8 encoding [RFC3629] >> string service name in US-ASCII >> string method name in US-ASCII >> .... method specific fields follow > > RFC-Editor has put just >>method specific fields<<. (*shrug*.) I'll think abut this. > >> 4) >> Section 5.2, second paragraph >> - replace the paragraph >> OLD: >> If no authentication is needed for the user, the server MUST return >> SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return >> SSH_MSG_USERAUTH_FAILURE and MAY return it with a list of >> authentication 'method name' values. >> NEW: >> If no authentication is needed for the user, the server MUST return >> SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return >> SSH_MSG_USERAUTH_FAILURE and MAY return it a list of methods that >> may continue in its 'authentications that can continue' value. > > RFC-Editor's edit matches this, but on the third line, I'd > s/return it a list/return with it a list/. OK > >> 8) >> Section 7, Second paragraph >> - replace the paragraph >> OLD: >> With this method, the possession of a private key serves as >> authentication. This method works by sending a 'signature' created >> with a private key of the user. The server MUST check that the key >> is a valid authenticator for the user, and MUST check that the >> 'signature' is valid. If both hold, the authentication request MUST >> be accepted; otherwise, it MUST be rejected. (Note that the server >> MAY require additional authentications after successful >> authentication.) >> NEW: >> With this method, the possession of a private key serves as >> authentication. This method works by sending a signature created >> with a private key of the user. The server MUST check that the key >> is a valid authenticator for the user, and MUST check that the >> signature is valid. If both hold, the authentication request MUST >> be accepted; otherwise, it MUST be rejected. (Note that the server >> MAY require additional authentications after successful >> authentication.) > > Parentheses on the final sentence seem to have been removed. > (*shrug*.) I did request that as well. I couldn't see why it needs to be in parentheses. > > Extra edits have appeared in sections 7, 8, and 9 in packet > descriptions: s/service/service name/ in a couple of places. > However, there is still one place in section 8 (packet description after > 1st paragraph) where it just says 'service'. The RFC Editor did miss that. I'll re-request it. > >> 11) >> Section 8, second paragraph >> - change the wording >> OLD: >> added to the database, or compare them (with or without hashing) to >> ^^^^^^^^^^^^ >> NEW: >> added to the database, or compared (with or without hashing) to > > RFC-Editor hasn't removed the "them". The resulting sentence doesn't > make sense. IIRC the consensus from previous discussion was that the > original edit approached a semantic change, so it would be good to have > this clear. Got it. > >> 13) >> Section 9, in the fourth paragraph >> - add a reference >> OLD: >> key' are defined in the transport layer specification. The 'public >> NEW: >> key' are defined in the transport layer specification [RFC4253]. The 'public > > Actually edited to [SSH-TRANS] (which I prefer, and is consistent with > references elsewhere). I caught that before submitting to the RFC Editor. It is more descriptive that way. > > RFC4253 (transport): missing edits, but nits really: >> 5) >> Section 6.1, first paragraph >> - revise a line >> OLD: >> larger packets MAY be sent if the version string indicates that the >> ^^^^^^^ >> NEW: >> larger packets MAY be sent if the identification string indicates that >> the >> ^^^^^^^^^^^^^^ > > RFC-Editor's version has lost the final "the" (possibly due to confusing > wrapping as above). Text now reads "[...] indicates that other party is > able [...]". Got it. > > An extra, but welcome, edit has appeared in 6.3 third paragraph. That was discussed after I posted to the list but before I submitted to the RFC Editor. > >> 13) >> Section 7.1, seventh paragraph >> - replace the paragraph >> OLD: >> Note, however, that during a key re-exchange, after sending a KEXINIT >> message, each party MUST be prepared to process an arbitrary number >> of messages that may be in-flight before receiving a KEXINIT from the >> other party. >> NEW: >> Note, however, that during a key re-exchange, after sending a >> SSH_MSG_KEXINIT message, each party MUST be prepared to process an >> arbitrary number of messages that may be in-flight before receiving a >> SSH_MSG_KEXINIT messages from the other party. > > RFC-Editor's text matches this, but on the last line, "messages" should > be just "message". OK > >> 15) >> Section 8, second paragraph with bullets >> - replace the paragraph with bullets >> - do not break the bulleted sections across page boundaries >> OLD: >> The following steps are used to exchange a key. In this, C is the >> client; S is the server; p is a large safe prime; g is a generator >> for a subgroup of GF(p); q is the order of the subgroup; V_S is S's >> version string; V_C is C's version string; K_S is S's public host >> key; I_C is C's KEXINIT message and I_S is S's KEXINIT message that >> have been exchanged before this part begins. >> >> 1. C generates a random number x (1 < x < q) and computes e = g^x mod >> p. C sends "e" to S. >> >> 2. S generates a random number y (0 < y < q) and computes f = g^y mod >> p. S receives "e". It computes K = e^y mod p, H = hash(V_C || >> V_S || I_C || I_S || K_S || e || f || K) (these elements are >> encoded according to their types; see below), and signature s on H >> with its private host key. S sends "K_S || f || s" to C. The >> signing operation may involve a second hashing operation. >> >> 3. C verifies that K_S really is the host key for S (e.g., using >> certificates or a local database). C is also allowed to accept >> the key without verification; however, doing so will render the >> protocol insecure against active attacks (but may be desirable for >> practical reasons in the short term in many environments). C then >> computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || K_S >> || e || f || K), and verifies the signature s on H. >> NEW: >> The following steps are used to exchange a key. In this, C is the >> client; S is the server; p is a large safe prime; g is a generator >> for a subgroup of GF(p); q is the order of the subgroup; V_S is S's >> identification string; V_C is C's identification string; K_S is S's >> public host key; I_C is C's SSH_MSG_KEXINIT message and I_S is S's >> SSH_MSG_KEXINIT message that have been exchanged before this part >> begins. >> >> 1. C generates a random number x (1 < x < q) and computes >> 'e' = g^x mod p. C sends 'e' to S. >> >> 2. S generates a random number y (0 < y < q) and computes >> 'f' = g^y mod p. S receives 'e'. It computes K = e^y mod p, >> H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K) >> (these elements are encoded according to their types; see below), >> and s ('signature of H') with its private host key. S sends >> "K_S || f || s" to C. The signing operation may involve a >> second hashing operation. >> >> 3. C verifies that K_S really is the host key for S (e.g., using >> certificates or a local database). C is also allowed to accept >> the key without verification; however, doing so will render the >> protocol insecure against active attacks (but may be desirable for >> practical reasons in the short term in many environments). C then >> computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || K_S >> || e || f || K), and verifies the 'signature of H' (s). > > The text change requested here has not been performed. > (The requested changes boil down to: > s/version/identification/; > s/KEXINIT/SSH_MSG_KEXINIT/; > s/signature s on H/s ('signature of H')/ and similar; > quote character changes and quote mark additions) > > (It's not clear to me what you meant by your request "replace the > paragraph with bullets". Nothing seems to have happened, anyway.) It meant, "replace the paragraph and all the associated bullets". The RFC Editor requested clarification of my requested changes. Having 'e' and 'f' (rather than naked e and f, and "e" and "f") doesn't really work throughout this section. I'm going to try again. > > RFC4254 (connection): >> 7) >> Section 5.2, fourth paragraph >> - replace the paragraph >> OLD: >> The maximum amount of data allowed is the current window size. The >> window size is decremented by the amount of data sent. Both parties >> MAY ignore all extra data sent after the allowed window is empty. >> NEW: >> The maximum amount of data allowed is determined by the maximum >> packet size for the channel, and the current window size, whichever >> is smaller. The window size is decremented by the amount of data >> sent. Both parties MAY ignore all extra data sent after the allowed >> window is empty. >> >> Implementations are expected to have some limit on the ssh >> transport layer packet size (any limit for rececived packets MUST >> be 32768 bytes or larger, as described in [SSH-TRANS]). The >> implementation of the SSH connection layer >> >> o MUST NOT advertise a maximum packet size that would result in >> transport packets larger than its transport layer is willing to >> receive. >> >> o MUST NOT generate data packets larger that its transport layer is >> willing to send, even if the remote end would be willing to >> accept very large packets. > > RFC-Editor's changes match the request (modulo the typo 'rececived' > above). A couple of further nits: > s/ssh transport layer/SSH transport layer/ in the second paragraph; > s/larger that/larger than/ in the second bullet. OK > An extra edit was made in section 6.10 first paragraph: remove "after > this message". It's actually still there. The page break makes that look strange. > >> 14) >> Section 6.10, fourth paragraph >> - do not break a hyphen segmented name >> OLD: >> Additional 'signal name' values MAY be sent in the format "sig- >> name@xyz", where "sig-name" and "xyz" may be anything a particular >> NEW: >> Additional 'signal name' values MAY be sent in the format >> "sig-name@xyz", where "sig-name" and "xyz" may be anything a particular > > This edit has not been made. OK New set of minor change requests on their way. Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Dec 05 02:14:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjAY0-0002Yv-I3 for secsh-archive@megatron.ietf.org; Mon, 05 Dec 2005 02:14:04 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09016 for ; Mon, 5 Dec 2005 02:13:13 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id D76A963B33F; Mon, 5 Dec 2005 07:13:57 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id AAADD63B335 for ; Mon, 5 Dec 2005 07:13:56 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id CAA15715; Mon, 5 Dec 2005 02:13:55 -0500 (EST) From: der Mouse Message-Id: <200512050713.CAA15715@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Mon, 5 Dec 2005 02:11:16 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: Core IDs - last review In-Reply-To: References: <20051203193459.GA28505@chiark.greenend.org.uk> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> Nit: was edited as requested, but >>a 'encoded terminal modes' value<< >> should be >>an 'encoded terminal modes' value<< in the new text (2nd >> line). > I think it's "a value" (or "a blob value") rather than "an value". Yes, it would be, but that's not the way "a"-vs-"an" works. It's the next word, not the base noun, which controls, and here that's "encoded", which takes "an". /~\ 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 bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Dec 05 10:16:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjI4o-0007gQ-Ge for secsh-archive@megatron.ietf.org; Mon, 05 Dec 2005 10:16:26 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01240 for ; Mon, 5 Dec 2005 10:15:36 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5E72063B176; Mon, 5 Dec 2005 15:16:21 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from tonnant.cnchost.com (tonnant.concentric.net [207.155.248.72]) by mail.netbsd.org (Postfix) with ESMTP id 776DD63B16C for ; Mon, 5 Dec 2005 15:16:20 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by tonnant.cnchost.com id JAA01093; Mon, 5 Dec 2005 09:14:02 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: denis bider To: X-Mailer: Barca 1.4 (1000) - Licensed Version Date: Mon, 5 Dec 2005 15:14:00 +0100 Message-ID: <200512515140.647732@nucleus> In-Reply-To: <200512405718.775980@nucleus> Subject: Re: SFTP ACLs need inheritance support Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Hello all, I think we are also missing an ACE mask flag for accessing system security. When communicating with a Windows server, a client can open a file with= READ_ACL and WRITE_ACL masks which will allow it to read or write the DACL= later. However, the client has no way of opening a file handle in a way= that will allow it to read or write AUDIT ACEs. In order to do this, the= client needs to request the ACCESS_SYSTEM_SECURITY access right when= opening the file, and the server needs to enable the Security privilege for= the duration of the file open attempt. We need an ACE mask flag that will be equivalent to ACCESS_SYSTEM_SECURITY.= I suggest allocating 0x00200000 for this. Best regards, denis On Sun, 4 Dec 2005 00:57:18 +0100, denis bider wrote: >=A0Hello all, > >=A0I believe the ACL support which SFTP has lifted from NFS v4 is >=A0insufficient. It seems as if this system was developed directly >=A0with Windows NT4 ACLs in mind. It does not support inheritance >=A0which is an important feature of NTFS file security since Windows >=A02000. > >=A0To address this, I suggest the following additions to the SFTP >=A0draft: > >=A01. In the Attributes structure, in addition to the ACL string, >=A0there should be an "ACL flags" value containing any combination of >=A0the following values: > >=A0DACL present =3D ... >=A0DACL protected =3D ... >=A0SACL present =3D ... >=A0SACL protected =3D ... > >=A0Without the DACL present and SACL present flags, there is no way >=A0for a server to know whether the client, by sending an ACL with no >=A0system audit entries, wishes to clear the SACL or leave it intact. >=A0This is important because a special privilege is required to set or >=A0clear the SACL, and this privilege is not held by regular users. An >=A0explicit flag would make it easier for the server to determine the >=A0user's intent. > >=A0The "protected" flags are necessary to control inheritance of ACEs >=A0from the parent container. Without these flags, there is no way for >=A0the SFTP client to control ACE inheritance. > > >=A02. The ACE flags need to be extended with something like >=A0"INHERITED_ACE_FLAG". When the client retrieves an ACL, this flag >=A0would be set by the server to indicate that the particular ACE >=A0entry is inherited from a parent directory. The SFTP client would > >=A0Obviously we probably won't call this ACE4_INHERITED_ACE_FLAG, >=A0since this flag is not in NFS v4. > > >=A03. Optionally, one might also choose to support "inherited from" >=A0information so that the SFTP client could be told about the source >=A0of an inherited ACE. > > >=A0I believe these changes are necessary to implement a quality SFTP >=A0client. If these additions are not agreed to, I will have to devise >=A0a private extension for them. That will be bad for interoperability. > >=A0If these additions are incorporated into the SFTP draft, they could >=A0be made backwards compatible by specifying the Attributes structure >=A0ACL flag as an extension. However, as far as I'm concerned, the >=A0protocol version might also be bumped up to 7; that seems a bit >=A0cleaner, but otherwise it is all the same to me. > >=A0So, what does everyone think? > > >=A0Best regards, > >=A0denis From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Dec 05 12:01:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjJip-0006vF-EM for secsh-archive@megatron.ietf.org; Mon, 05 Dec 2005 12:01:52 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13301 for ; Mon, 5 Dec 2005 12:01:00 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1559863B113; Mon, 5 Dec 2005 17:01:46 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by mail.netbsd.org (Postfix) with ESMTP id 424A663B148 for ; Mon, 5 Dec 2005 17:01:45 +0000 (UTC) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.1/8.13.1) with ESMTP id jB5GWQVq026937; Mon, 5 Dec 2005 10:32:26 -0600 Received: from ponyxpress.rosslyn.ads.sparta.com (861.rosslyn.sparta.com [157.185.86.1]) by Beta5.sparta.com (8.12.11/8.12.11) with ESMTP id jB5GWNed005254; Mon, 5 Dec 2005 10:32:24 -0600 Received: from mailbin.rosslyn.ads.sparta.com ([157.185.85.6]) by ponyxpress.rosslyn.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 11:32:22 -0500 Received: from [192.168.1.114] ([158.69.83.250]) by mailbin.rosslyn.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 11:43:27 -0500 In-Reply-To: References: <20051203194819.GB28505@chiark.greenend.org.uk> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <703ADE47-BE70-4744-9F8F-032E6C50E7E3@sparta.com> Cc: Wesley Griffin , ietf-ssh@NetBSD.org, Frank Cusack , Martin Forssen , Jakob Schlyter Content-Transfer-Encoding: 7bit From: Wesley Griffin Subject: Re: collated comments for -dns (RFC 4255) and -kbdinteract (RFC 4256) Date: Mon, 5 Dec 2005 11:32:13 -0500 To: Jakob Schlyter X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 05 Dec 2005 16:43:27.0984 (UTC) FILETIME=[04834700:01C5F9BB] Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Chiming in here, yes I have ack'd the draft as well. On Dec 4, 2005, at 5:35 AM, Jakob Schlyter wrote: > On Sat, 3 Dec 2005, Jacob Nevins wrote: > >> As far as comments on the WG mailing list are concerned: >> - secsh-dns is fine as is and just needs acking by the authors; > > I far as I know, both wes and I have ack'd the secsh-dns draft to > the rfc editor. > > jakob > > -- > Jakob Schlyter +46 70 595 07 94 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Dec 05 13:51:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjLR7-00076T-7w for secsh-archive@megatron.ietf.org; Mon, 05 Dec 2005 13:51:41 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26545 for ; Mon, 5 Dec 2005 13:50:49 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id BE47863B1C8; Mon, 5 Dec 2005 18:51:35 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from hoth.savecore.net (hoth.savecore.net [209.234.108.136]) by mail.netbsd.org (Postfix) with ESMTP id E646363B21E for ; Mon, 5 Dec 2005 18:51:34 +0000 (UTC) Received: from [192.168.1.101] (unknown [209.76.127.102]) by hoth.savecore.net (Postfix) with ESMTP id 090352AC40; Mon, 5 Dec 2005 10:51:23 -0800 (PST) Date: Mon, 05 Dec 2005 10:51:22 -0800 From: Frank Cusack To: ietf-ssh@NetBSD.org Cc: Martin Forssen , Jakob Schlyter , Wesley Griffin Subject: Re: collated comments for -dns (RFC 4255) and -kbdinteract (RFC 4256) Message-ID: <9E555B8C60C67EFB4571FD61@maguro.local> In-Reply-To: <20051203194819.GB28505@chiark.greenend.org.uk> References: <20051203194819.GB28505@chiark.greenend.org.uk> X-Mailer: Mulberry/4.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On December 3, 2005 7:48:19 PM +0000 Jacob Nevins wrote: > [CC'd to listed authors in the secsh-dns and secsh-kbdinteract > Internet-Drafts] > ... > Neither of these documents has been updated on ftp.rfc-editor.org for > over a month. Is anything happening with them? I repackaged your comments and sent them off to the rfc editor. There was some activity so I don't know why the edits weren't made. ... > I note that the email address for Frank Cusack in secsh-kbdinteract is > not the same as the From: header of a message recently sent to this > list. Are the contact details in these documents up-to-date? If not, > perhaps the authors haven't seen any email from the RFC Editor? > (I guess I'll find out if the email addresses bounce from the CCs of > this message.) The contacts are correct. -frank From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Dec 05 16:51:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjOFM-0005wY-HA for secsh-archive@megatron.ietf.org; Mon, 05 Dec 2005 16:51:44 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17713 for ; Mon, 5 Dec 2005 16:50:53 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 896C363B2A0; Mon, 5 Dec 2005 21:51:35 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.netbsd.org (Postfix) with ESMTP id 1E2A463B1B9 for ; Mon, 5 Dec 2005 21:51:34 +0000 (UTC) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 05 Dec 2005 13:51:34 -0800 X-IronPort-AV: i="3.99,218,1131350400"; d="scan'208"; a="681664993:sNHT33484182" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB5LpWBI010199 for ; Mon, 5 Dec 2005 13:51:32 -0800 (PST) Date: Mon, 5 Dec 2005 13:51:31 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Please review last nits I'm sending to the RFC Editor In-Reply-To: <20051203193459.GA28505@chiark.greenend.org.uk> Message-ID: References: <20051203193459.GA28505@chiark.greenend.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi Folks, I'm planning on sending these requests to the RFC Editor. Please let me know if you'd suggest any changes. Thanks, Chris === RFC 4250 [SSH-NUMBERS] 1) Section 4.5.1, first paragraph - change "a" to "an" OLD: a "pty-req" string MUST contain a 'encoded terminal modes' value. ^ NEW: a "pty-req" string MUST contain an 'encoded terminal modes' value. ^^ 2) Section 4.6.1, first paragraph - remove extraneous "a" OLD: sign ("@"), a comma (","), whitespace, control characters (ASCII ^ NEW: sign ("@"), comma (","), whitespace, control characters (ASCII 3) Section 4.8, first paragraph - Please don't split this paragraph like this across a page break. It leaves "Names." as the only word from the paragraph on the next page. 4) Section 4.9.3, table after first paragraph - Please don't split this table across a page break. 5) Section 6, references - Would you please insert a page break after Section 5 so that the references start on a new page? === RFC 4251 [SSH-ARCH] 1) Section 4.1, last paragraph - reverse wording OLD: Thus, providing the option to not check the server host key is ^^^^^^ NEW: Thus, providing the option not to check the server host key is ^^^^^^ 2) Section 4.3, third bullet in the first paragraph - modify a line OLD: depend on the location from where the user is trying to log in. ^^^^^^ NEW: depend on the location from where the user is trying to gain access. ^^^^^^^^^^^^ 3) Section 6, first bullet in second paragraph - remove extraneous "a" OLD: at-sign ("@"), a comma (","), whitespace, or control characters ^ NEW: at-sign ("@"), comma (","), whitespace, or control characters 4) Section 9.3.7, first paragraph - quote a value OLD: and diffie-hellman-group14-sha1) are secure even if private NEW: and "diffie-hellman-group14-sha1") are secure even if private 5) Section 7, Connection protocol table - Please don't split this two-line table across a page break. NEW: Connection protocol: 80 to 89 Connection protocol generic 90 to 127 Channel related messages 6) Section 10, references - Would you please insert a page break after Section 9 so that the references start on a new page? === RFC 4252 [SSH-USERAUTH] 1) Section 5, first paragraph - remove the following line The rest of the packet is method-specific. 2) Section 5.2, second paragraph - insert a word OLD: SSH_MSG_USERAUTH_FAILURE and MAY return it a list of NEW: SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of ^^^^ 3) Section 7, packet description after first paragraph - insert words OLD: string service NEW: string service name 4) Section 8, second paragraph - remove a word OLD: added to the database, or compared them (with or without hashing) to ^^^^ NEW: added to the database, or compared (with or without hashing) to 5) Section 12, references - Would you please insert a page break after Section 10 so that the references start on a new page? === RFC 4253 [SSH-TRANS] 1) Section 4.2, second paragraph - replace a word; Implementers for Implementors OLD: (ASCII 13 and 10, respectively). Implementors who wish to maintain ^^^^^^^^^^^^ NEW: (ASCII 13 and 10, respectively). Implementers who wish to maintain ^^^^^^^^^^^^ 2) Section 6.1, first paragraph - insert a word OLD: that other party is able to process them. However, implementations NEW: that the other party is able to process them. However, implementations ^^^ 3) Section 7.1, last paragraph - change a word OLD: SSH_MSG_KEXINIT messages from the other party. ^^^^^^^^ NEW: SSH_MSG_KEXINIT message from the other party. ^^^^^^^ 4) Section 5.2, fifth paragraph - change a word OLD: Implementations are expected to have some limit on the ssh transport ^^^ NEW: Implementations are expected to have some limit on the SSH transport ^^^ 5) Section 8, second paragraph with associated bullets - replace the paragraph and associated bullets - do not break the bulleted sections across page boundaries OLD: The following steps are used to exchange a key. In this, C is the client; S is the server; p is a large safe prime; g is a generator for a subgroup of GF(p); q is the order of the subgroup; V_S is S's version string; V_C is C's version string; K_S is S's public host key; I_C is C's KEXINIT message and I_S is S's KEXINIT message that have been exchanged before this part begins. 1. C generates a random number x (1 < x < q) and computes e = g^x mod p. C sends "e" to S. 2. S generates a random number y (0 < y < q) and computes f = g^y mod p. S receives "e". It computes K = e^y mod p, H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K) (these elements are encoded according to their types; see below), and signature s on H with its private host key. S sends "K_S || f || s" to C. The signing operation may involve a second hashing operation. 3. C verifies that K_S really is the host key for S (e.g., using certificates or a local database). C is also allowed to accept the key without verification; however, doing so will render the protocol insecure against active attacks (but may be desirable for practical reasons in the short term in many environments). C then computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K), and verifies the signature s on H. NEW: The following steps are used to exchange a key. In this, C is the client; S is the server; p is a large safe prime; g is a generator for a subgroup of GF(p); q is the order of the subgroup; V_S is S's identification string; V_C is C's identification string; K_S is S's public host key; I_C is C's SSH_MSG_KEXINIT message and I_S is S's SSH_MSG_KEXINIT message that have been exchanged before this part begins. 1. C generates a random number x (1 < x < q) and computes e = g^x mod p. C sends e to S. 2. S generates a random number y (0 < y < q) and computes f = g^y mod p. S receives e. It computes K = e^y mod p, H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K) (these elements are encoded according to their types; see below), and signature s on H with its private host key. S sends (K_S || f|| s) to C. The signing operation may involve a second hashing operation. 3. C verifies that K_S really is the host key for S (e.g., using certificates or a local database). C is also allowed to accept the key without verification; however, doing so will render the protocol insecure against active attacks (but may be desirable for practical reasons in the short term in many environments). C then computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K), and verifies the signature s on H. 6) Section 8, table after seventh paragraph - change words "version" to "identification" in two lines - change "NL" to "LF" in the same lines OLD: string V_C, the client's version string (CR and NL excluded) string V_S, the server's version string (CR and NL excluded) NEW: string V_C, the client's identification string (CR and LF excluded) string V_S, the server's identification string (CR and LF excluded) 7) Section 15, references - Would you please insert a page break after Section 14 so that the references start on a new page? === RFC 4254 [SSH-CONNECT] 1) Section 5.2, fifth paragraph second bullet - change a word OLD: o MUST NOT generate data packets larger that its transport layer is ^^^^ NEW: o MUST NOT generate data packets larger than its transport layer is ^^^^ 2) Section 6.10, packet description after third paragraph - remove some words OLD: string language tag as defined in [RFC3066] NEW: string language tag [RFC3066] 3) Section 6.10, fourth paragraph - do not break the hyphen segmented name "sig-name@xyz" OLD: Additional 'signal name' values MAY be sent in the format "sig- name@xyz", where "sig-name" and "xyz" may be anything a particular NEW: Additional 'signal name' values MAY be sent in the format "sig-name@xyz", where "sig-name" and "xyz" may be anything a particular ===end From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Dec 05 23:51:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjUnK-0008FQ-NJ for secsh-archive@megatron.ietf.org; Mon, 05 Dec 2005 23:51:14 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03018 for ; Mon, 5 Dec 2005 23:50:24 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 6831463B18E; Tue, 6 Dec 2005 04:51:09 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 6875063B113 for ; Tue, 6 Dec 2005 04:51:08 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8237815; Mon, 05 Dec 2005 21:51:07 -0700 Message-ID: <43951846.7060203@vandyke.com> Date: Mon, 05 Dec 2005 21:49:10 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: denis bider CC: ietf-ssh@NetBSD.org Subject: Re: SFTP ACLs need inheritance support References: <200512405718.775980@nucleus> In-Reply-To: <200512405718.775980@nucleus> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Do you think this should be added to SFTP v6, or do we need a v7? Has anyone begun implementing yet? What do others think? I did try to address the dacl presence / absence problem, but in the end, it seemed _very_ windows specific. I've started twice today to spec something out, and haven't liked what I got either time... I'm tempted to do this with an extension. What would you think of the following extension: string "win32-acl-flags" string extension-data uint32 acl-flags If the extension is not absent, then all bit values default to '0' SFX_DACL_PRESENT This bit need be set if and only if the DACL is present and empty (0 ALLOW/0 DENY entries in the ACL.) If the DACL is present and empty, this implies that no access is granted. If the DACL is not present (i.e., 0 ALLOW/0 DENY entries) this implies that access to the file is either granted to all users or governed by another mechanism, such as the permissions mask. SFX_DACL_PROTECTED If this bit is set, then the DACL may not be modified by inherited ACEs. SFX_SACL_PRESENT This bit need be set if and only if the SACL is present and empty (0 AUDIT/0 ALARM entries in the ACL.) NOTE> Does this even have significant meaning? SFX_SACL_PROTECTED If this bit is set, then the SACL may not be modified by inherited ACEs. Thanks, Joseph denis bider wrote: > Hello all, > > I believe the ACL support which SFTP has lifted from NFS v4 is insufficient. It seems as if this system was developed directly with Windows NT4 ACLs in mind. It does not support inheritance which is an important feature of NTFS file security since Windows 2000. > > To address this, I suggest the following additions to the SFTP draft: > > > 1. In the Attributes structure, in addition to the ACL string, there should be an "ACL flags" value containing any combination of the following values: > > DACL present = ... > DACL protected = ... > SACL present = ... > SACL protected = ... > > Without the DACL present and SACL present flags, there is no way for a server to know whether the client, by sending an ACL with no system audit entries, wishes to clear the SACL or leave it intact. This is important because a special privilege is required to set or clear the SACL, and this privilege is not held by regular users. An explicit flag would make it easier for the server to determine the user's intent. > > The "protected" flags are necessary to control inheritance of ACEs from the parent container. Without these flags, there is no way for the SFTP client to control ACE inheritance. > > > 2. The ACE flags need to be extended with something like "INHERITED_ACE_FLAG". When the client retrieves an ACL, this flag would be set by the server to indicate that the particular ACE entry is inherited from a parent directory. The SFTP client would > > Obviously we probably won't call this ACE4_INHERITED_ACE_FLAG, since this flag is not in NFS v4. > > > 3. Optionally, one might also choose to support "inherited from" information so that the SFTP client could be told about the source of an inherited ACE. > > > I believe these changes are necessary to implement a quality SFTP client. If these additions are not agreed to, I will have to devise a private extension for them. That will be bad for interoperability. > > If these additions are incorporated into the SFTP draft, they could be made backwards compatible by specifying the Attributes structure ACL flag as an extension. However, as far as I'm concerned, the protocol version might also be bumped up to 7; that seems a bit cleaner, but otherwise it is all the same to me. > > So, what does everyone think? > > > Best regards, > > denis > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 09:16:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejdcj-00045p-7m for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 09:16:53 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04690 for ; Tue, 6 Dec 2005 09:16:00 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 0166363B23C; Tue, 6 Dec 2005 14:16:44 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from devonshire.cnchost.com (devonshire.concentric.net [207.155.248.12]) by mail.netbsd.org (Postfix) with ESMTP id 0960263B104 for ; Tue, 6 Dec 2005 14:16:43 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by devonshire.cnchost.com id IAA24488; Tue, 6 Dec 2005 08:58:40 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: denis bider To: Joseph Galbraith , CC: X-Mailer: Barca 1.4 (1000) - Licensed Version Date: Tue, 6 Dec 2005 14:58:36 +0100 Message-ID: <2005126145836.350592@nucleus> In-Reply-To: <43951846.7060203@vandyke.com> Subject: Re: SFTP ACLs need inheritance support Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable >=A0Do you think this should be added to SFTP v6, or >=A0do we need a v7? I think the changes I recommended are central to any SFTP client or server= that implements ACLs, so I'd prefer them to be treated as such. For this= reason, I would prefer a new ACL flags field into the Attributes structure.= However, I could also live with the ACL flags field being an extension. > Has anyone begun implementing=A0yet? I will soon be done implementing the current v6 draft. Of course my= implementation already anticipates the suggested changes. >=A0I did try to address the dacl presence / absence >=A0problem, but in the end, it seemed _very_ windows >=A0specific. It doesn't seem to me that the presence/absence flag hurts people on other= platforms. Does it? From my experience at least, not having them makes it a factor of magnitude= more difficult to implement this right in Windows. >=A0What would you think of the following extension: > >=A0string "win32-acl-flags" >=A0string extension-data >=A0 uint32 acl-flags I'd remove the win32 reference. Any client or server can send this extension= if it wants to. >=A0SFX_SACL_PRESENT >=A0This bit need be set if and only if the SACL >=A0is present and empty (0 AUDIT/0 ALARM entries in >=A0the ACL.) >=A0NOTE>=A0Does this even have significant meaning? Oh, it does. Without this flag, it is very difficult for the server to know whether the= client, having sent a list of ACLs that does not include any AUDIT or ALARM= entries, wants the server to (a) clear the SACL, or (b) not touch the SACL= at all. The Windows DACL and SACL are edited separetely. Any access to the SACL= requires the SeSecurityPrivilege to be enabled, and a special access flag= to be included when the file is opened. Also, in a large majority of cases,= the user wants to modify just the DACL, not also the SACL. Suppose the client sends an ACL with no AUDIT or ALARM entries. If the= server goes ahead and tries to clear the SACL, but fails, it cannot know= whether to respond with an error (because perhaps the user wanted to clear= the SACL) or success (because perhaps the user didn't want to clear the= SACL, and doesn't have privilege to do it in the first place). Please do include also the ACE mask flag for ACCESS_SYSTEM_SECURITY. Sure,= it's Windows specific, but it improves compatibility and is very easy to= add. The spec should say that anyone who wants to read or write AUDIT or= ALARM ACEs from an opened file handle should have passed this flag when= opening the handle. Servers that have no need for this flag can simply= ignore it, as can clients that don't intend to query a Windows server for= ACLs. Best regards, denis From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 10:04:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjeMk-0001RR-SN for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 10:04:27 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10264 for ; Tue, 6 Dec 2005 10:03:34 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2783963B275; Tue, 6 Dec 2005 15:04:20 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 7624963B104 for ; Tue, 6 Dec 2005 15:04:19 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8238963; Tue, 06 Dec 2005 08:04:18 -0700 Message-ID: <4395A7FF.1060200@vandyke.com> Date: Tue, 06 Dec 2005 08:02:23 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: denis bider CC: ietf-ssh@NetBSD.org Subject: Re: SFTP ACLs need inheritance support References: <2005126145836.350592@nucleus> In-Reply-To: <2005126145836.350592@nucleus> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > Oh, it does. > > Without this flag, it is very difficult for the server to know > whether the client, having sent a list of ACLs that does not > include any AUDIT or ALARM entries, wants the server to (a) > clear the SACL, or (b) not touch the SACL at all. The Windows Okay, I see why we need this in the protocol. However, I don't think there is any difference between an empty SACL and an absent SACL like there is between a empty DACL and an absent DACL. > DACL and SACL are edited separetely. Any access to the SACL > requires the SeSecurityPrivilege to be enabled, and a special > access flag to be included when the file is opened. Also, in a > large majority of cases, the user wants to modify just the > DACL, not also the SACL. > > Suppose the client sends an ACL with no AUDIT or ALARM > entries. If the server goes ahead and tries to clear the SACL, > but fails, it cannot know whether to respond with an error > (because perhaps the user wanted to clear the SACL) or success > (because perhaps the user didn't want to clear the SACL, and > doesn't have privilege to do it in the first place). Yes, I see that. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 10:34:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjepW-0002Fk-Sm for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 10:34:11 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13739 for ; Tue, 6 Dec 2005 10:33:17 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 6AC2263B104; Tue, 6 Dec 2005 15:34:05 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 940F063B197 for ; Tue, 6 Dec 2005 15:34:04 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8239208; Tue, 06 Dec 2005 08:34:04 -0700 Message-ID: <4395AEF9.2010106@vandyke.com> Date: Tue, 06 Dec 2005 08:32:09 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: denis bider CC: ietf-ssh@NetBSD.org Subject: Re: SFTP ACLs need inheritance support References: <2005126145836.350592@nucleus> In-Reply-To: <2005126145836.350592@nucleus> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit denis bider wrote: >> Do you think this should be added to SFTP v6, or do we need >> a v7? > > I think the changes I recommended are central to any SFTP > client or server that implements ACLs, so I'd prefer them to > be treated as such. For this reason, I would prefer a new ACL > flags field into the Attributes structure. However, I could > also live with the ACL flags field being an extension. Remember, currently, the draft has no concept of DACL and SACL, and the other OS that does ACLs that I'm somewhat familiar with (VMS) does not seperate these, and so forcing them to emulate the behavior of being able to set these separately increases the complexity of their servers. Also, the meaning of a empty ACL is not universal; an empty ACL in VMS is the same as no ACL, and both mean defer to the permissions field. In NT, it an empty ACL means grant no access; an absent ACL means grant all access. I don't know if VMS supports the concept of inheritable ACLs (Richard, are you watching this thread?) And if it does, if it has a concept of "PROTECTED" like NT does. It may be that we need some increased complexity anyway to make it so that the client can predict what behavior will be if it sets an ACL with no ALLOW/DENY entries. Regardless I'm trying to balance increasing complexity for non-NT platforms with allowing NT platforms to communicate all the information needed. Using an extension, I think, accomplishes this nicely. Under NT, fetching the permissions is expensive enough that it isn't done all the time; hence the additional overhead of an extension isn't too much. I also tried to define the extension in a way such that it wouldn't need to be sent more often than not-- but given the first point, I'm not sure this is worth it. Servers that don't separate the two won't advertise the extension, and clients will know not to send them. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 11:03:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjfHj-00015P-Us for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 11:03:20 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16861 for ; Tue, 6 Dec 2005 11:02:28 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 628B163B135; Tue, 6 Dec 2005 16:03:13 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 8B79263B2A6 for ; Tue, 6 Dec 2005 16:03:12 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8239342; Tue, 06 Dec 2005 09:03:11 -0700 Message-ID: <4395B5CD.8040408@vandyke.com> Date: Tue, 06 Dec 2005 09:01:17 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: denis bider CC: ietf-ssh@NetBSD.org Subject: Re: SFTP ACLs need inheritance support References: <2005126145836.350592@nucleus> In-Reply-To: <2005126145836.350592@nucleus> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit denis bider wrote: > Please do include also the ACE mask flag for > ACCESS_SYSTEM_SECURITY. Sure, it's Windows specific, but it > improves compatibility and is very easy to add. The spec > should say that anyone who wants to read or write AUDIT or > ALARM ACEs from an opened file handle should have passed this > flag when opening the handle. Servers that have no need for > this flag can simply ignore it, as can clients that don't > intend to query a Windows server for ACLs. I'll do that. Here is what I'm planing: ACCESS_PRIV_SYSTEM_SECURITY = 0x00000200 The server should access the file in such a way the reading and writing an ACL with AUDIT/ALARM entries is permitted. Systems that don't require special privileges to write system audit or alarm events SHOULD ignore this bit during the open request. Servers that do not support AUDIT or ALARM ACE types should fail the open operation with NOT_SUPPORTED. ACCESS_PRIV_BACKUP_FILE = 0x00000400 The server should access the file in order to back it up. Servers that don't need to perform any special processing in order to gain access to a file for backup purposes should ignore this bit during an open request. ACCESS_PRIV_RESTORE_FILE = 0x00000800 The server should access the file in order to restore it. Servers that don't need to perform any special processing in order to gain access to a file for purposes of restoring from backup should ignore this bit during an open request. ACCESS_PRIV_OVERRIDE_OWNER = 0x00001000 This bit indicates that the client wishes to override the WRITE_DAC permission on the file. If the server does not support this operation, it must return NOT_SUPPORTED. If the user does not have ability to override the WRITE_DAC permission on the file, the operation should fail with ACCESS_DENIED. I choose these bits because they are still "specific bits" in the NT world of structured access masks. I'll probably also add text like this, someplace: When requesting all access to a file, a client SHOULD NOT as a matter of course include the ACCESS_PRIV_* bits. These bits should only be requested when the operation described is specifically intended. Does this fit your needs? Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 11:21:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjfZB-0000Xm-M2 for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 11:21:21 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19001 for ; Tue, 6 Dec 2005 11:20:29 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2CA3563B1B9; Tue, 6 Dec 2005 16:21:16 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from devonshire.cnchost.com (devonshire.concentric.net [207.155.248.12]) by mail.netbsd.org (Postfix) with ESMTP id 39E8D63B14F for ; Tue, 6 Dec 2005 16:21:15 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by devonshire.cnchost.com id LAA14925; Tue, 6 Dec 2005 11:21:06 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: denis bider To: Joseph Galbraith CC: X-Mailer: Barca 1.4 (1000) - Licensed Version Date: Tue, 6 Dec 2005 17:21:03 +0100 Message-ID: <200512617213.576340@nucleus> In-Reply-To: <4395A7FF.1060200@vandyke.com> Subject: Re: SFTP ACLs need inheritance support Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable >>=A0Without this flag, it is very difficult for the server to know >>=A0whether the client, having sent a list of ACLs that does not >>=A0include any AUDIT or ALARM entries, wants the server to (a) >>=A0clear the SACL, or (b) not touch the SACL at all. The Windows > >=A0Okay, I see why we need this in the protocol. >=A0However, I don't think there is any difference between >=A0an empty SACL and an absent SACL like there is between >=A0a empty DACL and an absent DACL. That is correct, in the filesystem itself, there isn't a difference between= an empty SACL and an absent SACL. I'm wondering if perhaps I should have suggested different names for the= PRESENT flags. Windows uses the SE_DACL_PRESENT and SE_SACL_PRESENT flags to describe the= actual contents of the security descriptor, e.g. as stored for a file on= disk. This maps directly to how the suggested SFX_DACL_PRESENT and= SFX_SACL_PRESENT flags would be used when sent in a STAT response from a= Windows SFTP server. However, when a Windows application modifies an existing security descriptor= for a file, it doesn't use the SE_DACL_PRESENT and SE_SACL_PRESENT control= flags in the security descriptor. Instead, there is an out-of-band= parameter to SetFileSecurity() and other functions. The parameter is named= SecurityInformation, and it dictates what portions of the security= descriptor will be modified. The defined bits for this parameter include= DACL_SECURITY_INFORMATION and SACL_SECURITY_INFORMATION. My proposal was that when the client sends a SETSTAT request to a Windows= SFTP server, the SFX_DACL_PRESENT and SFX_SACL_PRESENT flags take on the= meaning of the SecurityInformation parameter. In this case, therefore,= there is not a direct mapping to SE_DACL_PRESENT and SE_SACL_PRESENT flags.= In fact, it may be misleading that the name of the SFTP flag suggests= that. For this reason, therefore, it may be prudent to choose a third name for the= SFTP flags. Perhaps the names should be SFX_DACL_INCLUDED and= SFX_SACL_INCLUDED. We might even consider separating the "included" meaning from the "present"= meaning by defining separate flags. For example, responding to a STAT= request, the server may be able to tell the client that there is a SACL= defined, but may not be able to send the actual contents. Thus the= SFX_SACL_PRESENT flag would be on, but the SFX_SACL_INCLUDED flag would be= false. What do you think? Shall we separate the two purposes or shall we just mesh= them together, as was so far discussed? From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 11:44:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjfvE-0007Ap-QI for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 11:44:09 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21872 for ; Tue, 6 Dec 2005 11:43:17 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id BEA4D63B275; Tue, 6 Dec 2005 16:44:03 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id E926963B1C4 for ; Tue, 6 Dec 2005 16:44:02 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8239508; Tue, 06 Dec 2005 09:44:02 -0700 Message-ID: <4395BF5F.3060408@vandyke.com> Date: Tue, 06 Dec 2005 09:42:07 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: denis bider CC: ietf-ssh@NetBSD.org Subject: Re: SFTP ACLs need inheritance support References: <200512617213.576340@nucleus> In-Reply-To: <200512617213.576340@nucleus> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit denis bider wrote: >>> Without this flag, it is very difficult for the server to >>> know whether the client, having sent a list of ACLs that >>> does not include any AUDIT or ALARM entries, wants the >>> server to (a) clear the SACL, or (b) not touch the SACL at >>> all. The Windows >> Okay, I see why we need this in the protocol. However, I >> don't think there is any difference between an empty SACL >> and an absent SACL like there is between a empty DACL and an >> absent DACL. > > That is correct, in the filesystem itself, there isn't a > difference between an empty SACL and an absent SACL. > > I'm wondering if perhaps I should have suggested different > names for the PRESENT flags. > > Windows uses the SE_DACL_PRESENT and SE_SACL_PRESENT flags to > describe the actual contents of the security descriptor, e.g. > as stored for a file on disk. This maps directly to how the > suggested SFX_DACL_PRESENT and SFX_SACL_PRESENT flags would be > used when sent in a STAT response from a Windows SFTP server. > > However, when a Windows application modifies an existing > security descriptor for a file, it doesn't use the > SE_DACL_PRESENT and SE_SACL_PRESENT control flags in the > security descriptor. Instead, there is an out-of-band > parameter to SetFileSecurity() and other functions. The > parameter is named SecurityInformation, and it dictates what > portions of the security descriptor will be modified. The > defined bits for this parameter include > DACL_SECURITY_INFORMATION and SACL_SECURITY_INFORMATION. > > My proposal was that when the client sends a SETSTAT request > to a Windows SFTP server, the SFX_DACL_PRESENT and > SFX_SACL_PRESENT flags take on the meaning of the > SecurityInformation parameter. In this case, therefore, there > is not a direct mapping to SE_DACL_PRESENT and SE_SACL_PRESENT > flags. In fact, it may be misleading that the name of the SFTP > flag suggests that. > > For this reason, therefore, it may be prudent to choose a > third name for the SFTP flags. Perhaps the names should be > SFX_DACL_INCLUDED and SFX_SACL_INCLUDED. > > We might even consider separating the "included" meaning from > the "present" meaning by defining separate flags. For example, > responding to a STAT request, the server may be able to tell > the client that there is a SACL defined, but may not be able > to send the actual contents. Thus the SFX_SACL_PRESENT flag > would be on, but the SFX_SACL_INCLUDED flag would be false. > > What do you think? Shall we separate the two purposes or shall > we just mesh them together, as was so far discussed? What could a client do that is useful with the information that a SACL exists but not knowing it's contents? Unless you can think of something, I'm inclined to go the simply route. What would you think of SFX_ACL_ACCESS_CONTROL_INCLUDED and SFX_ACL_AUDIT_ALARM_INCLUDED? Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 11:46:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejfxb-00083f-RF for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 11:46:37 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22086 for ; Tue, 6 Dec 2005 11:45:45 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 6DC6363B230; Tue, 6 Dec 2005 16:46:29 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from valiant.cnchost.com (valiant.concentric.net [207.155.252.9]) by mail.netbsd.org (Postfix) with ESMTP id 72CEF63B224 for ; Tue, 6 Dec 2005 16:46:28 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by valiant.cnchost.com id LAA26871; Tue, 6 Dec 2005 11:46:26 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: denis bider To: Joseph Galbraith CC: X-Mailer: Barca 1.4 (1000) - Licensed Version Date: Tue, 6 Dec 2005 17:46:23 +0100 Message-ID: <2005126174623.897003@nucleus> In-Reply-To: <4395B5CD.8040408@vandyke.com> Subject: Re: SFTP ACLs need inheritance support Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable I think that's an excellent proposal! The backup and restore flags could prove very useful to specialized software= that performs backup over the network, as using these flags is really the= only way to backup a file with multiple streams. The "OVERRIDE_OWNER" flag appears to map directly to the WRITE_OWNER access= right, without which it is not possible for an administrator to take= ownership of an abandoned file. I think it's great that an administrator will be able to use an SFTP client= to do that! On Tue, 06 Dec 2005 09:01:17 -0700, Joseph Galbraith wrote: >=A0denis bider wrote: > >>=A0Please do include also the ACE mask flag for >>=A0ACCESS_SYSTEM_SECURITY. Sure, it's Windows specific, but it >>=A0improves compatibility and is very easy to add. The spec >>=A0should say that anyone who wants to read or write AUDIT or >>=A0ALARM ACEs from an opened file handle should have passed this >>=A0flag when opening the handle. Servers that have no need for >>=A0this flag can simply ignore it, as can clients that don't >>=A0intend to query a Windows server for ACLs. >> >=A0I'll do that. > >=A0Here is what I'm planing: > >=A0ACCESS_PRIV_SYSTEM_SECURITY =3D 0x00000200 >=A0The server should access the file in such a way the >=A0reading and writing an ACL with AUDIT/ALARM entries >=A0is permitted. > >=A0Systems that don't require special privileges to >=A0write system audit or alarm events SHOULD ignore >=A0this bit during the open request. =A0Servers that >=A0do not support AUDIT or ALARM ACE types should fail >=A0the open operation with NOT_SUPPORTED. > >=A0ACCESS_PRIV_BACKUP_FILE =A0 =A0 =3D 0x00000400 >=A0The server should access the file in order to back it up. > >=A0Servers that don't need to perform any special processing >=A0in order to gain access to a file for backup purposes >=A0should ignore this bit during an open request. > >=A0ACCESS_PRIV_RESTORE_FILE =A0 =A0=3D 0x00000800 >=A0The server should access the file in order to restore it. > >=A0Servers that don't need to perform any special processing >=A0in order to gain access to a file for purposes of restoring >=A0from backup should ignore this bit during an open request. > >=A0ACCESS_PRIV_OVERRIDE_OWNER =A0=3D 0x00001000 >=A0This bit indicates that the client wishes to override the >=A0WRITE_DAC permission on the file. =A0If the server does not >=A0support this operation, it must return NOT_SUPPORTED. > >=A0If the user does not have ability to override the >=A0WRITE_DAC permission on the file, the operation should >=A0fail with ACCESS_DENIED. > > >=A0I choose these bits because they are still "specific bits" >=A0in the NT world of structured access masks. =A0I'll probably >=A0also add text like this, someplace: > >=A0When requesting all access to a file, a client SHOULD >=A0NOT as a matter of course include the ACCESS_PRIV_* >=A0bits. =A0These bits should only be requested when the >=A0operation described is specifically intended. > >=A0Does this fit your needs? > >=A0Thanks, > >=A0Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 11:58:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejg96-0003I5-S4 for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 11:58:29 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23860 for ; Tue, 6 Dec 2005 11:57:38 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2D65163B2C9; Tue, 6 Dec 2005 16:58:26 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from valiant.cnchost.com (valiant.concentric.net [207.155.252.9]) by mail.netbsd.org (Postfix) with ESMTP id 4BA4363B224 for ; Tue, 6 Dec 2005 16:58:25 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by valiant.cnchost.com id LAA18389; Tue, 6 Dec 2005 11:58:22 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: denis bider To: Joseph Galbraith CC: X-Mailer: Barca 1.4 (1000) - Licensed Version Date: Tue, 6 Dec 2005 17:58:20 +0100 Message-ID: <2005126175820.213137@nucleus> In-Reply-To: <4395BF5F.3060408@vandyke.com> Subject: Re: SFTP ACLs need inheritance support Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable >=A0What could a client do that is useful with the information that >=A0a SACL exists but not knowing it's contents? Except that the client could hide the ability to edit the SACL for the= particular file, I can't really think of something incredibly useful. It's= just something I thought might be worth considering. >=A0What would you think of SFX_ACL_ACCESS_CONTROL_INCLUDED and >=A0SFX_ACL_AUDIT_ALARM_INCLUDED? That would be fine with me. As a bonus, it's nice that these names aren't= inherently platform-specific. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 12:07:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjgHq-0005D5-12 for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 12:07:31 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25363 for ; Tue, 6 Dec 2005 12:06:39 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id DAD7C63B18B; Tue, 6 Dec 2005 17:07:26 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 332D863B164 for ; Tue, 6 Dec 2005 17:07:26 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8239616; Tue, 06 Dec 2005 10:07:25 -0700 Message-ID: <4395C4DA.100@vandyke.com> Date: Tue, 06 Dec 2005 10:05:30 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: denis bider CC: ietf-ssh@NetBSD.org Subject: Re: SFTP ACLs need inheritance support References: <2005126175820.213137@nucleus> In-Reply-To: <2005126175820.213137@nucleus> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit denis bider wrote: >> What could a client do that is useful with the information >> that a SACL exists but not knowing it's contents? > > Except that the client could hide the ability to edit the SACL > for the particular file, I can't really think of something > incredibly useful. It's just something I thought might be > worth considering. Hmmm... but the server is likely to have to attempt to enable the privilege without even knowing if the client cares to find this out. It doesn't sound like you are strongly attached to this-- and if the client really wants to know, it can always attempt to open the file as if it were going to modify the security information itself before enabling the UI. >> What would you think of SFX_ACL_ACCESS_CONTROL_INCLUDED and >> SFX_ACL_AUDIT_ALARM_INCLUDED? > > That would be fine with me. As a bonus, it's nice that these > names aren't inherently platform-specific. That is precisely why I chose them. Explaining these names in the document is much easier (and less complicated) than explaining DACL and SACL. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 12:19:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjgTv-0004G1-42 for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 12:19:59 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27009 for ; Tue, 6 Dec 2005 12:19:07 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1F97263B1BE; Tue, 6 Dec 2005 17:19:53 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 569A563B164 for ; Tue, 6 Dec 2005 17:19:52 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8239672; Tue, 06 Dec 2005 10:19:51 -0700 Message-ID: <4395C7C4.8020303@vandyke.com> Date: Tue, 06 Dec 2005 10:17:56 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: denis bider CC: ietf-ssh@NetBSD.org Subject: Re: SFTP ACLs need inheritance support References: <2005126174623.897003@nucleus> In-Reply-To: <2005126174623.897003@nucleus> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit denis bider wrote: > I think that's an excellent proposal! > > The backup and restore flags could prove very useful to > specialized software that performs backup over the network, as > using these flags is really the only way to backup a file with > multiple streams. Hmmm... I was thinking of these as simply enabling the backup or restore privilege which bypasses access checks-- which would be highly useful for things like scanning the volume to see who is using what space-- also, if this turns on reading from the backup stream, an non-NT backup stream aware application can't use this feature. So, I'd suggest that we also have an open flag: SSH_FXF_ACCESS_BACKUP_STREAM Requests that the server return data to the read request as a structured backup stream. The format of the backup stream is system specific, but it should encode all the information that must be preserved in order to restore the file from a backup medium. The only well defined use for this data is to write it to the same server to a file also opened with this flag specified. However, if the server OS has a well defined backup stream format, it may be that there are other uses for this data outside the scope of this protocol. When this flag is present, the server expects a backup stream in the write requests. Data offsets are in the READ and WRITE packets are ignored when this flag is specified. What do you think? Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 13:13:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjhK8-0008Ij-AF for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 13:13:56 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02919 for ; Tue, 6 Dec 2005 13:13:05 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id ED0CB63B11A; Tue, 6 Dec 2005 18:13:51 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from valiant.cnchost.com (valiant.concentric.net [207.155.252.9]) by mail.netbsd.org (Postfix) with ESMTP id 6335B63B113 for ; Tue, 6 Dec 2005 18:13:51 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by valiant.cnchost.com id NAA11833; Tue, 6 Dec 2005 13:13:20 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: denis bider To: Joseph Galbraith CC: X-Mailer: Barca 1.4 (1000) - Licensed Version Date: Tue, 6 Dec 2005 19:13:17 +0100 Message-ID: <2005126191317.512252@nucleus> In-Reply-To: <4395C7C4.8020303@vandyke.com> Subject: Re: SFTP ACLs need inheritance support Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable >=A0Hmmm... I was thinking of these as simply enabling the >=A0backup or restore privilege which bypasses access >=A0checks-- which would be highly useful for things like >=A0scanning the volume to see who is using what space-- Based on my reading in the past few days (but not actual first-hand= experience), it seems that Windows always requires not just a privilege but= also a flag; i.e. the "SeSecurityPrivilege" goes hand in hand with= ACCESS_SYSTEM_SECURITY flag (one is not useful without the other), and the= "SeBackupPrivilege" goes hand in hand with the FILE_FLAG_BACKUP_SEMANTICS= flag. In other words, it is my understanding that you have to specify= FILE_FLAG_BACKUP_SEMANTICS in order to get any kind of special behavior= from Windows, and FILE_FLAG_BACKUP_SEMANTICS in turn means that you'll be= reading from the backup stream, and you can't have one without the other. My understanding may be incorrect. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 13:17:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjhNc-0001KJ-J6 for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 13:17:32 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03560 for ; Tue, 6 Dec 2005 13:16:39 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id BD46363B239; Tue, 6 Dec 2005 18:17:27 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from valiant.cnchost.com (valiant.concentric.net [207.155.252.9]) by mail.netbsd.org (Postfix) with ESMTP id 9256663B113 for ; Tue, 6 Dec 2005 18:17:26 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by valiant.cnchost.com id LAA00525; Tue, 6 Dec 2005 11:31:38 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: denis bider To: Joseph Galbraith CC: X-Mailer: Barca 1.4 (1000) - Licensed Version Date: Tue, 6 Dec 2005 17:31:35 +0100 Message-ID: <2005126173135.254310@nucleus> In-Reply-To: <4395AEF9.2010106@vandyke.com> Subject: Re: SFTP ACLs need inheritance support Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable I don't have any major complaints about including the ACL flags as an= extension to Attributes. NT4 is also a platform that supports ACLs but not inheritance. We support= it. I don't think the presence of inheritance flags hurts any platform that= doesn't support them. Such a platform can simply ignore those flags. It may however be useful if a server can advertise that it supports ACL= inheritance via the "supported2" mechanism in the version packet. What would be a good way to advertise that? On Tue, 06 Dec 2005 08:32:09 -0700, Joseph Galbraith wrote: >=A0denis bider wrote: > >>>=A0Do you think this should be added to SFTP v6, or do we need >>>=A0a v7? >>> >>=A0I think the changes I recommended are central to any SFTP >>=A0client or server that implements ACLs, so I'd prefer them to >>=A0be treated as such. For this reason, I would prefer a new ACL >>=A0flags field into the Attributes structure. However, I could >>=A0also live with the ACL flags field being an extension. >> >=A0Remember, currently, the draft has no concept of DACL >=A0and SACL, and the other OS that does ACLs that I'm >=A0somewhat familiar with (VMS) does not seperate these, >=A0and so forcing them to emulate the behavior of being >=A0able to set these separately increases the complexity >=A0of their servers. > >=A0Also, the meaning of a empty ACL is not universal; an >=A0empty ACL in VMS is the same as no ACL, and both >=A0mean defer to the permissions field. > >=A0In NT, it an empty ACL means grant no access; an >=A0absent ACL means grant all access. > >=A0I don't know if VMS supports the concept of inheritable >=A0ACLs (Richard, are you watching this thread?) =A0And if >=A0it does, if it has a concept of "PROTECTED" like NT >=A0does. > >=A0It may be that we need some increased complexity anyway >=A0to make it so that the client can predict what behavior >=A0will be if it sets an ACL with no ALLOW/DENY entries. > >=A0Regardless I'm trying to balance increasing complexity for >=A0non-NT platforms with allowing NT platforms to communicate >=A0all the information needed. > >=A0Using an extension, I think, accomplishes this nicely. >=A0Under NT, fetching the permissions is expensive enough >=A0that it isn't done all the time; hence the additional >=A0overhead of an extension isn't too much. =A0I also tried >=A0to define the extension in a way such that it wouldn't >=A0need to be sent more often than not-- but given the >=A0first point, I'm not sure this is worth it. > >=A0Servers that don't separate the two won't advertise >=A0the extension, and clients will know not to send them. > >=A0Thanks, > >=A0Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 13:39:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjhjF-0003l2-7e for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 13:39:53 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06364 for ; Tue, 6 Dec 2005 13:39:01 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 996A663B341; Tue, 6 Dec 2005 18:39:47 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from valiant.cnchost.com (valiant.concentric.net [207.155.252.9]) by mail.netbsd.org (Postfix) with ESMTP id D43C363B113 for ; Tue, 6 Dec 2005 18:39:46 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by valiant.cnchost.com id NAA01794; Tue, 6 Dec 2005 13:39:44 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: denis bider To: Joseph Galbraith CC: X-Mailer: Barca 1.4 (1000) - Licensed Version Date: Tue, 6 Dec 2005 19:39:41 +0100 Message-ID: <2005126193941.262841@nucleus> Subject: SFTP extensions draft should be submitted as working group item Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable By the way, Joseph - I think your filexfer extensions draft contains very useful extensions which= I will be implementing, or indeed already have. I think it's a pity that this draft should be lost to casual implementors= who come to the secsh working group page to get their latest SSH and SFTP= specifications. It is difficult to even know that your extensions exist= without semi-privileged knowledge. (It was published individually as= draft-galb-filexfer-extensions-00.txt.) I suggest that further iterations of the extensions draft be published as a= secsh group work item so that they will appear on the secsh group page as= one of its drafts. denis From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 13:48:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejhrw-0006W5-PS for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 13:48:52 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07646 for ; Tue, 6 Dec 2005 13:48:00 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 49BF263B1A1; Tue, 6 Dec 2005 18:48:48 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 8897663B113 for ; Tue, 6 Dec 2005 18:48:47 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8240007; Tue, 06 Dec 2005 11:48:46 -0700 Message-ID: <4395DC9C.30709@vandyke.com> Date: Tue, 06 Dec 2005 11:46:52 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: denis bider CC: ietf-ssh@NetBSD.org Subject: Re: SFTP ACLs need inheritance support References: <2005126191317.512252@nucleus> In-Reply-To: <2005126191317.512252@nucleus> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit denis bider wrote: >> Hmmm... I was thinking of these as simply enabling the >> backup or restore privilege which bypasses access checks-- >> which would be highly useful for things like scanning the >> volume to see who is using what space-- > > Based on my reading in the past few days (but not actual > first-hand experience), it seems that Windows always requires > not just a privilege but also a flag; i.e. the > "SeSecurityPrivilege" goes hand in hand with > ACCESS_SYSTEM_SECURITY flag (one is not useful without the > other), and the "SeBackupPrivilege" goes hand in hand with the > FILE_FLAG_BACKUP_SEMANTICS flag. > > In other words, it is my understanding that you have to > specify FILE_FLAG_BACKUP_SEMANTICS in order to get any kind of > special behavior from Windows, and FILE_FLAG_BACKUP_SEMANTICS > in turn means that you'll be reading from the backup stream, > and you can't have one without the other. FILE_FLAG_BACKUP_SEMANTIC in combination with SeBackupPrivilege bypasses the read access checks in the filesystem. It doesn't require you to use BackupRead() or BackupWrite() to my knowledge-- in other words, it is perfectly reasonable to open a file file FILE_FLAG_BACKUP_SEMANTIC and still call ReadFile/WriteFile. So in fact, if an application wanted to make tar file backups using the SFTP protocol, it could do so by specifying ACCESS_PRIV_BACKUP_FILE but not specifying SSH_FXF_ACCESS_BACKUP_STREAM. However, if ACCESS_PRIV_BACKUP_FILE implied that READ and WRITE data should return the backup stream (which it would have to in order to backup alternate data streams) it would no longer be possible to do a tar file backup. Thanks, Joseph PS. I'm tempted, as a win32 extension, to allow a file to be opened as a directory in order to enumerate the named streams. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 13:51:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjhuG-00073I-MV for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 13:51:16 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07818 for ; Tue, 6 Dec 2005 13:50:24 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 43BA363B239; Tue, 6 Dec 2005 18:51:13 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 8FB6963B113 for ; Tue, 6 Dec 2005 18:51:12 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8239992; Tue, 06 Dec 2005 11:51:11 -0700 Message-ID: <4395DD2D.3040305@vandyke.com> Date: Tue, 06 Dec 2005 11:49:17 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: denis bider CC: ietf-ssh@NetBSD.org Subject: Re: SFTP extensions draft should be submitted as working group item References: <2005126193941.262841@nucleus> In-Reply-To: <2005126193941.262841@nucleus> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit denis bider wrote: > By the way, Joseph - > > I think your filexfer extensions draft contains very useful extensions which I will be implementing, or indeed already have. > > I think it's a pity that this draft should be lost to casual implementors who come to the secsh working group page to get their latest SSH and SFTP specifications. It is difficult to even know that your extensions exist without semi-privileged knowledge. (It was published individually as draft-galb-filexfer-extensions-00.txt.) > > I suggest that further iterations of the extensions draft be published as a secsh group work item so that they will appear on the secsh group page as one of its drafts. I would like to do that... I'm not sure if Bill will accept a consensus of two or three though :-) I've been tempted to post and ask whether we want to keep it as a separate working group draft or roll it back in to the main draft. Thanks, Joseph PS. In terms of time lines, I believe that we are getting very close to being ready to call the SFTP draft done. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 13:54:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejhxr-0001Lz-IP for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 13:54:59 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08180 for ; Tue, 6 Dec 2005 13:54:06 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 55F8563B124; Tue, 6 Dec 2005 18:54:55 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from beacon.PSC.process.com (beacon.psc.process.com [192.42.95.237]) by mail.netbsd.org (Postfix) with ESMTP id 5E37863B113 for ; Tue, 6 Dec 2005 18:54:54 +0000 (UTC) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: SFTP extensions draft should be submitted as working group item Date: Tue, 6 Dec 2005 13:58:25 -0500 Message-ID: <3EF96AF20489A34296050FBD5C36ECB91885D7@beacon.PSC.process.com> Thread-Topic: SFTP extensions draft should be submitted as working group item Thread-Index: AcX6loqmgUYA3JU5RPew5aVcW+NNaQAAGEeg From: "Richard Whalen" To: "Joseph Galbraith" , "denis bider" Cc: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable I think that the filexfer extensions draft should be a working group = item and should remain a separate draft. I suggested that the extensions be a separate item so that the filexfer = draft could stabilize and proceed without the interference of new = extensions being added. Richard Whalen -----Original Message----- From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org]On Behalf Of Joseph Galbraith Sent: Tuesday, December 06, 2005 1:49 PM To: denis bider Cc: ietf-ssh@netbsd.org Subject: Re: SFTP extensions draft should be submitted as working group item denis bider wrote: > By the way, Joseph - >=20 > I think your filexfer extensions draft contains very useful extensions = which I will be implementing, or indeed already have. >=20 > I think it's a pity that this draft should be lost to casual = implementors who come to the secsh working group page to get their = latest SSH and SFTP specifications. It is difficult to even know that = your extensions exist without semi-privileged knowledge. (It was = published individually as draft-galb-filexfer-extensions-00.txt.) >=20 > I suggest that further iterations of the extensions draft be published = as a secsh group work item so that they will appear on the secsh group = page as one of its drafts. I would like to do that... I'm not sure if Bill will accept a consensus of two or three though :-) I've been tempted to post and ask whether we want to keep it as a separate working group draft or roll it back in to the main draft. Thanks, Joseph PS. In terms of time lines, I believe that we are getting very close to being ready to call the SFTP draft done. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 14:39:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejiev-0001xr-Fi for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 14:39:29 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12919 for ; Tue, 6 Dec 2005 14:38:37 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 76A3363B124; Tue, 6 Dec 2005 19:39:25 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from valiant.cnchost.com (valiant.concentric.net [207.155.252.9]) by mail.netbsd.org (Postfix) with ESMTP id B8FB063B132 for ; Tue, 6 Dec 2005 19:39:24 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by valiant.cnchost.com id OAA20468; Tue, 6 Dec 2005 14:39:19 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: denis bider To: Joseph Galbraith CC: X-Mailer: Barca 1.4 (1000) - Licensed Version Date: Tue, 6 Dec 2005 20:39:13 +0100 Message-ID: <2005126203913.624222@nucleus> In-Reply-To: <4395DC9C.30709@vandyke.com> Subject: Re: SFTP ACLs need inheritance support Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable >=A0FILE_FLAG_BACKUP_SEMANTIC in combination with >=A0SeBackupPrivilege bypasses the read access checks >=A0in the filesystem. > >=A0It doesn't require you to use BackupRead() or BackupWrite() >=A0to my knowledge-- in other words, it is perfectly >=A0reasonable to open a file file FILE_FLAG_BACKUP_SEMANTIC >=A0and still call ReadFile/WriteFile. Ah, indeed, I got BackupRead() and the effects of FILE_FLAG_BACKUP_SEMANTICS= mixed up. Therefore ACCESS_PRIV_BACKUP_FILE means the server will open the file with= FILE_FLAG_BACKUP_SEMANTICS, and SSH_FXF_ACCESS_BACKUP_STREAM means the= server will I/O with BackupRead() / BackupWrite(). That sounds great,= then! Best regards denis From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 15:28:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjjQi-00073Z-Nn for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 15:28:52 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18235 for ; Tue, 6 Dec 2005 15:28:00 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 7E55763B27B; Tue, 6 Dec 2005 20:28:48 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from valiant.cnchost.com (valiant.concentric.net [207.155.252.9]) by mail.netbsd.org (Postfix) with ESMTP id DCC9263B132 for ; Tue, 6 Dec 2005 20:28:47 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by valiant.cnchost.com id PAA16231; Tue, 6 Dec 2005 15:28:45 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: denis bider To: Joseph Galbraith CC: X-Mailer: Barca 1.4 (1000) - Licensed Version Date: Tue, 6 Dec 2005 21:28:41 +0100 Message-ID: <2005126212841.396855@nucleus> In-Reply-To: <4395DD2D.3040305@vandyke.com> Subject: clarifications for SFTP extensions draft Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Hello all, I feel that the SFTP extensions draft is in places underspecified. For example, it is not explicitly stated what kind of an extension= "vendor-id" is. Is this extension included in the server's VERSION packet?= The specification doesn't say so; one might even be lead to think that it's= a response to an SSH_FXP_EXTEND packet that must be sent by the client. How does the server advertise that it supports the "check file" extension?= There are two possible request names: "check-file-name" and= "check-file-handle". In the "supported2" VERSION extension, should the= server advertise "check-file", "check-file-name", "check-file-handle", or a= combination thereof? Does it make sense for the server to implement only= check-file-name, but not also check-file-handle? (My preference - the= server should advertise "check-file" and support both.) Why does the "check file" reply include the string "check-file"? The format= of SSH_FXP_EXTENDED_REPLY does not require any such string; the response= should be traced back to the original request by ID. Also, no such extra= string is specified for "space-available". However, there is such an extra= string in the reply for "home-directory". Unless someone already has a= fielded implementation, I suggest that we get rid of these while there is= time. Best regards, denis From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 15:44:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejjg4-0004eP-Gl for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 15:44:44 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20320 for ; Tue, 6 Dec 2005 15:43:52 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 47D7A63B2B3; Tue, 6 Dec 2005 20:44:40 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from valiant.cnchost.com (valiant.concentric.net [207.155.252.9]) by mail.netbsd.org (Postfix) with ESMTP id AC21B63B2AE for ; Tue, 6 Dec 2005 20:44:39 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by valiant.cnchost.com id PAA13440; Tue, 6 Dec 2005 15:44:36 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: denis bider To: Joseph Galbraith CC: X-Mailer: Barca 1.4 (1000) - Licensed Version Date: Tue, 6 Dec 2005 21:44:32 +0100 Message-ID: <2005126214432.082645@nucleus> In-Reply-To: <2005126212841.396855@nucleus> Subject: Re: clarifications for SFTP extensions draft Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable On Tue, 6 Dec 2005 21:28:41 +0100, denis bider wrote: >=A0For example, it is not explicitly stated what kind of an extension >=A0"vendor-id" is. Is this extension included in the server's VERSION >=A0packet? The specification doesn't say so; one might even be lead to >=A0think that it's a response to an SSH_FXP_EXTEND packet that must be >=A0sent by the client. Also, the spec says that the client MAY send the "vendor-id" as an= SSH_FXP_EXTEND request to the server. The specification should specify the= exact encoding of the request in this case, and should also determine how= the server needs to respond to such a request. Does it send SSH_FXP_STATUS= with SSH_FX_OK? Should it respond with SSH_FXP_EXTENDED_REPLY, perhaps= re-sending its own vendor ID? Or does it simply ignore it? These questions aren't answered by the current draft. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 15:49:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjjkS-0006Cz-Ah for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 15:49:16 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20705 for ; Tue, 6 Dec 2005 15:48:23 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 6D76363B2D7; Tue, 6 Dec 2005 20:49:12 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 0D85163B2D0 for ; Tue, 6 Dec 2005 20:49:11 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8240452; Tue, 06 Dec 2005 13:49:10 -0700 Message-ID: <4395F8D4.1020204@vandyke.com> Date: Tue, 06 Dec 2005 13:47:16 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: denis bider CC: ietf-ssh@NetBSD.org Subject: Re: SFTP ACLs need inheritance support References: <2005126173135.254310@nucleus> In-Reply-To: <2005126173135.254310@nucleus> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit denis bider wrote: > I don't have any major complaints about including the ACL > flags as an extension to Attributes. > > NT4 is also a platform that supports ACLs but not inheritance. > We support it. > > I don't think the presence of inheritance flags hurts any > platform that doesn't support them. Such a platform can simply > ignore those flags. Hmm... well, lets try a proposal that doesn't use extensions, and see how it comes out -- folks, let me know what you think! ACE uint32 ace-type uint32 ace-flag uint32 ace-mask string who [UTF-8] ACL uint32 acl-flags uint32 ace-count ACE ace[ace-count] acl-flags indicates information about the ACL as a whole. SFX_ACL_ACCESS_CONTROL_INCLUDED = 0x00000001 SFX_ACL_ACCESS_CONTROL_PRESENT = 0x00000002 SFX_ACL_CONTROL_INHERITED = 0x00000004 If INCLUDE is set during a setstat operation, then the client intends to modify the ALLOWED/DENIED entries of the ACL. Otherwise, the client intends for these entries to be preserved. If the PRESENT bit is not set, then the client wishes to remove control entries. If the server doesn't support separate control and audit information, the client MUST not clear this bit without also clearing the AUDIT_ALARM_PRESENT bit. If the PRESENT bit is clear, then control of the file MAY be through the permissions mask. The server MAY also grant full access to the file. If the both the INCLUDE and the PRESENT bit are set, but their are no ALLOW/DENY entries in the list, the client wishes to deny all access to the file or directory. The server may have to transform this into a ACL with a deny entry to implement it. If INHERITED is set, then ALLOW/DENY ACEs MAY be inherited from the parent directory. If it is off, then they MUST not be INHERITED. If the server does not support controlling inheritance, then the client MUST clear this bit; in this case the inheritance properties of the server are undefined. SFX_ACL_AUDIT_ALARM_INCLUDED = 0x00000010 SFX_ACL_AUDIT_ALARM_INHERITED = 0x00000020 If INCLUDE is set during a setstat operation, then the client intends to modify the AUDIT/ALARM entries of the ACL. Otherwise, the client intends for these entries to be preserved. If INHERITED is set, then AUDIT/ALARM ACEs MAY be inherited from the parent directory. If it is off, then they MUST not be INHERITED. If the server does not support controlling inheritance, then the client MUST clear this bit; in this case the inheritance properties of the server are undefined. Because some server require special permissions / privileges in order to modify the AUDIT/ALARM entries in the ACL, it is important to communicate to the server the clients intent to modify these entries. The client MUST both use the ACCESS_AUDIT_ALARM_ATTRIBUTES bit in the desired attribute of the open request and must set the SFX_ACL_AUDIT_ALARM_INCLUDED during the setstat operation. Clients that do not intend specifically to modify the AUDIT or ALARM entries SHOULD NOT request ACCESS_PRIV_ACCESS_AUDIT_ALARM_ATTRIBUTES access and SHOULD NOT set the SFX_ACL_AUDIT_ALARM_INCLUDED bit because these operations are often privileged and will fail. If the SFX_ACL_AUDIT_ALARM_INCLUDED is set, and the requested change can not be made, the server MUST fail the request. -- I believe rather than access flags, it makes more sense to do these as open flags (since they can't be set in a ACL): SSH_FXF_ACCESS_AUDIT_ALARM_INFORMATION = 0x00001000 This bit indicates that the client wishes the server to enable any privileges or extra capabilities that the user may have in to allow the reading and writing of AUDIT or ALARM access control entries. SSH_FXF_ACCESS_BACKUP = 0x00002000 This bit indicates that the client wishes the server to enable any privileges or extra capabilities that the user may have in order to bypass normal access checks for the purpose of backing up or restoring files. SSH_FXF_ACCESS_BACKUP_STREAM = 0x00004000 This bit indicates that the client wishes to read or write a backup stream. A backup stream is a system dependent structured data stream that encodes all the information that must be preserved in order to restore the file from backup medium. The only well defined use for backup stream data read in this fashion is to write it to the same server to a file also opened using the BACKUP_STREAM flag. However, if the server has a well defined backup stream format, their may be other uses for this data outside the scope of this protocol. ACCESS_OVERRIDE_OWNER = 0x00008000 This bit indicates that the client wishes the server to enable any privileges or extra capabilities that the user may have in order to gain access to the file with WRITE_OWNER permission. This bit MUST always be specified in combination with ACE4_WRITE_OWNER. > It may however be useful if a server can advertise that it > supports ACL inheritance via the "supported2" mechanism in the > version packet. > > What would be a good way to advertise that? Unfortunately people (myself included) have already implemented and shipped "supported2" -- the "supported2" and the "vendor-id" seem to be pretty popular :-) I'd suggest the following: "acl-supported" uint32 capabilities ACL_CAP_ALLOW = 0x00000001 ACL_CAP_DENY = 0x00000002 ACL_CAP_AUDIT = 0x00000004 ACL_CAP_ALARM = 0x00000008 The client may use the associated ACE type. ACL_CAP_INHERIT_ACCESS = 0x00000010 ACL_CAP_INHERIT_AUDIT_ALARM = 0x00000020 If these bits are clear, the SFX_ACL_INHERIT_* flags must be false. ACL_CAP_SEPERATES_AUDIT_AND_CONTROL = 0x00000040 If this bit is clear, then either both SFX_ACL_INHERIT_ bits must bet set or both must be clear. This is also true for the SFX_ACL_*_INCLUDED bits. What do you think? Thanks, Joseph > On Tue, 06 Dec 2005 08:32:09 -0700, Joseph Galbraith wrote: >> denis bider wrote: >> >>>> Do you think this should be added to SFTP v6, or do we >>>> need a v7? >>>> >>> I think the changes I recommended are central to any SFTP >>> client or server that implements ACLs, so I'd prefer them >>> to be treated as such. For this reason, I would prefer a >>> new ACL flags field into the Attributes structure. >>> However, I could also live with the ACL flags field being >>> an extension. >>> >> Remember, currently, the draft has no concept of DACL and >> SACL, and the other OS that does ACLs that I'm somewhat >> familiar with (VMS) does not seperate these, and so forcing >> them to emulate the behavior of being able to set these >> separately increases the complexity of their servers. >> >> Also, the meaning of a empty ACL is not universal; an empty >> ACL in VMS is the same as no ACL, and both mean defer to the >> permissions field. >> >> In NT, it an empty ACL means grant no access; an absent ACL >> means grant all access. >> >> I don't know if VMS supports the concept of inheritable ACLs >> (Richard, are you watching this thread?) And if it does, if >> it has a concept of "PROTECTED" like NT does. >> >> It may be that we need some increased complexity anyway to >> make it so that the client can predict what behavior will be >> if it sets an ACL with no ALLOW/DENY entries. >> >> Regardless I'm trying to balance increasing complexity for >> non-NT platforms with allowing NT platforms to communicate >> all the information needed. >> >> Using an extension, I think, accomplishes this nicely. Under >> NT, fetching the permissions is expensive enough that it >> isn't done all the time; hence the additional overhead of an >> extension isn't too much. I also tried to define the >> extension in a way such that it wouldn't need to be sent >> more often than not-- but given the first point, I'm not >> sure this is worth it. >> >> Servers that don't separate the two won't advertise the >> extension, and clients will know not to send them. >> >> Thanks, >> >> Joseph > > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 16:04:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejjyy-0004Ds-LD for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 16:04:16 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22146 for ; Tue, 6 Dec 2005 16:03:24 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id AAF2663B2E7; Tue, 6 Dec 2005 21:04:08 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id D9E4A63B2D0 for ; Tue, 6 Dec 2005 21:04:07 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8240500; Tue, 06 Dec 2005 14:04:06 -0700 Message-ID: <4395FC54.7080909@vandyke.com> Date: Tue, 06 Dec 2005 14:02:12 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: denis bider CC: ietf-ssh@NetBSD.org Subject: Re: clarifications for SFTP extensions draft References: <2005126214432.082645@nucleus> In-Reply-To: <2005126214432.082645@nucleus> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit denis bider wrote: > On Tue, 6 Dec 2005 21:28:41 +0100, denis bider wrote: >> For example, it is not explicitly stated what kind of an >> extension "vendor-id" is. Is this extension included in the >> server's VERSION packet? The specification doesn't say so; >> one might even be lead to think that it's a response to an >> SSH_FXP_EXTEND packet that must be sent by the client. It is both. The server sends it in it's version packet, the client sends it as a SSH_FXP_EXTENDED packet. > Also, the spec says that the client MAY send the "vendor-id" > as an SSH_FXP_EXTEND request to the server. The specification > should specify the exact encoding of the request in this case, > and should also determine how the server needs to respond to > such a request. Does it send SSH_FXP_STATUS with SSH_FX_OK? > Should it respond with SSH_FXP_EXTENDED_REPLY, perhaps > re-sending its own vendor ID? Or does it simply ignore it? > > These questions aren't answered by the current draft. When it is sent as a SSH_FXP_EXTENDED packet, the contents vendor-structure becomes the extension specific data: byte SSH_FXP_EXTENDED uint32 request-id string "vendor-id" string vendor-name [UTF-8] string product-name [UTF-8] string product-version [UTF-8] uint64 product-build-number The server responds with a status packet, which should always be SSH_FX_OK. I will clarify this. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 16:13:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejk7k-0007ec-UI for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 16:13:20 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23175 for ; Tue, 6 Dec 2005 16:12:28 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1F0C763B2AE; Tue, 6 Dec 2005 21:13:17 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 68F6763B285 for ; Tue, 6 Dec 2005 21:13:16 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1Ejk7f-0002dg-00 for ietf-ssh@netbsd.org; Tue, 06 Dec 2005 21:13:15 +0000 Date: Tue, 6 Dec 2005 21:13:15 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: Please review last nits I'm sending to the RFC Editor Message-ID: <20051206211314.GA16961@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Chris Lonvick writes: > I'm planning on sending these requests to the RFC Editor. Please let me > know if you'd suggest any changes. Another trivia review: > === > RFC 4253 [SSH-TRANS] [...] > 4) > Section 5.2, fifth paragraph > - change a word > OLD: > Implementations are expected to have some limit on the ssh transport > ^^^ > NEW: > Implementations are expected to have some limit on the SSH transport > ^^^ This edit is in the wrong section; it should be against RFC 4254 [SSH-CONNECT]. > 5) > Section 8, second paragraph with associated bullets > - replace the paragraph and associated bullets > - do not break the bulleted sections across page boundaries [...] > NEW: [...] > (K_S || f|| s) to C. The signing operation may involve a ^^ Missing space. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 16:11:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejk5a-00073P-FF for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 16:11:06 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22893 for ; Tue, 6 Dec 2005 16:10:12 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 63B7863B2D0; Tue, 6 Dec 2005 21:11:00 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id A7ECF63B117 for ; Tue, 6 Dec 2005 21:10:59 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8240539; Tue, 06 Dec 2005 14:10:59 -0700 Message-ID: <4395FDF1.7050901@vandyke.com> Date: Tue, 06 Dec 2005 14:09:05 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: denis bider CC: ietf-ssh@NetBSD.org Subject: Re: clarifications for SFTP extensions draft References: <2005126212841.396855@nucleus> In-Reply-To: <2005126212841.396855@nucleus> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit denis bider wrote: > Hello all, > > I feel that the SFTP extensions draft is in places > underspecified. > > [...] > > How does the server advertise that it supports the "check > file" extension? There are two possible request names: > "check-file-name" and "check-file-handle". In the "supported2" > VERSION extension, should the server advertise "check-file", > "check-file-name", "check-file-handle", or a combination > thereof? Does it make sense for the server to implement only > check-file-name, but not also check-file-handle? (My > preference - the server should advertise "check-file" and > support both.) I think I would put them both in-- it is the simplest most straight forward way. If you or someone else felt strongly about it though, I'd be willing to specify the "check-file" is the alias for both of these. > Why does the "check file" reply include the string > "check-file"? The format of SSH_FXP_EXTENDED_REPLY does not > require any such string; the response should be traced back to > the original request by ID. Also, no such extra string is > specified for "space-available". However, there is such an > extra string in the reply for "home-directory". Unless someone > already has a fielded implementation, I suggest that we get > rid of these while there is time. Well, last time I did an extension w/o the string someone (I don't recall) really really really really badly wanted the string in the reply too... I'm more than happy to take it out. In fact, unless someone screams bloody murder, I'm taking it out. In fact, I've removed them from my local source, and also specified the vendor-id thing in my local source. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 20:15:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejntr-0000lX-T0 for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 20:15:15 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16862 for ; Tue, 6 Dec 2005 20:14:22 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 201B263B35C; Wed, 7 Dec 2005 01:15:11 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from valiant.cnchost.com (valiant.concentric.net [207.155.252.9]) by mail.netbsd.org (Postfix) with ESMTP id 64BDF63B117 for ; Wed, 7 Dec 2005 01:15:10 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by valiant.cnchost.com id UAA07192; Tue, 6 Dec 2005 20:15:08 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: denis bider To: Joseph Galbraith CC: X-Mailer: Barca 1.4 (1000) - Licensed Version Date: Wed, 7 Dec 2005 02:15:03 +0100 Message-ID: <20051272153.050483@nucleus> In-Reply-To: <4395F8D4.1020204@vandyke.com> Subject: Re: SFTP ACLs need inheritance support Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable >=A0What do you think? That seems quite exhaustive! All the right ingredients are there, I'm just not yet 100% about the text= (the MUSTs and SHOULDs). I have to look at that from an implementor's= perspective, and it's too late for that today. If you don't hear otherwise from me tomorrow, I'm fine with the text. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 20:11:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjnqB-0007ZX-C2 for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 20:11:27 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16437 for ; Tue, 6 Dec 2005 20:10:35 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 8F2E263B350; Wed, 7 Dec 2005 01:11:21 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from valiant.cnchost.com (valiant.concentric.net [207.155.252.9]) by mail.netbsd.org (Postfix) with ESMTP id BCAAB63B117 for ; Wed, 7 Dec 2005 01:11:20 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by valiant.cnchost.com id UAA04094; Tue, 6 Dec 2005 20:11:13 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: denis bider To: Joseph Galbraith CC: X-Mailer: Barca 1.4 (1000) - Licensed Version Date: Wed, 7 Dec 2005 02:11:08 +0100 Message-ID: <20051272118.705639@nucleus> In-Reply-To: <4395FDF1.7050901@vandyke.com> Subject: Re: clarifications for SFTP extensions draft Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable >=A0If you or someone else felt strongly=A0about it though, > I'd be willing to specify the "check-file"=A0is the alias > for both of these. Well, I'd actually like to require the server that if it supports one, it= must support both. It seems trivial for a server to implement both versions= (the only difference is it has to explicitly open the file in the= check-file-name case), and adaptation is tricky for the client if it finds= that the server supports "check-file-handle" but not "check-file-name", for= example. I think we should classify both types of the request as "check-file" and say= explicitly that people should advertise exactly that, no variations. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 20:24:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejo2L-0004ua-CU for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 20:24:01 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17946 for ; Tue, 6 Dec 2005 20:23:09 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2B45063B1C8; Wed, 7 Dec 2005 01:23:57 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 7154A63B132 for ; Wed, 7 Dec 2005 01:23:56 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8241279; Tue, 06 Dec 2005 18:23:55 -0700 Message-ID: <4396393A.3040705@vandyke.com> Date: Tue, 06 Dec 2005 18:22:02 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: denis bider CC: ietf-ssh@NetBSD.org Subject: Re: clarifications for SFTP extensions draft References: <20051272118.705639@nucleus> In-Reply-To: <20051272118.705639@nucleus> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit denis bider wrote: >> If you or someone else felt strongly about it though, I'd be >> willing to specify the "check-file" is the alias for both of >> these. > > Well, I'd actually like to require the server that if it > supports one, it must support both. It seems trivial for a > server to implement both versions (the only difference is it > has to explicitly open the file in the check-file-name case), > and adaptation is tricky for the client if it finds that the > server supports "check-file-handle" but not "check-file-name", > for example. Well, there is one other difference: check-file-handle has to honor the SSH_FXF_ACCESS_TEXT_MODE flag. But it still seems reasonable to require support for both. I'll make this change. > I think we should classify both types of the request as > "check-file" and say explicitly that people should advertise > exactly that, no variations. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 06 20:27:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejo5Z-00068J-5o for secsh-archive@megatron.ietf.org; Tue, 06 Dec 2005 20:27:21 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18186 for ; Tue, 6 Dec 2005 20:26:29 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 0A3FC63B132; Wed, 7 Dec 2005 01:27:18 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 63A4063B117 for ; Wed, 7 Dec 2005 01:27:17 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8241261; Tue, 06 Dec 2005 18:27:16 -0700 Message-ID: <43963A03.6090800@vandyke.com> Date: Tue, 06 Dec 2005 18:25:23 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: denis bider CC: ietf-ssh@NetBSD.org Subject: Re: SFTP ACLs need inheritance support References: <20051272153.050483@nucleus> In-Reply-To: <20051272153.050483@nucleus> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit denis bider wrote: >> What do you think? > > That seems quite exhaustive! Yes... I've discovered that if I'm not exhaustive, one server does one thing and another does it a little different... one of the things I've been aiming for in the later SFTP drafts is a determistic behavior out of servers. I.e., it either happens the way the client wants or it fails :-) > All the right ingredients are there, I'm just not yet 100% > about the text (the MUSTs and SHOULDs). I have to look at that > from an implementor's perspective, and it's too late for that > today. > > If you don't hear otherwise from me tomorrow, I'm fine with > the text. All right, if I don't here from you tomorrow, I'll try to integrate this into the draft source. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Dec 07 21:17:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkBLi-000355-Ft for secsh-archive@megatron.ietf.org; Wed, 07 Dec 2005 21:17:36 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10521 for ; Wed, 7 Dec 2005 21:16:41 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id D316A63B2E1; Thu, 8 Dec 2005 02:17:27 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ajax.cnchost.com (ajax.cnchost.com [207.155.248.31]) by mail.netbsd.org (Postfix) with ESMTP id 1C50863B2DA for ; Thu, 8 Dec 2005 02:17:27 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by ajax.cnchost.com id TAA27715; Wed, 7 Dec 2005 19:46:45 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: denis bider To: Joseph Galbraith CC: X-Mailer: Barca 1.4 (1000) - Licensed Version Date: Thu, 8 Dec 2005 01:46:41 +0100 Message-ID: <200512814641.276363@nucleus> Subject: end-of-list in SSH_FXP_NAME Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Hi folks, for the end-of-list field in SSH_FXP_NAME, the draft says: "This field is= optional. If present in the packet, it MUST be true." I think this is, well, stupid. (?) Without this requirement, SSH_FXP_NAME= could be extended in the future with extra fields that older= implementations would ignore. But *with* this requirement, the packet is= not extensible, because now you can't add anything new to the end of the= packet without also including end-of-list, which "MUST be true". It seems to me that there would be no harm in letting the end-of-list flag= be false. It would allow room for future extension if necessary. Best regards, denis From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Dec 07 21:34:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkBbs-0006Mc-I7 for secsh-archive@megatron.ietf.org; Wed, 07 Dec 2005 21:34:16 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11988 for ; Wed, 7 Dec 2005 21:33:23 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 79A6D63B2E7; Thu, 8 Dec 2005 02:34:13 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id D35F463B2E1 for ; Thu, 8 Dec 2005 02:34:12 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8244907; Wed, 07 Dec 2005 19:34:11 -0700 Message-ID: <43979B35.6040003@vandyke.com> Date: Wed, 07 Dec 2005 19:32:21 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: denis bider CC: ietf-ssh@NetBSD.org Subject: Re: end-of-list in SSH_FXP_NAME References: <200512814641.276363@nucleus> In-Reply-To: <200512814641.276363@nucleus> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit denis bider wrote: > Hi folks, > > for the end-of-list field in SSH_FXP_NAME, the draft says: > "This field is optional. If present in the packet, it MUST be > true." > > I think this is, well, stupid. (?) Without this requirement, > SSH_FXP_NAME could be extended in the future with extra fields > that older implementations would ignore. But *with* this > requirement, the packet is not extensible, because now you > can't add anything new to the end of the packet without also > including end-of-list, which "MUST be true". > > It seems to me that there would be no harm in letting the > end-of-list flag be false. It would allow room for future > extension if necessary. Good point. I'll change that. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Dec 08 18:02:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUmV-00068e-1j for secsh-archive@megatron.ietf.org; Thu, 08 Dec 2005 18:02:31 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03297 for ; Thu, 8 Dec 2005 18:01:32 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 8539863B19B; Thu, 8 Dec 2005 23:02:04 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from tonnant.cnchost.com (tonnant.concentric.net [207.155.248.72]) by mail.netbsd.org (Postfix) with ESMTP id CA12663B199 for ; Thu, 8 Dec 2005 23:02:03 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by tonnant.cnchost.com id SAA29074; Thu, 8 Dec 2005 18:01:48 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: denis bider To: Joseph Galbraith CC: X-Mailer: Barca 1.4 (1000) - Licensed Version Date: Fri, 9 Dec 2005 00:01:45 +0100 Message-ID: <20051290145.312671@nucleus> In-Reply-To: <43979B35.6040003@vandyke.com> Subject: SFTP needs copying functionality Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable One other thing. I think the SFTP protocol is seriously missing a way to copy data on the= server without having to download it to the client and upload it back to= the server. At the very least, I think there needs to be a copy request that will make a= straightforward copy of file A to file B, with some very basic flags such= as whether to overwrite when file B is already present. A close second requirement is for an ability to concatenate files. We can go at this in multiple ways. One would be to provide separate= requests for each type of copy or append that we can envision. However, how about we provide a way to instruct the server to copy data= between two open file handles? This could be a request such as the following: SSH_FXP_COPY uint32 request-id string read-from-handle string write-to-handle uint64 read-from-offset uint64 read-from-length uint64 write-to-offset That's all that is needed. Now the client can open the source file, open or create the target file, and= copy data without having to download it in a gazillion separate packets and= upload it back to the server. How does that sound? Best regards! denis From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Dec 09 17:41:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekqvq-0003sA-1r for secsh-archive@megatron.ietf.org; Fri, 09 Dec 2005 17:41:38 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21836 for ; Fri, 9 Dec 2005 17:40:43 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3A25263B111; Fri, 9 Dec 2005 22:41:28 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id 62A2363B207 for ; Fri, 9 Dec 2005 22:41:26 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa02259; 9 Dec 2005 15:40 EST Date: Fri, 09 Dec 2005 15:40:26 -0500 From: Jeffrey Hutzelman To: Richard Whalen , Joseph Galbraith , denis bider cc: ietf-ssh@NetBSD.org Subject: RE: SFTP extensions draft should be submitted as working group item Message-ID: <3594A00117A23113D0460C8C@sirius.fac.cs.cmu.edu> In-Reply-To: <3EF96AF20489A34296050FBD5C36ECB91885D7@beacon.PSC.process.com> References: <3EF96AF20489A34296050FBD5C36ECB91885D7@beacon.PSC.process.com> Originator-Info: login-token=Mulberry:01UNErRLo5oLicHKPFg09bs+dDYm/XBaS9RlmphlE=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tuesday, December 06, 2005 01:58:25 PM -0500 Richard Whalen wrote: > I think that the filexfer extensions draft should be a working group item > and should remain a separate draft. > > I suggested that the extensions be a separate item so that the filexfer > draft could stabilize and proceed without the interference of new > extensions being added. I'm not sure if I care whether all the extensions work happens. I certainly don't object to it. But like Richard, I think it should remain a separate draft. It seems like every time I turn around, someone is suggesting adding yet another complex feature to SFTP. Often the argument is "when applications do XXX to a file in the filesystem, they need semantics YYY, so we should make sure sftp can provide those semantics". I'm sorry, but I guess I was under the impression that SFTP was intended to be a "Secure File Transfer Protocol", not a network filesystem. Filesystems are fun, but they're also hugely complex and, I dare say, not within the charter of the Secure Shell working group. Can we _please_ finish a standards-track _File Transfer_ protocol before we spend any more time specifying a complete filesystem? -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Dec 09 18:20:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkrWx-00032n-3y for secsh-archive@megatron.ietf.org; Fri, 09 Dec 2005 18:20:00 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25938 for ; Fri, 9 Dec 2005 18:18:59 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 216B263B28D; Fri, 9 Dec 2005 23:19:50 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 5922563B111 for ; Fri, 9 Dec 2005 23:19:49 +0000 (UTC) Received: from [127.0.0.1] (HELO gt) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 8251505; Fri, 09 Dec 2005 16:19:48 -0700 Message-ID: <028801c5fd17$08e64130$6401a8c0@gt> From: "Jeff P. Van Dyke" To: "Jeffrey Hutzelman" , "Richard Whalen" , "Joseph Galbraith" , "denis bider" Cc: References: <3EF96AF20489A34296050FBD5C36ECB91885D7@beacon.PSC.process.com> <3594A00117A23113D0460C8C@sirius.fac.cs.cmu.edu> Subject: Re: SFTP extensions draft should be submitted as working group item Date: Fri, 9 Dec 2005 16:19:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > On Tuesday, December 06, 2005 01:58:25 PM -0500 Richard Whalen > wrote: > >> I think that the filexfer extensions draft should be a working group item >> and should remain a separate draft. >> >> I suggested that the extensions be a separate item so that the filexfer >> draft could stabilize and proceed without the interference of new >> extensions being added. > > I'm not sure if I care whether all the extensions work happens. I > certainly don't object to it. But like Richard, I think it should remain a > separate draft. > > > It seems like every time I turn around, someone is suggesting adding yet > another complex feature to SFTP. Often the argument is "when applications > do XXX to a file in the filesystem, they need semantics YYY, so we should > make sure sftp can provide those semantics". > > I'm sorry, but I guess I was under the impression that SFTP was intended to > be a "Secure File Transfer Protocol", not a network filesystem. > Filesystems are fun, but they're also hugely complex and, I dare say, not > within the charter of the Secure Shell working group. > > Can we _please_ finish a standards-track _File Transfer_ protocol before we > spend any more time specifying a complete filesystem? I too would like to see it finished. Having said that, I've never been convinced that SFTP was a Secure File Transfer Protocol... it doesn't even have PUT and GET like FTP. Because one must use read and write, it is harder than it should be to implement simple transfers where both sides are 100% sure that a whole file has been transferred (as opposed to part of a file). --Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Dec 09 21:53:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkurV-0000bS-QE for secsh-archive@megatron.ietf.org; Fri, 09 Dec 2005 21:53:39 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01110 for ; Fri, 9 Dec 2005 21:52:22 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2415B63B1FC; Sat, 10 Dec 2005 02:53:03 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from devonshire.cnchost.com (devonshire.concentric.net [207.155.248.12]) by mail.netbsd.org (Postfix) with ESMTP id 7309763B1F4 for ; Sat, 10 Dec 2005 02:53:02 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by devonshire.cnchost.com id VAA19439; Fri, 9 Dec 2005 21:52:47 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: denis bider To: "Jeff P. Van Dyke" , Jeffrey Hutzelman , Richard Whalen , Joseph Galbraith , denis bider CC: X-Mailer: Barca 1.4 (1000) - Licensed Version Date: Sat, 10 Dec 2005 03:52:44 +0100 Message-ID: <2005121035244.458721@nucleus> In-Reply-To: <028801c5fd17$08e64130$6401a8c0@gt> Subject: Re: SFTP extensions draft should be submitted as working group item Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable >=A0Because=A0one must use read and write, it is harder than it > should be to=A0implement simple transfers where both sides > are 100% sure that a whole file has been=A0transferred >=A0(as opposed to part of a file). That is precisely it, SFTP is NOT a file transfer protocol, it is a remote= filesystem protocol, and the SFTP acronym is just a totally misleading= name. People come to us all the time with the preconception that SFTP is FTP over= an SSH connection. But it isn't, and I, for one, find this architectural= decision welcome. On the other hand, indeed, it makes it a bit more= difficult to define what an "upload" and what a "download" is, but I don't= consider that a major problem. I find Jeffrey's frustration understandable, but I think we have potentially= the best, the cleanest and most straightforward remote file access protocol= on our hands. It requires a few more tweaks to be complete, and I find that= all these latest tweaks that were made were necessary. Now we can either= specify a few simple tweaks, or botch that and leave those things= unspecified, resulting in a standardization void, an implementation chaos= and new standardization efforts attempting to fix that in 10 years' time. I'm fine if OpenSSH doesn't see the need to implement anything other than= SFTP version 3. That's totally OK with me, because you know what? It makes= it that much easier to compete with them on quality. But I, for one, find= the additions of the latest SFTP versions - ACLs, the check-file request= that's in the extensions draft, the TEXTMODE flag, the REALPATH behavior= change - quite necessary if SFTP is to become a universally useful network= protocol. And that is something I want it to be. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Dec 12 02:54:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EliVX-0004Kz-HL for secsh-archive@megatron.ietf.org; Mon, 12 Dec 2005 02:54:04 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12651 for ; Mon, 12 Dec 2005 02:53:06 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id AD6F463B268; Mon, 12 Dec 2005 07:53:54 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chico.itss.auckland.ac.nz (unknown [130.216.190.12]) by mail.netbsd.org (Postfix) with ESMTP id E9D6963B10C for ; Mon, 12 Dec 2005 07:53:53 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id 8A7F133E79; Mon, 12 Dec 2005 20:34:14 +1300 (NZDT) Received: from chico.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12770-22; Mon, 12 Dec 2005 20:34:14 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (unknown [130.216.33.152]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id 08BDA33E8A; Mon, 12 Dec 2005 20:34:08 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id BBFDD37743; Mon, 12 Dec 2005 20:34:08 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1EliCN-00058i-00; Mon, 12 Dec 2005 20:34:15 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: galb-list@vandyke.com, ietf-ssh@denisbider.com, jhutz@cmu.edu, jpv@vandyke.com, Whalenr@process.com Subject: Re: SFTP extensions draft should be submitted as working group item Cc: ietf-ssh@NetBSD.org In-Reply-To: <2005121035244.458721@nucleus> Message-Id: Date: Mon, 12 Dec 2005 20:34:15 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list denis bider writes: >That is precisely it, SFTP is NOT a file transfer protocol, it is a remote >filesystem protocol, and the SFTP acronym is just a totally misleading name. Hmm, I'm sure there are many who would want to dispute that :-). When asked to describe it, I've always referred to it as "An RPC mechanism for the Posix filesystem API". However virtually everyone I've ever talked to about it has seen it as "FTP with extras". So I think the SFTP name is accurate, it's all the additional cruft that's missing the point. Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Dec 12 03:53:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EljRK-0000Z1-4p for secsh-archive@megatron.ietf.org; Mon, 12 Dec 2005 03:53:59 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18984 for ; Mon, 12 Dec 2005 03:52:41 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id CA28063B2E8; Mon, 12 Dec 2005 08:53:02 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.mindrot.org (fuyu.mindrot.org [203.217.30.81]) by mail.netbsd.org (Postfix) with ESMTP id EE6C063B2DB for ; Mon, 12 Dec 2005 08:53:01 +0000 (UTC) Received: from [172.29.84.3] (unknown [172.29.84.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.mindrot.org (Postfix) with ESMTP id 1D87817E603; Mon, 12 Dec 2005 19:30:01 +1100 (EST) Message-ID: <439D3507.4010407@mindrot.org> Date: Mon, 12 Dec 2005 19:29:59 +1100 From: Damien Miller User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051123) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Gutmann CC: galb-list@vandyke.com, ietf-ssh@denisbider.com, jhutz@cmu.edu, jpv@vandyke.com, Whalenr@process.com, ietf-ssh@NetBSD.org Subject: Re: SFTP extensions draft should be submitted as working group item References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Peter Gutmann wrote: > denis bider writes: > > >>That is precisely it, SFTP is NOT a file transfer protocol, it is a remote >>filesystem protocol, and the SFTP acronym is just a totally misleading name. > > > Hmm, I'm sure there are many who would want to dispute that :-). When asked > to describe it, I've always referred to it as "An RPC mechanism for the Posix > filesystem API". The later drafts present an ad-hoc selection of features and semantics from the filesystem APIs of _several_ operating systems assembled without the architectual coherence of NFSv4. > So I think the SFTP name is accurate, it's all > the additional cruft that's missing the point. Agree 100%. -d From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 13 08:15:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em9zy-0002jx-5H for secsh-archive@megatron.ietf.org; Tue, 13 Dec 2005 08:15:21 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21361 for ; Tue, 13 Dec 2005 08:14:20 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 6F46863B4A7; Tue, 13 Dec 2005 13:15:02 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from marlborough.cnchost.com (marlborough.concentric.net [207.155.248.14]) by mail.netbsd.org (Postfix) with ESMTP id AB16F63B3DB for ; Tue, 13 Dec 2005 13:15:01 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by marlborough.cnchost.com id IAA25361; Tue, 13 Dec 2005 08:10:03 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: denis bider To: Damien Miller , Peter Gutmann CC: , , , , , X-Mailer: Barca 1.4 (1000) - Licensed Version Date: Tue, 13 Dec 2005 14:10:01 +0100 Message-ID: <2005121314101.074983@nucleus> In-Reply-To: <439D3507.4010407@mindrot.org> Subject: Re: SFTP extensions draft should be submitted as working group item Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable >>>=A0That is precisely it, SFTP is NOT a file transfer protocol, >>> it=A0is a remote=A0filesystem protocol, and the SFTP acronym is >>> just a totally=A0misleading name. >>=A0Hmm, I'm sure there are many who would want to dispute that :-). >>=A0When asked=A0to describe it, I've always referred to it as "An RPC >> mechanism=A0for the Posix=A0filesystem API". >> >=A0The later drafts present an ad-hoc selection of features and >=A0semantics=A0from the filesystem APIs of _several_ operating systems > assembled=A0without the architectual coherence of NFSv4. > >>=A0So I think the SFTP name is accurate, it's all >>=A0the additional cruft that's missing the point. >> >=A0Agree 100%. It is easy to see how someone who's environment is Unix will perceive= everything that departs from the POSIX filesystem API as "cruft". Of= course, if one works in an environment where 99% of the time the POSIX= interface has everything, all those additions are pointless. For people on other platforms though, the POSIX interface may only be= satisfactory 70% or less of the time. To people on such platforms, those= additions are important and make all the sense in the world. And non-POSIX= platforms are NOT in minority in the world! We need an SFTP that is useful across platforms. What's needed is something= less complex than NFS, but also something more complete than SFTP version= 3. I don't care for the "architectural coherence of NFSv4" if its= architecture is such that it's a pain to adapt for use over SSH. Why else= doesn't anyone implement an SSH+NFS server? There is a middle ground, and we need a protocol that will be there. It's not bad to have multiple designs for perhaps somewhat similar things.= It's evolution; the most useful design wins. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Dec 19 14:34:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoQm2-00016I-EM for secsh-archive@megatron.ietf.org; Mon, 19 Dec 2005 14:34:18 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01909 for ; Mon, 19 Dec 2005 14:33:14 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2CF4463B4B3; Mon, 19 Dec 2005 19:34:12 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by mail.netbsd.org (Postfix) with ESMTP id E66ED63B2A5 for ; Mon, 19 Dec 2005 19:34:10 +0000 (UTC) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from draco.cus.cam.ac.uk ([131.111.8.18]:54828) by ppsw-1.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.131]:25) with esmtp id 1EoPxl-0005ci-3L (Exim 4.54) for ietf-ssh@netbsd.org (return-path ); Mon, 19 Dec 2005 18:42:21 +0000 Received: from bjh21 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 4.60) (envelope-from ) id 1EoPxk-0002p0-OP; Mon, 19 Dec 2005 18:42:20 +0000 Date: Mon, 19 Dec 2005 18:42:20 +0000 (GMT) From: Ben Harris To: iesg@ietf.org, ietf-ssh@NetBSD.org Subject: draft-harris-ssh-rsa-kex Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list I've just sent off draft-harris-ssh-rsa-kex to . This should address all the concerns I've heard about, updates my postal address, and changes the e-mail address to a temporary disposable one for the time being. Detailed responses to comments follow. Scott Hollenback wrote: > Section 4: How many bits are in the "byte" data type? Is the > "string" data type null-terminated or not? I checked both > draft-ietf-secsh-assignednumbers and draft-ietf-secsh-transport to > see if they included normative definitions, but they appear to use > the same data types without providing a definition. > > Stated generically, where are the normative definitions for the > data types used in this document? I believe this is resolved by a new reference to draft-ietf-secsh-architecture in section 2. Russ Housley wrote: > The security considerations say: > > > > K, the random integer generated by the client, is the only secret > > shared by client and server. Thus its entropy directly determines > > the security of the session against eavesdropping. > > > Please point to RFC 4086 for guidance on generation of random values. Done. > Also, why is the random value and integer? draft-ietf-secsh-transport, section 7.2, states: Encryption keys MUST be computed as HASH of a known value and K as follows: o Initial IV client to server: HASH(K || H || "A" || session_id) (Here K is encoded as mpint and "A" as byte and session_id as raw data. "A" means the single character A, ASCII 65). K can only be encoded as an mpint if it's an integer. > I believe that the key is the > secret input to the SSH key derivation function. Finally, please > point out that the client has complete control over the secret value > that is used. The server does not provide any entropy. The penultimate paragraph of section 8 should cover this. In particular, it states: Unlike the Diffie-Hellman key exchange method defined by [I-D.ietf- secsh-transport], this method allows the client to fully determine the shared secret, K. Elwyn Davies wrote: > -secsh-assignments specifies the numbers defined in this range in > -secsh-transport but allows the numbers to be overloaded. Is it the > intention that future names/numbers in this range should be registered > with IANA even though it may not be strictly necessary? No. That was an error in -assignednumbers, and has been fixed in the RFC-Editor draft of RFC 4250. > s1: It might be useful to mention that the terminology and abbreviations > (such as K_S) are mostly taken from the -secsh-transport draft. I've added that to section 2. > s3: Might be useful to introduce the K_S notation for the server host > key here, if only to make it absolutely clear that it isn't the same as K_T. I think the reference in section 2 should be sufficient. > s3: It would be useful to point to s8 of -secsh-transport for the > mechanisms used for verifying the host key. Done (the reference to -transport was there already, but I've added a section number. > s4, para 1: s/, which are defined by the method name/that are specified, > fixed values defined for each method name/ I've rewritten this entirely. I think it's rather clearer now. > s4: There should be a note pointing to -secsh-architecture regarding how > the message contents are specified. I think that's covered by my new "other terminology" note in section 2. > s4: Generation of K: I would prefer (2*HLEN) to 2HLEN in the > specification of the range for K. > > Appendix A: The previous comment applies to 4 places in Appendix A also. All changed. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Dec 19 17:15:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoTI6-00049n-OF for secsh-archive@megatron.ietf.org; Mon, 19 Dec 2005 17:15:34 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22227 for ; Mon, 19 Dec 2005 17:14:31 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 7000363B19C; Mon, 19 Dec 2005 22:15:29 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by mail.netbsd.org (Postfix) with ESMTP id B504E63B18C for ; Mon, 19 Dec 2005 22:15:28 +0000 (UTC) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from draco.cus.cam.ac.uk ([131.111.8.18]:57295) by ppsw-1.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.131]:25) with esmtp id 1EoTHy-0000xd-4f (Exim 4.54) for ietf-ssh@netbsd.org (return-path ); Mon, 19 Dec 2005 22:15:26 +0000 Received: from bjh21 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 4.60) (envelope-from ) id 1EoTHy-0004CQ-1J; Mon, 19 Dec 2005 22:15:26 +0000 Date: Mon, 19 Dec 2005 22:15:26 +0000 (GMT) From: Ben Harris To: Sam Hartman cc: iesg@ietf.org, ietf-ssh@NetBSD.org Subject: Re: draft-harris-ssh-rsa-kex In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, 19 Dec 2005, Sam Hartman wrote: > Ben, I'm a bit concerned that you may have changed too much. I'll go > look at the diffs, but I may ask you to back out some changes if I > think they will require a second last call. That's fine. I'm not wedded to any of the changes (well, apart from the update of my postal address). -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Dec 19 21:34:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoXKU-0002Yj-Md for secsh-archive@megatron.ietf.org; Mon, 19 Dec 2005 21:34:18 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25412 for ; Mon, 19 Dec 2005 21:33:14 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2188663B43F; Tue, 20 Dec 2005 02:34:13 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by mail.netbsd.org (Postfix) with ESMTP id 85F5C63B437 for ; Tue, 20 Dec 2005 02:34:12 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 16EE1E0070; Mon, 19 Dec 2005 17:02:27 -0500 (EST) To: Ben Harris Cc: iesg@ietf.org, ietf-ssh@NetBSD.org Subject: Re: draft-harris-ssh-rsa-kex References: From: Sam Hartman Date: Mon, 19 Dec 2005 17:02:27 -0500 In-Reply-To: (Ben Harris's message of "Mon, 19 Dec 2005 18:42:20 +0000 (GMT)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list Ben, I'm a bit concerned that you may have changed too much. I'll go look at the diffs, but I may ask you to back out some changes if I think they will require a second last call. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 20 06:59:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eog9H-0000zS-9T for secsh-archive@megatron.ietf.org; Tue, 20 Dec 2005 06:59:20 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17013 for ; Tue, 20 Dec 2005 06:58:15 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5998063B104; Tue, 20 Dec 2005 11:59:15 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mss-de950fd1a83 (unknown [219.134.253.251]) by mail.netbsd.org (Postfix) with ESMTP id F296463B100 for ; Tue, 20 Dec 2005 11:59:12 +0000 (UTC) From: "Steven" Subject: $3.9 High quality digitizing To: ietf-ssh@NetBSD.org Content-Type: text/plain Reply-To: Steven.lee@micolong.com Date: Tue, 20 Dec 2005 19:59:12 +0800 X-Priority: 3 Message-Id: <20051220115912.F296463B100@mail.netbsd.org> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hello, Merry Christmas! High quality digitizing offered here, with $3.9 per 1,000 stitches for digitizing service with the following: 1. High quality for digitizing 2. Competitive price: $ 3.9 per 1,000 stitches, and includes a digital sew out . 3. Free 2,000 stitches for first order 4. No min. charge 5.All orders are delivered via email ( please indicate the wide¡¢material¡¢where will be embroidered) 6.normal turnaround time is 48 hours , urgent order is no additional fee too. 7. Free format change (DST, EXP, CND, EMB, etc) 8.Payment is easy, all by Pay Pal. If you are interested, welcome email to the following: Steven.Lee@micolong.com Steven.Lee88@163.com Looking forward to hearing from you soon. Steven Lee Sales Manager Micolong Manufacture Ltd. www.micolong.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Dec 22 12:53:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpUdb-000553-LA for secsh-archive@megatron.ietf.org; Thu, 22 Dec 2005 12:53:59 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12155 for ; Thu, 22 Dec 2005 12:52:53 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 34F2A63B28E; Thu, 22 Dec 2005 17:45:03 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sankara1.bol.com.br (sankara1.bol.com.br [200.221.24.109]) by mail.netbsd.org (Postfix) with ESMTP id D15C163B3D4 for ; Thu, 22 Dec 2005 17:44:31 +0000 (UTC) Received: from localhost (unknown [172.26.20.43]) by sankara1.bol.com.br (Postfix) with ESMTP id 13DE5781F for ; Thu, 22 Dec 2005 15:13:08 -0200 (BRST) X-Sender: cadas2005@bol.com.br From: Mariana Costa To: ietf-ssh@NetBSD.org Date: Thu, 22 Dec 2005 14:12:52 -0300 Subject: =?iso-8859-1?Q?2.000_Modelos_de_Cartas_Comerciais_-_Avisos,_Convites,_Propostas,_Contratos,_Agradecimentos,_Emprego_(Solicita=E7=E3o,_Apresenta=E7=E3o,_Demiss=E3o),_Vendas,_Cobran=E7as,_Pedidos,_Atestados,_Documentos,_Declara=E7=E3o,_Procura=E7=E3o,_P=EAsames,_Batizados,_etc.?= MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Sender-IP: 201.8.153.9 Message-Id: <20051222171308.13DE5781F@sankara1.bol.com.br> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA12155 Modelos prontos de cartas e e-mails comerciais. Visite o site: http://www.gueb.de/cartascomerciais E veja alguns dos modelos abaixo: * Agradecimentos e condol=EAncias * Atestados e Declara=E7=F5es * Cartas de Cobran=E7as * Cartas de Reclama=E7=E3o * Cartas em Ingl=EAs * Comunicados e Avisos * Convites * Documentos * Emprego * Propostas * Solicita=E7=F5es e pedidos * Viagem Procura=E7=E3o Carta de Recomenda=E7=E3o Convite para Exposi=E7=E3o ou Feira =20 AGRADECIMENTOS E CONDOL=CANCIAS =95 Agradecimento de convite e felicita=E7=F5es; =95 Agradecimento e convite para solenidade; =95 Agradecimento de mensagem de p=EAsames; =95 Agradecimento de pedido; =95 Agradecimento e boas vindas a cliente novo; =95 Agradecimento por mensagem de felicita=E7=E3o; =95 Confraterniza=E7=E3o; =95 Congratula=E7=F5es; =95 Cumprimentos por resultados comerciais; =95 Felicita=E7=F5es pessoais; =95 P=EAsames; =95 Votos de boas festas=20 Voltar ao topo =20 http://www.gueb.de/cartascomerciais CARTAS DE RECLAMA=C7=C3O =95 Reclama=E7=E3o de compra de produto; =95 Reclama=E7=E3o por atraso; =95 Reclama=E7=E3o por aumento de pre=E7o; =95 Reclama=E7=E3o por defici=EAncia t=E9cnica; =95 Reclama=E7=E3o por demora na entrega; =95 Reclama=E7=E3o por diverg=EAncia; =95 Respostas a reclama=E7=F5es; Voltar ao topo COMUNICADOS E AVISOS =95 Advert=EAncia a funcion=E1rio; =95 Aviso de aumento de pre=E7os; =95 Aviso de incorpora=E7=E3o da empresa; =95 Aviso de lan=E7amento de produto e servi=E7o; =95 Aviso de mudan=E7a de endere=E7o; =95 Aviso de ocorr=EAncia de acidente; =95 Aviso de t=E9rmino de contrato; =95 Aviso gen=E9rico; =95 Comunica=E7=E3o de atraso no envio de mercadorias; =95 Comunica=E7=E3o de devolu=E7=E3o de duplicata; =95 Comunica=E7=E3o de devolu=E7=E3o de mercadoria; =95 Comunica=E7=E3o de envio de mercadorias; =95 Comunica=E7=E3o de envio de parte do pedido; =95 Comunica=E7=E3o de extravio de mercadorias; =95 Comunica=E7=E3o de f=E9rias coletivas; =95 Comunica=E7=E3o de liquida=E7=E3o de d=E9bito; =95 Comunica=E7=E3o de novo servi=E7o de televendas; =95 Comunica=E7=E3o de reuni=E3o; =95 Confirma=E7=E3o de pedido; =95 Resposta ao comunicado de reuni=E3o;=20 Voltar ao topo http://www.gueb.de/cartascomerciais EMPREGO =95 Aviso pr=E9vio de dispensa de empregado: 1, 2, e 3; =95 Carta de recomenda=E7=E3o; =95 Pedido de demiss=E3o: 1 e 2; =95 Solicita=E7=E3o de emprego: 1, 2 e 3; =95 Solicita=E7=E3o de est=E1gio;=20 Voltar ao topo ATESTADOS E DECLARA=C7=D5ES =95 Atestado de bons antecedentes; =95 Atestado m=E9dico; =95 Declara=E7=E3o negativa de v=EDnculo empregat=EDcio; =95 Declara=E7=E3o para cancelamento de protesto; =95 Declara=E7=E3o para fins escolares; Voltar ao topo CARTAS DE COBRAN=C7A =95 Cartas de cobran=E7a: 1, 2, 3, 4, 5, 6, 7 e 8; =95 Encaminhamento de cobran=E7a a protesto; =95 Oferecimento de servi=E7o de cobran=E7a; =95 Recebimento de d=E9bito pendente; Voltar ao topo CARTAS EM INGL=CAS =95 Cancelamento de pedido; =95 Carta de demiss=E3o; =95 Carta de refer=EAncia; =95 Curriculum vitae; =95 Pedido de produto: 1 e 2; =95 Reclama=E7=E3o de assinatura de publica=E7=E3o; =95 Remessa de valores; =95 Resposta a pedido de produto; =95 Resposta a solicita=E7=E3o de emprego; =95 Resposta a solicita=E7=E3o de informa=E7=F5es; =95 Resposta a solicita=E7=E3o de pre=E7os; =95 Solicita=E7=E3o de emprego; =95 Solicita=E7=E3o de informa=E7=F5es comerciais; =95 Solicita=E7=E3o de licen=E7a; =95 Solicita=E7=E3o de pre=E7os;=20 Voltar ao topo CONVITES http://www.gueb.de/cartascomerciais =95 Convite para batizado; =95 Convite para evento social; =95 Convite para exposi=E7=E3o ou feira; =95 Convite para lan=E7amento de produto; =95 Resposta negativa a convite; =95 Resposta positiva a convite;=20 Voltar ao topo DOCUMENTOS =95 Ata; =95 Contrato de loca=E7=E3o de im=F3vel; =95 Contrato firmado acordo; =95 Contrato social; =95 Edital de convoca=E7=E3o; =95 Procura=E7=E3o; =95 Recibo de venda de autom=F3vel;=20 Voltar ao topo PROPOSTAS =95 Proposta de abertura de conta corrente; =95 Proposta de presta=E7=E3o de servi=E7os: 1 e 2; =95 Proposta de representa=E7=E3o comercial: 1 e 2; =95 Proposta para ocupa=E7=E3o de cargo; =95 Proposta para recupera=E7=E3o de clientes; =95 Resposta negativa =E0 proposta de representa=E7=E3o: 1 e 2; =95 Resposta positiva =E0 proposta de representa=E7=E3o: 1 e 2;=20 Voltar ao topo http://www.gueb.de/cartascomerciais SOLICITA=C7=D5E E PEDIDOS =95 Pedido de desculpas; =95 Pedido de mercadorias; =95 Resposta a pedido de carta de apresenta=E7=E3o; =95 Resposta a solicita=E7=E3o de c=F3pias de documentos; =95 Resposta a solicita=E7=E3o de or=E7amento; =95 Resposta negativa a solicita=E7=E3o de informa=E7=F5es comerciais; =95 Resposta positiva a solicita=E7=E3o de informa=E7=F5es comerciais; =95 Solicita=E7=E3o de atestado de Idoneidade Financeira; =95 Solicita=E7=E3o de cat=E1logos de pre=E7os; =95 Solicita=E7=E3o de cr=E9dito; =95 Solicita=E7=E3o de informa=E7=F5es comerciais; =95 Solicita=E7=E3o de informa=E7=F5es sobre curso; =95 Solicita=E7=E3o de listas de pre=E7os; =95 Solicita=E7=F5es de refer=EAncias pessoais; =95 Suspens=E3o de pedido de mercadoria; Voltar ao topo VIAGEM =95 Informa=E7=F5es sobre requisitos de viagem; =95 Pedido de reserva em hotel; =95 Recupera=E7=E3o de bagagem extraviada; =95 Reclama=E7=E3o de maus tratos =E0 bagagem; =95 Recupera=E7=E3o de objeto esquecido em hotel; =95 Reserva de passagens; =95 Roteiro tur=EDstico.=20 http://www.gueb.de/cartascomerciais From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 27 12:21:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErIWD-0007Sz-EL for secsh-archive@megatron.ietf.org; Tue, 27 Dec 2005 12:21:49 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16345 for ; Tue, 27 Dec 2005 12:20:39 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 7FE7B63B37A; Tue, 27 Dec 2005 17:21:31 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 9538F63B379 for ; Tue, 27 Dec 2005 17:21:30 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1ErIVt-0006iA-00 for ietf-ssh@netbsd.org; Tue, 27 Dec 2005 17:21:29 +0000 Date: Tue, 27 Dec 2005 17:21:29 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: Please review last nits I'm sending to the RFC Editor Message-ID: <20051227172129.GB21631@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051206211314.GA16961@chiark.greenend.org.uk> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list In the core drafts (RFC4250-4254) currently at , the edits discussed here have been made correctly. FWIW, there are a couple of extra edits wrt the versions available at 2005-11-30: dates have been changed from November to December (they'll need changing again at this rate...) and Tatu's address has changed. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 27 12:36:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErIkH-0001OE-0L for secsh-archive@megatron.ietf.org; Tue, 27 Dec 2005 12:36:21 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18581 for ; Tue, 27 Dec 2005 12:35:10 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 41BD863B1A4; Tue, 27 Dec 2005 17:36:18 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 90B5563B193 for ; Tue, 27 Dec 2005 17:36:17 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1ErIkC-0001sq-00 for ietf-ssh@netbsd.org; Tue, 27 Dec 2005 17:36:16 +0000 Date: Tue, 27 Dec 2005 17:36:16 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: collated comments for -dns (RFC 4255) and -kbdinteract (RFC 4256) Message-ID: <20051227173616.GC21631@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9E555B8C60C67EFB4571FD61@maguro.local> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Frank Cusack writes: > I repackaged your comments and sent them off to the rfc editor. There > was some activity so I don't know why the edits weren't made. A new 4256 (-kbdinteract) draft was posted around 14 December, doing s/November/December/ as for other drafts and removing Frank's postal address. However, the edits alluded to above have still not been made. (4255, -dns, has also been updated with the date change.) From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 27 12:44:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErIrw-0002tj-44 for secsh-archive@megatron.ietf.org; Tue, 27 Dec 2005 12:44:16 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19596 for ; Tue, 27 Dec 2005 12:43:05 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 26C0A63B33D; Tue, 27 Dec 2005 17:44:13 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 7764763B193 for ; Tue, 27 Dec 2005 17:44:12 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1ErIrr-0004IN-00 for ietf-ssh@netbsd.org; Tue, 27 Dec 2005 17:44:11 +0000 Date: Tue, 27 Dec 2005 17:44:11 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: Core IDs - last review Message-ID: <20051227174411.GD21631@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051204213241.GA1390@chiark.greenend.org.uk> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list I wrote: > I see the IANA registry at > hasn't been updated > yet (to remove KEXDH_*, spki-sign-* and so on). There's a new (19 Dec) version. It removes KEXDH_*. However: * spki-sign-* are still present; * the reference for TTY_OP_END has not been corrected; * "keyboard-interactive" is still missing. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 27 14:10:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErKDr-0007yj-Hs for secsh-archive@megatron.ietf.org; Tue, 27 Dec 2005 14:10:59 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01260 for ; Tue, 27 Dec 2005 14:09:50 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id DDC6963B36F; Tue, 27 Dec 2005 19:08:56 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sankara2.bol.com.br (sankara2.bol.com.br [200.221.24.89]) by mail.netbsd.org (Postfix) with ESMTP id 69FEA63B332 for ; Tue, 27 Dec 2005 19:08:47 +0000 (UTC) Received: from localhost (unknown [172.26.20.44]) by sankara2.bol.com.br (Postfix) with ESMTP id 910B3777E for ; Tue, 27 Dec 2005 16:02:48 -0200 (BRST) X-Sender: cadas2005@bol.com.br From: Julian Souza To: ietf-ssh@NetBSD.org Date: Tue, 27 Dec 2005 15:02:43 -0300 Subject: Cartas Comerciais MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Sender-IP: 201.8.230.205 Message-Id: <20051227180248.910B3777E@sankara2.bol.com.br> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA01260 Cartas Comerciais. Modelos prontos de cartas e e-mails comerciais. Visite= o site: http://www.gueb.de/cartascomerciais Cartas Comerciais, E veja alguns dos modelos abaixo: http://www.gueb.de/cartascomerciais * Agradecimentos e condol=EAncias * Atestados e Declara=E7=F5es * Cartas de Cobran=E7as * Cartas de Reclama=E7=E3o * Cartas em Ingl=EAs * Comunicados e Avisos * Convites * Documentos * Emprego * Propostas * Solicita=E7=F5es e pedidos * Viagem Cartas Comerciais Procura=E7=E3o Carta de Recomenda=E7=E3o Convite para Exposi=E7=E3o ou Feira Cartas Comerciais AGRADECIMENTOS E CONDOL=CANCIAS =95 Agradecimento de convite e felicita=E7=F5es; =95 Agradecimento e convite para solenidade; =95 Agradecimento de mensagem de p=EAsames; =95 Agradecimento de pedido; =95 Agradecimento e boas vindas a cliente novo; =95 Agradecimento por mensagem de felicita=E7=E3o; =95 Confraterniza=E7=E3o; =95 Congratula=E7=F5es; =95 Cumprimentos por resultados comerciais; =95 Felicita=E7=F5es pessoais; =95 P=EAsames; =95 Votos de boas festas=20 Voltar ao topo =20 http://www.gueb.de/cartascomerciais CARTAS DE RECLAMA=C7=C3O Cartas Comerciais =95 Reclama=E7=E3o de compra de produto; =95 Reclama=E7=E3o por atraso; =95 Reclama=E7=E3o por aumento de pre=E7o; =95 Reclama=E7=E3o por defici=EAncia t=E9cnica; =95 Reclama=E7=E3o por demora na entrega; =95 Reclama=E7=E3o por diverg=EAncia; =95 Respostas a reclama=E7=F5es; Voltar ao topo COMUNICADOS E AVISOS =95 Advert=EAncia a funcion=E1rio; =95 Aviso de aumento de pre=E7os; =95 Aviso de incorpora=E7=E3o da empresa; =95 Aviso de lan=E7amento de produto e servi=E7o; =95 Aviso de mudan=E7a de endere=E7o; =95 Aviso de ocorr=EAncia de acidente; =95 Aviso de t=E9rmino de contrato; =95 Aviso gen=E9rico; =95 Comunica=E7=E3o de atraso no envio de mercadorias; =95 Comunica=E7=E3o de devolu=E7=E3o de duplicata; =95 Comunica=E7=E3o de devolu=E7=E3o de mercadoria; =95 Comunica=E7=E3o de envio de mercadorias; =95 Comunica=E7=E3o de envio de parte do pedido; =95 Comunica=E7=E3o de extravio de mercadorias; =95 Comunica=E7=E3o de f=E9rias coletivas; =95 Comunica=E7=E3o de liquida=E7=E3o de d=E9bito; =95 Comunica=E7=E3o de novo servi=E7o de televendas; =95 Comunica=E7=E3o de reuni=E3o; =95 Confirma=E7=E3o de pedido; =95 Resposta ao comunicado de reuni=E3o;=20 Voltar ao topo Cartas Comerciais http://www.gueb.de/cartascomerciais EMPREGO =95 Aviso pr=E9vio de dispensa de empregado: 1, 2, e 3; =95 Carta de recomenda=E7=E3o; =95 Pedido de demiss=E3o: 1 e 2; =95 Solicita=E7=E3o de emprego: 1, 2 e 3; =95 Solicita=E7=E3o de est=E1gio;=20 Voltar ao topo Cartas Comerciais ATESTADOS E DECLARA=C7=D5ES =95 Atestado de bons antecedentes; =95 Atestado m=E9dico; =95 Declara=E7=E3o negativa de v=EDnculo empregat=EDcio; =95 Declara=E7=E3o para cancelamento de protesto; =95 Declara=E7=E3o para fins escolares; Voltar ao topo Cartas Comerciais CARTAS DE COBRAN=C7A =95 Cartas de cobran=E7a: 1, 2, 3, 4, 5, 6, 7 e 8; =95 Encaminhamento de cobran=E7a a protesto; =95 Oferecimento de servi=E7o de cobran=E7a; =95 Recebimento de d=E9bito pendente; Voltar ao topo CARTAS EM INGL=CAS Cartas Comerciais =95 Cancelamento de pedido; =95 Carta de demiss=E3o; =95 Carta de refer=EAncia; =95 Curriculum vitae; =95 Pedido de produto: 1 e 2; =95 Reclama=E7=E3o de assinatura de publica=E7=E3o; =95 Remessa de valores; =95 Resposta a pedido de produto; =95 Resposta a solicita=E7=E3o de emprego; =95 Resposta a solicita=E7=E3o de informa=E7=F5es; =95 Resposta a solicita=E7=E3o de pre=E7os; =95 Solicita=E7=E3o de emprego; =95 Solicita=E7=E3o de informa=E7=F5es comerciais; =95 Solicita=E7=E3o de licen=E7a; =95 Solicita=E7=E3o de pre=E7os;=20 Voltar ao topo Cartas Comerciais CONVITES http://www.gueb.de/cartascomerciais =95 Convite para batizado; =95 Convite para evento social; =95 Convite para exposi=E7=E3o ou feira; =95 Convite para lan=E7amento de produto; =95 Resposta negativa a convite; =95 Resposta positiva a convite;=20 Voltar ao topo DOCUMENTOS =95 Ata; =95 Contrato de loca=E7=E3o de im=F3vel; =95 Contrato firmado acordo; =95 Contrato social; =95 Edital de convoca=E7=E3o; =95 Procura=E7=E3o; =95 Recibo de venda de autom=F3vel;=20 Voltar ao topo PROPOSTAS =95 Proposta de abertura de conta corrente; =95 Proposta de presta=E7=E3o de servi=E7os: 1 e 2; =95 Proposta de representa=E7=E3o comercial: 1 e 2; =95 Proposta para ocupa=E7=E3o de cargo; =95 Proposta para recupera=E7=E3o de clientes; =95 Resposta negativa =E0 proposta de representa=E7=E3o: 1 e 2; =95 Resposta positiva =E0 proposta de representa=E7=E3o: 1 e 2;=20 Voltar ao topo http://www.gueb.de/cartascomerciais SOLICITA=C7=D5E E PEDIDOS =95 Pedido de desculpas; =95 Pedido de mercadorias; =95 Resposta a pedido de carta de apresenta=E7=E3o; =95 Resposta a solicita=E7=E3o de c=F3pias de documentos; =95 Resposta a solicita=E7=E3o de or=E7amento; =95 Resposta negativa a solicita=E7=E3o de informa=E7=F5es comerciais; Cartas Comerciais =95 Resposta positiva a solicita=E7=E3o de informa=E7=F5es comerciais; =95 Solicita=E7=E3o de atestado de Idoneidade Financeira; =95 Solicita=E7=E3o de cat=E1logos de pre=E7os; =95 Solicita=E7=E3o de cr=E9dito; =95 Solicita=E7=E3o de informa=E7=F5es comerciais; =95 Solicita=E7=E3o de informa=E7=F5es sobre curso; =95 Solicita=E7=E3o de listas de pre=E7os; =95 Solicita=E7=F5es de refer=EAncias pessoais; =95 Suspens=E3o de pedido de mercadoria; Cartas Comerciais Voltar ao topo VIAGEM =95 Informa=E7=F5es sobre requisitos de viagem; =95 Pedido de reserva em hotel; =95 Recupera=E7=E3o de bagagem extraviada; =95 Reclama=E7=E3o de maus tratos =E0 bagagem; =95 Recupera=E7=E3o de objeto esquecido em hotel; =95 Reserva de passagens; =95 Roteiro tur=EDstico.=20 http://www.gueb.de/cartascomerciais From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Dec 27 20:34:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErQCq-0001ns-G8 for secsh-archive@megatron.ietf.org; Tue, 27 Dec 2005 20:34:20 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24597 for ; Tue, 27 Dec 2005 20:33:11 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id C671D63B3CB; Wed, 28 Dec 2005 01:34:15 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.netbsd.org (Postfix) with ESMTP id 287C263B3CA for ; Wed, 28 Dec 2005 01:34:15 +0000 (UTC) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 27 Dec 2005 17:34:15 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jBS1YEQg021796 for ; Tue, 27 Dec 2005 17:34:14 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: SFTP URI issues Date: Tue, 27 Dec 2005 17:40:24 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906679DC6@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: SFTP URI issues Thread-Index: AcYLTs6v2mpKlbc3TcOtRa/G2dFhVw== From: "Salowey, Joe" To: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Several issues have been raised in the past month over the SFTP URI.=20 Issue #1: On the IETF list several people expressed concern that the scheme name "sftp" might be confused with RFC 913 (Simple FTP) or RFC 2228/4217 (FTP security extensions using TLS). While I think 913 is historic and unlikely to cause confusion I believe there are implementations of TLS FTP around. I think there are probably many more implementations of sftp and many people would understand that SFTP is file transfer in SSH, but there is room for confusion. We could either note the confusion and keep sftp or select some other scheme name such as sshftp and reserve sftp so no other protocol uses it.=20 Issue #2: The current draft states that if you specify a URL that begins without a %2F (URL encoded /) it is relative to the home directory. Several people have suggested that this is awkward and they would rather see=20 A) A URL that beings without a %2f to be an absolute URL, and choose another delimiter such as ~ to indicate a path relative to the home directory. B) Allow / instead of %2F so sftp://joe@example.com/%2ffile becomes sftp://joe@example.com//file=20 I'm not sure B is legal URL encoding, but I think it may work. A seems like it would work.=20 Any Recommendations? Thanks, Joe From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Dec 28 00:27:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErTqO-0006q2-Gj for secsh-archive@megatron.ietf.org; Wed, 28 Dec 2005 00:27:24 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16437 for ; Wed, 28 Dec 2005 00:26:13 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 8252163B349; Wed, 28 Dec 2005 05:27:19 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 480A163B12C for ; Wed, 28 Dec 2005 05:27:18 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id AAA01621; Wed, 28 Dec 2005 00:27:17 -0500 (EST) From: der Mouse Message-Id: <200512280527.AAA01621@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Wed, 28 Dec 2005 00:17:34 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: X11 forwarding Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit I recognize it may be too late to get this into the upcoming RFCs - but if I don't mention it it definitely won't get in.... In an offlist email exchange about X11 forwarding, I realize there is an aspect of it which is unsaid in the drafts, but is important: existing server implementations use the "x11 authentication protocol" and "x11 authentication cookie" (which really are *authorization* values than *authentication* values, but never mind) values directly, rather than providing its own nonce authorization information for the session and replacing it with the values from the x11-req when forwarding connections. The reason I mention this now is that it is critical for security that client implementors understand this expectation, and there is nothing in the drafts even alluding to it. Indeed, I am astonished to hear that existing servers work this way, but I consider my correspondent competent to report their behaviour accurately. Until I was told this, I had no idea server implementers were that crazy - for, yes, I do consider it crazy; quite aside from the security aspects of it, it means that the *client* must know what authorization-protocol-name and authorization-protocol-data (to give them their X names) are appropriate on the *server*'s system. I assume it is too late to fix the semantics. But is it too late to get a note added warning implementors of this? /~\ 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 bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Dec 28 07:27:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EraPC-0005Ho-ML for secsh-archive@megatron.ietf.org; Wed, 28 Dec 2005 07:27:47 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00913 for ; Wed, 28 Dec 2005 07:26:34 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 274D463B43A; Wed, 28 Dec 2005 12:27:41 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from astro.systems.pipex.net (astro.systems.pipex.net [62.241.163.6]) by mail.netbsd.org (Postfix) with ESMTP id 223DA63B42D for ; Wed, 28 Dec 2005 12:27:40 +0000 (UTC) Received: from pc6 (1Cust10.tnt102.lnd4.gbr.da.uu.net [213.116.52.10]) by astro.systems.pipex.net (Postfix) with SMTP id D6512E000160; Wed, 28 Dec 2005 12:02:15 +0000 (GMT) Message-ID: <00cf01c60b9d$ca4183a0$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Salowey, Joe" , References: <7210B31550AC934A8637D6619739CE6906679DC6@e2k-sea-xch2.sea-alpha.cisco.com> Subject: Re: SFTP URI issues Date: Wed, 28 Dec 2005 11:55:00 +0100 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Salowey, Joe" To: Sent: Wednesday, December 28, 2005 2:40 AM Subject: SFTP URI issues > Several issues have been raised in the past month over the SFTP URI. > > Issue #1: On the IETF list several people expressed concern that the > scheme name "sftp" might be confused with RFC 913 (Simple FTP) or RFC > 2228/4217 (FTP security extensions using TLS). While I think 913 is > historic and unlikely to cause confusion I believe there are > implementations of TLS FTP around. I think there are probably many more > implementations of sftp and many people would understand that SFTP is > file transfer in SSH, but there is room for confusion. We could either > note the confusion and keep sftp or select some other scheme name such > as sshftp and reserve sftp so no other protocol uses it. Choose another one! ideally one starting with ftp like ftps or ftpssh; for me it is the ftp that matters most, with ssh being subsidiary to that (in an ssh WG, it it tempting but I think misleading to put it the other way round:-) > > Issue #2: The current draft states that if you specify a URL that begins > without a %2F (URL encoded /) it is relative to the home directory. > Several people have suggested that this is awkward and they would rather > see > > A) A URL that beings without a %2f to be an absolute URL, and choose > another delimiter such as ~ to indicate a path relative to the home > directory. > > B) Allow / instead of %2F so sftp://joe@example.com/%2ffile becomes > sftp://joe@example.com//file > > I'm not sure B is legal URL encoding, but I think it may work. A seems > like it would work. > Legal URI since authority is always present (according to the syntax) and it falls under the path-abempty construct of RFC3986, as opposed to the path-absolute which begins with a single such character. But I would go for another character to indicate a relative path; solidus has so many different uses in different contexts. And I would change URL to URI throughout the I-D. > Any Recommendations? Gosh, shades of ITU-T:-) Tom Petch > > Thanks, > > Joe From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Dec 28 09:16:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erc6Y-0001yf-St for secsh-archive@megatron.ietf.org; Wed, 28 Dec 2005 09:16:39 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11185 for ; Wed, 28 Dec 2005 09:15:27 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id E847C63B16D; Wed, 28 Dec 2005 14:16:33 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from astro.systems.pipex.net (astro.systems.pipex.net [62.241.163.6]) by mail.netbsd.org (Postfix) with ESMTP id E7AEF63B13F for ; Wed, 28 Dec 2005 14:16:32 +0000 (UTC) Received: from pc6 (1Cust27.tnt30.lnd3.gbr.da.uu.net [62.188.122.27]) by astro.systems.pipex.net (Postfix) with SMTP id E4951E000186; Wed, 28 Dec 2005 14:16:29 +0000 (GMT) Message-ID: <01c701c60bb0$8b138620$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Salowey, Joe" , References: <7210B31550AC934A8637D6619739CE6906679DC6@e2k-sea-xch2.sea-alpha.cisco.com> Subject: presence of authority was Re: SFTP URI issues Date: Wed, 28 Dec 2005 12:37:08 +0100 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Mmmm I should have added to my previous reply that I never find RFC3986 easy to understand, perhaps because it is not easy to understand:-( In RFC3986 is the following hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty which means authority path-abempty OR path-absolute OR path-rootless OR path-empty while the I-D has hier-part = "//" authority ( path-empty / path-abempty ) which means authority path-empty OR authority path-abempty Is this change intended? Tom Petch ----- Original Message ----- From: "Salowey, Joe" To: Sent: Wednesday, December 28, 2005 2:40 AM Subject: SFTP URI issues > Several issues have been raised in the past month over the SFTP URI. > > Issue #1: On the IETF list several people expressed concern that the > scheme name "sftp" might be confused with RFC 913 (Simple FTP) or RFC > 2228/4217 (FTP security extensions using TLS). While I think 913 is > historic and unlikely to cause confusion I believe there are > implementations of TLS FTP around. I think there are probably many more > implementations of sftp and many people would understand that SFTP is > file transfer in SSH, but there is room for confusion. We could either > note the confusion and keep sftp or select some other scheme name such > as sshftp and reserve sftp so no other protocol uses it. > > Issue #2: The current draft states that if you specify a URL that begins > without a %2F (URL encoded /) it is relative to the home directory. > Several people have suggested that this is awkward and they would rather > see > > A) A URL that beings without a %2f to be an absolute URL, and choose > another delimiter such as ~ to indicate a path relative to the home > directory. > > B) Allow / instead of %2F so sftp://joe@example.com/%2ffile becomes > sftp://joe@example.com//file > > I'm not sure B is legal URL encoding, but I think it may work. A seems > like it would work. > > Any Recommendations? > > Thanks, > > Joe From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Dec 28 15:19:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErhlQ-0002FA-Fh for secsh-archive@megatron.ietf.org; Wed, 28 Dec 2005 15:19:12 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04783 for ; Wed, 28 Dec 2005 15:18:02 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 614BA63B4A8; Wed, 28 Dec 2005 20:18:57 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.netbsd.org (Postfix) with ESMTP id 8419A63B109 for ; Wed, 28 Dec 2005 20:18:56 +0000 (UTC) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 28 Dec 2005 12:18:56 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jBSKItYW004455; Wed, 28 Dec 2005 12:18:56 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: presence of authority was Re: SFTP URI issues Date: Wed, 28 Dec 2005 12:25:05 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906679E88@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: presence of authority was Re: SFTP URI issues Thread-Index: AcYL0I1FZ90Cz2kpTNOaGYgaEb5FvgAGoyPg From: "Salowey, Joe" To: "Tom Petch" , Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable This ABNF is for the SSH URI which should not contain a non-empty path. The deviation from the 3986 path was intended to describe this. I think the change is correct, but I could have missed something. The "sftp" URI uses the path description from 3986.=20 > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > Sent: Wednesday, December 28, 2005 3:37 AM > To: Salowey, Joe; ietf-ssh@NetBSD.org > Subject: presence of authority was Re: SFTP URI issues >=20 > Mmmm >=20 > I should have added to my previous reply that I never find=20 > RFC3986 easy to > understand, perhaps because it is not easy to understand:-( >=20 > In RFC3986 is the following > hier-part =3D "//" authority path-abempty > / path-absolute > / path-rootless > / path-empty > which means > authority path-abempty OR > path-absolute OR > path-rootless OR > path-empty > while the I-D has > hier-part =3D "//" authority ( path-empty / path-abempty ) > which means > authority path-empty OR > authority path-abempty > Is this change intended? >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Salowey, Joe" > To: > Sent: Wednesday, December 28, 2005 2:40 AM > Subject: SFTP URI issues >=20 >=20 > > Several issues have been raised in the past month over the SFTP URI. > > > > Issue #1: On the IETF list several people expressed concern that the > > scheme name "sftp" might be confused with RFC 913 (Simple=20 > FTP) or RFC > > 2228/4217 (FTP security extensions using TLS). While I think 913 is > > historic and unlikely to cause confusion I believe there are > > implementations of TLS FTP around. I think there are=20 > probably many more > > implementations of sftp and many people would understand=20 > that SFTP is > > file transfer in SSH, but there is room for confusion. We=20 > could either > > note the confusion and keep sftp or select some other=20 > scheme name such > > as sshftp and reserve sftp so no other protocol uses it. > > > > Issue #2: The current draft states that if you specify a=20 > URL that begins > > without a %2F (URL encoded /) it is relative to the home directory. > > Several people have suggested that this is awkward and they=20 > would rather > > see > > > > A) A URL that beings without a %2f to be an absolute URL, and choose > > another delimiter such as ~ to indicate a path relative to the home > > directory. > > > > B) Allow / instead of %2F so sftp://joe@example.com/%2ffile becomes > > sftp://joe@example.com//file > > > > I'm not sure B is legal URL encoding, but I think it may=20 > work. A seems > > like it would work. > > > > Any Recommendations? > > > > Thanks, > > > > Joe >=20 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Dec 28 16:05:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EriTk-0007ib-Kx for secsh-archive@megatron.ietf.org; Wed, 28 Dec 2005 16:05:00 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14272 for ; Wed, 28 Dec 2005 16:03:49 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 425BA63B26D; Wed, 28 Dec 2005 21:04:56 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id 0E76C63B130 for ; Wed, 28 Dec 2005 21:04:54 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa25981; 28 Dec 2005 16:04 EST Date: Wed, 28 Dec 2005 16:04:42 -0500 From: Jeffrey Hutzelman To: Tom Petch , "Salowey, Joe" , ietf-ssh@NetBSD.org Subject: Re: SFTP URI issues Message-ID: <40AA56AE9FB3B6468AE33C92@sirius.fac.cs.cmu.edu> In-Reply-To: <00cf01c60b9d$ca4183a0$0601a8c0@pc6> References: <7210B31550AC934A8637D6619739CE6906679DC6@e2k-sea-xch2.sea-alpha. cisco.com> <00cf01c60b9d$ca4183a0$0601a8c0@pc6> Originator-Info: login-token=Mulberry:016pVqCFT933w24OKJHROad4EHoTNxyeNXCphtIBU=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Wednesday, December 28, 2005 11:55:00 AM +0100 Tom Petch wrote: > ----- Original Message ----- > From: "Salowey, Joe" > To: > Sent: Wednesday, December 28, 2005 2:40 AM > Subject: SFTP URI issues > > >> Several issues have been raised in the past month over the SFTP URI. >> >> Issue #1: On the IETF list several people expressed concern that the >> scheme name "sftp" might be confused with RFC 913 (Simple FTP) or RFC >> 2228/4217 (FTP security extensions using TLS). While I think 913 is >> historic and unlikely to cause confusion I believe there are >> implementations of TLS FTP around. I think there are probably many more >> implementations of sftp and many people would understand that SFTP is >> file transfer in SSH, but there is room for confusion. We could either >> note the confusion and keep sftp or select some other scheme name such >> as sshftp and reserve sftp so no other protocol uses it. > > Choose another one! ideally one starting with ftp like ftps or ftpssh; > for me it is the ftp that matters most, with ssh being subsidiary to that > (in an ssh WG, it it tempting but I think misleading to put it the other > way round:-) The widely adopted convention for naming "protocol X over TLS" is to append an "s" to the name of protocol X (https, imaps, etc). Using that name for this protocol would be highly misleading. Second, it is worth noting that this protocol is _not_ FTP over SSH; it is the "SSH File Transfer Protocol", so named because it was originally intended to be carried over SSH, though I don't believe there is anything which prevents its use over other stream-oriented transports. You could begin calling the protocol "SSHFTP" instead of "SFTP", but I think that's likely to cause more confusion than does the conflict with RFC913, not to mention being harder to say. Calling the protocol "FTPSSH" or "FTPS" would be wrong; those aren't abbreviations for the name of the protocol, and are likely to confuse people into thinking you're talking about FTP-over-SSH or FTP-over-TLS, and this is neither. Using either of those as URI keywords would have exactly the same problem. Personally, I think as long as people refer to the protocol as "SFTP", the SSH subsystem name used by the protocol is "sftp", and multiple implementations call their client "sftp", it would be silly and confusing to use any other name in the construction of a URI scheme. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Dec 29 06:29:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErvyI-0005zT-7Q for secsh-archive@megatron.ietf.org; Thu, 29 Dec 2005 06:29:26 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10063 for ; Thu, 29 Dec 2005 06:28:14 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 118D363B35D; Thu, 29 Dec 2005 11:29:21 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from astro.systems.pipex.net (astro.systems.pipex.net [62.241.163.6]) by mail.netbsd.org (Postfix) with ESMTP id 0282D63B11F for ; Thu, 29 Dec 2005 11:29:19 +0000 (UTC) Received: from pc6 (1Cust165.tnt102.lnd4.gbr.da.uu.net [213.116.52.165]) by astro.systems.pipex.net (Postfix) with SMTP id 7677AE00015C; Thu, 29 Dec 2005 11:29:16 +0000 (GMT) Message-ID: <015901c60c62$58eb9400$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Salowey, Joe" , References: <7210B31550AC934A8637D6619739CE6906679E88@e2k-sea-xch2.sea-alpha.cisco.com> Subject: Re: presence of authority was Re: SFTP URI issues Date: Thu, 29 Dec 2005 11:20:03 +0100 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Salowey, Joe" To: "Tom Petch" ; Sent: Wednesday, December 28, 2005 9:25 PM Subject: RE: presence of authority was Re: SFTP URI issues > This ABNF is for the SSH URI which should not contain a non-empty path. > The deviation from the 3986 path was intended to describe this. I think > the change is correct, but I could have missed something. The "sftp" URI > uses the path description from 3986. > Yes, understood. I am being opaque:-( I was obliquely referring to the addition of brackets in the SSH URI which, I believe, changes the meaning from RFC3986 to mean that the ssh ABNF requires authority always to be present whereas the URI ABNF only requires authority to be present for path-abempty, not for the other variants of path. So when the ABNF for the SFTP URI says it uses the path definition from RFC3986, I am unclear what position it takes on authority, always present or not. There is, I think, a defect in RFC3986 here, in that path-abempty, which is allowed to start // (two solidus), is only permitted to be used when authority is present - else the // that precedes authority could be confused with the // that starts the path-abempty. Where RFC3986 could be defective is that authority is defined as, being selective, authority = host host = reg-name reg-name = *( unreserved / pct-encoded / sub-delims ) which allows authority to be zero characters, in which case the // can get confused with // :-) So, you asked if it was ok to start a path with // - my reading of RFC3986 is that that is what it intends to say but does not quite do so ie it is ok as long as authority is present and is not zero length. If the last is what the ABNF for the SFTP URI., or for the SSH URI, intends to say, then I think this should be spelt out; but I am not clear what you are intending to say:-( Tom Petch > > -----Original Message----- > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > Sent: Wednesday, December 28, 2005 3:37 AM > > To: Salowey, Joe; ietf-ssh@NetBSD.org > > Subject: presence of authority was Re: SFTP URI issues > > > > Mmmm > > > > I should have added to my previous reply that I never find > > RFC3986 easy to > > understand, perhaps because it is not easy to understand:-( > > > > In RFC3986 is the following > > hier-part = "//" authority path-abempty > > / path-absolute > > / path-rootless > > / path-empty > > which means > > authority path-abempty OR > > path-absolute OR > > path-rootless OR > > path-empty > > while the I-D has > > hier-part = "//" authority ( path-empty / path-abempty ) > > which means > > authority path-empty OR > > authority path-abempty > > Is this change intended? > > > > Tom Petch > > > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Dec 31 11:28:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsjaP-0001CS-No for secsh-archive@megatron.ietf.org; Sat, 31 Dec 2005 11:28:06 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26019 for ; Sat, 31 Dec 2005 11:26:51 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id D0EFE63B2CF; Sat, 31 Dec 2005 16:28:00 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.metronet.co.uk (mail.metronet.co.uk [213.162.97.75]) by mail.netbsd.org (Postfix) with ESMTP id 24B3A63B1AA for ; Sat, 31 Dec 2005 16:28:00 +0000 (UTC) Received: from riva.pelham.vpn.ucam.org (83-216-156-196.colinw664.adsl.metronet.co.uk [83.216.156.196]) by smtp.metronet.co.uk (MetroNet Mail) with ESMTP id 05EC44102BB; Sat, 31 Dec 2005 16:05:49 +0000 (GMT) Received: from cjwatson by riva.pelham.vpn.ucam.org with local (Exim 3.36 #1 (Debian)) id 1EsjF1-00057I-00; Sat, 31 Dec 2005 16:05:59 +0000 Date: Sat, 31 Dec 2005 16:05:59 +0000 From: Colin Watson To: ietf-ssh@NetBSD.org Cc: Vincent Lefevre , 337041@bugs.debian.org Subject: IUTF8 pseudo-terminal mode Message-ID: <20051231160559.GK4231@riva.ucam.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Recent versions of the Linux kernel support an IUTF8 flag (see http://www.cl.cam.ac.uk/~mgk25/unicode.html#mod) which allows the character-erase function in cooked mode to handle UTF-8 characters correctly. I would like to allow this mode to be preserved by SSH, but there is no assignment for it at present. Could this line be added to the appropriate place in draft-ietf-secsh-connect and draft-ietf-secsh-assignednumbers to create this assignment? 42 seems like a reasonable place for it. 42 IUTF8 Assume input characters are UTF-8 encoded. Thanks, -- Colin Watson [cjwatson@debian.org]